Thursday, June 30, 2011

Building Fault-Tolerant Windows Server 2008 R2 Systems - Designing Fault-Tolerant IP Networks

Network design can also incorporate fault tolerance by creating redundant network routes and by utilizing technologies that can group devices together for the purposes of load balancing and device failover. Load balancing is the process of spreading requests across multiple devices to keep individual device load at an acceptable level. Failover is the process of moving services offered on one device to another upon device failure, to maintain availability. Common scenarios for creating fault-tolerant IP networks can include, but are not limited to, the following:

» Acquiring multiple network connections between the data center and the Internet—This includes using different Internet service providers and, hopefully, each of the connections is not connected to the same external telco box on the street as this becomes the single point of failure if hit by a car, truck, or cut off from communications.

» Deploying multiple and redundant firewalls, virtual private networks (VPNs), and network routers that will failover to one another—This usually involves software or hardware configurations that allow each of the devices to communicate with one another to detect failures. These devices, when deployed in redundant configurations, can be leveraged in an active/passive configuration where only a single primary device is used and the secondary device only comes online when the primary fails. Alternatively, in many cases these devices can be used in an active/active configuration that disperses or distributes the load and requests across each device and when a single device fails, the remaining device handles the entire load.

» Deploying critical servers with multiple network adapters connected to separate network switches—This allows a server to be connected and available on different switches in case a single network card in the server fails or if the port or the entire network switch or blade fails.

» Deploying hardware-based NLB devices—Many network switches, routers, and certain devices created just for this purpose can provide some, if not all, of the functionality included in Windows Server 2008 R2 NLB. This, of course, might be the best choice for load balancing at the network level when organizations deploy and support systems other than Windows Server 2008 R2 and when they also need to load-balance network devices, such as firewalls and VPN devices.

» Deploying servers with multiple network adapters using third-party network teaming software—This configuration uses third-party software installed and configured on a server to create a new virtual network adapter that is used to provide access to the server system through a single or all of the physical network adapters on the server that are part of this configuration. Windows Server 2008 R2 supports teamed network adapters as long as the drivers and software are certified to work with Windows Server 2008 R2.

If the Windows Server 2008 R2 system utilizes iSCSI storage, the network adapters designated for iSCSI communications are not supported on teamed network adapters.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Monday, June 27, 2011

Building Fault-Tolerant Windows Server 2008 R2 Systems - Powering the Computer and Network Infrastructure

Powering Windows Server 2008 R2 servers and network hardware with battery or generator- backed power sources not only provides these devices with conditioned line power by removing voltage spikes and providing steady line voltage levels, but it also provides alternative power when unexpected blackouts or brownouts occur. Many organizations cannot afford to implement redundant power sources or generators to power the offices, data centers, and server rooms. For these organizations, the best approach to providing reliable power to the computer and network infrastructure is to deploy uninterruptible power supplies (UPSs) with battery-backed power. With a UPS, power is normally supplied from the batteries, which are continually charged by the utility line power. When the line power fails, a properly sized UPS provides ample time for end users to save their data to the server and to gracefully shut down the server or network device without risk of damaging hardware or corrupting data. UPS manufacturers commonly provide software that can send network notifications, run scripts, or even gracefully shut down servers automatically when power thresholds are reached. Of course, if end-user data is important, each end-user workstation and the network switches that connect these workstations to the computer and network infrastructure should also be protected with UPSs that can provide at least 5 to 10 minutes of battery-backup power.

One final word on power is that most computer and network hardware manufacturers offer device configurations that incorporate redundant power supplies designed to keep the system powered up in the event of a single power supply failure.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Thursday, June 23, 2011

Windows Server 2008 R2 System-Level Fault Tolerance (Clustering/Network Load Balancing)

Many businesses today rely heavily on their computer and network infrastructure. Internet access, email, instant messaging, file and print services, and networking services such as domain name system (DNS), Dynamic Host Configuration Protocol (DHCP), and virtual private networking are just a few of the core computer and networking services that are critical to many businesses. If one of these critical systems is down or unexpectedly offline, the impact to the business can be huge. When businesses cannot withstand extended periods of unexpected or unplanned downtime, deploying a fault-tolerant computer and network infrastructure might be necessary.

Windows Server 2008 R2 provides several methods of improving system- and service-level fault-tolerance by leveraging some of the roles, role services, and features included in the different editions of the operating system. The Distributed File System (DFS) can be used to create and deploy redundant and automatically synchronized file data through DFS shares and DFS Replication. Another example of providing redundant services is to design an infrastructure that includes multiple domain controllers and print services in each major site and for remote sites, configuring the Active Directory site properties to utilize remote site domain controllers when local services become unavailable.

Windows Server 2008 R2 provides many functions and services that can extend and enhance the reliability and resilience of computer and networking services. Many services, however, are only available when deployed on specific hardware platforms and when deployed on the Enterprise or Datacenter Editions of Windows Server 2008 R2. This chapter covers system level fault tolerance using Windows Server 2008 R2 Network Load Balancing (NLB) and failover clusters. NLB is available in Standard, Enterprise, and Datacenter Editions of Windows Server 2008 R2. Failover clusters are available only in the Enterprise and Datacenter Editions of Windows Server 2008 R2. These built-in clustering technologies provide load-balancing and failover capabilities that can be used to increase fault tolerance for many different types of applications and network services. Each of these clustering technologies is different in many ways. Choosing the right Windows Server 2008 R2 clustering technology depends on the services and applications that will be hosted by the cluster.

Windows Server 2008 R2 technologies such as NLB and failover clusters improve fault tolerance for services, but before these clustering technologies can be leveraged effectively, basic server or system stability best practices must be used.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Monday, June 20, 2011

Using the Volume Shadow Copy Service

The Windows Server 2008 R2 Volume Shadow Copy Service (VSS) is a feature available for NTFS volumes. VSS is used to perform a point-in-time backup of an entire volume to the local disk. This backup can be used to quickly restore data that was deleted from the volume locally or through a network-mapped drive or network file share. VSS is also used by Windows Server Backup and by compatible third-party backup applications to back up local and shared NTFS volumes.

VSS can make a point-in-time backup of a volume, including backing up open files. This entire process is completed in a very short period of time but is powerful enough to be used to restore an entire volume, if necessary. VSS can be scheduled to automatically back up a volume once, twice, or several times a day. This service can be enabled on a volume that contains DFS targets and standard Windows Server 2008 R2 file shares.


Using VSS and Windows Server Backup
When the Windows Server Backup program runs a backup of a local NTFS volume, VSS is used by default to create a snapshot or shadow copy of the volume’s current data. This data is saved to the same or another local volume or disk. The Backup program then uses the shadow copy to back up data, leaving the disk free to support users and the operating system. When the backup is complete, the shadow copy is automatically deleted from the local disk. One important point is that in order for VSS backups to work properly, shadow copies should be enabled on every volume and enough free space should exist to store the shadow copies. Even if the schedule is set to once a year, enabling shadow copies on the volume defines the shadow copies with the Volume Shadow Copy provider and reduces VSS errors on backups.


Configuring Shadow Copies
Enabling shadow copies for a volume can be very simple. Administrators have more options when it comes to recovering lost or deleted data and, in many cases, can entirely avoid restoring data to disk from a backup tape device or tape library. In addition, select users can be given the necessary rights to restore files that they’ve accidentally deleted.
The Volume Shadow Copy Service is already installed and is automatically available using NTFS-formatted volumes.

To enable and configure shadow copies, follow these steps:

1. Log on to the Windows Server 2008 R2 system with an account with administrator privileges.

2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.

3. In the tree pane, double-click the Storage node, and select Disk Management.

4. In the tasks pane, scroll down to locate the desired volume, right-click the volume, and select Properties.

5. Select the Shadow Copies tab, and in the Select a Volume section, click on the desired volume, and click the Settings button.

6. The Settings page allows you to choose an alternate volume to store the shadow copies. Select another volume to store the shadow copies in line with best practices
and set the storage space limit for the shadow copies. The default is usually set to
10% of the volume size; accepting the defaults is recommended.

7. After the location and maximum size are configured, click the Schedule button and define the schedule. The defaults create a shadow copy at 7:00 a.m. and 12:00 p.m., but for this example, set up an additional shadow copy to run at 5:00 p.m.

8. Click OK to close the Schedule window and click OK again to close the Volume Shadow Copy Settings window. The shadow copy for the originally selected volume is now enabled.

9. If necessary, select the next volume and enable shadow copying; otherwise, click the Create Now button to create the initial shadow copy.

10. If necessary, select the next volume and immediately create a shadow copy by clicking the Create Now button.

11. After the shadow copies are created, click OK to close the Disk Volume window, close Server Manager, and log off the server.


Recovering Data Using Shadow Copies
The server administrator or a standard user who has been granted permissions can recover data using previously created shadow copies. The files stored in the shadow copy cannot be accessed directly, but they can be accessed by connecting the volume that has had a shadow copy created.

To recover data from a file share, follow these steps:

1. Log on to a Windows Server 2008 R2 system, Windows XP SP1, or later workstation with either administrator rights or with a user account that has permissions to restore the files from the shadow copy.

2. Click Start and select Run or type in the server and share name in the Search pane.

3. At the Run prompt or Search pane, type \\servername\sharename, where servername represents the NetBIOS or fully qualified domain name of the server hosting the file share. The share must exist on a volume in which a shadow copy has already been created.

4. When the folder opens, right-click on the folder that contains the data that will be restored and select Properties.

5. When the window opens, if necessary, select the Previous Versions tab, select the desired folder version, and click the Open button.

6. An Explorer window then opens, displaying the contents of the folder when the shadow copy was made. If you want to restore only a single file, locate the file, rightclick it, and select Copy.

7. Open the server share location in which the restored file will be placed, right-click, and choose Paste. Overwrite the file as required and close all the windows as desired.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Saturday, June 18, 2011

Backing Up DFS

Administrators do not need to perform any special steps to back up DFS data other than backing up the actual data in the folders as well as the System State of the servers that host and participate in the DFS namespace. The following elements should be backed up:

» Folder Target data— This is the actual data that is being accessed by end users. With a true multimaster replication topology, only one target needs to be backed up for each DFS folder target.

» DFS hierarchy— For standalone DFS namespaces, the System State of the root server and System State of all servers containing DFS targets should be backed up. For domain-based DFS namespaces, the System States of domain controllers and all other servers containing DFS targets should be backed up. Active Directory stores all the DFS hierarchy and DFSR replication connection information. Active Directory is backed up with the domain controller System State.

To back up the DFS Hierarchy only, the DFSutil can be used to export the settings. To perform this task, follow these steps:

1. Log on to the Windows Server 2008 R2 system that has the DFS services installed, with an account with local server administrator privileges.

2. Click Start, Run; then type cmd in the search pane and press Enter to open a Command Prompt window.

3. In the Command Prompt window, type dfsutil domain companyabc.com and press Enter to list all of the namespaces in the companyabc.com domain as an example. For our example, we returned the Apps name space located at \\companyabc.com\apps.

4. Once the namespace name is determined, type dfsutil root export \\companyabc.com\apps c:\dfs-export-namespace-Apps.xml and press Enter to export this namespace.

5. In the Command Prompt window, type c:\dfs-export-namespace-Apps.xml to review the exported information.

This process should be performed on all DFS server and domain-based namespaces for reference. Also, this file can be used to migrate a DFS namespace from a set of namespace servers to a different set of servers by deleting the original namespace, editing this file, and using the dfsutil root import command.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Thursday, June 16, 2011

Managing and Troubleshooting DFS

DFS can be managed through the DFS Management console included in the Windows Server 2008 R2 Administrative Tools program group and in the Server Manager console. DFS can also be managed in a command-line environment using the DFS command-line utilities. These utilities include the following:

» DfsUtil — Can be used to manage DFS namespaces, servers, and clients. DfsUtil can also be used to export DFS namespaces to XML files so they can be migrated to new systems.

» DfsCmd — Can be used to manage the folders and targets within an existing DFS namespace.

» DfsrAdmin — Can be used to perform actions on existing DFS Replication groups, including adding new replication group folders and generating reports on existing replicated folder members.

» DfsrDiag — Can be used to force replication, stop replication, or report on replication health.

Using the DFS management console, DFS standalone and domain-based roots can be shown and managed in a single DFS console window. The administrator can check DFS root and folder targets for availability by checking the Connection status of all targets for a particular replication group. Using the DFS Management console, a DFS administrator can also create a DFS Replication Diagnostic report. To create a diagnostic report for replication, perform the following steps:

1. Open the DFS Management console and expand it.

2. Double-click on Replication to reveal the desired replication group. If the desired replication group is not shown, right-click the Replication node, select Add Replication Groups to Display, and follow the steps to add the desired group.

3. Right-click the desired replication group, and select Create Diagnostic Report.

4. When the Diagnostic Report Wizard window opens, select either the health report,
propagation test, or propagation report, and click Next.

5. If a report was selected, the report will be saved to the c:\DFSReports folder with a default name; if necessary, change the report name and location and click Next.

6. On the Members to Include page, add or remove the desired folder target servers for the report, and click Next.

7. On the Options page, select the desired options for the report details, to count or not count backlogged files and whether or not to count the replicated files and folders, including data set size on each member, and click Next.

8. Review the selections and if everything looks correct, click Create to generate and display the report.

9. The report will be displayed in the default browser; close the browser and DFS Management console when you are finished.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Tuesday, June 14, 2011

Best Practices for DFS Replication

Following best practices for DFS Replication can help ensure that replication occurs as expected. Because file replication is triggered by a file version change or last-saved or modified time stamp, a standard file share might generate many replication changes, which can saturate the network bandwidth if no bandwidth constraints are placed within DFS Replication connections. To avoid such scenarios, follow as many of these suggestions as possible:

» Start with empty DFS namespace folders and targets to keep from having to replicate any data at the root level. Also, this can simplify the restore process of a DFS root folder because it contains only folders that are managed by DFS.

» Do not replicate data between DFS namespace shares because the namespace shares will try to replicate the data in the namespace folders as well as the data contained within the folder targets. Replication is not necessary if the folder targets are already replicating. Because the roots will not replicate for redundancy, deploy domain DFS namespaces and add additional namespace servers.

» Back up at least one DFS folder target and configure the backup to not update the archive bit. Changing the archive bit might trigger unnecessary replication.

» Thoroughly test server operating system antivirus programs to ensure that no adverse effects are caused by the scanning of files on a replicated DFS target. Also, configure server antivirus to scan at write operations only and configure clients to scan on read operations to ensure complete antivirus protection for DFS servers and clients.

» Verify that the drive that will contain the staging folder for a replication connection contains ample space to accept the amount of replicated data sent and received by the server.

Having a high number of read-write operations is not desirable because it causes heavy replication, and in a scenario like this, DFS Replication should be performed during offpeak hours unless Windows Server 2008 R2 DFS Replication can be used in conjunction with bandwidth constraints.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Friday, June 10, 2011

Creating a DFS Folder and Replication Group

Creating a DFS folder is similar to creating the DFS root. A folder can be created to target existing shares or folders beneath shares, or a new share can be created on the desired server or servers. As recommended previously, pre-create the file share on an NTFS folder and properly configure the share and NTFS permissions for each folder target that will be added to the folder.

When a new folder is created with multiple folder targets, a replication group can be created at the same time. To create a folder within an existing namespace, perform the following steps:

1. Log on to the Windows Server 2008 R2 system with an account with local server administrator privileges.

2. Pre-create and set NTFS permissions on the servers and shares that will host the DFS namespace folder.

3. Click Start, click All Programs, click Administrative Tools, and select DFS Management.

4. Select the Namespaces node, and then double-click the Namespaces node to expose the existing namespaces.

5. If the desired namespace does not appear, in the Actions pane, click on the Add Namespaces to Display link and follow the steps to search for and add an existing namespace to the console view.

6. Select the desired existing namespace, and in the Actions pane, click on the New Folder link.

7. When the New Folder window opens, type in the name of the folder and click the Add button to locate the folder targets.

8. After all the folder target servers have been added to the New Folder window, click OK to continue.

9. When a new folder is created and multiple targets are specified, a Replication pop-up window opens, asking if a replication group should be created. Click Yes to create a new replication group for the folder targets.

10. When the Replication Group and Replicate Folder Name window opens, review the name of the proposed replication group name and the replicated folder name, and click Next to continue. The prepopulated names will match the namespace and folder names.

11. The Replication Eligibility page will display whether or not each of the folder targets are capable of DFS Replication. If all targets are eligible, click Next to continue.

12. On the Primary Member page, click the Primary Member drop-down list arrow and select the folder target server that will be used to populate the remaining member folder targets. The data that exists in the folder of the primary target member will be replicated to each of the other targets. After selecting the desired primary server, click Next to continue.

13. On the Topology Selection page, select the desired replication topology. For this example, select the Hub and Spoke option button, and click Next to continue.

14. On the Hub Members page, all servers will initially be listed in the Spoke Member section. Double-click the desired servers to move them to the Hub Member section, if they will be used as a hub server. Hub servers will replicate with all other servers and spoke servers will only replicate with the hub servers defined on this page. Once all the necessary hub servers are in the Hub Member section, click Next to continue.

15. On the Hub and Spoke Connections page, each of the spoke servers will be listed with their required hub member and an optional hub member. Optional hub members will only be populated if multiple servers are selected as hub members in the previous step. Even though the hub servers are listed as required and optional, the spoke servers will replicate with both and a connection between each hub server and spoke system will be created. Also, hub servers will replicate with one another as well.

16. On the Replication Group Schedule and Bandwidth page, select the desired bandwidth limitation if desired or set the hours replication to allowed, and click Next to continue.

17. On the Review Settings and Create Replication Group page, review the selections and if everything looks correct, click Create.

18. On the Confirmation page, if the replication group creation tasks were all completed successfully, click Close. Otherwise, select the Errors tab and review and repair the errors, and rerun the Replication Group Creation Wizard.

19. Once the window is closed, back in the DFS Management console, double-click on the Replication node to reveal the new replication group and select it.

20. In the tasks pane, with the new replication group selected in the tree pane, select the Connections tab to review the connections created from the previous steps.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Wednesday, June 8, 2011

Adding an Additional Namespace Server to a Domain-Based Namespace

After a domain namespace has been successfully created, it is a best practice to add an additional server to host the namespace. To add an additional server to an existing domain-based namespace, perform the following steps:

1. Log on to the Windows Server 2008 R2 system with an account with local server administrator privileges. If a domain DFS namespace and root will be configured, ensure that the account has the necessary permissions to the DFS-Configuration container and child objects in Active Directory.

2. Pre-create and set NTFS permissions on the servers and shares that will host the DFS namespace root.

3. Click Start, click All Programs, click Administrative Tools, and select DFS Management.

4. Select the Namespaces node, and then double-click the Namespaces node to expose the existing namespaces.

5. If the desired namespace does not appear, in the Actions pane, click on the Add
Namespaces to Display link and follow the steps to search for and add an existing namespace to the console view.

6. Select the desired existing namespace, and in the Actions pane, click on the Add Namespace Server link.

7. Type in the name of the server, and click OK to continue.

8. If the share already exists, click OK on the pop-up window to use the existing share and existing share permissions. If the share does not exist, it will be created under c:\DFSRoots\ by default.

9. In the tasks pane, select the Namespace Servers tab to verify that the additional namespace server was successfully added. Also note that at the top of the pane, it shows that the namespace is a domain-based in Windows Server 2008 mode.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Monday, June 6, 2011

Creating the DFS Namespace and Root

When creating a DFS namespace, the administrator requires local Administrator group access on each of the servers hosting the namespace, and if a domain namespace is selected, the administrator also requires domain-level permissions because the domain name space information is stored in Active Directory.

A DFS namespace root requires a file share. When the DFS root is created, the name can be matched to an existing file share name or a custom name can be selected. The wizard searches the specified server for an existing file share matching the DFS root name; if it does not locate one, the wizard can create the share as part of the process. As a best practice, the file share should be created and have shared and NTFS permissions configured prior to the DFS namespace creation. One thing to keep in mind, though, is that the share name must match the DFS namespace name. Reconfiguring the NTFS permission will help simplify troubleshooting and administration of the namespace.

Before attempting to create a new DFS namespace, if the DFS services have just been installed, ensure that the DFS services are running. In addition, for the DFS Management console to appear in Server Manager, all instances of Server Manager might have to be closed and reopened before following the proceeding steps.

To create a DFS namespace and root, follow these steps:
1. Log on to the Windows Server 2008 R2 system with an account with local server administrator privileges. If a domain DFS namespace and root will be created, ensure that the account has the necessary permissions to the DFS-Configuration container in Active Directory.

2. Pre-create the share and set share and NTFS permissions on the servers and shares that will host the DFS namespace root.

3. Click Start, click All Programs, click Administrative Tools, and select DFS Management.

4. Select the Namespaces node, and in the Actions pane, click on the New Namespace link.

5. When the New Namespace Wizard opens, type in the name of the server that will host the namespace, and click Next.

6. On the Namespace Name and Settings page, type in the name of the share previously created, and click Next.

7. A pop-up window opens, asking whether the existing share should be used. Click Yes to use the previously configured share.

8. On the Namespace Type page, to create a domain-based namespace, select the appropriate option button and check the Enable Windows Server 2008 Mode check box to enable scalability and allow for access-based enumeration within the namespace.

9. On the Review Settings and Create Namespace page, review the namespace settings and if everything looks correct, click Create to start the namespace creation.

10. On the Confirmation page, if the result status is reported as a success, click Close to complete the process. If the creation failed, select the Errors tab to review the issues, repair the problems, and attempt the namespace creation again.

The initial DFS root name must match the name of the file share created previously. If the share does not exist, the wizard will prompt you to create a file share from an existing folder or a new folder. Although the wizard can simplify the process by automating this task, it does not provide a method of configuring NTFS permissions.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Thursday, June 2, 2011

DNS in an Active Directory Domain Services Environment

DNS is inseparable from Active Directory. In fact, the two are often confused for one another because of the similarities in their logical structures.

Active Directory uses a hierarchical X.500-based structure that was designed to map into the DNS hierarchy, hence the similarities. In addition, Active Directory utilizes DNS for all internal lookups, from client logons to global catalog lookups. Subsequently, strong consideration into how DNS integrates with Active Directory is required for those considering deploying or upgrading AD.


The Impact of DNS on Active Directory Domain Services
Problems with DNS can spell disaster for an Active Directory environment. Because all servers and clients are constantly performing lookups on one another, a break in name resolution service can severely affect Active Directory functionality.

For this and other reasons, installing a redundant DNS infrastructure in any Active Directory Domain Services implementation is strongly recommended. Even smaller environments should consider duplication of the primary DNS zone, and nearly as much emphasis as is put into protecting the global catalog AD index should be put into protecting DNS.

Security considerations for the DNS database should not be taken for granted. Secure updates to AD-integrated zones are highly recommended, and keeping DHCP servers off a domain controller can also help to secure DNS. In addition, limiting administrative access to DNS will help to mitigate problems with unauthorized “monkeying around” with DNS.


Active Directory Domain Services in Non-Microsoft DNS Implementations
Active Directory Domain Services was specifically written to be able to coexist and, in fact, utilize a non-Microsoft DNS implementation as long as that implementation supports dynamic updates and SRV records. For example, AD will function in all versions of UNIX BIND 8.1.2 or higher. With this point in mind, however, it is still recommended that an organization with a significant investment in Microsoft technologies consider hosting Active Directory DNS on Windows Server 2008 R2 systems because functionality and security enhancements provide for the best fit in these situations.

For environments that use older versions of DNS or are not able (or willing) to host Active Directory clients directly in their databases, Active Directory DNS can simply be delegated to a separate zone in which it can be authoritative. The Windows Server 2008 R2 systems can simply set up forwarders to the foreign DNS implementations to provide for resolution of resources in the original zone.


Using Secondary Zones in an AD DS Environment
Certain situations in Active Directory require the use of secondary zones to handle specific name resolution. For example, in peer-root domain models, where two separate trees form different namespaces within the same forest, secondaries of each DNS root were required in Windows 2000 to maintain proper forestwide synchronization. Because each tree in a peer-root model is composed of independent domains that might not have security privileges in the other domains, a mechanism will need to be in place to allow for lookups to occur between the two trees. The creation of secondary zones in each DNS environment will provide a solution to this scenario. Windows Server 2008 R2 now has the option of replicating these separate trees to all DNS servers in the forest, reducing the need for secondary zones. Replicating secondary zones outside of a forest is still sometimes necessary, however. Conditional forwarding and stub zones can also be used in certain cases to achieve a similar result without the need for data replication.


SRV Records and Site Resolution
All Active Directory Domain Services clients use DNS for any type of domain-based lookups. Logons, for example, require lookups into the Active Directory for specific SRV records that indicate the location of domain controllers and global catalog servers. Windows Server 2008 R2, as previously mentioned, divides the location of the SRV records into a separate zone, which is replicated to all domain controllers that have DNS installed on them.

Subdomains for each site are created in this zone; they indicate which resource is available in those specific sites. In a nutshell, if an SRV record in the specific site subdomain is incorrect, or another server from a different site is listed, all clients in that site are forced to authenticate in other sites. This concept is important because a common problem is that when Active Directory sites are created before they are populated with servers, an SRV record from the hub location is added to that site subdomain in DNS. When a new server is added to those sites, their SRV records join the other SRV records that were placed there when the site was created. These records are not automatically deleted, and they consequently direct clients to servers across slow wide area network (WAN) links, often making logon times very slow.

In addition to the site containers, the root of these containers contains a list of all domain controllers in a specific domain. These lists are used for name resolution when a particular site server does not respond. If a site domain controller is down, clients randomly choose a domain controller in this site.


GlobalNames Zone
In some cases, using a fully qualified domain name (FQDN) is not convenient for the end users. This is especially true for novice users or in the case of very long domain names. A user entering the uniform resource locator (URL) http://intranet.convergentcomputing.com is quite likely to make a mistake in the typing. The WINS name resolution provides relief from this, in that single-label names can be used instead. This allows the user to type the URL http://intranet and still reach the desired resource.

However, with the advent of IPv6, WINS will no longer be supported as the new addressing is deployed throughout the organization. There are also many advantages of DNS over WINS, including reducing administrative overhead, single name resolution repository, security, and open standards.

Windows Server 2008 R2 provides a feature that was introduced in Windows Server 2008 to address this problem, specifically the GlobalNames zone (GNZ). This zone provides single-label name resolution via a DNS zone, similar to WINS. The zone is a normal forward lookup zone, albeit with a special name (GlobalNames), and is used by the DNS server in a special way. If the DNS server is unable to resolve an address in its local zones, it will then resolve the single-label address against the GlobalNames zone. The GNZ holds out the promise of finally doing away with WINS and NetBIOS naming.

To configure the GlobalNames zone, execute the following steps:
1. Launch Server Manager.

2. Expand the Roles, DNS Server, and DNS nodes, and then select the server name.

3. Select the Forward Lookup Zones node.

4. Select Action, New Zone.

5. Click Next on the Welcome page.

6. Select Primary Zone and make sure that the Store the Zone in Active Directory check box is checked. Click Next.

7. Select To All DNS Servers in This Forest, and click Next.

8. Enter the Zone name GlobalNames and click Next.

9. Leave the default Dynamic Update setting and click Next.

10. Click Finish to create the zone.

11. Open a command prompt and enter the command dnscmd /config
/EnableGlobalNamesSupport 1. The message “Registry property
EnableGlobalNamesSupport successfully reset” should be returned. This command
must be run on each DNS server that is expected to resolve GlobalNames, regardless
of if the zone is replicated to them already.

Now the GlobalNames zone is ready to respond to queries. For any server that needs to respond to single-label queries, enter a CNAME record in the GlobalNames zone with the appropriate FQDN for the resource. The DNS server will try the GlobalNames zone after trying other local zones.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)