(2014-01-17) Bug In DC Locator Makes AD Client Use Siteless SRV Record Instead Of Site Based SRV Record

Today while helping another Directory Services MVP regarding the troubleshooting of DC Locator in Windows 7 (also applies to W2K8R2 server), a bug was found. While the Windows 7 client knew the AD site it was in, it was still doing a DNS query for siteless SRV records instead of doing a DNS query for site based SRV records.

–

SYMPTOMS

When you restart a client computer that is running Windows 7 or Windows Server 2008 R2 in an Active Directory domain environment, the Net Logon service starts before the network interface is initialized. This behavior causes the status of the network adapter to change to intermediate. Additionally, this behavior causes the IP address to change even though the network adapter is assigned to the same IP address eventually. In this situation, the client computer uses site-less LDAP DNS Server (SRV) records (_ldap._tcp.DnsDomainName or _ldap._tcp.dc._msdcs.DnsDomainName) to locate the domain controller (DC).
If this issue occurs in an environment in which only the hub DCs for the site-less SRV records are registered in DNS, and if the client computer’s remote branch site is disconnected from the hub site, then the client computer cannot locate a DC. However, the local branch DCs are available in DNS when the hub DCs cannot be reached from the branch site. Therefore, the client computer does not recognize the local branch DCs as DCs.

–

CAUSE

This issue occurs because the Net Logon service invalidates the cached site information in the registry prematurely.

–

MORE DETAILED INFORMATION

If you enable debug logging for the Net Logon service by using the method that is described in Microsoft Knowledge Base (KB) article 109626, you receive a sequence that resembles the following. The sequence indicates how the site name is invalidated.

10/20 13:20:01 [SITE] Setting site name to 'MyCachedSiteName'
10/20 13:20:01 [SITE] Hint avoided. 31
10/20 13:20:01 [SESSION] \Device\NetBT_Tcpip_{6964FC65-C026-4EC4-A8B9-29C2019401AC}: Transport Added (169.254.237.187)
10/20 13:20:01 [CRITICAL] IPV6SocketAddressList is too small 0.
10/20 13:20:01 [SESSION] Winsock Addrs: 169.254.237.187 (1) Address changed.
10/20 13:20:01 [SESSION] V6 Winsock Addrs: (0) 
10/20 13:20:01 [CRITICAL] Address list changed since last boot. (Forget DynamicSiteName.)
10/20 13:20:01 [SITE] Setting site name to '(null)'

–

For more information about KB article 109626, click the following article number to view the article in the Microsoft Knowledge Base:

MS-KBQ109626 Enabling debug logging for the Net Logon service

–

If the hotfix is installed, you may also receive the new error messages that is mentioned in Microsoft Knowledge Base (KB) article 2654097. For more information about 2654097, click the following article number to view the article in the Microsoft Knowledge Base:

MS-KBQ2654097 New event log entries that track NTLM authentication delays and failures in Windows Server 2008 R2 are available

–

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Advertisement

(2011-09-11) Service (SRV) Locator Records Registered By Windows Domain Controllers

Windows DCs register a set of service locator records in DNS to be able to service both windows and non-clients. The complete list of service (SRV) records is specified below with an explanation of the service that’s represented, including which clients used it. By default. Windows DCs register all available service records. This is OK for datacenter located RWDCs. For RWDCs not located in datacenters, the RWDCs need to be told not to register the domain-wide SRV records. This can be achieved through the registry or through a GPO. The latter of course is preferred and a best practice. For more information about how to configure RWDCs NOT to register specific mnemonics see this blog post. RODCs by default only register site-wide SRV records, so no need to use a GPO to tell the RODC not to register domain-wide SRV records.

–

The NetLogon service on a DC, during boot and regularly (every hour, and previously that was every 24 hours), is responsible to registering the correct service records. The service records that will be registered are listed in the “netlogon.dns” file in the “C:\Windows\System32\config” folder. An example of this file is shown below.

–

 

–

It is also possible to force the registration and deregistration of the service records that should be registered/deregistered. The commands are:

• Forced manual registration: NLTEST /DSREGDNS
• Forced manual deregistration: NLTEST /DSDEREGDNS:<FQDN DC>

–

The following RFC provide detailed information about this: “A DNS RR for specifying the location of services (DNS SRV)”

–

The SRV record is used to map the name of a service (in this case, the LDAP service) to the DNS computer name of a server that offers that service. In a Windows Server network, an LDAP resource record locates a domain controller. A workstation that is logging on to a Windows domain queries DNS for SRV records in the general form:

_Service._Protocol.DnsDomainName

–

Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server by querying DNS for a record of the form:

_ldap._tcp.DnsDomainName

–

_msdcs Subdomain

There are possible implementations of LDAP servers other than Windows based domain controllers. There are also possible implementations of LDAP directory services that employ Global Catalog servers but are not servers that are running Windows Server. To facilitate locating Windows Server–based domain controllers, in addition to the standard _Service._Protocol.DnsDomainName format, the NetLogon service registers SRV records that identify the well-known server-type pseudonyms "dc" (domain controller), "gc" (Global Catalog), "pdc" (primary domain controller), and "domains" (globally unique identifier, or GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain allows location of domain controllers that have Windows Server–specific roles in the AD domain or AD forest, as well as the location by GUID when an AD domain has been renamed (more info about domain rename can be found here). To accommodate locating domain controllers by server type or by GUID (abbreviated "dctype"), Windows Server–based domain controllers register SRV records in the following form:

_Service._Protocol.DcType._msdcs.DnsDomainName

–

The addition of the _msdcs subdomain means that two sets of DNS names can be used to find an LDAP server: DnsDomainName is used to find an LDAP server or Kerberos server that is running TCP (or, in the case of a Kerberos server, either TCP or the User Datagram Protocol [UDP]), and the subdomain _msdcs.DnsDomainName is used to find an LDAP server that is running TCP and also functioning in a particular Windows Server role. The name "_msdcs" is reserved for locating WIndows domain controllers. The single keyword "_msdcs" was chosen to avoid cluttering the DNS namespace unnecessarily. Other constant, well-known names (pdc, dc, and gc) were kept short to avoid exceeding the maximum length of DnsDomainName.

–

SRV Records Registered by NetLogon

The list that follows provides the definitions of the names associated with registered SRV records. It also describes the lookup criteria supported by each record and the checks performed by Net Logon as each record is registered. Text in bold type denotes constant record components; text in italic type denotes variable names.

–

In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain name that is used during creation of the first domain controller when the AD domain tree is joined or created (that is, while the computer is running the Active Directory Installation Wizard). DnsForestName refers to the DNS domain name of the forest root AD domain.

–

The following is a list of the owner names of the SRV records that are registered by NetLogon. An owner name is the name of the DNS node to which the resource record pertains.

–

_ldap._tcp.DnsDomainName.

Allows a client to locate a server that is running the LDAP service in the AD domain named by DnsDomainName. The server is not necessarily a domain controller — that is, the only assumption that can be made about the server is that it supports the LDAP application programming interface (API). All Windows Server–based domain controllers register this SRV record (for example, _ldap._tcp.adcorp.lab.).

–

_ldap._tcp.SiteName._sites.DnsDomainName.

Allows a client to locate a server that is running the LDAP service in the AD domain named in DnsDomainName in the AD site named by SiteName. SiteName is the relative distinguished name of the site object that is stored in the Configuration container in Active Directory. The server is not necessarily a domain controller. All Windows Server–based domain controllers register this SRV record (for example, _ldap._tcp.amsterdam._sites.adcorp.lab.).

–

_ldap._tcp.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller (dc) of the AD domain named by DnsDomainName. All Windows Server–based domain controllers register this SRV record.

–

_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller for the AD domain named by DnsDomainName and in the AD site named by SiteName. All Windows Server–based domain controllers register this SRV record.

–

_ldap._tcp.pdc._msdcs.DnsDomainName.

Allows a client to locate the server that is acting as the primary domain controller (also known as a "PDC") in the AD domain named in DnsDomainName. Only the PDC emulator FSMO of the AD domain (the Windows Server–based domain controller that advertises itself as the primary domain controller to computers that need a primary domain controller) registers this SRV record.

–

_ldap._tcp.gc._msdcs.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD forest. Only domain controllers that are functioning as Global Catalog servers for the AD forest named in DnsForestName register this SRV record (for example, _ldap._tcp.gc._msdcs.adcorp.lab.).

–

_ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD forest in the AD site named in SiteName. Only domain controllers that are serving as Global Catalog servers for the AD forest named in DnsForestName register this SRV record (for example, _ldap._tcp.amsterdam._sites.gc._msdcs.adcorp.lab.).

–

_gc._tcp.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD domain. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the AD forest named in DnsForestName registers this SRV record (for example, _gc._tcp.adcorp.lab.).

REMARK: In Windows Server, a Global Catalog server is a domain controller. Other non-Windows 2000 implementations of directory services can also register servers as Global Catalog servers.

–

_gc._tcp.SiteName._sites.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD forest in the AD site named in SiteName. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the AD forest named in DnsForestName registers this SRV record (for example, _gc._tcp.amsterdam._sites.adcorp.lab.).

–

_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName.

Allows a client to locate a domain controller in an AD domain on the basis of its GUID. A GUID is a 128-bit number that is automatically generated for referencing objects in Active Directory – in this case, the AD domain object. This operation is expected to be infrequent; it occurs only when the DnsDomainName of the AD domain has changed, the DnsForestName is known, and DnsForestName has not also been renamed (for example, _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains._msdcs.adcorp.lab.). All domain controllers register this SRV record.

–

_kerberos._tcp.DnsDomainName.

Allows a client to locate a server that is running the Kerberos KDC service for the AD domain that is named in DnsDomainName. The server is not necessarily a domain controller. All Windows Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

–

_kerberos._udp.DnsDomainName.

Same as _kerberos._tcp.DnsDomainName, except that UDP is implied.

–

_kerberos._tcp.SiteName._sites.DnsDomainName.

Allows a client to locate a server that is running the Kerberos KDC service for the AD domain that is named in DnsDomainName and is also in the AD site named in SiteName. The server is not necessarily a domain controller. All Windows Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

–

_kerberos._tcp.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller that is running the Windows Server implementation of the Kerberos KDC service for the AD domain named in DnsDomainName. All Windows Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos v5 protocol Authentication Service Exchange subprotocol) register this SRV record.

–

_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller that is running the Windows Server implementation of the Kerberos KDC service for the AD domain that is named in DnsDomainName and that is also in the AD site named in SiteName. All Windows Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos protocol Authentication Service Exchange subprotocol) register this SRV record.

–

_kpasswd._tcp.DnsDomainName.

Allows a client to locate a Kerberos Password Change server for the AD domain. All servers that provide the Kerberos Password Change service (which includes all Windows Server–based domain controllers) register this name. This server at least conforms to "Kerberos Change Password Protocol”. The server is not necessarily a domain controller. All Windows Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

–

_kpasswd._udp.DnsDomainName.

Same as _kpasswd._tcp.DnsDomainName, except that UDP is implied.

–

If multiple domain controllers have the same criteria, multiple records exist with the same owner name. A client that is looking for a domain controller with specific criteria would receive all the applicable records from the DNS server. The client would pick one of the returned records to select a domain controller, as described in the RFC "A DNS RR for specifying the location of services (DNS SRV)."

For information about the Kerberos v5 authentication protocol see:

• http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx
• http://technet.microsoft.com/en-us/library/cc787313(WS.10).aspx
• http://technet.microsoft.com/en-us/library/cc753173(WS.10).aspx
• http://msdn.microsoft.com/en-us/library/aa378747(v=VS.85).aspx
• http://en.wikipedia.org/wiki/Kerberos_(protocol)
• http://technet.microsoft.com/en-us/library/bb742516.aspx
• https://jorgequestforknowledge.wordpress.com/2006/12/28/ntlm-and-kerberos-authentication-explained-the-easy-way/
• https://jorgequestforknowledge.wordpress.com/2011/02/13/accessing-a-resource-with-the-kerberos-authentication-protocol/

–

Host Records for Non-SRV-Record-Aware Clients

NetLogon registers the following DNS A records for the use of LDAP clients that do not support DNS SRV records (that is, that are "non-SRV-aware"). The Locator does not use these records.

The following owner names of A (host) records are registered by NetLogon:

–

DnsDomainName.

Allows a non-SRV-aware client to locate any domain controller in the AD domain by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. A non-SRV-aware client looks up the name; an SRV-aware client looks up the appropriate SRV resource record.

–

gc._msdcs.DnsForestName.

Allows a non-SRV-aware client to locate any Global Catalog server in the AD forest by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. A non-SRV-aware client looks up this name; an SRV-aware client looks up the appropriate SRV resource record.

–

NetLogon also registers a DNS CNAME (alias) record for use by Active Directory replication. The Locator does not use this record. The owner name of the CNAME record is:

DsaGuid._msdcs.DnsForestName.

Allows a client to locate any domain controller in the AD forest by looking up an A record. The only information that is known about the domain controller is the GUID (“objectGUID” attribute) of the directory system agent (also known as the "DSA") object (“NTDS Settings” object) for the domain controller and the name of the AD forest in which the domain controller is located. This record is used to facilitate renaming a domain controller.

–

Other SRV Record Content

The following information is also included in an SRV record:

• Priority – The priority of the server. Clients attempt to contact the server with the lowest priority (a.k.a. lowest (cost)value).
• Weight – A load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight
• Port Number – The port where the server is listening for this service.
• Target – The fully qualified domain name of the host computer.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

 

(2011-01-27) DC Locator – What Does "NO_CLIENT_SITE" Mean In Netlogon.log

When your DCs are logging the "NO_CLIENT_SITE" warning in the NETLOGON.LOG file, it depends on whether you can/should ignore it or not. I will explain the reason through examples by how it works and also the reasoning of why you can ignore it or not.

WHY THE "NO_CLIENT_SITE" ERROR OCCURS…..

When a computer is domain joined it knows for sure of which AD domain it is a member. A domain joined computer may or may not know the AD site it is in. Even if it thinks it knows the AD site, it may not even be in the correct AD site (e.g. because it was moved, or AD site was renamed, etc.). For the remaining part of the text I will just mention "computer" instead of domain joined computer.

Now, the following steps will be taken when the computer starts/boots and:

1. It DOES know the AD site it is in:
   
   1. It queries DNS with "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN AD DOMAIN>"
      
   2. DNS returns a list of DCs that have registered the site-wide SRV records for <SITE NAME> (By default this will be done by the RWDCs/RODCs in that AD site OR if the site has no DC, it will be done by RWDCs covering that AD site. How site coverage works can be read here – "Site Coverage Algorithm" section/paragraph.)
      
   3. The computer contacts the first DC (RWDC/RODC) (through LDAP ping, UDP:389) and does whatever it needs to do. It moves to the next DC, when the previous does not respond and if another DC exists. When there are no more site specific DCs, it performs the steps in [2]
      
   4. Based upon the IP Address of the computer (and without using its subnet mask!), the RWDC/RODC will check if it can match the IP address of the computer to an AD subnet (as specific as possible).
      
      1. Assuming the RWDC/RODC can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC/RODC will tell the computer in which AD site the computer is in, in which AD site the RWDC/RODC is in and the "close proximity bit" specifying if the RWDC/RODC is in the same AD site as the AD client.
         
      2. If the RWDC/RODC cannot match the IP address of the computer to an AD subnet OR if it can match the IP address to an AD subnet but the AD subnet is not linked to an AD site (in this case the AD client moved to a new AD site, got a new IP address, but the AD subnet was not defined yet or the AD subnet was not linked to an AD site), the RWDC/RODC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug). In the case of an RODC, it that RODC does not have the password cached of the computer, the RODC will then forward authentication to the RWDC with which the RODC has setup the secure channel
         
2. It DOES NOT know the AD site it is in, OR site specific DCs are not responding
   
   1. It queries DNS with "_ldap._tcp.dc._msdcs.<FQDN AD DOMAIN>"
      
   2. DNS returns a list of DCs that have registered the domain-wide SRV records for <FQDN AD DOMAIN> (By default this will be done by all RWDCs in the AD domain. In scenarios where datacenters are used with branches, it is a best practice to configure RWDCs in the branches not to register domain-wide SRV records. RODCs do not register domain-wide SRV records by default, and again by default register only the site-wide SRV records and also do not perform automatic site coverage.)
      
   3. The computer contacts the RWDC (through LDAP ping, UDP:389).
      
   4. Based upon the IP Address of the computer (and without using its subnet mask!), the RWDC will check if it can match the IP address of the computer to an AD subnet (as specific as possible)
      
      1. Assuming the RWDC can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC will tell the computer in which AD site the computer is in, in which AD site the RWDC is in and the "close proximity bit" specifying if the RWDC is in the same AD site as the AD client. Assuming it can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC will tell the computer in which AD site the computer is in, in which AD site the RWDC is in. The computer will then repeat the process as specified in option [1] above.
         
      2. If the RWDC cannot match the IP address of the computer to an AD subnet OR if it can match the IP address to an AD subnet but the AD subnet is not linked to an AD site, the RWDC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug)
         

When a user then logs on to the computer, the AD domain information and the AD site information known to the computer will be used to find a DC and authenticate the user. So if the computer knows in which AD site it is in, to authenticate the user it will query DNS with "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN AD DOMAIN>" and follow the steps as specified above in [1].

The steps above apply for authentication WITHIN the same AD forest and also BETWEEN AD forests or BETWEEN AD domains in different AD forests.

The following two scenarios exist, for which the steps are very very similar:

• User is logged on to computer in the same AD domain as the user and the user wants to access a resource in a different AD forest/domain (over an AD Forest Trust or an AD External Trust)
  
• User from one AD domain is logging on to a computer in another AD domain (over an AD Forest Trust or an AD External Trust)
  

Taking the first scenario as an example. When a user is logged on to the computer and the user wants to access a resource in another AD forest, it will query DNS with the following query: "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN OTHER AD DOMAIN>". Although it uses the FQDN of the AD forest the resource is in, it will use the AD site of the computer it is logged on to. If the AD site also exists in the other AD forest, then the steps as mentioned in step 1 will be used. If the AD site does not exist in that other AD forest, then the steps as mentioned in step 2 will be used, but then using <FQDN AD OTHER DOMAIN>. However, step 2d will be a little bit different. Based upon the IP address of the computer the RWDC of the other AD forest/domain will check if it can match the IP address of the computer to an AD subnet (as specific as possible) in the other AD forest .

[.A.] Assuming it can match the IP address to an AD subnet in the other AD forest and the AD subnet is linked to an AD site in the other AD forest, the RWDC will tell the computer in which AD site the computer is in in the other AD forest, in which AD site the RWDC is in and the "close proximity bit" specifying if the RWDC is in the same AD site as the AD client. The computer will then repeat the process as specified in step [1] above, but using the AD site in the other AD forest, OR…

[.B.] If the RWDC in the other AD forest cannot match the IP address of the computer to an AD subnet in the other AD forest OR if it can match the IP address to an AD subnet in the other AD forest but the AD subnet in the other AD forest is not linked to an AD site in the other AD forest, the RWDC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug).

Within the same AD forest, if you get the "NO_CLIENT_SITE" error, it is not recommended to ignore this. To get rid of these errors make sure an AD subnet exists and that it is linked to an AD site. However, between AD forests it is very likely that this error occurs because the AD subnet structure and/or the AD site structure is different. Even if a match can be made, it may not even be the most optimal one to use. as the meaning of each AD site may be different. If you can ignore these errors or not between AD forest depends on the specific scenario.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2010-05-19) Locating Domain Controllers To Access The Default Domain DFS (SYSVOL/NETLOGON)

In the case of locating a DC to access the SYSVOL/NETLOGON, the authN DC creates two referral lists. The first list contains the DCs (in random order) from the same AD site of the AD client. The second list contains all the other DCs outside the AD site of the AD client.

The order of the second list is in random order when "Site Costed Referrals" are NOT enabled

The order of the second list is NOT in random order, but rather ordered based upon the (cumulative) site link costs with the AD client’s AD site as a reference, when "Site Costed Referrals" are enabled

"Site Costed Referrals" are NOT enabled by default on W2K3 SP1/R2 DCs. Requires registry setting.

"Site Costed Referrals" are enabled by default on W2K8/W2K8R2 DCs

However, for "Site Costed Referrals" to work for the default domain DFS (SYSVOL/NETLOGON) or custom DFS namespaces [1], the following MUST be TRUE:

• A correct definition and implementation of the AD sites/subnets/site link costs
  
• "Bridge All Site Links" (BASL) MUST be enabled so that Intersite Messaging can be used to calculate the cost matrix for the site-costing functionality [2]
  
• Each AD site must have an ISTG defined to be able to generate the cost-matrix the site-costing functionality [3]
  

[1] The configuration for "Site Costed Referrals" for the default domain DFS and the custom DFS namespaces is done in a different way!

For default Domain DFS, on every DC:

• Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
  
• Registry value name: SiteCostedReferrals
  
• Registry value type: REG_DWORD
  
• Registry value data: 1
  

For custom DFS namespaces:

• Namespace properties –> Referrals tab –> Folder properties –> Referrals tab
  
• The three ordering methods are:
  
• Random order
  
  • Targets in the same Active Directory site as the client are listed in random order at the top of the referral.
    
  • Next, targets outside of the client’s site are listed in random order.
    
  • If no same-site target servers are available, the client computer is referred to a random target server no matter how expensive the connection is or how distant the target is.
    
• Lowest cost
  
  • Targets in the same site as the client are listed in random order at the top of the referral.
    
  • Next, targets outside of the client’s site are listed in order of lowest cost to highest cost. Referrals with the same cost are grouped together and within each group the targets are listed in random order.
    
• Exclude targets outside of the client’s site
  
  • In this method, the referral contains only the targets that are in the same site as the client. These same-site targets are listed in random order. If no same-site targets exist, the client does not receive a referral and cannot access that portion of the namespace.
    

[2] However, if do not want the ISTG/KCC to create replication connection objects to DCs in, for example, other Branch Offices because the network is not fully routed, you must turn off the "Bridge All Site Link" option on the IP container. BUT…this will impact the usage of Intersite Messaging to calculate the cost matrix for the site-costing functionality. There is a way to solve this though! When the FFL is at least W2K3 (interim) and the ISTG in an AD site is at least W2K3SP1, it is possible to disable Intersite Messaging for the ISTG (disabling auto site link bridging) and enable Intersite Messaging to calculate the cost matrix. This is done by:

• Enabling the "Bridge All Site Link" option
  
• For each AD site where you need to accommodate site-costing, execute the command "REPADMIN /SITEOPTIONS /SITE:<SITENAME> +W2K3_BRIDGES_REQUIRED". This option can be executed on ANY DC for ANY AD site, but it only takes effect as soon as the ISTG in the corresponding AD site takes notice of its new configuration
  

This applies to BOTH default domain DFS and the custom DFS namespaces!

[3] AD sites with an RWDC automatically have an ISTG and also have an automatic failover process. By default the very first RWDC in an AD site always becomes the ISTG. The selection of a new ISTG depends on the FFL. AD sites with an RODC do not have ISTG because RODCs do not register as one. Register an RODC as ISTG manually so that it is able to calculate the cost-matrix for the site-costing functionality. Downside is that there is not auto failover when the RODC becomes unavailable or is replaced by another RODC.

More info about DC Locator:

• DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 1
• DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 2
• DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 3

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2009-08-05) Different GPOs For HUBs And For Branch DCs

If you are using writable DCs (RWDCs) in Branch Offices you want to optimize authentication as best as possible by:

• Allowing HUB DCs (DCs in datacenters) to register ALL possible service records (domain-wide and site wide) and therefore service whatever AD client that requests authentication
  
• Allowing Branch Office DCs to register ONLY service records for site-wide authentication and therefore service only clients in the same AD site as the DC itself
  

REMARK: RODCs by default only register site-wide SRV records, so for an RODC this is not needed!

Registration of SRV records for RWDCs happens automatically by default and by default ALL SRV records are registered. So you have to tell the DC NOT to register certain SRV records. With regards to the Dc locator process I suggest you also read the following posts:

• DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 1
• DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 2
• DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 3

This post is HOW to tell a DC NOT to register certain SRV records. You have a few options:

1. Configure the registry of RWDCs in question
   
2. Keep RWDCs in Domain Controllers OU and use different GPOs including group filtering
   
3. Create one child OU in the Domain Controllers OU, put the BO RWDCs in that child OU, use separate GPO linked to that child OU which reconfigures the registration of the SRV records for those RWDCs
   
4. Create multiple child OUs, put each BO RWDC in its own child OU, use separate GPO for each child OU linked to that child OU which reconfigures the registration of the SRV records for those RWDCs
   

AD.(1)

In W2K you had to configure the registry of each BO RWDC. Another solution was to create your custom ADM file and load that in the GPO that was targeting the BO RWDCs as specified in (2), (3) or (4). The main disadvantage was that custom ADM files tattoo the registry, meaning that undoing the setting was done through the usage of an exact reverse/opposite setting.

AD.(2)

In W2K3 new GPO settings were introduced for this, so it was not need to use custom ADMs. The default available ADMs did not tattoo the registry whereas undoing meant you have to remove the GPO setting and set it to NOT CONFIGURED.

So to use this option you could do the following:

• Create a Global Security Group (e.g. "GSG_HUB-DCs") for the DCs in the HUB locations
  
• Add ALL HUB DCs (non-BO DCs) as member to that group
  
• Create a new GPO (e.g. "Branch Office DCs GPO Settings") and link it to the Domain Controllers OU
  
• For the GPO "Branch Office DCs Settings" configure which DC locator records should NOT be registered
  
  • "Computer Configuration\Administrative Templates\System\Net Logon\DC Locator\DNS Records"
    
    • "DC Locator DNS records not registered by the DCs"
      
      • Dc DcByGuid Gc GcIpAddress GenericGc Kdc Ldap LdapIpAddress Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd
        
• For the GPO "Branch Office DCs Settings" configure DENY READ & APPLY for the global security group "GSG_HUB-DCs"
  
• Make sure the order of applying GPOs is:
  
  • "Default Domain Controller" GPO
    then
    
  • "Branch Office DCs Settings" GPO
    

The procedure for this is:

• Adding a new HUB RWDC:
  
  • Install Windows Server and promote to DC
    
  • Computer account automatically added to Domain Controllers OU
    
  • Add new HUB DC to group "GSG_HUB-DCs" (if you forget this step the new HUB DC will behave as a BO DC by first applying the Default Domain Controllers GPO and then the "Branch Office DCs GPO Settings" GPO. It will therefore only auth. clients which query DNS for DCs that provide site-wide auth. for THAT site.
    
  • Done!
    
• Adding a new BO RWDC:
  
  • Install Windows Server and promote to DC
    
  • Computer account automatically added to Domain Controllers OU
    
  • Done!
    

REMARK: the thought here is that it is most likely to add an additional or new BO RWDC then a HUB RWDC. You can of course turn it around and use the group for BO RWDCs and the group then needs READ+APPLY and you need to remove APPLY for Auth. Users.

AD.(3)

I do not have much problem of creating child OUs beneath the Domain Controllers OU. As long as you keep the DC computers accounts within the scope of that OU there should be no problem. Besides that, some apps that expect the accounts to be directly in the Domain Controllers OU (e.g. DCDIAG will report an error about this, but in the case of a child OU you can ignore it)

So to use this option you could do the following:

• Create ONE new child OU beneath the Domain Controllers OU
  
• Create a new GPO (e.g. "Branch Office DCs GPO Settings") and link it to the new child OU
  
• For the GPO "Branch Office DCs Settings" configure which DC locator records should NOT be registered
  
  • "Computer Configuration\Administrative Templates\System\Net Logon\DC Locator\DNS Records"
    
    • "DC Locator DNS records not registered by the DCs"
      
      • Dc DcByGuid Gc GcIpAddress GenericGc Kdc Ldap LdapIpAddress Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd
        

The procedure for this is:

• Adding a new HUB RWDC:
  
  • Install Windows Server and promote to DC
    
  • Computer account automatically added to Domain Controllers OU
    
  • Done!
    
• Adding a new BO RWDC:
  
  • Install Windows Server and promote to DC
    
  • Computer account automatically added to Domain Controllers OU
    
  • Move computer account to child OU for BO RWDCs (if you forget this step, the new BO RWDC will also auth. clients which query DNS for DCs that provide domain-wide auth.)
    
  • Done!

 

AD.(4)

This option can become quite a mess as you end up with a separate child OU and a separate GPO (or link one GPO to multiple OUs, but then what is the value of having multiple OUs?) for each BO having an RWDC. I do not recommend going for this option.

If I had to make a choice it would be either [2] or [3]. Choose whatever is easier for you to manage. If you ask Microsoft you will most likely hear to use [2].

!!! You should NOT (NEVER!!!) create multiple OUs under the Domain Controllers OU to delegate permissions to "non-Domain Admins"!!!

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2007-07-02) DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 3

This is the 3^rd and last part of "DC Locator Process in W2K, W2K3(R2) and W2K8"

Until now I talked about locating a DC for authentication. What I did not talk about yet is locating the SYSVOL to apply GPOs and to use the legacy NETLOGON share. Let’s see how that works.

Each AD domain contains one system domain DFS that allows access to the SYSVOL and NETLOGON share. After a computer or user has been authenticated a referral is requested at the authenticating DC for \<Domain Name><SYSVOL or NETLOGON>. The authenticating DC creates two lists being one list with random referrals IN the same AD site as the computer/user and one list with random referrals OUTside the AD site of the computer/user. As you can see the authenticating DC is not by default (it can be however) also the DC that provides access to the SYSVOL or NETLOGON shares. It can thus be another DC in the same AD site as the computer/user that will provide access to the SYSVOL or NETLOGON shares. To make sure the authenticating DC in the same AD site as the computer/user is at the top of the DFS referrals in-site list an update needs to be installed on the DCs and a registry configuration needs to be made on the same DCs. For more information see MS-KBQ831201.

In addition to installing the update on the DCs the following configuration needs to be made on the DCs to put the authenticating DC on top of the DFS referrals list:

• Registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dfs\Parameters
  
• Registry value name: PreferLogonDC
  
• Registry value type: REG_DWORD
  
• Registry value data: 1
  

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8.

It gets even worse if a computer/user is authenticated outside its AD site because its DC is not available or because it is a DC-less AD site. In that situation it will use ANY DC to gain access to the SYSVOL or NETLOGON shares and in the worst case it will use some DC on the other side of the world with the tiniest WAN link you can imagine. That kinda sucks!

For both W2K and W2K3 a solution exist so that the referral process uses the nearest referral based upon site link costs. To achieve this the following is needed:

• For W2K SP4 (!) DCs
  
  • Install update as mentioned in MS-KBQ823362
  • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Driver
    
  • Registry value name: DfsEnableSmartClient
    
  • Registry value type: REG_DWORD
    
  • Registry value data: 1
    
• For W2K3(R2) DCs and later:
  
  • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
    
  • Registry value name: SiteCostedReferrals
    
  • Registry value type: REG_DWORD
    
  • Registry value data: 1
    

To determine DFS referral information:

• DFSUTIL /SPCINFO
  
• DFSUTIL /PKTINFO
  

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8. If it is the most probably you need to use the W2K3 configuration

Now imagine the client used a DFS referral for the SYSVOL or NETLOGON outside of its AD site because its local DC was not available for some reason. Of course you want the client to fallback to its local DC in the AD site as soon as it becomes available to either access the SYSVOL or NETLOGON share. But will it do that? No! It will use the DFS referral outside its AD site until it is rebooted or its cached is reset. W2K3 SP1 allows a client to fallback to its local DFS referral target as soon as it becomes available again and it needs to access the SYSVOL or NETLOGON share.

On W2K3 SP1 DCs and later:

• Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
  
• Registry value name: SysvolNetlogonTargetFailback
  
• Registry value type: REG_DWORD
  
• Registry value data: 1
  

On WXP SP2 clients and W2K3 SP1 servers:

• Install the "DFS Client Failback QFE" (MS-KBQ898900)
  

For additional information, make sure to have a look at:

• SRV record
  
  • http://en.wikipedia.org/wiki/SRV_record
• How to verify that SRV DNS records have been created for a domain controller
  
  • http://support.microsoft.com/?kbid=816587
• SRV Resource Records
  
  • http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbc_nar_sdns.mspx?mfr=true
• How to optimize the location of a domain controller or global catalog that resides outside of a client’s site
  
  • http://support.microsoft.com/?kbid=306602
• How DFS Works
  
  • http://technet2.microsoft.com/windowsserver/en/library/a9096e88-1634-4da6-b820-537341d349061033.mspx?mfr=true

Additional interesting links:

• Windows Server 2008 Home
  
  • http://www.microsoft.com/windowsserver/2008/default.mspx
• Windows Server 2008 Product Overview
  
  • http://www.microsoft.com/windowsserver2008/evaluation/overview.mspx
• Windows Server 2008 Wiki Info
  
  • http://en.wikipedia.org/wiki/Windows_Server_2008
• Live WebCasts
  
  • http://www.microsoft.com/events/webcasts/upcoming.mspx
• Microsoft Technical Communities
  
  • http://www.microsoft.com/communities/default.mspx

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2007-07-01) DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 2

This is the 2^nd part of "DC Locator Process in W2K, W2K3(R2) and W2K8"

Looking at this all, the DC locator process as explained above still applies to Windows Vista and to Windows Server 2008 and later. Are there any differences or additions? Yes, there are!

Basically the client either queries for a DC in the AD site it is in or it queries for a DC in the AD domain it is in. I have always asked myself why the DC locator process did not support following the site topology based on the site cost to find the next closest DC for authentication. The answer to that is unknown to me, but both Windows Vista and Windows Server 2008 provide an additional possibility that exists between "a DC in the AD site" (the closest end) and "a DC in the AD domain" (the far end). The new possibility is "a DC in the next closest site". 😉

Both Windows Vista and Windows Server 2008 still use the default behavior W2K, WXP, W2K3(R2) have. For both Windows Vista and Windows Server 2008 to locate a DC in the next closest site, it needs to be enabled explicitly. That can be done by using the following:

• For WVT/W2K8 and later:
  
  • GPO setting path: "Computer Configuration\Administrative Templates\System\Net Logon\DC Locator DNS Records"
    
  • GPO setting: "Try next closest site"
    
  • GPO setting mode: Enabled
    

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate the client:

• NLTEST /DSGETDC:<FQDN DOMAIN>
  

To determine a writable DC within a set of DCs in the next closed AD site from the client’s perspective that could authenticate the client:

• NLTEST /DSGETDC: <FQDN DOMAIN> /WRITABLE /TRY_NEXT_CLOSEST_SITE
  

Continued in part 3 of the "DC Locator Process in W2K, W2K3(R2) and W2K8"

For additional information, make sure to have a look at:

• SRV record
  
  • http://en.wikipedia.org/wiki/SRV_record
• How to verify that SRV DNS records have been created for a domain controller
  
  • http://support.microsoft.com/?kbid=816587
• SRV Resource Records
  
  • http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbc_nar_sdns.mspx?mfr=true
• How to optimize the location of a domain controller or global catalog that resides outside of a client’s site
  
  • http://support.microsoft.com/?kbid=306602
• How DFS Works
  
  • http://technet2.microsoft.com/windowsserver/en/library/a9096e88-1634-4da6-b820-537341d349061033.mspx?mfr=true

Additional interesting links:

• Windows Server 2008 Home
  
  • http://www.microsoft.com/windowsserver/2008/default.mspx
• Windows Server 2008 Product Overview
  
  • http://www.microsoft.com/windowsserver2008/evaluation/overview.mspx
• Windows Server 2008 Wiki Info
  
  • http://en.wikipedia.org/wiki/Windows_Server_2008
• Live WebCasts
  
  • http://www.microsoft.com/events/webcasts/upcoming.mspx
• Microsoft Technical Communities
  
  • http://www.microsoft.com/communities/default.mspx

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2007-06-30) DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 1

This is the 1^st part of "DC Locator Process in W2K, W2K3(R2) and W2K8"

By default a client that knows in what AD site it is in, will ask for a DC in that same site by querying DNS with:

• _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD>
  

By default all DCs in AD site <SITE> will register that DNS SRV record. If no DCs are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. The DCs in the site list are in a random order and provided by the DNS round robin mechanism.

If a client does not know in what site it is in, it will ask for a DC in that same domain by querying DNS with:

• _ldap._tcp.dc._msdcs. <DOMAIN>.<TLD>
  

By default all writable DCs in AD domain <DOMAIN> will register that DNS SRV record. The writable DCs in the domain list are in a random order and provided by the DNS round robin mechanism. Read-Only DCs (RODCs) in Windows Server 2008 will not register domain-wide SRV records. RODCs only register SRV records for the AD site they are in.

To determine the AD site of a client:

• NLTEST /DSGETSITE
  

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate/service the client:

• NLTEST /DSGETDC:<FQDN DOMAIN>
  

So if you look at the situation where a client queries for a DC in the domain because it does not know in what AD site it is in, it can be somewhat interesting when you find out the client is communicating with some DC on the other side of the world. Not really efficient! In HUB and SPOKE environments this can be a problem. It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices (SPOKES) and the datacenter (HUB) are not that fast. To prevent that situation, it is a best practice to allow the DCs in the datacenters (HUB) register whatever SRV record and allowing the DCs in the branch offices (SPOKES) to register only their site specific SRV records. That way when a client queries for a DC in the domain it will be serviced by one of the DCs in the datacenter (HUB) and NOT in some branch office far far way!

This same situation occurs when a client is joined to the domain using the GUI. At that moment the client does not know its site and it will thus query for A DC in the domain to create its computer account. Guess what, after the clients reboots you might experience authentication problems because the computer account was created at a DC in branch office X while the client is in branch office Y. The issues will go away as soon as the computer account replicates from branch office X to the datacenter and from the datacenter to branch office Y. How long that takes depends on your AD site and replication topology. By using the configuration explained above, the computer account will be created on a DC in the datacenter. That way it only needs to replicate from the datacenter to the branch office. To target the correct AD site where the client will based it is better to use the command-line tool NETDOM. Using that command-line tool you can specify a DC in the AD site where the client will based AND you can specify in what OU the computer account should be placed. The syntax is:

• NETDOM JOIN %COMPUTERNAME% /DOMAIN:<DOMAIN><DC> /OU:<distinguished name of OU> /USERD:<DOMAIN><USER> /PASSWORDD:<PASSWORD>
  
  • REMARK: I specify %COMPUTERNAME% instead of the computername because this command needs to be executed locally on the client/server that needs to be joined to a domain
    

Because DCs by default register all SRV records, you need to configure the branch office NOT to register certain records. W2K DCs do not have a GPO setting to do the configuration, so you need to configure the registry locally. To prevent that you can still create your own ADM file. W2K3 DCs do have a special GPO setting to make the configuration.

To Configure Domain Controllers or global catalogs to Not Register Generic (domain wide) Records

• For W2K DCs
  
  • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
    
  • Registry value name: DnsAvoidRegisterRecords
    
  • Registry value type: REG_MULTI_SZ
    
  • Registry value data: <list of ENTER-delimited mnemonics>
    
• For W2K3(R2)/W2K8 DCs and later:
  
  • GPO setting path: "Computer Configuration\Administrative Templates\System\Net Logon\DC Locator DNS Records"
    
  • GPO setting: "DC Locator DNS records not registered by the DCs"
    
  • GPO setting mode: Enabled
    
  • GPO setting value: <list of SPACE-delimited mnemonics>
    

List of "mnemonics" that should not be registered by branch office DCs:

• Dc
  
• DcByGuid
  
• Gc
  
• GcIpAddress
  
• GenericGc
  
• Kdc
  
• Ldap
  
• LdapIpAddress
  
• Rfc1510Kdc
  
• Rfc1510Kpwd
  
• Rfc1510UdpKdc
  
• Rfc1510UdpKpwd
  

UPDATE:

If you have configured your branch office DCs to not register domain-wide specific records, the clients will use those DCs and fail over to the datacenter if the local DC becomes unavailable. However if the local DC comes back online the client keeps using the datacenter DC until the client is restarted or the datacenter DCs become unavailable for some reason. Apparently it does not rediscover its local DC is available again. MS-KBQ939252 provides a hotfix and registry configuration for Windows XP (SP1 & SP2) and Windows Server 2003 (SP1 & SP2). The registry configuration is the ability to configure a discovery interval for the locator process. Make sure you also see MS-KBQ247811, as there it mentions: "After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client."

Continued in part 2 of the "DC Locator Process in W2K, W2K3(R2) and W2K8"

For additional information, make sure to have a look at:

• SRV record
  
  • http://en.wikipedia.org/wiki/SRV_record
• How to verify that SRV DNS records have been created for a domain controller
  
  • http://support.microsoft.com/?kbid=816587
• SRV Resource Records
  
  • http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbc_nar_sdns.mspx?mfr=true
• How to optimize the location of a domain controller or global catalog that resides outside of a client’s site
  
  • http://support.microsoft.com/?kbid=306602
• How DFS Works
  
  • http://technet2.microsoft.com/windowsserver/en/library/a9096e88-1634-4da6-b820-537341d349061033.mspx?mfr=true

Additional interesting links:

• Windows Server 2008 Home
  
  • http://www.microsoft.com/windowsserver/2008/default.mspx
• Windows Server 2008 Product Overview
  
  • http://www.microsoft.com/windowsserver2008/evaluation/overview.mspx
• Windows Server 2008 Wiki Info
  
  • http://en.wikipedia.org/wiki/Windows_Server_2008
• Live WebCasts
  
  • http://www.microsoft.com/events/webcasts/upcoming.mspx
• Microsoft Technical Communities
  
  • http://www.microsoft.com/communities/default.mspx

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————