Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Windows Server 2003 on HP ProLiant Servers : Server Placement (part 1) - DNS Placement, Site Affinity

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
4/22/2013 5:27:53 PM

The location of file, print, and application servers depends on a variety of factors, including user population, required accessibility, and more. The inclusion of application partitions in Windows 2003, shows the potential of allowing applications to take advantage of Lightweight Directory Access Protocol (LDAP) services and to replicate application date via Active Directory (AD) replication.

Another solution is the Microsoft Active Directory Application Mode (ADAM) product. ADAM could well be named “Active Directory Lite” because it provides pure LDAP Directory Services (DS) and replication for applications. With ADAM, Microsoft has decoupled DS from the Network Operating System (NOS) directory that AD represents. ADAM requires Windows 2003. This is similar to how application partitions work, except ADAM does not require the intervention of DCs or AD. Thus, applications can be installed on member servers. Another advantage is that each ADAM session has its own schema, so application owners can update their individual schemas without affecting other applications. Multiple instances of ADAM can run on a single server, making very powerful and flexible application servers. The down side of ADAM is that it can't use Domain Name Server (DNS) SRV records to locate servers. For additional information about ADAM, download the whitepaper from Microsoft at http://www.microsoft.com/windowsserver2003/techinfo/overview/adam.mspx.

1. DNS Placement

Although the Windows community has more than four years of Windows 2000 experience, there is still a lot of difference of opinion regarding placement of DNS server. A large number of deployments I've seen specify every DC to be a DNS. I suppose it's a natural progression to make all DCs DNS server as well, but this isn't necessary. Typically, DNS server—at least caching-only servers—are placed in remote sites or sites across slow links to provide DNS name resolution on a more reliable basis than connecting to remote DNS server, which is a good practice.

However, just blindly making every DC a DNS is not following good design practices. My experience working in troubleshooting DNS problems over the past four plus years has taught me three things about DNS and AD:

  • DNS is really a simplistic service, at least in relation to AD.

  • Sometimes we make DNS structure more complicated than it needs to be. The simpler you make the DNS structure, the better it will work and the fewer problems you'll have.

  • The more ADI (Active Directory Integrated) DNS server you have, the more potential problems you have.

This list would indicate that making every DC a DNS is not a good idea. If you analyze each situation and it happens that every DC should be a DNS, that's fine. For instance, if all of your remote sites have a single DC, it makes sense that they should also be DNS server if the links are slow or unreliable.

HP has three domains worldwide and employs three DNS ADI servers per domain. Thus, only three DNS server for North, South, and Central America; three more for Europe, the Middle East, and Africa; and three more for Asia-Pacific. In the Qtest environment at HP, we have a similar configuration, and place those DNS server in sites on or, one hop from, the corporate backbone.

Note that ADI DNS stores the DNS records in the AD. Thus, even if all the DNS server in a domain become unavailable, you can simply install DNS on another DC, and the zone will be populated. Of course, to complete the transformation you would need to do the following:

  • Configure the new DNS with the IP (Internet Protocol) address of the old one (and give the old DNS a new IP address)

    OR

  • Configure all the clients (workstations, servers, DCs, other DNS server) to point their resolvers to the new DNS server's IP address. This could be done easily for DHCP clients.

The first option is usually the easiest, because it avoids having to change the DNS resolver on all the clients. This built-in redundancy caused one company I know of to move from UNIX BIND for its corporate DNS structure to Windows 2000.

Consider these points when determining how many DNS server to deploy and where to deploy them.

2. Site Affinity

Windows 2000 introduced the Site Affinity feature to allow clients who request services from a DC or a GC to contact a DC or a GC in their local site. This could be for authentication, access to Distributed File System (DFS) shares, GC searches, Exchange GC access, and many other applications. Although DCs have to be associated with a site, a site doesn't necessarily have to have a DC in it. DC-less sites often cannot justify a DC, but want to have Site Affinity defined for the benefit of applications such as DFS.

When designing sites without DCs, it's important to note that AD employs auto site coverage. Site coverage is an algorithm that defines a DC in one site to provide services to clients in another site that has no DC. This DC responds to a request as if it were indeed in the same site as those clients. This means that clients in the DC-less site authenticate to the DC that is “covering” that site. Because DCs have domain boundaries, this principle also applies to clients that are members of a domain for which there are no DCs for that domain in the client's site. Thus, if the clients in the Atlanta site were members of the B.A.com domain, but there was only a DC for the A.com domain in Atlanta, the clients would authenticate to a DC in another site that is a member of B.A.com and is covering Atlanta for that domain.

In terms of design, Site Affinity follows the least-cost path rule. For instance in Figure 1, four sites—Atlanta, San Francisco, Charlotte, and San Jose—are all in a single domain. Only Atlanta and San Francisco have DCs. The costing has been constructed so that the DC in Atlanta covers Charlotte, and the DC in San Francisco covers San Jose. This is true because the cost from Charlotte to Atlanta is 50 and Charlotte to San Francisco is 70, and likewise from San Jose to San Francisco is 50 and to Atlanta is 70.

Figure 1. A well-designed cost structure allows Site Affinity to be forced to preferred DCs for DC-less sites.


One customer I worked with had been the victim of bad information and it nearly caused the company to implement a poor design. With more than 200 physical locations, the company had DCs in only about 15 sites. However, the company wanted to implement Site Affinity for clients in all sites. The “Automatic Site Coverage” section of the Distributed Systems Guide (in the Windows 2000 Resource Kit) describes the site-coverage process. It specifies that sites that have no DCs for a particular domain are “covered”by a DC for that domain in another site. The “closest” DC is defined as a DC in a site that has the least-cost path to the DC-less site. For example, if a user from Domain A logs into the Boston site, and there are no DCs for Domain A in Boston (or none respond), the Knowledge Consistency Checker (KCC) determines the closest site that has a DC for Domain A by evaluating the site cost to that site from Boston. Now, if the KCC determines that 2 sites have Domain A DCs, and they both have the same cost from Boston, then there are a couple of tie-breaker rules. The rules are the site with the most DCs will cover the DC-less site and, if that fails, then the site whose name is highest in alphabetical order will provide coverage.

This customer decided to put all sites in a single site link, DefaultIPSiteLink, and let the KCC use these tie-breaker rules to determine site coverage. The company also wanted all the sites in the United States to be affiliated with the New York site, all the sites in Europe to be affiliated with the London site, and all the sites in Asia to be affiliated with Singapore or Tokyo.

This could never work reliably. The company's own testing determined that the tie-breaker rules didn't always work as expected (remember these are for tie-breakers, not design points). Even if the rules did work, it's highly unlikely the company could ever get lucky enough to have the Site Affinity to New York, London, Singapore, or Tokyo as desired.

Throwing all sites in one basket, letting the KCC sort them out, and having it all work out in a certain way is virtually impossible—unless you happen to get lucky once or twice. The solution was simply to create a multi-tier topology with site links, as shown in Figure 2. Note that New York is the first tier; London, Singapore, Tokyo, and Amsterdam are in the second tier; and DC-less sites are in the third tier. Site links were assigned costs according to their tier level, forcing replication up the tree to the core sites. This forced a DC-less site in Berlin to be covered by the Amsterdam DC who replicates with the central hub in New York. Under the original design using the tie-breaker rules, all site link costs were equal, and because there are more DCs in NYC than Amsterdam, Berlin would have had automatic site coverage provided by the DCs in NYC.

Figure 2. Site link costing is used to define site coverage for DC-less sites as well as for replication for sites with DCs.

Note that designing Site Affinity for DC-less sites follows the same rules as if they were sites with DCs. Use explicit site links and costing to force replication (and site coverage) in the way you want it to go. Designing Site Affinity really isn't that hard. It took this company a couple of weeks of testing and it still didn't have the answer. It took me about an hour and a half to do it the right way.
Other -----------------
- Managing SharePoint 2010 with Windows PowerShell : Managing SharePoint 2010 Sites (part 2)
- Managing SharePoint 2010 with Windows PowerShell : Managing SharePoint 2010 Sites (part 1)
- System Center Configuration Manager 2007 : Reporting Configuration (part 3) - Console Reporting Links, Relational Database Concepts
- System Center Configuration Manager 2007 : Reporting Configuration (part 2) - Copying ConfigMgr Classic Reports to SQL Reporting Services, Report Categories
- System Center Configuration Manager 2007 : Reporting Configuration (part 1) - Configuring the Reporting Point for Classic Reporting, SRS Reporting
- System Center Configuration Manager 2007 : ConfigMgr Classic Reports Versus SQL Reporting Services
- Deploying the Client for Microsoft Exchange Server 2007 : Deploying with Microsoft Systems Management Server, Managing Postdeployment Tasks
- Deploying the Client for Microsoft Exchange Server 2007 : Installing the Exchange Client, Pushing Client Software with Windows Server 2003 Group Policies
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from Dynamics CRM to BizTalk Server (part 3) - Registering the plugin, Testing the plugin
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from Dynamics CRM to BizTalk Server (part 2) - Writing the Dynamics CRM plugin
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server