Site icon TheWindowsUpdate.com

Active Directory Web Services Event 1202

This post has been republished via RSS; it originally appeared at: Ask the Directory Services Team articles.

Hey there! Josh Mora here, with a brief post on an issue I recently had and wanted to make public, in hopes this will help those that run into this issue, and in addition, provide some helpful logging information that can be useful for any ADWS issues you might come across.

 

Scenario:

So, the issue I want to talk to you about: You have an AD LDS server, on which you are running ADWS, and you are constantly, minute after minute after minute, getting Event 1202 in the ADWS events with the following information:

 

 

 

Log Name:      Active Directory Web Services Source:        ADWS Date:          5/05/2020 1:30:00 PM Event ID:      1202 Task Category: ADWS Instance Events Level:         Error Keywords:      Classic User:          N/A Computer:      LDS01.Contoso.com Description: This computer is now hosting the specified directory instance, but Active Directory Web Services could not service it. Active Directory Web Services will retry this operation periodically. Directory instance: ADAM_INSTANCE Directory instance LDAP port: 389 Directory instance SSL port: 636

 

 

 

Now, this might not even be disrupting your services, everything may continue to work properly. However, this excessive logging of 1202 events can become annoying, and even troubling, since it very well could be indicating issues that you aren’t even aware of. So, let’s jump straight into how we can find the cause of this, and how we resolve it.

 

ADWS Debug Logging:

In this situation, I used the built-in functionality of ADWS Debug Logging. Enabling the debug logging consists in modifying the “Microsoft.ActiveDirectory.WebServices.exe.config” file, a file you can modify with different configuration parameters in order to achieve some extra functionality out of ADWS, information which is explained in this Microsoft Documentation. Unfortunately, that documentation doesn’t go over the parameters for enabling the Debug Logging, hence why I am posting this.

 

Checking ADWS Configuration Information:

Special thanks to Jason Bender, who put these two commands together that conveniently provide the configuration information from the ADWS Config file.

 

  1. In a PowerShell window, run the following: [xml]$ADWSConfiguration = get-content -path c:\windows\adws\microsoft.activedirectory.webservices.exe.config
  2. Then, run: $ADWSConfiguration.configuration.appsettings.add
  3. You should get an output like this:
 

 

 

Enabling ADWS Debug Logging:

 

  1. Navigate to ‘C:\Windows\ADWS’. The file we are looking to modify is “Microsoft.ActiveDirectory.WebServices.Exe.Config”.

 

  1. Now, before making any changes, I strongly suggest to take a backup of the “Microsoft.ActiveDirectory.WebServices.Exe.Config” file. You can never be too safe!

 

  1. Right-click the file “Microsoft.ActiveDirectory.WebServices.Exe.Config”, then Open with, and select Notepad, or any other text editor. Right under <appSettings>, enter the following two lines:

 

<add key="DebugLevel" value="Info"/>

<add key="DebugLogFile" value="C:\Windows\Debug\ADWSlog.txt"/>

 

This Config file does not tolerate the smallest mistake, so make sure you do not have any typos or extra spaces.

 

 

  1. Once the file has been modified, save the file and then restart the ADWS service for the changes to take effect.

 

  1. You can then run the PowerShell commands and should now be able to see the DebugLevel and DebugLogFile set.

 

Information to keep in mind:

 

Analyzing the ADWS Debug Log file:

To clarify, this blog is not a guide on overall analysis of the ADWS Debug Log file, but more focused on the issue at hand, the excessive 1202 events, so that’s what I will be addressing.

 

The first we see, is the ScavengerThread waking up and begin looking for Instances:

 

LdapSessionPoolImplementation: [05/05/2020 1:29:40 PM] [8] ScavengerThread: woke up

LdapSessionPoolImplementation: [05/05/2020 1:29:40 PM] [8] ScavengerThread: processing next pool

ConnectionPool: [05/05/2020 1:29:40 PM] [8] GetReservationEnumerator: entering, instance=NTDS

LdapSessionPoolImplementation: [05/05/2020 1:29:40 PM] [8] ScavengerThread: processing next pool

ConnectionPool: [05/05/2020 1:29:40 PM] [8] GetReservationEnumerator: entering, instance=ADAM_INSTANCE

LdapSessionPoolImplementation: [05/05/2020 1:29:40 PM] [8] Scavenger: waking up at 00:00:40 interval

EnumerationContextCache: [05/05/2020 1:30:00 PM] [b] OnTimedEvent: got an event

EnumerationContextCache: [05/05/2020 1:30:00 PM] [b] RemoveExpiredEntries called

EnumerationContextCache: [05/05/2020 1:30:00 PM] [b] RemoveExpiredEntries -- found 0 entries to remove

EnumerationContextCache: [05/05/2020 1:30:00 PM] [b] RemoveExpiredEntries done

 

Next, we see ADWS checking registry keys for NTDS, in order to determine if this Instance is actually servicing:

 

InstanceMap: [05/05/2020 1:31:00 PM] [d] CheckAndLoadNTDSInstance: entered

InstanceMap: [05/05/2020 1:31:00 PM] [d] CheckAndLoadNTDSInstance: found NTDS Parameters key

 

At this point, ADWS has found that there is an NTDS Parameter registry key (which would contain all the NTDS settings), and due to the presence of this key, ADWS believes this is a Domain Controller providing ADDS services.

So, now ADWS checks to see if we are indeed meeting basic requirements for providing ADDS services, more specifically if the server is providing Global Catalog services:

 

InstanceMap: [05/05/2020 1:31:00 PM] [d] CheckAndLoadGCInstance: entered

InstanceMap: [05/05/2020 1:31:00 PM] [d] CheckForGlobalCatalog: entered

DirectoryUtilities: [05/05/2020 1:31:00 PM] [d] GetTimeRemaining: remaining time is 00:02:00

InstanceMap: [05/05/2020 1:31:01 PM] [d] CheckForGlobalCatalog: isGlobalCatalogReady:

InstanceMap: [05/05/2020 1:31:01 PM] [d] GlobalCatalog is not ready to service the requests.

InstanceMap: [05/05/2020 1:31:01 PM] [d] CheckAndLoadGCInstance: CheckForGlobalCatalog=False

 

At this point, we can see the failure, which is triggering the event 1202.

After this, ADWS moves on to checking ADAM Instances are ready for servicing, as well, however we no longer care for that “noise” in the log file, as we’ve found our problem.

 

Interpretation of the Data:

The data above tells us the following:

 

 

So, in simple words, ADWS was tricked into believing that this was a Domain Controller, however since it’s not a Domain Controller, the isGlobalCatalogReady/CheckForGlobalCatalog obviously failed.

This triggers the Event 1202 to get logged, being logged every minute (because that is the default interval in which this check is performed).

 

Solution:

The solution in this case is very clear and simple. An AD LDS server is not supposed to have a Parameters key under NTDS, as it’s not a Domain Controller and should not/will not require any of the values specified under that key.

 

Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\, and delete the Parameters key.

 

A Similar Scenario:

There are other situations, in which the same 1202 event is logged, but perhaps the server is not an AD LDS server, but rather an actual Domain Controller. In these scenarios, the common solution is to delay the startup type for the ADWS service.

This is because, in those cases, the issue is due to a “race condition”, where ADWS begins performing it’s checks before ADDS services has started, and therefor fails the check and logs the event.  I have only seen this scenario with Domain Controllers running 2012 R2 and below.

 

Thank you, and that's all for now!

- Josh

Exit mobile version