DirectAccess Configuration Load Error

I was implementing a DirectAccess solution at a customer using Windows 2012 R2 and Windows 8.1

Everything went fine with installation and configuration and I was looking forward to testing it. But after everything was done I opened the Remote Access Management Console only to be met by an error stating “Configuration Load Error. Settings for server <servername> cannot be retrieved. The system cannot find the file specified.” as seen below:
DirectAccess post install error 2Re-applying the settings from the DirectAccess server GPO did not resolve the issue and since I was unable to find any documentation stating which files are being used in the DirectAccess configuration I decided to start again.

I therefore deleted the GPO’s, and ran a GPUPDATE on the server. The wizard then detected that the GPO settings¬†was no longer present and gave me the option of clearing the configuration on the server.

After this I was able to run the configuration wizard once more and this time it worked…

Un-installing Exchange 2013 server fails with “Setup can’t continue with the uninstall because the eseutil has open files”

So, I was at a customer uninstalling an Exchange 2013 server as the customer had finished their migration to Office 365.

Went through the usual process of decommissioning the server, such as ensuring no mailboxes where left, removing arbitration boxes and so on.
Got to the point where the actual uninstall could take place, and was faced with this:

E2K13 eseutil uninstall error

Thought to myself, that was kinda weird… Looking in Task Manager showed that ESEUTIL has a lot of processes running:

E2K13 eseutil task manager

Well, since all data had been migrated away from the server and all databases had been removed I didn’t see much point in finding out why all these ESEUTIL processes where spawned.

A simple reboot later, and the uninstall procedure continued without any problems.

Max Concurrent API reached alert in SCOM 2012…

Over the last couple of months I’ve implemented a couple of Operations Manager solutions at customers where they all use the Windows Server Management Pack version 6.0.7026.0
This management pack includes a new monitor where it monitors how many secure channels are created to a domain controller when authenticating users using NTLM pass-through.

In Windows 2008 and R2 the monitor can however create false positives, which can make this monitor quite noisy. This is a confirmed bug in this version of the management pack which can be seen here at Kevin Holmans Technet blog here.

First off, you need to ascertain whether this is an actual issue on the server in question or if it’s a false positive. To do this you need to monitor the performance counters for NETLOGON.
The default values to expect are as follows:

  • Windows Server, pre-Windows 2012: 2 concurrent threads
  • Windows Server 2012: 10
  • Windows client: 1
  • Domain controllers, pre-Windows-2012: 1
  • Domain controllers, Windows-2012: 10

If you do not bump against these values, then you are most likely struck by above mentioned bug and could turn off the monitor if you don’t want it to be noisy. If you decide to do this, then remember to check whether this problem is resolved in an upcoming update and delete the overrides.

If you however bump against these values, then you can increase it by editing this registry value:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaxConcurrentApi

The maximum value is however 150, which Windows Server 2012 and beyond already has set at the default value. In that case you would consider scaling out unless you are willing to accept the user experience degradation of slower validation and possibly additional validation prompts.