We have recently come across an issue with Server 2008.  The problem came to light when a 2008 DC was brought up with the same computer name as an existing server elsewhere in the forest.  The 2008 server began throwing the following error to the System Log:

Source: Kerberos    Event ID: 11

The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is cifs/SERVERNAME (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occurring remove the duplicate entries for cifs/SERVERNAME in Active Directory.

Microsoft has information about discovering duplicate Service Principal Names in KB321044, however the recommended steps may not necessarily reveal the duplicate SPN.  A better explanation for this problem is located here: http://blog.joeware.net/2008/07/17/1407/

The short story is as follows…  It appears that Server 2008 is less tolerant of server names that are duplicated in other locations within the forest.  This is a known issue with WINS dating back to Windows 2000 Server, but it appears to cause problems on Server 2008 regardless of whether WINS is in use.  The problem is caused by some services (apparently both on the client and server) still using NETBIOS names to query Active Directory to find a resource – which will yield multiple results when two or more servers have the same NETBIOS names.  The solution to the problem is to ensure that every server (and domain-joined workstation) has a unique name within the forest.

A server experiencing these symptoms may be unable to authenticate logins, as Kerberos in this state is “broken”.  You may also notice Group Policy replication failure events being logged.  We also saw workstations that would attempt to log in to the domain for upwards of 30 minutes.  Rebooting the DCs appeared to provide temporary relief (on the order of 10-15 minutes), but shortly thereafter the above conditions would return.

In working on deploying Windows Server 2008 in our Test Forest, we've been troubleshooting compatibility between our in-house identity management solution's Active Directory sync application, and Server 2008 64 bit.  The IM solution reads account information from an Oracle database, and uses LDAP to update accounts within AD.  Our problems this morning revolved around getting the correct Oracle client installed on the server (32 bit vs. 64 bit).  We took a snapshot on VMWare of our new 2008 root test forest DC, in order to play with the installation order of the different versions of Oracle.  As an aside, we eventually settled on needing on the 64 bit Oracle client, and we were forced to change our Connection String within the compiled VB.Net/C# application to access the Oracle driver in a different way.  The fix for this, creating and editing a dummy UDL file, deserves it's own blog post, but I've got bigger phish to phry at the moment.

So, in doing this testing we on three separate occasions reverted to our snapshot image, which was taken after promoting the DC and installing DNS, but before any Oracle client installations and prior to transferring FSMO roles (I'm counting my lucky stars here - we're practicing our full migration to 2008, and FSMO transfer was next on the list after Oracle).  The snapshots applied correctly, and really helped us solve our Oracle problems.

About two hours later, I was attempting to recreate the scheduled tasks that call our sync application.  I created a Domain Admin account with a strong password to use as the logon account for the task within the Test Forest, and then set about assigning that account to the task.  I used the Browse button to find the account, was able to select it, and configure the rest of the options for the task.  However as soon as I clicked the final OK, I got an error that I was using an invalid account.  A quick check of AD yielded the account, but I was unable to select it no matter what I tried.  I wondered if perhaps the account in question needed to be a member of the Local Administrators group in order to log on to the server and start the task, so I went to make that change from within Server Manager, but at this step I couldn't find the account when I would attempt to browse.  It was at this point that I realized I was probably in trouble.

I attempted to force a replication using ReplMon from the Server 2003 Support Tools (a handy GUI for a lot of the replication functionality that RepAdmin.exe provides), but noticed immediately that both of the replication partners for the DC in question were failing with the error "The destination server is currently rejecting replication requests."  Google pointed to a couple things to try, including the handy "repadmin /options <servername>", which reported that the options DISABLE_INBOUND_REPL and DISABLE_OUTBOUND_REPL were set.  Manually changing these options yielded no results.  Another Google search pointed to checking for a paused NETLOGON service, which indeed was the case, and I turned straight over to the Directory Service Event Log to find event ID 2095, which points to the following KB article: http://support.microsoft.com/?scid=kb%3Ben-us%3B875495&x=17&y=10

The short story is this: reverting to a snapshotted VM image put Active Directory on that DC in a state in which it other DCs did not realize that it was dealing with an old version of the AD database.  If we had restored AD in such a manner that other DCs were notified, they would appropriately replicate the "missing" data, and all DCs would continue on their merry way.  Not so in the case of a snapshot - you'll want to read the above article for a full description of the problem.

Bottom line: If you end up with a DC in this condition, you will need to forcibly demote the DC using ADSIEdit.  DCPromo fails with the same error reported by ReplMon "The destination server is currently rejecting replication requests."  It's a good thing this all happened in our Test Forest, and a damn good thing we learned about this before we virtualize any production Domain Controllers...