Archive for Windows Server 2003

I ran into a weird issue the other day when configuring permissions on a Share that was clustered.  I couldn’t find much online about this, and the one similar issue from Russ was not the issue here.

Here is a little background info to help set the stage.  An admin changes the permission on the Shared Folder (not the File Share Cluster Resource) that is clustered from Read to Full Control.  This works when connecting to the node explicitly but not with the cluster name.  So he fails over the resource to the other node and notices that the permissions had reset to Read.  This is where I get called in.  I’m thinking this is going to be a very easy 30 second fix (which it ended up being…but more on that later).  I had the admin explain to me what process was followed to change the permission.  Right away I knew that changing the permission on the Shared Folder and not the File Share resource was an issue. 

I went into to Cluster Administrator (cluadmin.msc) and went to alter the permissions from Read to Full Control for the group in question and I was presented with the following error:

An error occurred validating the cluster security descriptor
The RPC server is unavailable
Error ID -2147023174 (800706ba)


As most of you know this is a very generic error.  In fact if there is one error I can’t stand from Microsoft it is “The RPC server is unavailable” error.  After doing some research and testing we found that we couldn’t even add a new Security Principal to the permissions of this cluster.  It mentioned that the Computer was not part of the domain.  In hind sight I wish I would have got the entire error for you but I forgot to grab the screen cap for that one.  The name it was referencing was the clustered name.  Well the cluster name is not going to have an Active Directory account so I went to check in DNS and sure enough there was no record for this cluster name in DNS.  After adding the record into DNS we were able to immediately change the permission.

There I go again assuming things were set up correctly initially.  I really need to break that wall down and start from the very beginning when I’m troubleshooting.  Ah the things we take for granted when looking at a problem.

There are quite a few ways to view what your FSMO roles are.  You can use the GUI tools or even the following netdom command that I”ve shared in the past – netdom query fsmo

However if you are working in a trusted multi-domain environment the following command can help you view the FSMO role holders remotely.

netdom query /domain:%domainname% fsmo

This is just a huge time saver and hopefully you can add it to your tool belt of commands.

I’ve seen this issue come up time and time again.  Some administrator decided to remove an old DC from the network but forgot to remove it from Active Directory or the DC has entered a failed state and cannot be recovered from.  In a perfect world DCPROMO is all you have to do to remove a DC from the environment.  However, if that DC was already shutdown or DCPROMO is giving you problems you will have to remove it the manual way.  That method involves using a command called NTDSUTIL.  NTDSUTIL is a command line tool that allows you to perform some of the more advanced Active Directory maintenance tasks.

Below are the steps needed to remove a failed or offline Domain Controller from your environment.
TIP: NTDSUTIL does not require the full command to be entered…you only have to enter enough of the command that is unique.  For Example, instead of typing metadata cleanup you could just type met cle…or better yet m c

  1. Open the Command Prompt
  2. Type ntdsutil (all the commands will be entered via this command prompt)
  3. Type metadata cleanup
  4. Type connections
  5. Type connect to server <ServerName> and replace <ServerName> with the name of a functional DC in your environment…even if you are logged in locally.  This step is not needed post W2K3 SP1.
  6. Type quit
  7. Type select operations target
  8. Type lists sites
  9. Type select site <#> where <#> is the site where the failed or offline DC resided
  10. Type list servers in site
  11. Type select server <#>  where <#> is the DC that is failed or offline
  12. Type list domains
  13. Type select domain <#>  where <#> is the domain where the failed or offline DC resided (at this point you should verify that the site, server and domain are all selected)
  14. Type quit (this should set you back to the metadata cleanup menu)
  15. Type remove selected server ( a warning message will pop up…verify that this is the correct DC…in fact get a peer to verify it for you too)
  16. Click Yes
  17. Open Active Directory Sites and Services
  18. Expand out the site that the failed or offline DC resided in
  19. Verify the DC cannot be expanded out (no connection objects and such)
  20. Right Click the DC and select Delete
  21. Close Active Directory Sites and Services
  22. Open Active Directory Users and Computers
  23. Expand the Domain Controllers OU
  24. Delete the failed or offline DC from the OU (if it even exists)
  25. Close Active Directory Users and Computers
  26. Open DNS Manager
  27. Expand the zones where this DC was also a DNS server and perform the following steps
  28. Right click the zone and select Properties
  29. Click the Name Servers tab
  30. Remove the failed or offline DC from the Name Servers tab
  31. Click OK to also remove the HOST (A) or Pointer (PTR) record if asked
  32. Verify the zone no longer has a DNS record for the failed or offline DC

You can also find more info located on Microsoft site here and here for removing orphaned domains.

From time to time I’ve had to figure out which user account has a specific email address.  Actually its more like finding who has the “” so another “more senior” person can get it.  Well if you work in a smaller company this can be kind of easy…but if your directory has thousands of accounts it becomes more difficult and time consuming.

What you will want to do is open up Active Directory Users and Computers and right-click the domain and select Search.  Select the drop-down arrow in the Find field to select Custom Search.  If you have multiple domains make sure to select Entire Directory on the In field.  Now just click on the Advanced tab and put the following text in the LDAP Query – proxyaddresses=smtp:<whatever the email is you’re looking for>.  Now all you have to do is click on Find Now and if the email is in use it will show the user account that is using it.


I recently blogged about time and how critical it is in a domain environment. Just this morning I read a post from the Directory Services Team that shows how to configure WMI Filtering through Group Policy to ensure that the PDC Emulator always has the right time configuration.  You need to read through this post really consider implementing a similar policy into your environment.

The only portion that is missing from that post is the location of the W32Time settings in Group Policy.  The policy you will be configuring is located under the Computer ConfigurationAdministrative TemplatesSystemWindows Time ServiceTime ProvidersConfigure Windows NTP Client


After you enable it you will want to change the default setting from NT5DS (which means find and sync with the PDCe) to NTP.  This is because we are configuring this for our PDCe which should be pointing to a reliable time source (internal or external).  You will also configure the location to that reliable source in the NTPServer dialog box.

I haven’t seen a great tip like this in some time.  This is one of those great little finds and I hope you enjoy it.

I ran into this error awhile back after building a new root level Domain Controller (DC). My initial health checks panned out ok but after about an hour the following should up in my System Event log:
Event Type:    Error
Event Source:    KDC
Event Category:    None
Event ID:    11
User:        N/A
Computer:    DCShortName
There are multiple accounts with name cifs/DCShortName of type DS_SERVICE_PRINCIPAL_NAME.

My forest root domain has a fairly small amount of accounts with the majority of them being DCs.  I knew that the name that was added was not in conflict with the forest root.  With this name being the shortname of the DC I knew that I would have to check other child domains.  After a quick search of the directory (GC) via Active Directory Users and Computers I was able to find another computer with the same name.  Unfortunately one of the computers had to go bye-bye…and it sure wasn’t going to be my DC.  Needless to say after the computer was removed from Active Directory the errors stopped showing up.

My daughter Alyssa and I play a game…well she might not consider it a game but she is constantly  asking me “What time is it without looking”.  I’ve actually gotten pretty good at it and can usually get within a few minutes.  Not sure why she likes to play but perhaps time is something they recently talked about at school but she seems obsessed with it.  I keep telling her that at 6 she really shouldn’t worry to much about time.

Although time may not be important for my daughter, it is immensely important for Active Directory.  Most AD admins know that domain controllers and clients need to be within 5 mins of each other to work correctly.  If your time was out by 5 or more minutes the client would not be able to authenticate.  What most AD admins might not know is that time just doesn’t affect AD, it also can affect certain time sensitive applications.   I don’t know of any out of the box ones from Microsoft but organizations have plenty of custom built apps that may use time syncs.  I’ve seen custom applications that need to be accurate within less than a second.

Let’s take a look at how time synchronization works in an Active Directory forest.  The magic all starts in the root domain (I always wanted to use that in my blog).  The PDC Emulator (PDCe) is solely responsible for time synchronization and uses the Network Time Protocol (NTP) on port UDP 123.  You will want to sync the PDCe with a reliable source, either internal (perhaps a router) or external.  The problem with going external is that there is less security because of the lack of authentication and verifiable authenticity. 

Clients and servers in your forest root domain will sync their time with any DC in the forest root.  This is all configured in the registry at the following location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters.  Domain members have Nt5DS set for the TYPE key which configures them to use the domain hierarchy for time.  Some people change this to NTP which means it will go to a specific time source besides the PDCe but I prefer to keep the default here because it works!  If you’re crazy enough you could configure it so that it relies on the CMOS clock…I just don’t have enough faith in the batteries for that.

If you have child domains or other tree roots in your forest realize that the forest root PDCe is STILL the authority for forest wide time synchronization.  The PDCe for the child domains will sync their time with the forest root PDCe or any DC in the root (but those root DCs get their time from the PDCe).  The clients and servers in the child domain will always go to a DC in their domain, so they should never go up to the forest root domain.  Clients poll the time every 45 minutes by default.  After three successful synchronizations it will increase that polling time to 8 hours.  Below is a great illustration of how time works in a multi domain forest.


To configure your forest root PDCe with a valid time source you should use the w32tm command:
w32tm /config /manualpeerlist:peers /syncfromflags:manual /reliable:yes /update
You can and I recommend adding multiple peers but simply putting a space between them.  Please don’t forget to run this command on the DC that you have designated as the DC to fail the PDCe role over to during downtime (for example, patching).

To test how close your time is synced you can use the w32tm command again, except this time we can get a really cool command prompt chart…hey its the simple things in life that get me.
w32tm /stripchart /computer:target /samples:n
Replace target target with the name of the forest root PDCe.  I prefer to get 10 samples but you can go for whatever amount you like.  This will tell you the difference between the clocks.   More info can be found on the w32tm here.

The Microsoft Directory Services team has a great blog that talks about high accuracy in w32tm and why they don’t support it.  This is a must read for all AD admins.  Don’t forget to set up an RSS feed to the Windows Time Service blog as well.

I would recommend baseline the time difference in your environment so that if an issue does occur you will know what the norm state is for your time differential.  You may also want to include some monitoring that can alert you of time drift using the baseline numbers you’ve collected.  I would also recommend talking to your developers and ensure they understand how time works in the environment.

Hopefully this sheds some light on how time works in an Active Directory forest but also how you can control and tweak it.  Oh and if you’re bored try playing the time game…its a great exercise for your mind and internal clock! :,,)

Please don’t just read this post…participate by answering the questions I ask using the comments.  Don’t worry you don’t have to register.  :,,)

One of the things that I’ve been waiting awhile for, was a Windows operating system that is smart enough to not have to reboot as much as previous versions.  I thought that wait would end with Windows Server 2008 but unless someone can prove me wrong I think there is actually potential for more reboots.

The first and obvious one that we still have to deal with is patching.  Didn’t Microsoft mention that reboots after patching would be much fewer?  I can’t seem to find anything from the early hype days but, the excellent ASKPERF blog does go into some detail as why there should be fewer reboots.  The problem is system DLL”s such as NTDLL.DLL and Kernel32.DLL still require a reboot when they are updated.  Have you seen fewer reboots because of patching?

My next big complaint about Server 2008 reboots has to do with Features and Roles.  I first experienced this after installing the limp Windows Server Backup.  I know many people don’t like the old built in tool but if you manage an AD environment it was perfect for doing AD backups while not allowing domain Backup Operators the ability to restore your AD to their desktop. I know other ways to do this in Server 2008 but that is not my point of this post.

I installed the Windows Server Backup and quickly decided to uninstall it.  What do you know…I have to reboot my server to uninstall backup software.  I couldn’t believe that.  During some testing I had to uninstall AD and DNS on a DC.  I go and run DCPROMO on the DC and of course afterwards I have to reboot.  So I do.  Next I go to uninstall DNS from Server Manager (also removed the AD Binaries) and sure enough not 5 mins after rebooting for DCPROMO I had to reboot again.  This was not an issue with Server 2003.

COME ON MICROSOFT!!!  The last time I had to reboot this frequently was with Windows NT.  Heck I was surprised after a right-click it didn’t ask me to reboot…Okay, so maybe it isn’t that bad but it definitely seems to be more now than it was in Server 2003, especially with Services.  Have you experienced reboots doing tasks that didn’t require them in Server 2003?  Are you happy with that?

The problem with this is when I want to install an additional Feature or Role it won’t let me because it is pending an uninstall.  I’d love to hear what others think of this.

Have you ever had one of those jobs where you just weren’t sure what Schema update had been applied in an environment?  The following command will let you know which of the Windows Server Schema updates have been applied. 

dsquery.exe * “CN=Schema,CN=Configuration,DC=domain,DC=com” -scope base -attr objectversion

Here is what the versions will mean:

44 = Windows Server 2008
31 = Windows Server 2003 R2
30 = Windows Server 2003
13 = Windows 2000

If anyone knows the Exchange Schema update numbers please post and share.

I just read over at Jane Lewis”s blog that if you plan on deploying Server 2008 Read Only Domain Controllers (RODC) and have down-level clients (XP and 2003 clients) then you will want to check out the RODC Compatibility Pack.

I know a lot of people are planning on deploying this so this should be something that you should pay attention to.  The KB article (and patch) addresses 10 potential issues.

The patch itself can be downloaded from Microsoft here.