1. Self healing functionality (e.g. journal wraps)
2. Improved RODC support
3. Efficient replication

Note that the http://blogs.technet.com/askds/archive/2009/05/01/sysvol-migration-from-frs-to-dfsr-whitepaper-released.aspx provides details of the process to migrate to DFS-R. The key points I would recommend anyone follow in any environment migrating SYSVOL to DFS-R are

1. Ensure FRS based SYSVOL is healthy (http://blogs.technet.com/askds/archive/2008/05/22/verifying-file-replication-during-the-windows-server-2008-dfsr-sysvol-migration-down-and-dirty-style.aspx)
2. Run dfsrmig.exe to change globalstate in gradual steps. Don’t go to eliminated at once.
3. Stay in redirected for a while ( a few days at least) and ensure DFS-R is working. The health reports with backlog details are available from DFS management console. Note that the DFS management console is not installed by default on a DC.
4. Once DFS-R based SYSVOL is confirmed as converging from step 3, go to eliminated stage. This will remove FRS replica set.

Regular backups of the contents of SYSVOL is essential throughout the migration. This helps if the replica set needs to be recreated from scratch for some unfortunate reason.

Also note that even while in redirected mode, the FRS replica sets health must be monitored. Note that any new DC initialises SYSVOL first by creating a FRS based replica set and then by migrating it to DFS-R. If FRS is broken, this will prevent creating the temporary FRS replica required in order to go to DFS-R. Therefore, I recommend eliminating the FRS replica set as soon as possible.

M

M

I got a call around 2AM Wednesday about a customer that needed help recovering the business after accidentally deleting the OU that had all the user accounts in the organisation. I assumed it would be a simple case of performing an authoritative restore and accepted the case. After turning up onsite I learned that authoritative restores had already been performed but when they ran the LDIF file to recover group membership, the destination servers hung. Without running the LDIF file, they had managed to get all the users replicate out successfully. But the DCs geographically spread across the country had inconsistent group membership information.

As the LDIF file could not be replicated out and as the customer was desperate for resolution, we resorted to rebuilding all the DCs using the source DC backup and performing IFM based promotions. This turned out to be the resolution mechanism while we attempted root cause analysis. A colleague of mine joined me onsite and we recreated the problem in an isolated lab network. Analysis of the memory dump revealed issues with the storage related drivers. Specifically HpCISSs2.sys.

We then tested the DC (All HP DL360 G5) after updating the following.

• Controller Firmware (1.82 as per KB969550)
• Disk Firmware (version HPDA for DH036ABAA5 although customer had DH036ABAA6 disks)
• Controller Drivers (as per KB969550 we installed 6.14.0.32 from a smartstart CD)
• Storport.sys (KB957910 )

We could no longer reproduce the issue and a fix was now available. Yay! Customer decided to keep the DCs that were recovered using IFM online and to turn off the remainder and perform metadata and DNS cleanup. They are now planning to rebuild the remainder later after completely rebuilding them using latest HP SmartStart CD and Windows Server 2003 R2 SP2 CDs. Online DCs are to be also gradually updated with updates shown above.

Lessons learnt were as follows.

1. Importance of preventing accidental deletions of key OUs.
2. Importance of applying all relevant Windows Server service packs/hotfixes (disable SNP, hotfixes for LVR, ntdsutil etc.)
3. Importance of updating hardware firmware/drivers

I have tried to keep this post short by skipping information about the long hours and sleep lost, the time it took for trial and error parts of resolution, challenges with 3rd party DNS that had to be circumvented using Windows DNS temporarily during recovery and the pain to customers while they were down for 3 days. But I assure you that failure to learn the lessons highlighted above, will be very painful if this happens to you.

Regards

M

1. Windows 2008 X64 based domain controllers didn’t replicate with each other. However they were pulling updates inbound from other DCs (that happened to be Windows 2000 Server based) fine. Running commands such as repadmin /bind <W2k8DCname>  and /replsum switches indicated replication failed with access denied. Additionally terminal server sessions –(remote admin mode) were dropped repeatedly within milliseconds of establishing a session. It turned out that the newly built Windows 2008 based DCs had Broadcom cards in them and the driver installer enabled the above setting. Once this was turned off, everything started working perfectly.
2. Was at a customer recently that claimed when they made their Windows 2003 X64 DC in a single domain forest a GC, after a while the server was unresponsive to certain RPC traffic. once the server was removed from been a GC and rebooted, it would not cause issues. I didn’t believe them at first but then they demonstrated by configuring the DC to a GC role. Sure enough a few hours later the server was having issues. repadmin /bind <dcname> traffic once captured over netmon showed resets immediately. dir \\dcname\c$ and other SMB share access access such as SYSVOL and same DC worked. LDAP and GC traffic was perfect. However repadmin based commands like /bind, /replsum did not work. portqry commands to port 135 failed (unfortunately I don’t have error details at the moment). Once the above setting was turned off on the NIC and server was rebooted, no further recurrences were noted.

So in case you run into issues where “RPC traffic is not responded to properly”, check and disable the above setting if configured on your server NIC. Please post a comment if you run into similar issues resolved by this setting.

Thanks

M

The +W2K3_BRIDGES_REQUIRED has nothing to do with DFS.  Repeat after me….”+W2K3_BRIDGES_REQUIRED has nothing to do with DFS”

This setting, when configured on a site, tells the KCC on the ISTG in said site to ignore the BASL setting (on or off) when determining site link transitiveness for the purpose of creating connection objects. Nothing more, nothing less.

If you want DFS to provide intelligence that can take advantage of site link costing, then you turn on sitecostedreferrals ( see DFS Tools and Settings for details).  If you want that intelligence to extend beyond the adjacent site, then you must have a site link bridge to the transitive sites containing DFS namespace and link servers.

One way to accomplish this transitiveness is the catchall BASL.  Another completely accurate way is manual site link bridge for each referral path for which you would like the costed referral to be something less than infinity.  That does not necessarily necessitate a full mesh of site link bridges.

DFS is just a consumer of ISM and its site cost matrix services.

If there is an adjacent or transitive path from this site to some other site, then that other site will have a cost from this site.  If there is no adjacent or transitive path from this site to some other site, then the cost of the other site is infinity.

DFS will order referrals for DFS namespace servers and link servers based on that servers site location and its cost away from the callers site.

Was onsite recently and had a DC that was not advertising is a time server. DCDiag confirmed it.

Checked announceflags and it was set to 10 in hex (0x00000010) instead of 10 in decimal (0x0000000A).

Changed registry value and use “w32tm /config /update” and all was well. Interestingly it appears to only read last value. So even he (0x0000001A) also works and advertises as time server. Presumably because it reads the last character “A” and thinks

A = 10 = (0x8) + (0x2)

and as per http://technet.microsoft.com/en-us/library/cc773263(WS.10).aspx#w2k3tr_times_tools_uhlp 

AnnounceFlags

Registry path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Version

Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008

This entry controls whether this computer is marked as a reliable time server. A computer is not marked as reliable unless it is also marked as a time server.

• 0x00 Not a time server
• 0x01 Always time server
• 0x02 Automatic time server
• 0x04 Always reliable time server
• 0x08 Automatic reliable time server

The default value for domain members is 10. The default value for stand-alone clients and servers is 10.

To cut a long story short the customer had a host file on the DCs of that domain in the following format.

10.1.1.1 DC1 DC1.Domain.Com

10.2.3.1 DC2 DC1.Domain.Com

As both IP addresses were bound to the same FQDN, FRS on each DC was having issues pulling updates from its partner. However AD replication was working fine. The reason for this is the DCs were using the <GUID>._msdcs.forestFQDN and therefore DNS was resolving the record.

Note to self, when troubleshooting name resolution always do the test from the host machine directly.

HTH

M

For the real detail on dsgetdcname and details on the nltest /dsgetdc flags, please see http://msdn.microsoft.com/en-us/library/ms675983(VS.85).aspx.

I made a lab environment which consisted of a single domain forest and 1 x Vista and 1 x XP client. Here are my observations.

If the Vista client’s IP address is from a subnet known by AD, a Windows Server 2008 DC will provide the closest site info details as well. It does not do this for XP. Presumably other down-level OS editions are also not given this detail but I didn’t check.

Here is the LDAP filter one of the UDP based CLDAP ping performed by the Vista client.

Filter: (&(DnsDomain=adatum.com)(Host=ADTMCLIENT1)(DomainGuid={AEF3F962-37E0-D147-8611-D8CA1AAED85E})(NtVer=16:00:00:00))

And the response back from the Windows Server 2008 DC is as follows.

Frame: Number = 86, Captured Frame Length = 200, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-03-FF-0D-FA-00],SourceAddress:[00-03-FF-A5-9B-45]

+ Ipv4: Src = 10.1.1.2, Dest = 10.1.1.6, Next Protocol = UDP, Packet ID = 3904, Total IP Length = 186

+ Udp: SrcPort = LDAP(389), DstPort = 58266, Length = 166

+ Cldap: (CLDAP)Search Result Entry, MessageID: 1, Status: Success

- NetlogonAttribute: LogonSAMLogonResponseEX (SAM Response to SAM logon request): 23 (0x17)

- SamLogonResponseEx: ADTMDC1.adatum.com

Opcode: LogonSAMLogonResponseEX

Sbz: 0 (0x0)

+ Flags: 0x000013FD

DomainGuid: {62F9F3AE-E037-47D1-8611-D8CA1AAED85E}

DnsForestName: adatum.com

DnsDomainName: adatum.com

DnsHostName: ADTMDC1.adatum.com

NetbiosDomainName: ADATUM

NetbiosComputerName: ADTMDC1

UserName:

DcSiteName: HQ

ClientSiteName: HQ

Unknown: Binary Large Object (7 Bytes)

+ Version: 0x00000015 NT Version 5 Client

+ LmNtToken: Windows NT Networking: 0xFFFF

+ Lm20Token: OS/2 LAN Manager 2.0 (or later) Networking: 0xFFFF

The italic Unknown: Binary Large Object (7 Bytes) has hex details corresponding to the following.

05 53 69 74 65 32 00

.Site2.

Here is the site topology created using the ADTD Visio tool.

Currently Netmon 3.2 with latest parsers decodes as above. Wireshark as of v1.0.5 did not decode this.

Please note that the above “Unknown: Binary Large Object (7 Bytes)” field is NOT available if the DC cannot see a subnet that the Vista machine belongs to. Netlogon.log on the client shows that the client did not use any try_next_closest_site flags. Yet the DC still presents the information. It can do this as the filter has a NtVer=16:00:00:00 string identifying the Client OS. XP for example would use NtVer=06:00:00:00. Hence a Windows Server 2008 DC will not respond with closest site info to them.

1. “Registration of the DNS record '_kpasswd._tcp.domain.com. 600 IN SRV 0 100 464 DC1.adatum.com.' failed with the following error: %An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.”
2. “No Windows NT or Windows 2000 Domain Controller is available for domain adatum. The following error occurred: %Not enough storage is available to process this command.”
3. “The attempt to establish a replication link with parameters.

Partition: CN=Configuration,DC=adatum,DC=com

Source DSA DN: CN=NTDS Settings,CN=DC3,CN=Servers,CN=Branch1,CN=Sites,CN=Configuration,DC=adatum,DC=com

Source DSA Address: 5bbb4c2b-47bf-4593-b0dc-460ea4916d49._msdcs.adatum.com

Inter-site Transport (if any): CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=adatum,DC=com

failed with the following status:

Not enough storage is available to complete this operation.

The record data is the status code.  This operation will be retried.”

4.  Following is the summary of warnings and errors encountered by File Replication Service while polling the Domain Controller dc1.adatum.com for FRS replica set configuration information.

 Could not bind to a Domain Controller. Will try again at next polling cycle.

Realising we had a network issue I used “netstat –an” on the DC1 to see the network connections it had established. Output similar to below was

Proto  Local Address          Foreign Address        State
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
TCP    0.0.0.0:990            0.0.0.0:0              LISTENING
<snip>
TCP    0.0.0.0:1025          0.0.0.0:0              LISTENING
TCP    0.0.0.0:1026          0.0.0.0:0              LISTENING
TCP    0.0.0.0:1027          0.0.0.0:0              LISTENING
<snip>
TCP    0.0.0.0:4998          0.0.0.0:0              LISTENING
TCP    0.0.0.0:4999          0.0.0.0:0              LISTENING
TCP    0.0.0.0:5000          0.0.0.0:0              LISTENING

As this was a Windows 2000 Server I did not have the “-o”option of neststat to print out the process ID that was listening on the ports. But you will note that in the above output all ports between 1024-5000 were in use. This is the ephemeral port range. I was pretty certain that the server was infected by now. I wanted to know what the process was so I used TCPView from Sysinternals. TCPview revaled the process name and a quick search on the Malware Protection Center revealed it to be an IRC Bot. Further investigation revealed the DC did not have any anti-virus software and was missing many critical and important security updates. Unfortunately I don’t recall the exact name of the worm.

This was the first time I’d come across a real production DC that was infected. This particular server had replication issues because it did not have any free ports available for use for replication. AD and FRS replication was affected as a result.

HTH

M

I wasn't sure whether I could believe him :) I did some tests using nslookup and dcdiag and then assumed it was a non existent issue. However, he reproduced the issue. I was absolutely amazed at the time as the same query done on W2K3 worked but it didn't on W2K8. This was for a record that was in an AD integrated zone and so I didn't want to assume a corrupt zone. Netmon traces clearly showed the record as non existent despite visible in dnsmgmt.msc and dnscmd.

Then I did what I should have done first. I checked the event log :-). In there was an event about "global query block list". The record that they could not resolve was an important record. I.e. it was the wpad record for proxy settings. In this case the customer had literally typed wpad into the proxy server settings (instead of the proxy server name) along with the relevant port. wpad resolution is typically only required if "Auto detect settings" checkbox is selected to detect the proxy settings. As they were literally using the name "wpad" in the proxy settings dialogs box, they couldn't access the Internet.

With the mystery solved I proceeded to advise them of the behaviour and point them at Technet resources for more details. The recommendation was to change the proxy settings to use a more meaningful name such as the real proxy server name as they were not reliant on auto proxy settings discovery. Please see Managing the Global Query Block List for details.

HTH

M