Event ID 10154 after promoting 2008 R2 Domain Controller

Fark. What a day. Another spurious event log error.

What’s worse than getting event log errors after deploying an OS… How about after promoting a domain controller. It creates far too many questions and far too few answers!

After building out a new Active Directory forest I noticed the following event log errors in the 2008 R2 Domain Controllers:

The WinRM service failed to create the following SPNs: WSMAN/servername.fqdn; WSMAN/servername 
Additional Data 
The error received was 1355: %%1355.
User Action 
The SPN can be created by an administrator using setspn.exe utility.

This appears to be caused by the NETWORK SERVICE not being given the necessary permissions on the domain controller AD object to make write changes.

I tried a number of things to get this to work and I think I have found the solution.

Adding the necessary values with SETSPN manually does not resolve the issue because the NETWORK SERVICE attempts to write the WSMAN SPN values each time the WinRM service is started.

You can apply the necessary permissions manually with ADSIEDIT or via the command line with dsacls.

The domain controller AD object resides in the Domain Controllers OU. If you apply permissions directly to the domain controller object they will (should!) be replaced by the permissions held on the AdminSDHolder object. In my testing this what not the case, however all the documentation I’ve read indicates differently.

Anyhow, the AdminSDHolder object resides in the System container in every domain and is used to secure privileged users, groups and objects from modification. A background process on the PDC emulator runs every 60 minutes and compares the ACL of the AdminSDHolder object with the ACL of the protected users, group and computers. If there are any differences it overwrites them. Read more about this here.

When I applied the necessary permissions to the AdminSDHolder object only, I could not get the permissions to overwrite on the domain controller object. I waited a couple of hours and even forced the SDPROP process to run. No joy.

I used adfind.exe as described in the Technet article above and confirmed that the \Users\Domain Controllers group is a protected group and as the domain controller objects reside in the Domain Controllers group they should be protected.

I can see the AdminSDHolder ACL being applied to the Domain Controllers group, but not the objects contained with the Domain Controllers. Weird.

I don’t yet know why the ACL of the domain controller object wasnt overwritten , but this was consistent across multiple domains I tested this on. This will need further investigation as all evidence points to the domain controller objects being protected. I also recreated the issue on a vanilla Windows 2008 R2 SP1 ISO to eliminate any other potential causes. When testing with the vanilla ISO, I also received the same error as above, just with a different error code in the message ‘The error received was 8344: %%8344.

To work around this issue I applied permissions directly to the domain controller and AdminSDHolder objects with dsacls:

dsacls “CN=AdminSDHolder,CN=System,DC=domain,DC=com” /G “NETWORK SERVICE:WS;Validated write to service principal name”

dsacls “CN=domaincontroller,OU=Domain Controllers,DC=domain,DC=com” /G “NETWORK SERVICE:WS;Validated write to service principal name”

After that just stop and start the WinRM service and check the System log. Event ID 10154 should be gone.

Event ID 10 after you install 2008 R2 SP1 — KB950375

I hate unnecessary event log errors, especially when it some unintelligible bullshit that repeatedly clogs up the event logs, making it harder to troubleshoot real issues.

If you’ve noticed the following below in your 2008 R2 SP1 servers, don’t panic, its not your fault:

Event filter with query “SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA “Win32_Processor” AND TargetInstance.LoadPercentage > 99″ could not be reactivated in namespace “//./root/CIMV2” because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.

Some crappy coder forgets to do their job properly and we end up with event log errors that raise false alarms, finger pointing (usually!) and time wasting.

Whoever was the release manager for SP1 should be fired… Steve Jobs style.

The fix is easier enough. Documented under KB950375 – run a vbs script or install an msi as found in article 2545227. I went the vbs script route, seems to do the job.

–UPDATE 25/10/2011

I have tested this on a vanilla Windows 2008 R2 SP1 ISO and the error is also present so is indeed a SP1 issue.

VMware Tools Unattended install — Shared F**king Folders

Note to Self. When attempting to remove Shared Folders ‘ during an unattended installation of VMware Tools in Windows as per the unattended installation guide and KB2000399, you need to remove ThinPrint as well as it has a dependency. Otherwise you get a missing tpmon error during the installation. Having had experience building 8 node thinprint clusters and deploying and supporting Thinprint in an enterprise environment, I detest Thinprint. Universal drivers that support ‘every’ printer are always a compromise, reducing printer functionality and increase hostlity towards IT. Thinprint is one of the cheapest universal drivers for a reason. I digress… shown below is an unattended install example.

msiexec.exe /i “vmware tools64.msi” ADDLOCAL=ALL REMOVE=”Hgfs,ThinPrint” /qn /l*v c:\support\vmwaretools64-install.log /norestart

I’m beginning to hate shared folders.