February, 2011

Windows Server 2008 R2 and Windows 7 SP1 has shipped. Here’s the bottom line:

• Volume Licensed, MSDN and TechNet subscribers get access February 16.
• All customers get access February 22 through Windows Update and direct download.

More info and high-fiving here at the Windows Server team blog.

Besides the usual fixes and rollups, this SP includes several new features, such as Hyper-V Dynamic Memory and Remote FX.

- Ned “espy” Pyle

I think people are still digging out of the snow; go enjoy your weekend folks. And remember: no matter who wins, the Packers and Steelers are equally losers.

Face!

- Ned “bitter” Pyle

This is a guest post from our friend Keith Brewer, a Premier Field Engineer that recently spent some time with us here in support as part of a “foreign exchange student” program. As you can see, we pay him by the screenshot… :-P

Hi all, Keith here. Recently I answered a forum question on KCC “topology review” frequency. You can read that here.

There were some interesting follow up questions that came from that conversation:

1. How exactly does the KCC behave when a bridgehead goes offline?
2. What is the impact if the bridgehead is the ISTG or if the ISTG goes offline at the same time as one of the domain controllers serving as the bridgehead?
3. Do manually created connection objects change the behavior?

So I thought the easiest way to explain is to walk through it…

The setup is below (don’t worry about Branch1 and the RODC). For the purposes of this example, we will concentrate on the Hub Site HQ, the Branch Site Branch2, and the Backup Hub Site BackupHub.

• FAB-DC3 & FAB-DC4 are Windows Server 2008 R2
• FAB-DC1 & FAB-DC2 are Windows Server 2008 SP2
• Forest & Domain Functional Level is Windows Server 2003

Under normal operation the ISTG builds an automatically-generated connection object to a DC (or DCs) in the HQ Site. Similar to what we see below for the BackupHub site and HQ because of the connectivity described on the HQ-BUHUB Site Link.

I have created a manual connection object between Branch2 DC (FAB-DC3) and the HQ site with FAB-DC2 to speak to question 3 above.

Additionally here are the HQ connections that have both FAB-DC1 & FAB-DC2 acting as bridgehead domain controllers.

Here is the current (truncated) replication information.

@ 14:44 FAB-DC2 goes offline

@ 14:49 FAB-DC3 shows 1^st failure from FAB-DC2

@ 14:54 DC4 follows suit and shows 1^st failure from FAB-DC2

Now we wait for the 2 hour default window. While we wait let’s look at the ISTG election information:

Conveniently the ISTG for HQ Site is FAB-DC2 who as we all know has tragically gone offline @ 14:44

So we know that FAB-DC1 will review its information (contained in the UpToDateness Vector Table) on the validity of DC2 as the ISTG. Seen here:

So then at some point between 16:43 & 16:58 we should see DC1 take over the HQ sites ISTG Role.

JACKPOT!

Looking at the Replication Metadata we can get a clear picture of when the election took place and who wrote the change.

A new ISTG is elected @ 16:44 2 hours from the last successful replication of the old ISTG.

So now we see what the KCC did once we met both criteria…

• # of Failures
• Duration of time since last success

We can see on FAB-DC3 a new automatically created connection was created.

Note the creation time of 4:39 or 16:39 (Which is 2:05 from the last successful Replication which occurred at 14:34 or 2:34.

Now taking a look at FAB-DC4 (similar behavior):

FAB-DC4 created a connection @ 4:45 or 16:45 (Which was 2:02 from the last successful replication which occurred at 14:43 or 2:43

Last but not least we see how the Hub Site Behavior and resulting connections are handled once the new ISTG is elected.

And now connection from Branch2 (FAB-DC3) has been created by the KCC from FAB-DC3 to FAB-DC1 at 4:44pm seconds after the ISTG election took place @ 4:44:37 in response to the # of failures and amount of time since FAB-DC2 last replicated from Branch3.

Note About the use of manual connection objects:

While the question posed involves manual connection objects and the explanation of the behavior includes manual connection objects that is by no means an endorsement of their use.

Careful planning should be invested into designing the Active Directory site & site link configuration.

In most cases it is preferred to allow the KCC to utilize Active Directory configuration information to build and manage all replication connections. Adding manual connection’s adds administrative overhead and limits the KCC’s ability to build and manage the replication topology.

Now how the KCC cleans up the connections on DC4 for DC2 on DC3 for DC2 and in the Hub on DC2 from DC3 is a story for another thread….

-Keith “What’s your vector, Victor?” Brewer

Hello all, David here again. If you are reading this post, you likely have Distributed File System Namespaces (DFSN) deployed or are at least considering it. In large environments, DFS Namespaces may stretch across many sites and target tens or hundreds of file servers. Depending on the size and quantity of namespaces, you may be wondering about the methods available to monitor the health of namespaces and ensure their proper function. I have written the information below to provide such methods.

Utilize the DFSDiag.exe utility

First, the administrator of any environment with namespaces should routinely run the DFS Diagnostics (DFSDiag.exe) tool. DFSDiag is available in Windows Vista, Server 2008, 7, and 2008 R2. For any 2008 or 2008 R2 systems not hosting the DFS Namespaces service, you will need to install the Distributed File System Tools found in the Remote Server Administration Tools (RSAT) by using Server Manager. RSAT is a separate download for Vista and Windows 7. In addition, you may leverage the tool in an environment consisting of Windows Server 2003 domain controllers and namespace servers, but you will need at least one of the later OS's to run DFSDiag. If possible, use the Windows 7 or 2008 R2 version of DFSDiag--it contains additional help text describing each option. Lastly, it supports both domain-based and standalone namespaces.

While there have been a few other blog posts about DFSdiag (look here and here), I will mention the key issues it detects within an environment:

• Offline file servers, domain controllers, and DFSN servers (Helpful in detecting retired servers that are still referenced within the namespace!)
• Inaccessible file servers because they have inconsistent NTFS and share permissions when compared to other targets of the DFSN folder
• Invalid site associations of the system running DFSDiag locally or of any targets defined in the namespace
• Inconsistent registry settings for the DFSN service compared between namespace servers
• Inconsistent Active Directory metadata between the domain's domain controllers (may indicate replication latencies or failures)
• Overlapping folders, folder targets, and duplicated folders
• Inconsistencies with Access Based Enumeration (ABE) of the namespace and of the namespace share

Here is a screenshot of DFSDiag output while file server "2008fs1" is offline and the NTFS permissions of the two targets of \\CONTOSO\Namespace1\folder1 are not consistent:

As you can see, checking all these dependencies manually would take an enormous amount of time. So let DFSDiag do all the work and allow you to fix problems before your users have an opportunity to call the helpdesk!

Be mindful when configuring subnets and their site associations within the Active Directory. Clients and servers which cannot be mapped to a site will prevent DFS from referring clients to their local targets. DFSDiag will report a failure to map a server's IP address to a site, but it will not alert you if there are random clients in your environment not belonging to an Active Directory site. For this reason, periodically check if any Netlogon ‘5807’ events have been reported on any domain controllers. If any are found, follow the instructions within the event to review the Netlogon.log debug log file located within "%systemroot%\debug" and search for all occurrences of 'NO_CLIENT_SITE'. These indicate the name and IP address of clients on your network which cannot be mapped to an Active Directory site. Then, create the appropriate subnets.

Event ID: 5807
Source: NETLOGON
Description:

During the past number hours there have been number connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites. The names and IP addresses of the clients in question have been logged on this computer in the following log file 'SystemRoot\debug\netlogon.log' and, potentially, in the log file 'SystemRoot\debug\netlogon.bak' created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text 'NO_CLIENT_SITE:'. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize'; the default is 20000000 bytes. The current maximum size is 20000000 bytes. To set a different maximum size, create the above registry value and set the desired maximum size in bytes.

Leverage the File Services Management Pack found in SCOM

If you have System Center Operations Manager (SCOM) deployed, you may utilize the File Services Management Pack to retrieve health information from all File Services roles, including DFS Namespaces. Download is available here.

Ready a “toolkit” of common tools and utilities

Troubleshooting DFS Namespace issues can be difficult. It usually makes sense to begin investigations on a client experiencing a specific failure to access the namespace. Consider building a “toolkit” to make it easier to run DFSDiag, DFSUtil, and Network Monitor 3.4 on the problematic client. Otherwise, you will be forced to download and install the Remote Server Administration Tools (RSAT) to the system you wish to diagnose, and then configure the DFSN RSAT component. A much easier method is to copy DFSUtil.exe and DFSDiag.exe (both found in %systemroot%\system32) to a share, to a thumbdrive, or directly to the client. Ensure that you also copy the dfsdiag.exe.mui language file from the '%systemroot%\system32\en-us' folder and place it into an 'en-us' subfolder where you intend to run dfsdiag. Note, you will also need to maintain separate versions of dfsdiag if you maintain both Vista/2008 and Window 7/2008 R2 systems. If you were to rename dfsdiag.exe to 'dfsdiagwin7.exe', ensure you similarly rename the MUI file to 'dfsdiagwin7.exe.mui'.

Create a disaster recovery plan

Do you have a disaster recovery plan in the event all or portions of your namespace are lost due to hardware failures or accidental deletions? If not, strongly consider exporting your namespace using DFSUtil.exe periodically. The XML-based output file may be imported back into the namespace (or a completely new namespace) in the event of a problem, or it may be utilized simply as a historical record of the namespace's design. The export should be considered in addition to regular Active Directory (system state) and namespace server backups (you are backing up Active Directory regularly, right???). Trust me... you won't realize the value of this exported namespace data until you experience a situation where it takes you hours to recover the namespace rather than minutes. A sample command to export a namespace 'sales' in domain 'contoso.com' is:

dfsutil /root:\\contoso.com\sales /export:c:\NameSpaceBackups\sales_namespace_1-10-2011.txt

Install Service Updates

Ensure that you are running the latest version of DFS Namespace-related components. The articles listed in the link below are routinely updated to reflect the latest updates available for both DFSN and DFSR: http://www.microsoft.com/windowsserversystem/dfs/hotfixes.mspx

Increase the scalability of DFSN

If your namespaces host thousands of links and operates in 'Windows 2000 Server mode', strongly consider converting the namespace to 'Windows Server 2008 mode'. You will gain increased scalability and the option to use Access Based Enumeration (ABE). For more information, please see http://technet.microsoft.com/en-us/library/cc753875.aspx.

Utilize the Best Practices Analyzer

Lastly, on Windows Server 2008 R2 DFSN servers run the Best Practices Analyzer for File Services. While it is focused on DFSN settings of the local server, it covers a few scenarios not covered by DFSDiag. More information about the BPA, please visit http://technet.microsoft.com/en-us/library/ff633466(WS.10).aspx and also download an updated version of the BPA here.

Any distributed service can be very difficult to monitor and maintain. My hope is the strategies and methods above keep your DFS Namespaces in tiptop shape. Happy DFSN'ing!

- Dave “Fire Marshall Bill” Fisher

Hot enough for ya, Mark?

Update - way more glad now that I saw this:

Ned “drove in with his windows down today” Pyle

Hi, David here. Some of you may have noticed that if you tried to migrate Office 2010 settings using USMT 4.0, the results were often less than ideal. Without going into a very long and ultimately meaningless explanation, this happened because USMT 4.0 didn’t have any of the information needed to know where Office 2010 expected its data to be. Office 2010 is different enough from its predecessors that USMT does need to have that information in order to be able to handle the settings.

Fortunately, I have good news: we have created an update for USMT 4.0 that adds support for Office 2010. USMT 4.0 migrations of Office 2010 are now supported .

You can get the update here: http://support.microsoft.com/kb/2023591

Here are some things you should be aware of:

• Certain settings and customizations in MS Word won’t migrate from any version to Word 2010, because of with the way Word is designed and how data is stored in “HKEY_CURRENT_USER\software\Microsoft\Office\<OfficeVersion>\Word\Data".
• Many Office settings (across all Office apps) won’t migrate when going from 32-bit Office to 64-bit Office. This is due to the way that the settings are stored in 64-bit Office installations.
• If you’ve launched Office on the destination PC as a user before doing the migration of that user’s profile, most of your settings won’t migrate. This happens because Office relies on some code that only runs the first time that an Office app is launched to migrate settings.
• This update isn’t a magic bullet. You may still need to do some customization to make USMT fit your particular configuration.

The update also fixes a couple of issues around hard-link migration performance when copying a folder with a huge number of files and an issue that affected certain time zones.

If you’re doing a migration, make sure you’ve allotted plenty of time for testing and customization, and if you do need help from us, get it early so that you have time to make adjustments to what you’re doing before you start running into deadlines. Make sure you read the KB fully before pinging us!

That said, go get the update. Then go forth and migrate.

- David “Clippy” Beach