ADFS 3.0 Error: The Web request failed because the web.config file is malformed

Had a strange one today after an Azure outage. One of my Server 2012 R2 ADFS proxies wouldn’t start the ADFS service.

When looking in the logs, it appeared like a case of simply having to re-establish the proxy trust, but I got a different error when trying to start the service:

The federation server proxy could not be started.
Reason: Error retrieving proxy configuration from the Federation Service.

Additional Data
Exception details:
An error occurred when attempting to load the proxy configuration.

There were other errors in the ADFS Event logs about a malformed config file:

The Web request failed because the web.config file is malformed.

User Action:
Fix the malformed data in the web.config file.

Exception details:
Root element is missing. (C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config)
Root element is missing.

When I opened the abovementioned config file, it was empty. I compared this to the config file on the other ADFS proxy, and that one looked like a normal config file.

My solution, and what ended up fixing the issue in the end, was simply to copy the contents of the .config file from the working ADFS proxy to the broken one. I could then re-establish the proxy trust, and everything started running again.

I’m not sure if this would work, but in case you don’t have another ADFS proxy to grab the config file from, here’s a sanitised version of mine:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="microsoft.identityServer.proxyservice" type="Microsoft.IdentityServer.Management.Proxy.Configuration.ProxyConfiguration, Microsoft.IdentityServer.Management.Proxy, Version=6.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
</configSections>
<microsoft.identityServer.proxyservice>
<congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64"
enabled="true" />
<connectionPool connectionPoolSize="200" scavengeInterval="5" />
<diagnostics eventLogLevel="15" />
<host tlsClientPort="49443" httpPort="80" httpsPort="443" name="adfs.example.com" />
<proxy address="" />
<trust thumbprint="FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
proxyTrustRenewPeriod="21600" />
</microsoft.identityServer.proxyservice>
<!-- <system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage="true"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="true">
</messageLogging>
</diagnostics>
</system.serviceModel> -->
</configuration>

Once I’d resolved the problem, I did a bit of searching around for this error message, and it appears that other people have had the same problem previously, with no resolution listed in the one thread that I looked at on the TechNet forums.

Script to create new local admin account for use with LAPS

I’ve got a bunch of older SOE machines that still had the local Administrator account enabled. As part of implementing Microsoft LAPS, I wanted to disable that account, and use a newly-created ‘LocalAdmin’ account with LAPS.

The account is created with a randomly-generated GUID as the password. The account’s password is going to come under the management of LAPS anyway. Additionally, it would be a terrible idea to hard-code a password into a script that’s stored in Sysvol.

If an account with that name already exists, the script will quit. Some basic events are also logged to the Event Log to indicate what happened.

My first revision of the script used ADSI to create the account and add it to the Administrators group, but I found that my mileage varied with that method. Some computers had the account created, but it wasn’t a member of Administrators.

It’s now set up to use plain “NET USER” and “NET LOCALGROUP” commands. This is an example of what would be executed:
2016-04-04 16_01_06

This script is designed to be set up as a computer Startup Script:

PowerShell: Finding folders that don’t match a pattern

This week I came across an issue where some folders didn’t match a naming convention that was required by another third-party system. Because of this, data wasn’t being extracted from all of the incorrectly-named folders.

The naming convention in question goes like this: “{whatever} {4-digit-number}”. Lots of folders were missing the relevant number at the end.

To quickly identify which folders were wrongly-named, I used a regex that searches the end of a string for a space followed by four numbers. I then used that in conjunction with Where-Object:

Get-ChildItem -Path | Where-Object {$_.Name -notmatch " d{4}$"}

Then, so that I could identify who was naming new folders incorrectly, I then did this:

Get-ChildItem -Path  | Where-Object {$_.Name -notmatch " d{4}$"} | Select-Object -Property Name,CreationTime,@{Name="Owner";Expression={(Get-Owner $_.FullName).Owner.AccountName}}

I then piped the above command to Sort-Object, and exported the lot to a CSV file for the department in question to review:

Get-ChildItem -Path  | Where-Object {$_.Name -notmatch " d{4}$"} | Select-Object -Property Name,CreationTime,@{Name="Owner";Expression={(Get-Owner $_.FullName).Owner.AccountName}}| Sort-Object CreationTime -Descending | Export-Csv c:tempinsolfolder.csv -NoTypeInformation

In all, a quick, easy, and repeatable way of getting a report out to the people who need to maintain the folder structure. It’s possible to extend it further to just email the owners of each of the non-compliant folders on a set schedule.

Delete old log files with PowerShell

Today I came across a folder full of log files created by an import/integration application on one of our servers. The folder contained over 50,000 files. Rather than manually delete the old logs, here’s how I removed all items older than 1 month:

Get-ChildItem "C:Path_To_logs*.txt" | Where-Object {$_.CreationTime -lt (Get-Date).AddMonths(-1)} | Remove-Item -Force -Verbose -WhatIf

Since PowerShell is based on the .NET Framework, you can use standard System.DateTime methods when working with dates and times.

PS C:> Get-Date | Get-Member Add*


   TypeName: System.DateTime

Name            MemberType Definition
----            ---------- ----------
Add             Method     datetime Add(timespan value)
AddDays         Method     datetime AddDays(double value)
AddHours        Method     datetime AddHours(double value)
AddMilliseconds Method     datetime AddMilliseconds(double value)
AddMinutes      Method     datetime AddMinutes(double value)
AddMonths       Method     datetime AddMonths(int months)
AddSeconds      Method     datetime AddSeconds(double value)
AddTicks        Method     datetime AddTicks(long value)
AddYears        Method     datetime AddYears(int value)

Passing a negative value to one of the Add* methods will result in subtracting that amount of time:

PS C:> Get-Date
Wednesday, 12 August 2015 2:37:23 PM

PS C:> (Get-Date).AddMonths(1)
Saturday, 12 September 2015 2:37:37 PM

PS C:> (Get-Date).AddMonths(-1)
Sunday, 12 July 2015 2:37:40 PM

Obviously you need to be very careful with specifying a path to a command like Remove-Item. I’ve left the -WhatIf switch on the example code above.

It’s easy to add something like this to a scheduled task to keep a log folder tidy.

Simple IP Range Scan using PowerShell

I had to jump on a bunch of remote servers today that are largely unmanaged by my department.

Since it was the first time I’d needed to deal with this job, and there was no prior documentation, I needed to run a basic discovery process to see which machines were on the network. In lieu of finding, downloading, and installing an IP scan tool, I decided to give it a go using PowerShell 2.0, which is what was installed on these servers.

The network range to be scanned was a simple 192.168.0.0/24, so what I tried first was this:

1..254 | ForEach-Object {Test-Connection -ComputerName "192.168.0.$_" -Count 1 -ErrorAction SilentlyContinue}

This will at least tell me which IPs are alive, but it won’t resolve those IPs to hostnames. I discovered that several other people had the same gripe as me.

Since Test-Connection uses WMI under the covers, I decided to give the WMI-based solution a go. A bit of tweaking, and it resulted in what I needed.

Here’s the code, a classic PowerShell one-liner:

1..254 | ForEach-Object {Get-WmiObject Win32_PingStatus -Filter "Address='192.168.0.$_' and Timeout=200 and ResolveAddressNames='true' and StatusCode=0" | select ProtocolAddress*}

And here’s what it outputs:

image

More Information – MSDN: Win32_PingStatus