... on my Polish blog a question was asked on Sunday evening if I can provide some description on the SYSVOL location process and the pitfalls which might wait there. I said ... 'Why not' ... and then you have to keep your promise. So today it will be about SYSVOL volume. Recently it is common topic for me as I gave a talk for local communities in Warsaw about GPO mechanics, which also touches this topic. If you can read Polish and you are interested, the slide deck is available on my Polish blog.
So ... regarding SYSVOL, everyone can see that it is there and it does a job ... until something bad happens. That's the short version. Its primary goal is to serve domain clients files on a DC, in particular to serve GPO templates which are the file based part of GPO. Remember: a GPO consists of two parts – the GP container (GPC) in the directory and the GP Template (GPT) in SYSVOL. Plus some extras like logon scripts etc. If there is no SYSVOL or it is not up to date because of FRS problems (sounds familiar?) there are no or outdated GPOs processed on a client side (actually if there is no SYSVOL share, a DC will not do its job).
(cc) swingnut
From a technical point of view, SYSVOL is just a DFS domain based namespace which content is being replicated with FRS in pre-Windows 2008 operating systems and with DFS-R for Windows 2008 and higher if migration was done (if not ... what are you waiting for????). In fact, SYSVOL content can be replicated in any way, as long as you know how to keep it in sync (don't tell our PSS guys I wrote this ;) ).
SYSVOL is present on every DC, it is a DFS namespace so ... how can you tell which replica is our client using at a given time??? And here is the problem we will be talking about today.
Theory …
As I wrote a few times on this blog (and Jorge wrote also about it + he will give a talk about this on the upcoming TEC 2010 – if you will be there, don't miss it – I will miss it ;) ) a client is locating DCs using DNS records and information about sites and subnets in what is called the DC location process. This way, DS client can (at least should) locate the closest (in terms of AD configuration) DC which can handle its requests. Problem is that this is not the case with SYSVOL, as SYSVOL location process does not follow the same path as the DC location process. Many AD administrators have learned this in a more painful way, when they were trying to figure out why clients are using SYSVOL replicas in some small village north of whatever country it was.
A directory service client is receiving a list of SYSVOL replicas, divided into two lists:
- SYSVOL replicas in the same site
- SYSVOL replicas outside of the client site.
By default, both lists are in random order and are not reflecting things like costs or location in which DCs are located, except obvious information about local DCs. This behavior does not ensure that clients will use the same DCs for logon and SYSVOL within the same site, when multiple DCs are in this site (the word random is key).
To ensure that the DC which handles logon request will be the one which will also be used for SYSVOL location some tweaks have to be performed. These tweaks (and update) are described in KB831201. After applying the tweaks, the DC which handles the request will return its own name as the first DC on the list of SYSVOL replicas returned to a client.
However the problem remains if a client, for whatever reason, is using a SYSVOL replica outside of its site. The list of replicas in the second list, which is replicas located outside of clients site, is not ordered with taking into consideration the cost of getting to this site – it is random. So it might happen that the first DC on the list is in some place far north (or south if you prefer) of the globe. With slow WAN links between them, affecting clients in terms of performance. It is also a common case I observe in customer networks, where customers are not able to access this replica anyway, because of firewall policies which are in place and are prohibiting network traffic between branches.
How to deal with this? It can be easily resolved with additional configuration for DCs, which will enable calculation of the SYSVOL replicas list with taking cost of connection between client and replica into consideration. This option is available for Windows Server 2003-based DCs by default (there is also a fix described in KB823362 for Windows 2000 Server – remember , support for 2K ends on July this year) and it is called SiteCostedRefferals. To enable this option configure this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
Value Name: SiteCostedReferrals
Data Type: REG_DWORD
Value: 1
However, to make this work you have to provide additional information through configuration at the directory level. This information is required for the directory service to calculate possible routes and this is information about which sites can be accessed by the client. To do this we can enable Bridge all site links (BASL) option, however this might not be the preferred way to do this. Why? Because this will also disrupt the replication topology calculation process from KCC standpoint. But if we want to enable SYSVOL cost based replica list calculation while not disturbing KCC with BASL information we can choose to enable it for given sites, which will cause KCC to ignore information about site bridging during calculations, but still seeing it (bridged) for SYSVOL replica cost calculation.
In theory you can think about it as maintaining site bridges manually as alternative to BASL however I don't know if this will work in a real world scenario (but with right people following right process ... it might).
And with the information provided above, for those who were not aware of it so far, I hope life with SYSVOL is much simpler right now.
Toolkit …
Here's some short information about tools that can be used in information gathering or troubleshooting process. The basic tool to start with is dfsutil. Dfsutil allows you to see the list of replicas from the client point of view and see which one is active at given point in time. Two switches to remember:
DFSUTIL /SPCINFO
DFSUTIL /PKTINFO
In Windows Server 2008, these switches have changed and have become:
DFSUTIL CACHE DOMAIN
DFSUTIL CACHE REFERRAL
To have access to DFSUTIL in Windows Server 2008 and later you will have to install DFS management tools using features.
And that's all for now ... at least about SYSVOL.