Why you should not use yourdomain.local domain?

Microsoft recommended use of .local domain when Microsoft released Microsoft Small Business Server. Microsoft also understood that an SBS customer may not have in house expertise to manage Active Directory Domain and Exchange Server. Microsoft understood that SBS user will not have proper firewall. It is obvious that Exchange autodiscovery, single sign on for SharePoint and Lync Server was not in scenario at that time. So Microsoft recommended use of .local domain in Active Directory. Those who worked in SBS environment thought that they could take that concept now and implement .local domain in any organization which is a fundamental design flaw.

You have to understand  that .local domain was a past concept. Moving forward technology has changed a lot since then. You should change yourself when technology changes. But when I visit clients I see that old dog doesn’t learn new trick. Which means their autodiscovery doesn’t work. These clients end up with many issues including blaming Microsoft. You should ask yourself did you design your Active Directory and DNS correctly. Why you expect your autodiscovery to function correctly when your DNS is messy?

When you are promoting a new domain or a new forest, it is highly recommended that you use registered domain name for example yourdomain.com.au. Again those who worked in past SBS era they will raise concern of hacking, TLD etc. I would address their concern by putting the question to them, did you design and configure a correct firewall and security in your corporate infrastructure. If not then you should hire a security professional who will address your concern. Simply promoting a yourdomain.local domain will not secure your domain and you will have a false sense of security that your Active Directory is safe. In realty your corporate network might be open and vulnerable to hacking.

Here are why you should use yourdomain.com.au or registered domain in Active Directory.

  • To implement correct Exchange Autodiscovery
  • To discover correct registered domain for SharePoint and Lync Server
  • To implement single sign on
  • To install correct public certificates for Exchange, SharePoint and Lync. Note that Public Certificate Authority no longer issue certificate using .local domain
  • To use correct UPN of your registered domain
  • To setup correct local and public DNS
  • To design correct Active Directory. You shouldn’t use SBS server as your model. Microsoft retired SBS for many reasons. Brutal truth is Microsoft didn’t want to lose poor customer who couldn’t afford an open license or software assurance so most of SBS users got OEM license through hardware vendor or a reseller.
  • To follow the guidelines of IANA and IEEE when you deal with a domain.

What should you do if you already have a .local domain in SBS server?

If your SBS server is 2008, then create an Active Directory DNS zone using registered domain example: yourdomain.com.au then add HOST (A) record with PTR of webmail or mail and autodiscovery in yourdomain.com.au zone. Create public DNS record for webmail.yourdomain.com.au and autodiscover.yourdomain.com.au.

http://www.yourdomain.com.au (example registered domain) doesn’t resolve after creating yourdomain.com.au?

This happened when http://www.yourdomain.com.au is hosted with third party web hoster not internally. There is an easy fix, create a DNS forwarder or conditional forward for your http://www.yourdomain.com.au. Follow this URL to configure a conditional forwarder. For example: you can forward http://www.yourdomain.com.au to Google DNS server or the DNS server of your ISP or your web hoster who is actually hosting http://www.yourdomain.com.au. To find out who is hosting your website and their DNS record, go to https://www.easywhois.com/ type yourdomain.com.au and hit enter.

Further Study:

http://microsoftguru.com.au/2011/05/28/microsoft-active-directory-best-practice/ 

http://microsoftguru.com.au/2012/07/29/microsoft-active-directory-best-practice-part-ii/

http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html 

http://technet.microsoft.com/en-us/library/cc757172%28v=ws.10%29.aspx

http://technet.microsoft.com/en-us/library/cc754941.aspx

http://technet.microsoft.com/en-us/library/cc794735%28v=ws.10%29.aspx

Windows Server Patching Best Practices

This article provides actionable advice about how to manage patches to reduce downtime while still maintaining the security of software services through the proactive reduction of dependencies and the use of workaround solutions.

Patching Requirements

Windows Server patches, hotfixes and service pack is critical for compliance, service level agreement and security purposes. Keeping an operating systems and application up to date is the key to align your infrastructure with latest software. Patches and hotfixes also enable you to prevent any security breaches and malware infection.

Windows Patch Classification

The following are strongly recommended patches:

  1. Critical
  2. Security
  3. Definition Updates for malware
  4. Service packs

Windows Product Classification

It is highly recommended that you patch Windows Servers, Windows Clients, Office, Applications (Silverlight, .Net Framework, SQL, Exchange, SharePoint, FF TMG).

Patching Groups

Consultants should take time to test the patches in a non-production environment prior to being deployed to production. This will help to gauge the impact of such changes. Ideally you will have the following patching groups:

1. UAT (UAT1, UAT2, etc)

2. Test Environment (Test1, Test2, etc)

3. Development Environment (Dev1, Dev2 etc)

4. Production (Prod1, Prod2, etc)

If you have clustered environment like SQL, Exchange and SharePoint then create Prod1, prod2 group and place each node on each group.

Change Management

System administrators should maintain a log, written or electronic, of all changes to the operating environment, to include hardware, system security software, operating system, and applications. Prior to any changes being implemented on a system, the system administrator should receive approval of stakeholders.

Backup

Why am I discussing backup with patching best practice? In case of emergency you can rollback completely and restore a server to its original state if necessary. It is very important that servers be backed up on a regular basis. Depending on the use of the server, it may be adequate to backup the server once per week. A backup of a more critical environment may be needed daily, and possibly continuously. The backup program provided with Windows is capable of backing up to virtually any writable media, which can include network drives provided by a server in another physical location. This program is also capable of scheduling backups which can ensure backups occur on a regular interval.

Microsoft strongly recommends that you create the following backups before you install an update rollup, service pack and patch on Exchange and SQL:

  • A full backup of all databases on the server.
  • A full backup of transaction log and log backup
  • A system state backup of the server.
  • A snapshot of virtualized exchange server. Delete snapshot after successful patching and updating.

Application Compatibility

Read release notes of each hotfixes you are going to apply so that you are compliant with the application installed on the server. Consult with application vendor before applying service pack to any server if the server is hosting specific business application. Consult with application engineer about the importance of server patching. Inform and educate application engineer as much as possible to avoid conflict of interest.

Documentation

Documentation released with the updates is usually in the form of web pages, attached Word documents and README.TXT files. These should be printed off and attached to change control procedures as supporting documentation.

Back out Plan

A back-out plan will allow the system and enterprise to return to their original state, prior to the failed implementation. It is important that these procedures are clear, and that contingency management has tested them, because in the worst case a faulty implementation can make it necessary to activate contingency options. Historically, service packs have allowed for uninstalling, so verify there is enough free hard disk space to create the uninstall folder. Create a back out plan electronically and attach with change management software.

User Notifications

You need to notify helpdesk staff and support agencies of the pending changes so they may be ready for arising issues or outages.

Consistency across Servers

Always install the same service packs or hotfixes to each SQL server node, Exchange DAG member and Domain Controller.

Routine Maintenance Window

A scheduled maintenance window must be agreed with business so that application outage and server reboot can maintain a respectable Service Level Agreement (SLA). If you have a large infrastructure with thousands of servers and many regions working round the clock then you must consider application dependencies. A patching schedule can be considered in between every Friday of every month at 6:00 P.M. Friday to 6:00 A.M Monday. Setup maintenance window in system center or deadline for WSUS to make sure patches are applied when you want instead of when patch is available. In this way you will have a complete control over change windows approved by change advisory board (CAB). Do not allow end users to update patches on their client machine according to their wishes and happiness! then user will never install any patch.

Patching Tools

I strongly recommend that you spend few $$$ to buy Microsoft System Center 2012 to manage and deploy Windows patches, service pack and hotfixes. However you can use Windows Server Update Services (WSUS) as poor man’s patching solutions.

Patching DMZ server can be accomplished using WSUS offline patching solutions available for free to download from http://download.wsusoffline.net/.

Automate, Automate and Automate!

Automated patch management using System Center could enable a single IT administrator to access a pre-populated patch policy. He then could execute the command and with the press of a single button, download the patches from Microsoft’s website, install them on a test machine and test for compatibility issues. Meanwhile, an automatic inventory check could search for systems with the affected software, wake them up, check their readiness and push the verified patches out to waiting machines. The patches would then be automatically installed on each system, and they’d reboot as necessary. The final step is an automated report on the status of the remediated devices.

Standardize Patch Management Processes

Standardized patch management processes could allow for daily assessment and remediation of client devices and weekly assessment and remediation for servers. Reports can then be generated to validate system status on a weekly or bi-weekly schedule. A systems monitoring task that used to take days now takes minutes, and patches are deployed more completely and consistently across the entire IT environment. A single IT administrator can proactively manage thousands of systems tasks in the same amount of time it took an entire team to do the tasks manually.

Reboot Windows Computer

Some application may require reboot of server before patching such as RSA Secure Console. However most of the server must be rebooted after patching. Do not suppress reboot after patching in any circumstances or you will have a messy environment and broken clusters.

X86 and X64 Windows Systems

The most prominent 32-bit application you’re likely to see on a 64-bit Windows system is Office. In this sort of situation System Center benefits most because you can adjust and make decision based on architecture and compliance as well. You can approve patches based on “Needed and Not Installed”. If a server or client need update it will install if not then it will not installed. It’s safe to do so.

Antivirus and Antispyware

Servers are vulnerable to many forms of attack. Implementation and standardization of security methods should be developed to allow early and rapid deployment on servers. It’s important that a Windows server be equipped with a latest centrally managed Antivirus program. Antivirus update must be scheduled with the same maintenance window to update antivirus with latest definition.

Audit Practices

Servers have a powerful auditing feature built in. Typically, server managers would want the auditing system to capture logins, attempted logins, logouts, administrative activities, and perhaps attempts to access or delete critical system files. Auditing should be limited to gathering just the information that is needed, as it does require CPU and disk time for auditing to gather information. Log Management software should be used, if possible, for ease of managing and analysing information. Report can be generated from Systems Center and WSUS as proof of patching cycle.

Log Retention

Servers keep multiple logs and, by default, may not be set to reuse log file entries. It is a good practice to expand the size of the allowed log file and to set it to reuse space as needed. This allows logging to continue uninterrupted. How far back your log entries go will depend on the size of the log file and how quickly you are accumulating log data. If your server environment is critical, you may wish to ensure that the log file size is sufficient to store about 30 days of logging information, and then rotate log files once per month.

Installing Updates on a single Exchange Server

Download Exchange Update from Microsoft Download Center. Record Current Exchange Version information

Check for publisher’s certificate revocation

1. Start Internet Explorer.

2. On the Tools menu, click Internet Options.

3. Click the Advanced tab, and then locate the Security section.

4. Clear the Check for publisher’s certificate revocation check box, and then click OK.

5. After the update rollup installation is complete, select the Check for publisher’s certificate revocation option.

Pre-check before installing

1. Determine which update rollup packages are installed on your Exchange server roles

2. Determine whether any interim updates are installed

3. Review interim updates

4. Obtain the latest update rollup package

5. Apply on a Test Exchange Server

Install Exchange Update

1. Ensure that you have downloaded the appropriate rollup to a local drive on your Exchange servers, or on a remote network share.

2. Run the Windows Installer *.msp Setup file that you downloaded in step 1.

Install Exchange Update on DAG Member

To update all DAG members, perform the following procedures on each DAG member, one at a time. Set the member server in maintenance mode using this PowerShell Command.

.StartDagServerMaintenance.ps1 <ServerName>

Install the update rollup

1. Close all Exchange management tools.

2. Right-click the Exchange update rollup file (.msp file) you downloaded, and then select Apply.

3. On the Welcome page, click Next.

4. On the License Terms page, review the license terms, select I accept the License Terms, and then click Next.

5. On the Completion page, click Finish.

Once installed exit from maintenance mode run the StopDagServerMaintenance.ps1 script. Run the following command to re-balance the DAG, as needed

.RedistributeActiveDatabases.ps1 -DagName <DAGName> -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

When the installation is finished, complete the following tasks:

  • Start the Services MMC snap-in, and then verify that all the Exchange-related services are started successfully.
  • Log on to Outlook Web App to verify that it’s running correctly.
  • Restore Outlook Web App customizations, and then check Outlook Web App for correct functionality.
  • After the update rollup installation is complete, select the Check for publisher’s certificate revocation option in Internet Explorer. See “Certificate Revocation List” earlier in this topic.
  • Check Exchange 2010 version information
  • View Update rollup in Control Panel>Programs and Features

Patching Microsoft Failover Cluster

You can install Windows service packs on Windows Server Failover Cluster nodes using the following procedure. Administrative privilege is required to perform the following tasks.

Procedure to install Windows service pack or hotfixes in Windows Server 2003:

  1. Check the System event log for errors and ensure proper system operation.
  2. Make sure you have a current backup and updated emergency repair disk for each system. In the event of corrupt files, power outage, or incompatibility, it may be necessary to revert back to the state of the system prior to attempting to install the service pack/hotfixes.
  3. Expand Node A, and then click Active Groups. In the left pane, right-click the groups, and then click Move Group to move all groups to Node B.
  4. Open Cluster Administrator, right-click Node A, and then click Pause Node.
  5. Install the service pack on Node A, and then restart the computer.
  6. Check the System event log for errors. If you find any errors, troubleshoot them before continuing this process.
  7. In Cluster Administrator, right-click Node A, and then click Resume Node.
  8. Right-click Node B, and then click Move Group for all groups owned by Node B to move all groups to Node A.
  9. In Cluster Administrator, right-click Node B, and then click Pause Node.
  10. Install the service pack on Node B, and then restart the computer.
  11. Check the system event log for errors. If you find any errors, troubleshoot them before continuing this process.
  12. In Cluster Administrator, right-click Node B, and then click Resume Node.
  13. Right-click each group, click Move Group, and then move the groups back to their preferred owner.

Procedure to install Windows service pack or hotfixes in Windows Server 2008 and Windows Server 2012:

  1. Check the event log for errors and ensure proper system operation.
  2. Make sure you have a current backup and updated emergency repair disk for each system. In the event of corrupt files, power outage, or incompatibility, it may be necessary to revert back to the state of the system prior to attempting to install the service pack/hotfixes.
  3. On Node A, Expand Services and Applications, and then click the service or application
  4. Under Actions (on the right), click Move this service or application to another node, then choose the node or select Best possible.
  5. In the Failover Cluster Manager snap-in, right-click Node A, and then click Pause.
  6. Install the service pack/hotfixes on Node A, and then restart the computer.
  7. Check the event log for errors. If you find any errors, troubleshoot them before continuing this process.
  8. In Failover Cluster Manager snap-in, right-click Node A, and then click Resume.
  9. Under Actions (on the right), click Move this service or application to another node, then choose the node.
    Note: As the service or application moves, the status is displayed in the results pane (in the center pane). Follow the Step 9 and 10 for each service and application configured on the cluster.
  10. Install the service pack/hotfixes on Node B, and then restart the computer.
  11. Check the event log for errors. If you find any errors, troubleshoot them before continuing this process.
  12. From the Failover Cluster Manager snap-in, right-click Node B, and then click Pause.
  13. In Failover Cluster Manager, right-click Node B, and then click Resume.
  14. Right-click each group, click Move Group, and then move the groups back to their preferred owner.

You can use the following PowerShell Cmdlet to accomplish the same.

1. Load the module with the command: Import-Module FailoverClusters

2. Suspend (Pause) activity on a failover cluster nodeA: Suspend-ClusterNode nodeA

3. Move a clustered service or application (a resource group) from one node to another: Get-ClusterNode NodeA | Get-ClusterGroup | Move-Cluster Group

4. Resume activity on nodeA that was suspended in step 5: Resume-ClusterNode nodeA

5. Move a clustered service or application (a resource group) from one node to another: Get-ClusterNode NodeB | Get-ClusterGroup | Move-Cluster Group

6. Suspend (Pause) activity on other failover cluster node: Suspend-ClusterNode nodeB

7. Resume activity on nodeB that was suspended in step 10 above: Resume-ClusterNode nodeB

Conclusion

It is critical that when service packs, hotfixes, and security patches are required to be installed, that these best practices be followed.

Bottom line

1. Read all related documents.

2. Use a change control process.

3. Apply updates that are needed.

4. Test patches and hotfixes on test environment.

5. Don’t get more than 2 service packs behind.

6. Target non-critical servers first.

7. Service Pack (SP) level consistency.

8. Latest SP instead of multiple hotfixes.

9. Apply only on exact match.

10. Subscribe to Microsoft email notification.

11. Always have a back-out plan.

12. Have a working Backup and schedule production downtime.

13. Consistency across Domain Controllers and application servers.

Additional Readings:

SQL Server failover cluster rolling patch and service pack process

Patch Management on Business-Critical Servers

Windows Server 2012: Failover Clustering Deep Dive

Physical Hardware Requirements -Up to 23 instances of SQL Server requires the following resource:

  1. Processor 2 processors for 23 instances of SQL Server as a single cluster node would require 46 CPUs.
  2. Memory 2 GB of memory for 23 instances of SQL Server as a single cluster node would require 48 GB of RAM (2 GB of additional memory for the operating system).
  3. Network adapters- Microsoft certified network adapter. Converged adapter or iSCSI Adapter or HBA.
  4. Storage Adapter- multipath I/O (MPIO) supported hardware
  5. Storage – shared storage that is compatible with Windows Server 2008/2012. Storage requirements include the following:
  • Use basic disks, not dynamic disks.
  • Use NTFS partition.
  • Use either master boot record (MBR) or GUID partition table (GPT).
  • Storage volume larger than 2 terabytes, use GUID partition table (GPT).
  • Storage volumes smaller than 2 terabytes, use master boot record (MBR).
  • 4 disks for 23 instances of SQL Server as a cluster disk array would require 92 disks.
  • Cluster storage must not be Windows Distributed File System (DFS)

Software Requirements

Download SQL Server 2012 installation media. Review SQL Server 2012 Release Notes. Install the following prerequisite software on each failover cluster node and then restart nodes once before running Setup.

  1. Windows PowerShell 2.0
  2. .NET Framework 3.5 SP1
  3. .NET Framework 4

Active Directory Requirements

  1. Cluster nodes must be member of same Active Directory Domain Services
  2. The servers in the cluster must use Domain Name System (DNS) for name resolution
  3. Use cluster naming convention for example Production Physical Node: DC1PPSQLNODE01 or Production virtual node DC2PVSQLNODE02

Unsupported Configuration

the following are the unsupported configuration: 

  1. Do not include cluster name with these characters like <, >, “,’,&
  2. Never install SQL server on a Domain Controller
  3. Never install cluster services in a domain controller or Forefront TMG 2010

Permission Requirements

System admin or project engineer who will be performing the tasks of creating cluster must be a member of at least Domain Users security group with permission to create domain computers objects in Active Directory and must be a member of administrators group on each clustered server.

Network settings and IP addresses requirements

you need at least two network card in each cluster node. One network card for domain or client connectivity and another network card heartbeat network which is shown below.

image

The following are the unique requirements for MS cluster.

  1. Use identical network settings on each node such as Speed, Duplex Mode, Flow Control, and Media Type.
  2. Ensure that each of these private networks uses a unique subnet.
  3. Ensure that each node has heartbeat network with same range of IP address
  4. Ensure that each node has unique range of subnet whether they are placed in single geographic location of diverse location.

Domain Network should be configured with IP Address, Subnet Mask, Default Gateway and DNS record.

image

Heartbeat network should be configured with only IP address and subnet mask.

image

Additional Requirements

  1. Verify that antivirus software is not installed on your WSFC cluster.
  2. Ensure that all cluster nodes are configured identically, including COM+, disk drive letters, and users in the administrators group.
  3. Verify that you have cleared the system logs in all nodes and viewed the system logs again.
  4. Ensure that the logs are free of any error messages before continuing.
  5. Before you install or update a SQL Server failover cluster, disable all applications and services that might use SQL Server components during installation, but leave the disk resources online.
  6. SQL Server Setup automatically sets dependencies between the SQL Server cluster group and the disks that will be in the failover cluster. Do not set dependencies for disks before Setup.
  7. If you are using SMB File share as a storage option, the SQL Server Setup account must have Security Privilege on the file server. To do this, using the Local Security Policy console on the file server, add the SQL Server setup account to Manage auditing and security log rights.

Supported Operating Systems

  • Windows Server 2012 64-bit x64 Datacenter
  • Windows Server 2012 64-bit x64 Standard
  • Windows Server 2008 R2 SP1 64-bit x64 Datacenter
  • Windows Server 2008 R2 SP1 64-bit x64 Enterprise
  • Windows Server 2008 R2 SP1 64-bit x64 Standard
  • Windows Server 2008 R2 SP1 64-bit x64 Web

Understanding Quorum configuration

In a simple definition, quorum is a voting mechanism in a Microsoft cluster. Each node has one vote. In a MSCS cluster, this voting mechanism constantly monitor cluster that how many nodes are online and how nodes are required to run the cluster smoothly. Each node contains a copy of cluster information and their information is also stored in witness disk/directory. For a MSCS, you have to choose a quorum among four possible quorum configurations.

  • Node Majority- Recommended for clusters with an odd number of nodes. 

clip_image002

  • Node and Disk Majority – Recommended for clusters with an even number of nodes. Can sustain (Total no of Node)/2 failures if a disk witness node is online. Can sustain ((Total no of Node)/2)-1 failures if a disk witness node is offline.

clip_image004 

clip_image006 

  • Node and File Share Majority- Clusters with special configurations. Works in a similar way to Node and Disk Majority, but instead of a disk witness, this cluster uses a file share witness.

clip_image008 

clip_image010 

  • No Majority: Disk Only (not recommended)

Why quorum is necessary? Network problems can interfere with communication between cluster nodes. This can cause serious issues. To prevent the issues that are caused by a split in the cluster, the cluster software requires that any set of nodes running as a cluster must use a voting algorithm to determine whether, at a given time, that set has quorum. Because a given cluster has a specific set of nodes and a specific quorum configuration, the cluster will know how many “votes” constitutes a majority (that is, a quorum). If the number drops below the majority, the cluster stops running. Nodes will still listen for the presence of other nodes, in case another node appears again on the network, but the nodes will not begin to function as a cluster until the quorum exists again.

Understanding a multi-site cluster environment

Hardware: A multi-site cluster requires redundant hardware with correct capacity, storage functionality, replication between sites, and network characteristics such as network latency.

Number of nodes and corresponding quorum configuration: For a multi-site cluster, Microsoft recommend having an even number of nodes and, for the quorum configuration, using the Node and File Share Majority option that is, including a file share witness as part of the configuration. The file share witness can be located at a third site, that is, a different location from the main site and secondary site, so that it is not lost if one of the other two sites has problems.

Network configuration—deciding between multi-subnets and a VLAN: configuring a multi-site cluster with different subnets is supported. However, when using multiple subnets, it is important to consider how clients will discover services or applications that have just failed over. The DNS servers must update one another with this new IP address before clients can discover the service or application that has failed over. If you use VLANs with multi-site you must reduce the Time to Live (TTL) of DNS discovery.

Tuning of heartbeat settings: The heartbeat settings include the frequency at which the nodes send heartbeat signals to each other to indicate that they are still functioning, and the number of heartbeats that a node can miss before another node initiates failover and begins taking over the services and applications that had been running on the failed node. In a multi-site cluster, you might want to tune the “heartbeat” settings. You can tune these settings for heartbeat signals to account for differences in network latency caused by communication across subnets.

Replication of data: Replication of data between sites is very important in a multi-site cluster, and is accomplished in different ways by different hardware vendors. Therefore, the choice of the replication process requires careful consideration. There are many options you will find while replicating data. But before you make any decision, consult with your storage vendor, server hardware vendor and software vendors. Depending on vendor like NetApp and EMC, your replication design will change. Review the following considerations:

Choosing replication level ( block, file system, or application level): The replication process can function through the hardware (at the block level), through the operating system (at the file system level), or through certain applications such as Microsoft Exchange Server (which has a feature called Cluster Continuous Replication or CCR). Work with your hardware and software vendors to choose a replication process that fits the requirements of your organization.

Configuring replication to avoid data corruption: The replication process must be configured so that any interruptions to the process will not result in data corruption, but instead will always provide a set of data that matches the data from the main site as it existed at some moment in time. In other words, the replication must always preserve the order of I/O operations that occurred at the main site. This is crucial, because very few applications can recover if the data is corrupted during replication.

Choosing between synchronous and asynchronous replication: The replication process can be synchronous, where no write operation finishes until the corresponding data is committed at the secondary site, or asynchronous, where the write operation can finish at the main site and then be replicated (as a background operation) to the secondary site.

Synchronous Replication means that the replicated data is always up-to-date, but it slows application performance while each operation waits for replication. Synchronous replication is best for multi-site clusters that can are using high-bandwidth, low-latency connections. Typically, this means that a cluster using synchronous replication must not be stretched over a great distance. Synchronous replication can be performed within 200km distance where a reliable and robust WAN connectivity with enough bandwidth is available. For example, if you have GigE and Ten GigE MPLS connection you would choose synchronous replication depending on how big is your data.

Asynchronous Replication can help maximize application performance, but if failover to the secondary site is necessary, some of the most recent user operations might not be reflected in the data after failover. This is because some operations that were finished recently might not yet be replicated. Asynchronous replication is best for clusters where you want to stretch the cluster over greater geographical distances with no significant application performance impact. Asynchronous replication is performed when distance is more than 200km and WAN connectivity is not robust between sites.

Utilizing Windows Storage Server 2012 as shared storage

Windows® Storage Server 2012 is the Windows Server® 2012 platform of choice for network-attached storage (NAS) appliances offered by Microsoft partners.

Windows Storage Server 2012 enhances the traditional file serving capabilities and extends file based storage for application workloads like Hyper-V, SQL, Exchange and Internet information Services (IIS). Windows Storage Server 2012 provides the following features for an organization.

Workgroup Edition

  • As many as 50 connections
  • Single processor socket
  • Up to 32 GB of memory
  • As many as 6 disks (no external SAS)

Standard Edition

  • No license limit on number of connections
  • Multiple processor sockets
  • No license limit on memory
  • No license limit on number of disks
  • De-duplication, virtualization (host plus 2 virtual machines for storage and disk management tools), and networking services (no domain controller)
  • Failover clustering for higher availability
  • Microsoft BranchCache for reduced WAN traffic

Presenting Storage from Windows Storage Server 2012 Standard

From the Server Manager, Click Add roles and features, On the Before you begin page, Click Next. On the installation type page, Click Next. 

image

On the Server Roles Selection page, Select iSCSI Target and iSCSI target storage provider, Click Next

image

On the Feature page, Click Next. On the Confirm page, Click Install. Click Close.

On the Server Manager, Click File and Storage Services, Click iSCSI

image

On the Task Button, Click New iSCSI Target, Select the Disk drive from where you want to present storage, Click Next

image

Type the Name of the Storage, Click Next

image

Type the size of the shared disk, Click Next

image

Select New iSCSI Target, Click Next

image

Type the name of the target, Click Next

image

Select the IP Address on the Enter a value for selected type, Type the IP address of cluster node, Click Ok. Repeat the process and add IP address for the cluster nodes.   

image

image

Type the CHAP information. note that CHAP password must be 12 character. Click Next to continue.

image

Click Create to create a shared storage. Click Close once done.

image

image

Repeat the step to create all shared drive of your preferred size and create a shared drive of 2GB size for quorum disk.

image

Deploying a Failover Cluster in Microsoft environment

Step1: Connect the cluster servers to the networks and storage

1. Review the details about networks in Hardware Requirements for a Two-Node Failover Cluster and Network infrastructure and domain account requirements for a two-node failover cluster, earlier in this guide.

2. Connect and configure the networks that the servers in the cluster will use.

3. Follow the manufacturer’s instructions for physically connecting the servers to the storage. For this article, we are using software iSCSI initiator. Open software iSCSI initiator from Server manager>Tools>iSCSI Initiator. Type the IP address of target that is the IP address of Microsoft Windows Storage Server 2012. Click Quick Connect, Click Done.

image

5. Open Computer Management, Click Disk Management, Initialize and format the disk using either MBR and GPT disk type. Go to second server, open Computer Management, Click Disk Management, bring the disk online simply by right clicking on the disk and clicking bring online. Ensure that the disks (LUNs) that you want to use in the cluster are exposed to the servers that you will cluster (and only those servers).

image

6. On one of the servers that you want to cluster, click Start, click Administrative Tools, click Computer Management, and then click Disk Management. (If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.) In Disk Management, confirm that the cluster disks are visible.

image

7. If you want to have a storage volume larger than 2 terabytes, and you are using the Windows interface to control the format of the disk, convert that disk to the partition style called GUID partition table (GPT). To do this, back up any data on the disk, delete all volumes on the disk and then, in Disk Management, right-click the disk (not a partition) and click Convert to GPT Disk.

8. Check the format of any exposed volume or LUN. Use NTFS file format.

Step 2: Install the failover cluster feature

In this step, you install the failover cluster feature. The servers must be running Windows Server 2012.

1. Open Server Manager, click Add roles and features. Follow the screen, go to Feature page.

2. In the Add Features Wizard, click Failover Clustering, and then click Install.

image

4. Follow the instructions in the wizard to complete the installation of the feature. When the wizard finishes, close it.

5. Repeat the process for each server that you want to include in the cluster.

Step 3: Validate the cluster configuration

Before creating a cluster, I strongly recommend that you validate your configuration. Validation helps you confirm that the configuration of your servers, network, and storage meets a set of specific requirements for failover clusters.

1. To open the failover cluster snap-in, click Server Manager, click Tools, and then click Failover Cluster Manager.

image

2. Confirm that Failover Cluster Manager is selected and then, in the center pane under Management, click Validate a Configuration. Click Next.

image

3. On the Select Server Page, type the fully qualified domain name of the nodes you would like to add in the cluster, then click Add.

image 

4. Follow the instructions in the wizard to specify the two servers and the tests, and then run the tests. To fully validate your configuration, run all tests before creating a cluster. Click next

image

5. On the confirmation page, Click Next

image

6. The Summary page appears after the tests run. To view the results, click Report. Click Finish. You will be prompted to create a cluster if you select Create the Cluster now using validation nodes.

image 

5. While still on the Summary page, click View Report and read the test results.

image

To view the results of the tests after you close the wizard, see

SystemRootClusterReportsValidation Report date and time.html

where SystemRoot is the folder in which the operating system is installed (for example, C:Windows).

6. As necessary, make changes in the configuration and rerun the tests.

Step4: Create a Failover cluster

1. To open the failover cluster snap-in, click Server Manager, click Tools, and then click Failover Cluster Manager.

image

2. Confirm that Failover Cluster Management is selected and then, in the center pane under Management, click Create a cluster. If you did not close the validation nodes then the validation wizard automatically open cluster creation wizard. Follow the instructions in the wizard to specify, Click Next

  • The servers to include in the cluster.
  • The name of the cluster i.e. virtual name of cluster
  • IP address of the virtual node

image

3. Verify the IP address and cluster node name and click Next

image

4. After the wizard runs and the Summary page appears, to view a report of the tasks the wizard performed, click View Report. Click Finish.

image

image

Step5: Verify Cluster Configuration

On the Cluster Manager, Click networks, right click on each network, Click Property, make sure Allow clients to connect through this network is unchecked for heartbeat network. verify IP range. Click Ok.

image

On the Cluster Manager, Click networks, right click on each network, Click Property, make sure Allow clients to connect through this network is checked for domain network. verify IP range. Click Ok.

image

On the Cluster Manager, Click Storage, Click disks, verify quorum disk and shared disks are available. You can add multiple of disks by simply click Add new disk on the Task Pan.

image

An automated MSCS cluster configuration will add quorum automatically. However you can manually configure desired cluster quorum by right clicking on cluster>More Actions>Configure Cluster Quorum Settings.

image

Configuring a Hyper-v Cluster

In the previous steps you have configured a MSCS cluster, to configure a Hyper-v cluster all you need to do is install Hyper-v role in each cluster node. from the Server Manager, Click Add roles and features, follow the screen and install Hyper-v role. A reboot is required to install Hyper-v role.  Once role is installed in both node.

Note that at this stage add Storage for Virtual Machines and networks for Live Migration, Storage network if using iSCSI, Virtual Machine network, and Management Network. detailed configuration is out of scope for this article as I am writing about MSCS cluster not Hyper-v.

image

from the Cluster Manager, Right Click on Networks, Click Network for Live Migration, Select appropriate network for live Migration.

image

If you would like to have virtual machine additional fault tolerance like Hyper-v Replica, Right Click Cluster virtual node, Click Configure Role, Click Next.

image

From Select Role page, Click Hyper-v Replica broker, Click Next. Follow the screen.

image

From the Cluster manager, right Click on Roles, Click Virtual machine, Click New Hard Disk to configure virtual machine storage and virtual machine configuration disk drive. Once done, From the Cluster manager, right Click on Roles, Click Virtual machine, Click New Virtual machine to create virtual machine.

image

Backing up Clustered data, application or server

There are multiple methods for backing up information that is stored on Cluster Shared Volumes in a failover cluster running on

  • Windows Server 2008 R2
  • Hyper-V Server 2008 R2
  • Windows Server 2012
  • Hyper-V Server 2012

Operating System Level backup

The backup application runs within a virtual machine in the same way that a backup application runs within a physical server. When there are multiple virtual machines being managed centrally, each virtual machine can run a backup “agent” (instead of running an individual backup application) that is controlled from the central management server. Backup agent backs up application data, files, folder and systems state of operating systems.

clip_image012

Hyper-V Image Level backup

The backup captures all the information about multiple virtual machines that are configured in a failover cluster that is using Cluster Shared Volumes. The backup application runs through Hyper-V, which means that it must use the VSS Hyper-V writer. The backup application must also be compatible with Cluster Shared Volumes. The backup application backs up the virtual machines that are selected by the administrator, including all the VHD files for those virtual machines, in one operation. VM1_Data.VHDX, VM2_data.VHDX and VM1_System.VHDX, VM2_system.VHDX are stored in a backup disk or tape. VM1_System.VHDX and VM2_System.VHDX contain system files and page files i.e. system state, snapshot and VM configuration are stored as well.

clip_image014

Publishing an Application or Service in a Failover Cluster Environment

1. To open the failover cluster snap-in, click Server Manager, click Tools, and then click Failover Cluster Manager.

2. Right Click on Roles, click Configure Role to publish a service or application

image 

3. Select a Cluster Services or Application, and then click Next.

image

4. Follow the instructions in the wizard to specify the following details:

  • A name for the clustered file server
  • IP address of virtual node

image

5. On Select Storage page, Select the storage volume or volumes that the clustered file server should use. Click Next

image

6. On the confirmation Page, review and Click Next

image

7. After the wizard runs and the Summary page appears, to view a report of the tasks the wizard performed, click View Report.

8. To close the wizard, click Finish.

image

9. In the console tree, make sure Services and Applications is expanded, and then select the clustered file server that you just created.

10. After completing the wizard, confirm that the clustered file server comes online. If it does not, review the state of the networks and storage and correct any issues. Then right-click the new clustered application or service and click Bring this service or application online.

Perform a Failover Test

To perform a basic test of failover, right-click the clustered file server, click Move this service or application to another node, and click the available choice of node. When prompted, confirm your choice. You can observe the status changes in the center pane of the snap-in as the clustered file server instance is moved.

Configuring a New Failover Cluster by Using Windows PowerShell

Task

PowerShell command

Run validation tests on a list of servers.

Test-Cluster -Node server1,server2

Where server1 and server2 are servers that you want to validate.

Create a cluster using defaults for most settings.

New-Cluster -Name cluster1 -Node server1,server2

Where server1 and server2 are the servers that you want to include in the new cluster.

Configure a clustered file server using defaults for most settings.

Add-ClusterFileServerRole -Storage "Cluster Disk 4"

Where Cluster Disk 4 is the disk that the clustered file server will use.

Configure a clustered print server using defaults for most settings.

Add-ClusterPrintServerRole -Storage "Cluster Disk 5"

Where Cluster Disk 5 is the disk that the clustered print server will use.

Configure a clustered virtual machine using defaults for most settings.

Add-ClusterVirtualMachineRole -VirtualMachine VM1

Where VM1 is an existing virtual machine that you want to place in a cluster.

Add available disks.

Get-ClusterAvailableDisk | Add-ClusterDisk

Review the state of nodes.

Get-ClusterNode

Run validation tests on a new server.

Test-Cluster -Node newserver,node1,node2

Where newserver is the new server that you want to add to a cluster, and node1 and node2 are nodes in that cluster.

Prepare a node for maintenance.

Get-ClusterNode node2 | Get-ClusterGroup | Move-ClusterGroup

Where node2 is the node from which you want to move clustered services and applications.

Pause a node.

Suspend-ClusterNode node2

Where node2 is the node that you want to pause.

Resume a node.

Resume-ClusterNode node2

Where node2 is the node that you want to resume.

Stop the Cluster service on a node.

Stop-ClusterNode node2

Where node2 is the node on which you want to stop the Cluster service.

Start the Cluster service on a node.

Start-ClusterNode node2

Where node2 is the node on which you want to start the Cluster service.

Review the signature and other properties of a cluster disk.

Get-ClusterResource "Cluster Disk 2" | Get-ClusterParameter

Where Cluster Disk 2 is the disk for which you want to review the disk signature.

Move Available Storage to a particular node.

Move-ClusterGroup "Available Storage" -Node node1

Where node1 is the node that you want to move Available Storage to.

Turn on maintenance for a disk.

Suspend-ClusterResource "Cluster Disk 2"

Where Cluster Disk 2 is the disk in cluster storage for which you are turning on maintenance.

Turn off maintenance for a disk.

Resume-ClusterResource "Cluster Disk 2"

Where Cluster Disk 2 is the disk in cluster storage for which you are turning off maintenance.

Bring a clustered service or application online.

Start-ClusterGroup "Clustered Server 1"

Where Clustered Server 1 is a clustered server (such as a file server) that you want to bring online.

Take a clustered service or application offline.

Stop-ClusterGroup "Clustered Server 1"

Where Clustered Server 1 is a clustered server (such as a file server) that you want to take offline.

Move or Test a clustered service or application.

Move-ClusterGroup "Clustered Server 1"

Where Clustered Server 1 is a clustered server (such as a file server) that you want to test or move.

Migrating clustered services and applications to a new failover cluster

Use the following instructions to migrate clustered services and applications from your old cluster to your new cluster. After the Migrate a Cluster Wizard runs, it leaves most of the migrated resources offline, so that you can perform additional steps before you bring them online. If the new cluster uses old storage, plan how you will make LUNs or disks inaccessible to the old cluster and accessible to the new cluster (but do not make changes yet).

1. To open the failover cluster snap-in, click Administrative Tools, and then click Failover Cluster Manager.

2. In the console tree, if the cluster that you created is not displayed, right-click Failover Cluster Manager, click Manage a Cluster, and then select the cluster that you want to configure.

3. In the console tree, expand the cluster that you created to see the items underneath it.

4. If the clustered servers are connected to a network that is not to be used for cluster communications (for example, a network intended only for iSCSI), then under Networks, right-click that network, click Properties, and then click Do not allow cluster network communication on this network. Click OK.

5. In the console tree, select the cluster. Click Configure, click Migrate services and applications.

6. Read the first page of the Migrate a Cluster Wizard, and then click Next.

7. Specify the name or IP Address of the cluster or cluster node from which you want to migrate resource groups, and then click Next.

8. Click View Report. The wizard also provides a report after it finishes, which describes any additional steps that might be needed before you bring the migrated resource groups online.

9. Follow the instructions in the wizard to complete the following tasks:

    • Choose the resource group or groups that you want to migrate.
    • Specify whether the resource groups to be migrated will use new storage or the same storage that you used in the old cluster. If the resource groups will use new storage, you can specify the disk that each resource group should use. Note that if new storage is used, you must handle all copying or moving of data or folders—the wizard does not copy data from one shared storage location to another.
    • If you are migrating from a cluster running Windows Server 2003 that has Network Name resources with Kerberos protocol enabled, specify the account name and password for the Active Directory account that is used by the Cluster service on the old cluster.
  1. After the wizard runs and the Summary page appears, click View Report.

14. When the wizard completes, most migrated resources will be offline. Leave them offline at this stage.

Completing the transition from the old cluster to the new cluster. You must perform the following steps to complete the transition to the new cluster running Windows Server 2012.

1. Prepare for clients to experience downtime, probably brief.

2. Take each resource group offline on the old cluster.

3. Complete the transition for the storage:

    • If the new cluster will use old storage, follow your plan for making LUNs or disks inaccessible to the old cluster and accessible to the new cluster.
    • If the new cluster will use new storage, copy the appropriate folders and data to the storage. As needed for disk access on the old cluster, bring individual disk resources online on that cluster. (Keep other resources offline, to ensure that clients cannot change data on the disks in storage.) Also as needed, on the new cluster, use Disk Management to confirm that the appropriate LUNs or disks are visible to the new cluster and not visible to any other servers.

4. If the new cluster uses mount points, adjust the mount points as needed, and make each disk resource that uses a mount point dependent on the resource of the disk that hosts the mount point.

5. Bring the migrated services or applications online on the new cluster. To perform a basic test of failover on the new cluster, expand Services and Applications, and then click a migrated service or application that you want to test.

6. To perform a basic test of failover for the migrated service or application, under Actions (on the right), click Move this service or application to another node, and then click an available choice of node. When prompted, confirm your choice. You can observe the status changes in the center pane of the snap-in as the clustered service or application is moved.

7. If there are any issues with failover, review the following:

    • View events in Failover Cluster Manager. To do this, in the console tree, right-click Cluster Events, and then click Query. In the Cluster Events Filter dialog box, select the criteria for the events that you want to display, or to return to the default criteria, click the Reset button. Click OK. To sort events, click a heading, for example, Level or Date and Time.
    • Confirm that necessary services, applications, or server roles are installed on all nodes. Confirm that services or applications are compatible with Windows Server 2008 R2 and run as expected.
    • If you used old storage for the new cluster, rerun the Validate a Cluster Configuration Wizard to confirm the validation results for all LUNs or disks in the storage.
    • Review migrated resource settings and dependencies.
    • If you migrated one or more Network Name resources with Kerberos protocol enabled, confirm that the following permissions change was made in Active Directory Users and Computers on a domain controller. In the computer accounts (computer objects) of your Kerberos protocol-enabled Network Name resources, Full Control must be assigned to the computer account for the failover cluster.

Migrating Cluster Resource with new Mount Point

When you are working with new storage for your cluster migration, you have some flexibility in the order in which you complete the tasks. The tasks that you must complete include creating the mount points, running the Migrate a Cluster Wizard, copying the data to the new storage, and confirming the disk letters and mount points for the new storage. After completing the other tasks, configure the disk resource dependencies in Failover Cluster Manager.

A useful way to keep track of disks in the new storage is to give them labels that indicate your intended mount point configuration. For example, in the new storage, when you are mounting a new disk in a folder called Mount1-1 on another disk, you can also label the mounted disk as Mount1-1. (This assumes that the label Mount1-1 is not already in use in the old storage.) Then when you run the Migrate a Cluster Wizard and you need to specify that disk for a particular migrated resource, you can look at the list and select the disk labeled Mount1-1. Then you can return to Failover Cluster Manager to configure the disk resource for Mount1-1 so that it is dependent on the appropriate resource, for example, the resource for disk F. Similarly, you would configure the disk resources for all other disks mounted on disk F so that they depended on the disk resource for disk F.

Migrating DHCP to a Cluster Running Windows Server 2012

A failover cluster is a group of independent computers that work together to increase the availability of applications and services. The clustered servers (called nodes) are connected by physical cables and by software. If one of the cluster nodes fails, another node begins to provide service (a process known as failover). Users experience a minimum of disruptions in service.

This guide describes the steps that are necessary when migrating a clustered DHCP server to a cluster running Windows Server 2008 R2, beyond the standard steps required for migrating clustered services and applications in general. The guide indicates when to use the Migrate a Cluster Wizard in the migration, but does not describe the wizard in detail.

Step 1: Review requirements and create a cluster running Windows Server 2012

Before beginning the migration described in this guide, review the requirements for a cluster running Windows Server 2008 R2, install the failover clustering feature on servers running Windows Server 2008 R2, and create a new cluster.

Step 2: On the old cluster, adjust registry settings and permissions before migration

To prepare for migration, you must make changes to registry settings and permissions on each node of the old cluster.

1. Confirm that you have a current backup of the old cluster, one that includes the configuration information for the clustered DHCP server (also called the DHCP resource group).

2. Confirm that the clustered DHCP server is online on the old cluster. It must be online while you complete the remainder of this procedure.

3. On a node of the old cluster, open a command prompt as an administrator.

4. Type: regedit Navigate to:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDHCPServerParameters

5. Choose the option that applies to your cluster: If the old cluster is running Windows Server 2008, skip to step 7. If the old cluster is running Windows Server 2003 or Windows Server 2003 R2:

    • Right-click Parameters, click New, click String Value, and for the name of the new value, type: ServiceMain
    • Right-click the new value (ServiceMain), click Modify, and for the value data, type: ServiceEntry
    • Right-click Parameters again, click New, click Expandable String Value, and for the name of the new value, type: ServiceDll
    • Right-click the new value (ServiceDll), click Modify, and for the value data, type: %systemroot%system32dhcpssvc.dll

6. Right-click Parameters, and then click Permissions.

7. Click Add. Locate the appropriate account and assign permissions:

    • On Windows Server 2008: Click Locations, select the local server, and then click OK. Under Enter the object names to select, type NT ServiceDHCPServer. Click OK. Select the DHCPServer account and then select the check box for Full Control.
    • On Windows Server 2003 or Windows Server 2003 R2: Click Locations, ensure that the domain name is selected, and then click OK. Under Enter the object names to select, type Everyone, and then click OK (and confirm your choice if prompted). Under Group or user names, select Everyone and then select the check box for Full Control.

8. Repeat the process on the other node or nodes of the old cluster.

Step 3: On a node in the old cluster, prepare for export, and then export the DHCP database to a file

As part of migrating a clustered DHCP server, on the old cluster, you must export the DHCP database to a file. This requires preparatory steps that prevent the cluster from restarting the clustered DHCP resource during the export. The following procedure describes the process. On the old cluster, start the clustering snap-in and configure the restart setting for the clustered DHCP server (DHCP resource group):

1. Click Start, click Administrative Tools, and then click Failover Cluster Management. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

2. If the console tree is collapsed, expand the tree under the cluster that you are migrating settings from. Expand Services and Applications and then, in the console tree, click the clustered DHCP server.

3. In the center pane, right-click the DHCP server resource, click Properties, click the Policies tab, and then click If resource fails, do not restart.

This step prevents the resource from restarting during the export of the DHCP database, which would stop the export.

1. On the node of the old cluster that currently owns the clustered DHCP server, confirm that the clustered DHCP server is running. Then open a command prompt window as an administrator.

2. Type: netsh dhcp server export <exportfile> all

Where <exportfile> is the name of the file to which you want to export the DHCP database.

3. After the export is complete, in the clustering interface (Cluster Administrator or Failover Cluster Management), right-click the clustered DHCP server (DHCP resource group) and then click either Take Offline or Take this service or application offline. If the command is unavailable, in the center pane, right-click each online resource and click either Take Offline or Take this resource offline. If prompted for confirmation, confirm your choice.

4. If the old cluster is running Windows Server 2003 or Windows Server 2003 R2, obtain the account name and password for the Cluster service account (the Active Directory account used by the Cluster service on the old cluster). Alternatively, you can obtain the name and password of another account that has access permissions for the Active Directory computer accounts (objects) that the old cluster uses. For a migration from a cluster running Windows Server 2003 or Windows Server 2003 R2, you will need this information for the next procedure.

Step 4: On the new cluster, configure a network for DHCP clients and run the Migrate a Cluster Wizard

Microsoft recommends that you make the network settings on the new cluster as similar as possible to the settings on the old cluster. In any case, on the new cluster, you must have at least one network that DHCP clients can use to communicate with the cluster. The following procedure describes the cluster setting needed on the client network, and indicates when to run the Migrate a Cluster Wizard.

1. On the new cluster (running Windows Server 2012), click Server Manager, click Tools, and then click Failover Cluster Manager.

2. If the cluster that you want to configure is not displayed, in the console tree, right-click Failover Cluster Manager, click Manage a Cluster, and then select or specify the cluster that you want.

3. If the console tree is collapsed, expand the tree under the cluster.

4. Expand Networks, right-click the network that clients will use to connect to the DHCP server, and then click Properties.

5. Make sure that Allow cluster network communication on this network and Allow clients to connect through this network are selected.

6. To prepare for the migration process, find and take note of the drive letter used for the DHCP database on the old cluster. Ensure that the same drive letter exists on the new cluster. (This drive letter is one of the settings that the Migrate a Cluster Wizard will migrate.)

7. In Failover Cluster Manager, in the console tree, select the new cluster, and then under Configure, click Migrate services and applications.

8. Use the Migrate a Cluster Wizard to migrate the DHCP resource group from old to the new cluster. If you are using new storage on the new cluster, during the migration, be sure to specify the disk that has the same drive letter on the new cluster as was used for the DHCP database on the old cluster. The wizard will migrate resources and settings, but not the DHCP database.

Step 5: On the new cluster, import the DHCP database, bring the clustered DHCP server online, and adjust permissions

To complete the migration process, import the DHCP database that you exported to a file in Step 2. Then you can bring the clustered DHCP server online and adjust settings that were changed temporarily during the migration process.

1. If you are reusing the old cluster storage for the new cluster, confirm that you have stored the exported DHCP database file in a safe location. Then be sure to delete all the DHCP files other than the exported DHCP database file from the old storage. This includes the DHCP database, log, and backup files.

2. On the new cluster, in Failover Cluster Manager, expand Services and Applications, right-click the clustered DHCP server, and then click Bring this service or application online. The DHCP service starts with an empty database.

3. Click the clustered DHCP server.

4. In the center pane, right-click the DHCP server resource, click Properties, click the Policies tab, and then click If resource fails, do not restart. This step prevents the resource from restarting during the import of the DHCP database, which would stop the import.

5. In the new cluster, on the node that currently owns the migrated DHCP server, view the disk used by the migrated DHCP server, and make sure that you have copied the exported DHCP database file to this disk.

6. In the new cluster, on the node that currently owns the migrated DHCP server, open a command prompt as an administrator. Change to the disk used by the migrated DHCP server.

7. Type: netsh dhcp server import <exportfile>

Where <exportfile> is the filename of the file to which you exported the DHCP database.

8. If the migrated DHCP server is not online, in Failover Cluster Manager, under Services and Applications, right-click the migrated DHCP server, and then click Bring this service or application online.

9. In the center pane, right-click the DHCP server resource, click Properties, click the Policies tab, and then click If resource fails, attempt restart on current node.

This returns the resource to the expected setting, instead of the “do not restart” setting that was temporarily needed during the import of the DHCP database.

10. If the cluster was migrated from Windows Server 2003 or Windows Server 2003 R2, after the clustered DHCP server is online on the new cluster, make the following changes to permissions in the registry:

  • On the node that owns the clustered DHCP server, open a command prompt as an administrator.
  • Type: regedit Navigate to:
    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDHCPServerParameters
  • Right-click Parameters, and then click Permissions.
  • Click Add, click Locations, and then select the local server.
  • Under Enter the object names to select, type NT ServiceDHCPServer and then click OK. Select the DHCPServer account and then select the check box for Full Control. Then click Apply.
  • Select the Everyone account (created through steps earlier in this topic) and then click Remove. This removes the account from the list of those that are assigned permissions.

11. Perform the preceding steps only after DHCP is online on the new cluster. After you complete these steps, you can test the clustered DHCP server and begin to provide DHCP services to clients.

Configuring a Multisite SQL Server Failover Cluster

To install or upgrade a SQL Server failover cluster, you must run the Setup program on each node of the failover cluster. To add a node to an existing SQL Server failover cluster, you must run SQL Server Setup on the node that is to be added to the SQL Server failover cluster instance. Do not run Setup on the active node to manage the other nodes. The following options are available for SQL Server failover cluster installation:

Option1: Integration Installation with Add Node

Create and configure a single-node SQL Server failover cluster instance. When you configure the node successfully, you have a fully functional failover cluster instance. At this point, it does not have high availability because there is only one node in the failover cluster. On each node to be added to the SQL Server failover cluster, run Setup with Add Node functionality to add that node.

Option 2: Advanced/Enterprise Installation

After you run the Prepare Failover Cluster on one node, Setup creates the Configuration.ini file that lists all the settings that you specified. On the additional nodes to be prepared, instead of following these steps, you can supply the autogenerated ConfigurationFile.ini file from first node as an input to the Setup command line. This step prepares the nodes ready to be clustered, but there is no operational instance of SQL Server at the end of this step.

image

After the nodes are prepared for clustering, run Setup on one of the prepared nodes. This step configures and finishes the failover cluster instance. At the end of this step, you will have an operational SQL Server failover cluster instance and all the nodes that were prepared previously for that instance will be the possible owners of the newly-created SQL Server failover cluster.

Follow the procedure to install a new SQL Server failover cluster using Integrated Simple Cluster Install 

  1. Insert the SQL Server installation media, and from the root folder, double-click Setup.exe. To install from a network share, browse to the root folder on the share, and then double-click Setup.exe.
  1. The Installation Wizard starts the SQL Server Installation Center. To create a new cluster installation of SQL Server, click New SQL Server failover cluster installation on the installation page

image

  1. The System Configuration Checker runs a discovery operation on your computer. To continue, click OK.

image

  1. You can view the details on the screen by clicking Show Details, or as an HTML report by clicking View detailed report. To continue, click Next.
  2. On the Setup Support Files page, click Install to install the Setup support files.
  3. The System Configuration Checker verifies the system state of your computer before Setup continues. After the check is complete, click Next to continue.

image

  1. You can view the details on the screen by clicking Show Details, or as an HTML report by clicking View detailed report.
  2. On the Product key page, indicate whether you are installing a free edition of SQL Server, or whether you have a PID key for a production version of the product.
  3. On the License Terms page, read the license agreement, and then select the check box to accept the license terms and conditions.

image 

  1. To help improve SQL Server, you can also enable the feature usage option and send reports to Microsoft. Click Next to continue.

image

  1. On the Feature Selection page, select the components for your installation. You can select any combination of check boxes, but only the Database Engine and Analysis Services support failover clustering. Other selected components will run as a stand-alone feature without failover capability on the current node that you are running Setup on.

image

  1. The prerequisites for the selected features are displayed on the right-hand pane. SQL Server Setup will install the prerequisite that are not already installed during the installation step described later in this procedure. SQL Server setup runs one more set of rules that are based on the features you selected to validate your configuration.

image

  1. On the Instance Configuration page, specify whether to install a default or a named instance. SQL Server Network Name — Specify a network name for the new SQL Server failover cluster. that is the name of virtual node of the cluster.  This is the name that is used to identify your failover cluster on the network. Instance ID — By default, the instance name is used as the Instance ID. This is used to identify installation directories and registry keys for your instance of SQL Server. This is the case for default instances and named instances. For a default instance, the instance name and instance ID would be MSSQLSERVER. To use a nondefault instance ID, select the Instance ID box and provide a value. Instance root directory — By default, the instance root directory is C:Program FilesMicrosoft SQL Server. To specify a nondefault root directory, use the field provided, or click the ellipsis button to locate an installation folder.

image

  1. Detected SQL Server instances and features on this computer – The grid shows instances of SQL Server that are on the computer where Setup is running. If a default instance is already installed on the computer, you must install a named instance of SQL Server. Click Next to continue.

image

  1. The Disk Space Requirements page calculates the required disk space for the features that you specify, and compares requirements to the available disk space on the computer where Setup is running. Use the Cluster Resource Group page to specify the cluster resource group name where SQL Server virtual server resources will be located. To specify the SQL Server cluster resource group name, you have two options:
  • Use the drop-down box to specify an existing group to use.
  • Type the name of a new group to create. Be aware that the name “Available storage” is not a valid group name.

image

  1. On the Cluster Disk Selection page, select the shared cluster disk resource for your SQL Server failover cluster. More than one disk can be specified. Click Next to continue.

image

  1. On the Cluster Network Configuration page, Specify the IP type and IP address for your failover cluster instance. Click Next to continue. Note that the IP address will resolve the name of the virtual node which you have mentioned earlier step.

image

  1. On the Server Configuration — Service Accounts page, specify login accounts for SQL Server services. The actual services that are configured on this page depend on the features that you selected to install.

image

  1. Use this page to specify Cluster Security Policy. Use default setting. Click Next to continue. Work flow for the rest of this topic depends on the features that you have specified for your installation. You might not see all the pages, depending on your selections (Database Engine, Analysis Services, Reporting Services).
  2. You can assign the same login account to all SQL Server services, or you can configure each service account individually. The startup type is set to manual for all cluster-aware services, including full-text search and SQL Server Agent, and cannot be changed during installation. Microsoft recommends that you configure service accounts individually to provide least privileges for each service, where SQL Server services are granted the minimum permissions they have to have complete their tasks. To specify the same logon account for all service accounts in this instance of SQL Server, provide credentials in the fields at the bottom of the page. When you are finished specifying login information for SQL Server services, click Next.
  • Use the Server Configuration – Collation tab, use default collations for the Database Engine and Analysis Services.
  • Use the Database Engine Configuration — Account Provisioning page to specify the following:
  • select Windows Authentication or Mixed Mode Authentication for your instance of SQL Server.

image

  1. Use the Database Engine Configuration – Data Directories page to specify nondefault installation directories. To install to default directories, click Next. Use the Database Engine Configuration – FILESTREAM page to enable FILESTREAM for your instance of SQL Server. Click Next to continue.

image

  1. When you are finished editing the list, click OK. Verify the list of administrators in the configuration dialog box. When the list is complete, click Next.
  2. Use the Analysis Services Configuration — Account Provisioning page to specify users or accounts that will have administrator permissions for Analysis Services. You must specify at least one system administrator for Analysis Services. To add the account under which SQL Server Setup is running, click Add Current User. To add or remove accounts from the list of system administrators, click Add or Remove, and then edit the list of users, groups, or computers that will have administrator privileges for Analysis Services. When you are finished editing the list, click OK. Verify the list of administrators in the configuration dialog box. When the list is complete, click Next.

image

  1. Use the Analysis Services Configuration — Data Directories page to specify nondefault installation directories. To install to default directories, click Next.

image

  1. Use the Reporting Services Configuration page to specify the kind of Reporting Services installation to create. For failover cluster installation, the option is set to Unconfigured Reporting Services installation. You must configure Reporting Services services after you complete the installation. However, no harm to select Install and configure option if you are not an SQL expert.

image

  1. On the Error Reporting page, specify the information that you want to send to Microsoft that will help improve SQL Server. By default, options for error reporting is disabled.

image

  1. The System Configuration Checker runs one more set of rules to validate your configuration with the SQL Server features that you have specified.

image

  1. The Ready to Install page displays a tree view of installation options that were specified during Setup. To continue, click Install. Setup will first install the required prerequisites for the selected features followed by the feature installation.

image

  1. During installation, the Installation Progress page provides status so that you can monitor installation progress as Setup continues. After installation, the Complete page provides a link to the summary log file for the installation and other important notes. To complete the SQL Server installation process, click Close.
  2. If you are instructed to restart the computer, do so now. It is important to read the message from the Installation Wizard when you have finished with Setup.
  3. To add nodes to the single-node failover you just created, run Setup on each additional node and follow the steps for Add Node operation.

SQL Advanced/Enterprise Failover Cluster Install

Step1: Prepare Environment

  1. Insert the SQL Server installation media, and from the root folder, double-click Setup.exe.

  2. Windows Installer 4.5 is required, and may be installed by the Installation Wizard. If you are prompted to restart your computer, restart and then start SQL Server Setup again.

  3. After the prerequisites are installed, the Installation Wizard starts the SQL Server Installation Center. To prepare the node for clustering, move to the Advanced page and then click Advanced cluster preparation

  4. The System Configuration Checker runs a discovery operation on your computer. To continue, click OK. You can view the details on the screen by clicking Show Details, or as an HTML report by clicking View detailed report.

  5. On the Setup Support Files page click Install to install the Setup support files.

  6. The System Configuration Checker verifies the system state of your computer before Setup continues. After the check is complete, click Next to continue. You can view the details on the screen by clicking Show Details, or as an HTML report by clicking View detailed report.

  7. On the Language Selection page, you can specify the language, to continue, click Next

  8. On the Product key page, select PIDed product key, Click Next

  9. On the License Terms page, accept the license terms and Click Next to continue.

  10. On the Feature Selection page, select the components for your installation as you did for simple installation which has been mentioned earlier.

  11. The Ready to Install page displays a tree view of installation options that were specified during Setup. To continue, click Install. Setup will first install the required prerequisites for the selected features followed by the feature installation.

  12. To complete the SQL Server installation process, click Close.

  13. If you are instructed to restart the computer, do so now.

  14. Repeat the previous steps to prepare the other nodes for the failover cluster. You can also use the autogenerated configuration file to run prepare on the other nodes. A configurationfile.ini is generated in C:Program FilesMicrosoft SQL Server110Setup BootStrapLog20130603_014118configurationfile.ini which is shown below.

image

Step2 Install SQL Server

  1. After preparing all the nodes as described in the prepare step, run Setup on one of the prepared nodes, preferably the one that owns the shared disk. On the Advanced page of the SQL Server Installation Center, click Advanced cluster completion.

  2. The System Configuration Checker runs a discovery operation on your computer. To continue, click OK. You can view the details on the screen by clicking Show Details, or as an HTML report by clicking View detailed report.

  3. On the Setup Support Files page, click Install to install the Setup support files.

  4. The System Configuration Checker verifies the system state of your computer before Setup continues. After the check is complete, click Next to continue. You can view the details on the screen by clicking Show Details, or as an HTML report by clicking View detailed report.

  5. On the Language Selection page, you can specify the language, To continue, click Next.

  6. Use the Cluster node configuration page to select the instance name prepared for clustering

  7. Use the Cluster Resource Group page to specify the cluster resource group name where SQL Server virtual server resources will be located. On the Cluster Disk Selection page, select the shared cluster disk resource for your SQL Server failover cluster.Click Next to continue

  8. On the Cluster Network Configuration page, specify the network resources for your failover cluster instance. Click Next to continue.

  9. Now follow the simple installation steps to select Database Engine, reporting, Analysis and Integration services.

  10. The Ready to Install page displays a tree view of installation options that were specified during Setup. To continue, click Install. Setup will first install the required prerequisites for the selected features followed by the feature installation.

  11. Once installation is completed, click Close.

Follow the procedure if you would like to remove a node from an existing SQL Server failover cluster

  1. Insert the SQL Server installation media. From the root folder, double-click setup.exe. To install from a network share, navigate to the root folder on the share, and then double-click Setup.exe.

  2. The Installation Wizard launches the SQL Server Installation Center. To remove a node to an existing failover cluster instance, click Maintenance in the left-hand pane, and then select Remove node from a SQL Server failover cluster.

  3. The System Configuration Checker will run a discovery operation on your computer. To continue, click OK.

  4. After you click install on the Setup Support Files page, the System Configuration Checker verifies the system state of your computer before Setup continues. After the check is complete, click Next to continue.

  5. On the Cluster Node Configuration page, use the drop-down box to specify the name of the SQL Server failover cluster instance to be modified during this Setup operation. The node to be removed is listed in the Name of this node field.

  6. The Ready to Remove Node page displays a tree view of options that were specified during Setup. To continue, click Remove.

  7. During the remove operation, the Remove Node Progress page provides status.

  8. The Complete page provides a link to the summary log file for the remove node operation and other important notes. To complete the SQL Server remove node, click Close.

Using Command Line Installation of SQL Server

1. To install a new, stand-alone instance with the SQL Server Database Engine, Replication, and Full-Text Search component, run the following command

Setup.exe /q /ACTION=Install /FEATURES=SQL /INSTANCENAME=MSSQLSERVER

/SQLSVCACCOUNT=”<DomainNameUserName>” /SQLSVCPASSWORD

2. To prepare a new, stand-alone instance with the SQL Server Database Engine, Replication, and Full-Text Search components, and Reporting Services. run the following command

Setup.exe /q /ACTION=PrepareImage /FEATURES=SQL,RS /InstanceID =<MYINST> /IACCEPTSQLSERVERLICENSETERMS

3. To complete a prepared, stand-alone instance that includes SQL Server Database Engine, Replication, and Full-Text Search components run the following command

Setup.exe /q /ACTION=CompleteImage /INSTANCENAME=MYNEWINST /INSTANCEID=<MYINST>

/SQLSVCACCOUNT=”<DomainNameUserName>” /SQLSVCPASSWORD

4. To upgrade an existing instance or failover cluster node from SQL Server 2005, SQL Server 2008, or SQL Server 2008 R2.

Setup.exe /q /ACTION=upgrade /INSTANCEID = <INSTANCEID>/INSTANCENAME=MSSQLSERVER /RSUPGRADEDATABASEACCOUNT=”<Provide a SQL DB Account>” /IACCEPTSQLSERVERLICENSETERMS

5. To upgrade an existing instance of SQL Server 2012 to a different edition of SQL Server 2012.

Setup.exe /q /ACTION=editionupgrade /INSTANCENAME=MSSQLSERVER /PID=<PID key for new edition>” /IACCEPTSQLSERVERLICENSETERMS

6. To install an SQL server using configuration file, run the following command

Setup.exe /ConfigurationFile=MyConfigurationFile.INI

7. To install an SQL server using configuration file and provide service Account password, run the following command

Setup.exe /SQLSVCPASSWORD=”typepassword” /AGTSVCPASSWORD=”typepassword”

/ASSVCPASSWORD=”typepassword” /ISSVCPASSWORD=”typepassword” /RSSVCPASSWORD=”typepassword”

/ConfigurationFile=MyConfigurationFile.INI

8. To uninstall an existing instance of SQL Server. run the following command

Setup.exe /Action=Uninstall /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME=MSSQLSERVER

Reference and Further Reading

Windows Storage Server 2012

Virtualizing Microsoft SQL Server

The Perfect Combination: SQL Server 2012, Windows Server 2012 and System Center 2012

EMC Storage Replication

Download Hyper-v Server 2012

Download Windows Server 2012

Microsoft Active Directory Best Practice Part II

I have written Active Directory Best Practice last year. I received huge feedback on this article. Recently I had to deal with an Active Directory disaster. I believe time is perfect to write part II on this same topics and educate others so that they learn Active Directory and prepare themselves for disaster recover.  In this article I am also writing about Active Directory Design and the elements of the design. You may think you know Active Directory but have a look what you don’t know!

Readers who may benefit from this article:

Technical Architect, Systems Engineer, Systems Administrator, Active Directory Designer

Active Directory FSMO Role Design Best Practice

Scope of AD Design

  1. Provide Compliance, Governance and Oversee Network Authentication
  2. Secure Servers, Users and Computers
  3. Provide DNS Resolution
  4. Create central repository of all IT objects and assets

What are the elements of Active Directory Design?

  1. Forest Plan
  2. Domain Plan
  3. Organizational Unit Plan
  4. Site and Services Plan

1. Key Consideration for Forest Plan

• Determine the number of forests for your network
• Create a forest change control policy
• Understand the impact of changes to the forest after deployment

Multi-Master Model:

A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise, but it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way Windows deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to the DC to which changes were written last (that is, “the last writer wins”), while discarding the changes in all other DCs. Although this resolution method may be acceptable in some cases, there are times when conflicts are just too difficult to resolve using the “last writer wins” approach. In such cases, it is best to prevent the conflict from occurring rather than to try to resolve it after the fact. For certain types of changes, Windows incorporates methods to prevent conflicting Active Directory updates from occurring.

Single-Master Model:

To prevent conflicting updates in Microsoft AD, the Active Directory performs updates to certain objects in a single-master fashion. In a single-master model, only one DC in the entire directory is allowed to process updates. This is similar to the role given to a primary domain controller (PDC) in earlier versions of Windows, in which the PDC is responsible for processing all updates in a given domain.
Microsoft Active Directory extends the single-master model found in earlier versions of Windows to include multiple roles, and the ability to transfer roles to any domain controller (DC) in the enterprise. Because an Active Directory role is not bound to a single DC, it is referred to as a Flexible Single Master Operation (FSMO) role. Currently in Windows there are five FSMO roles:

  • Schema master
  • Domain naming master
  • RID master
  • PDC emulator
  • Infrastructure daemon

2. Domain Plan

The domain plan is perhaps the most complicated aspect of the Active Directory design process. The planning process described below is divided into three parts:
• Determining the number of domains
• DNS and Domain Names
• Post Deployment Change management

Who are the administrator and who are delegated in Active Directory?

• Current domain administrators who are responsible for user accounts, groups, and computers
• Teams that manage and monitor the physical networks
• Team that manage DNS
• Security teams

The steps to creating a domain plan for a forest are:
• Determine the number of domains in each forest
• Choose a forest root domain
• Assign a DNS name to each domain to create a domain hierarchy
• Plan DNS server deployment
• Optimize authentication with short cut trusts
• Understand the impact of changes to the domain plan after deployment

Active Directory domains are named with DNS names that are the locator services for the Active Directory. Clients query DNS to locate services such as LDAP and Kerberos Key Distribution Centers. Also, a client uses DNS to determine what site it is in and what site its domain controller is in.

3. Organization Unit Plan

OU is the logical presentation of Company organogram, departmental organogram and Site/divisional organogram. OU design and planning is another very complex aspect of the design. However, changes to the design after deployment, are relatively easy to accomplish. A well-designed OU plan will ensure a return on investment for your AD effort. The decisions on OU design, GPO, security groups, and delegation are critical; however these aspects of AD are designed to handle the changes to your directory.

Here are some reasons why complexity should be handled at the OU level.
• Changing the OU Structure is fairly easy
• OUs are very flexible when used in conjunction with security groups and Group Policy Objects
• OUs offer a type of security boundary
• GPOs as a parent OU are inherited by a child OU (remember this does not happen at the domain level: a child domain does not inherit policy from its parent domain in the domain name space)
• OUs can be delegated administration rights, thus saving the cost of adding a domain just for administrative reasons
• The initial OU design requirements can be influenced by the down level domain migration requirements. The OU infrastructure can be redesigned after the migration

4. Site and Services Plan

An Active Directory site topology is a logical representation of a physical networks (WAN & LAN). Site topology is defined on a per-forest basis. Active Directory clients and servers use the site topology of a forest to route query and replication traffic efficiently. A site topology also helps you to decide where to place domain controllers on your network. Keep the following definition in mind when designing the site plan.

A site is defined as a set of IP sub networks connected by fast reliable connectivity. As a rule of thumb, networks with LAN speed or better are considered as fast networks.

To create a site topology for a forest, use the following process:

  • Define sites and site links using your physical topology as a starting point. (Site links are connection objects, used to connect two sites, which are normally connected as a Wide Area Network)
  • Place servers into sites
  • Understand how changes to your site topology after deployment will impact end users

How many parties involve in Site Design

  • Teams that manage and monitor the TCP/IP networks. (Network Team)
  • Domain administrators for each domain in the forest (Wintel Team)
Writable DC or RODC?

Certain domain and enterprise-wide operations that are not well suited to multi-master updates must be performed on a single domain controller in the domain or in the forest. The purpose of having a single-master owner is to define a well-known target for critical operations and to prevent the introduction of conflicts or latency that could be created by multi-master updates. Having a single-operation master means that the relevant FSMO role owner must be online, discoverable, and available on the network by computers needing to perform FSMO dependent operations.

As per above statement, you can adopt HUB-SPOKE model with writable DC in Head Office and RODC in Site office with small number of users. However if you have sites with many users accessing DFS data, Printing and NTFS files randomly than its better to have writable DCs in all sites as well. If you are using MPLS service such as Telstra IP-WAN enterprise managed network than you definitely on a mesh WAN topology in that case you can happily have writable DCs on sites with mesh topology configured AD Sites and Services. However you are in SMB market with only several sites and low bandwidth than I would recommend RODC as your site domain controller.

 Relate the design with your organization or corporate scenario

• Design 1: Single Forest with a Single Domain
• Design 2: Single Forest with Multiple Domains
• Design 3: Multiple Forests

Ask yourself/client the following questions and find correct answer not reasonable answer

• How many Forests?
• How Many Domains?
• What is the best DNS Design for the Domain Name space?
• What are the Security verses Ease of Management Tradeoffs?

Understand FSMO Role Holder’s tasks and functionality: The operations masters, their scope and functionality are shown in the following table.

FSMO Role Scope
Function and availability requirements
Schema Master
Enterprise
  • Used to introduce manual and programmatic schema updates, and this includes those updates that are added by Windows ADPREP /FORESTPREP, by Microsoft Exchange, and by other applications that use Active Directory Domain Services (AD DS).
  • Must be online when schema updates are performed.
Domain Naming Master Enterprise
  • Used to add and to remove domains and application partitions to and from the forest.
  • Must be online when domains and application partitions in a forest are added or removed.
Primary Domain Controller
Domain
  • Receives password updates when passwords are changed for the computer and for user accounts that are on replica domain controllers.
  • Consulted by replica domain controllers that service authentication requests that have mismatched passwords.
  • Default target domain controller for Group Policy updates.
  • Target domain controller for legacy applications that perform writable operations and for some admin tools.
  • Must be online and accessible 24 hours a day, seven days a week.
RID Domain
  • Allocates active and standby RID pools to replica domain controllers in the same domain.
  • Must be online for newly promoted domain controllers to obtain a local RID pool that is required to advertise or when existing domain controllers have to update their current or standby RID pool allocation.
Infrastructure Master
Domain
Application partition
  • Updates cross-domain references and phantoms from the global catalog. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 248047 Phantoms, tombstones and the infrastructure master
  • A separate infrastructure master is created for each application partition including the default forest-wide and domain-wide application partitions created by Windows Server 2003 and later domain controllers.
    The Windows Server 2008 R2 ADPREP /RODCPREP command targets the infrastructure master role for default DNS application in the forest root domain. The DN path for this role holder is CN=Infrastructure,DC=DomainDnsZones,DC=<forest root domain>,DC=<top level domain> and CN=Infrastructure,DC=ForestDnsZones,DC=<forest root domain>,DC=<top level domain>.

Who owns what FSMO Roles & Where to place FSMO Roles

When the Active Directory Installation Wizard (Dcpromo.exe) creates the first domain in a new forest, the wizard adds five FSMO roles. A forest with one domain has five roles. The Active Directory Installation Wizard adds three domain-wide roles on the first domain controller in each additional domain in the forest. In addition, infrastructure master roles exist for each application partition. This includes the default domain and the forest-wide DNS application partitions that are created on Windows Server 2003 and on later domain controllers.

The Active Directory Installation Wizard performs the initial placement of roles on domain controllers. This placement is frequently correct for directories that have just a few domain controllers. In a directory that has many domain controllers, the default placement may not be the best match for your network.

Consider the following in your selection criteria:

  • It is easier to keep track of FSMO roles if you host them on fewer computers.
  • Place roles on domain controllers that are can be accessed by the computers that need access to a given role, especially on networks that are not fully routed. For example, to obtain a current or standby RID pool, or perform pass-through authentication, all DCs need network access to the RID and PDC role holders in their respective domains.
  • If a role has to be moved to a different domain controller, and the current role holder is online and available, you should transfer (not seize) the role to the new domain controller. FSMO roles should only be sized if the current role holder is not available.
  • FSMO roles that are assigned to domain controllers that are offline or in an error state only have to be transferred or seized if role-dependent operations are being performed. If the role holder can be made operational before the role is needed, you may delay seizing the role. If role availability is critical, transfer or seize the role as required. The PDC role in each domain should online 24×7.
  • Select a direct intra-site replication partner for existing role holders to act as a standby role holder. If the primary owner goes offline or fails, transfer or seize the role to the designated standby FSMO domain controller as required.
General recommendations for FSMO placement
  • Place the schema master on the PDC of the forest root domain.
  • Place the domain naming master on the forest root PDC.
    The addition or removal of domains should be a tightly controlled operation. Place this role on the forest root PDC. Certain operations that use the domain naming master, such as creating or removing domains and application partitions, fail if the domain naming master is not available. On a domain controller that runs Microsoft Windows 2000, the domain naming master must also be hosted on a global catalog server. On domain controllers that run Windows Server 2003 or later versions, the domain naming master does not have to be a global catalog server.
  • Place the PDC on your best hardware in a reliable hub site that contains replica domain controllers in the same Active Directory site and domain.
  • In large or busy environments, the PDC frequently has the highest CPU utilization because it handles pass-thru authentication and password updates. If high CPU utilization becomes a problem, identify the source, and this includes applications or computers that may be performing too many operations (transitively) targeting the PDC.
  • All domain controllers in a given domain, and computers that run applications and admin tools that target the PDC, must have network connectivity to the domain PDC.
  • Place the RID master on the domain PDC in the same domain.
    RID master overhead is light, especially in mature domains that have already created the bulk of their users, computers, and groups. The domain PDC typically receives the most attention from administrators, therefore, co-locating this role on the PDC helps insure good availability. Make sure that existing domain controllers and newly promoted domain controllers, especially those promoted in remote or staging sites, have network connectivity to obtain active and standby RID pools from the RID master.
  • Legacy guidance suggests placing the the infrastructure master on a non-global catalog server. There are two rules to consider:
    • Single domain forest:
      In a forest that contains a single Active Directory domain, there are no phantoms. Therefore, the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.
    • Multi-domain forest:
      If every domain controller in a domain that is part of a multi-domain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain. In practical terms, most administrators host the global catalog on every domain controller in the forest.
    • If every domain controller in a given domain that is located in a multi-domain forest does not host the global catalog, the infrastructure master must be placed on a domain controller that does not host the global catalog.

Techniques to reduce CPU include the following:

  • adding more or faster CPUs
  • Adding additional replicas
  • Adding additional memory to cache Active Directory objects
  • Removing the global catalog to avoid global catalog lookups
  • Reducing the number of incoming and outgoing replication partners
  • Increasing the replication schedule
  • Reducing authentication visibility by using LDAPSRVWEIGHT and LDAPPRIORITY that is described in KB296716 and the Randomize1CList described in KB231305

In short human readable English language I would recommend follow the following FSMO roles structure.

Domain Controller 1: Place the two forest roles on this server.

  • Schema Master
  • Domain Master

Domain Controller 2 Place the three domain roles on this server.

  • RID Master
  • Infrastructure Master
  • PDC Emulator

Global Catalog Rules:

Rule#1: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server(GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC’s event log.

Rule#2: If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role. In simple plain English yes you configure IM FSMO role holder a GC if all DCs are GC.

Group Policy Hierarchy Best Practice:

Group Policy(s) will flow down a hierarchy in the following order:
• Site
• Domain
• OU

The following are key element of Active Directory Users and Computer Policy:

• Password Policies, such as password length, password expiry interval and so forth
• Account Lockout Policies
• Kerberos policies
• Encrypted file system recovery policies
• IP security policies
• Public Key encryption policies
• Certificate authorities

Default Domain Policy determination

  • Encrypted File System Recovery Policies
  • IP Security Policies
  • Public Key Infrastructure Policies
  • Certificate Authorities
  • Password Policy
  • Account Lockout Policy
  • Kerberos Policies

How long can a PDC and DC be offline? In theory, you can take PDC master offline for tombstone lifetime period and get away with warnings, but without breaking anything.
By default the DCs will look for PDCE as authoritative time source and you will have issues related to editing GPOs, but as long as you do not have legacy clients, you can take the PDCE down for up to 60 days pre-W2K3 SP1 environment (DCs) and for 180 days if all the DCs are W2K3 SP1.

Another issue would have to do with password chaining – if PDCE is down, you might get temporary authentication failures after changing user passwords. see the KB for details on how password chaining works.

However in practice you shouldn’t shutdown a DC for longer than necessary that may create lot of issues such as replication issue and authentication issues for site users. You can patch and update a domain controller using SCCM/WSUS and reboot the DC without any issues.

Transferring the Flexible Single Master Operation Role

The transfer of an FSMO role is the suggested form of moving a FSMO role between domain controllers and can be initiated by the administrator or by demoting a domain controller, but is not initiated automatically by the operating system. This includes a server in a shut-down state. FSMO roles are not automatically relocated during the shutdown process–this must be considered when shutting down a domain controller that has an FSMO role for maintenance, for example.

In a graceful transfer of an FSMO role between two domain controllers, a synchronization of the data that is maintained by the FSMO role owner to the server receiving the FSMO role is performed prior to transferring the role to ensure that any changes have been recorded before the role change.

Operational attributes are attributes that translate into an action on the server. This type of attribute is not defined in the schema, but is instead maintained by the server and intercepted when a client attempts to read or write to it. When the attribute is read, generally the result is a calculated result from the server. When the attribute is written, a pre-defined action occurs on the domain controller.

The following operational attributes are used to transfer FSMO roles and are located on the RootDSE (or Root DSA Specific Entry–the root of the Active Directory tree for a given domain controller where specific information about the domain controller is kept). In the operation of writing to the appropriate operational attribute on the domain controller to receive the FSMO role, the old domain controller is demoted and and the new domain controller is promoted automatically. No manual intervention is required. The operational attributes that represent the FSMO roles are:

becomeRidMaster
becomeSchemaMaster
becomeDomainMaster
becomePDC
becomeInfrastructureMaster

If the administrator specifies the server to receive the FSMO role using a tool such as Ntdsutil, the exchange of the FSMO role is defined between the current owner and the domain controller specified by the administrator.
When a domain controller is demoted, the operational attribute “GiveAwayAllFsmoRoles” is written, which triggers the domain controller to locate other domain controllers to offload any roles it currently owns. Windows 2000 determines which roles the domain controller being demoted currently owns and locates a suitable domain controller by following these rules:

  1. Locate a server in the same site.
  2. Locate a server to which there is RPC connectivity.
  3. Use a server over an asynchronous transport (such as SMTP).

In all transfers, if the role is a domain-specific role, the role can be moved only to another domain controller in the same domain. Otherwise, any domain controller in the enterprise is a candidate.

Seizing the Flexible Single Master Operation Role

Administrators should use extreme caution in seizing FSMO roles. This operation, in most cases, should be performed only if the original FSMO role owner will not be brought back into the environment.
When the administrator seizes an FSMO role from an existing computer, the “fsmoRoleOwner” attribute is modified on the object that represents the root of the data directly bypassing synchronization of the data and graceful transfer of the role. The “fsmoRoleOwner” attribute of each of the following objects is written with the Distinguished Name (DN) of the NTDS Settings object (the data in the Active Directory that defines a computer as a domain controller) of the domain controller that is taking ownership of that role. As replication of this change starts to spread, other domain controllers learn of the FSMO role change.

Primary Domain Controller (PDC) FSMO:

LDAP://DC=MICROSOFT,DC=COM

RID Master FSMO:

LDAP://CN=Rid Manager$,CN=System,DC=MICROSOFT,DC=COM

Schema Master FSMO:

LDAP://CN=Schema,CN=Configuration,DC=Microsoft,DC=Com

Infrastructure Master FSMO:

LDAP://CN=Infrastructure,DC=Microsoft,DC=Com

Domain Naming Master FSMO:

LDAP://CN=Partitions,CN=Configuration,DC=Microsoft,DC=Com

For example, if Server1 is the PDC in the MicrosoftGuru.com.au domain and is retired and the administrator is unable to demote the computer properly, Server2 needs to be assigned the FSMO role of the PDC. After the seizure of the role takes place, the value

CN=NTDS Settings,CN=SERVER2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Microsoft,DC=Com

is present on the following object:  LDAP://DC=Domain,DC=COM,DC=AU

How to Fix ForestDnsZones and DomainDnsZones after failed demotion attempt

cscript fixfsmo.vbs DC=DomainDnsZones,DC=contoso,DC=com

cscript fixfsmo.vbs DC=ForestDnsZones,DC=contoso,DC=com

Can I change Active Directory Schema using ADSIEDIT? yes you can change Active Directory Schema using ADSIedit tools.  

Microsoft recommend that you transfer FSMO roles in the following scenarios:

  • The current role holder is operational and can be accessed on the network by the new FSMO owner.
  • You are gracefully demoting a domain controller that currently owns FSMO roles that you want to assign to a specific domain controller in your Active Directory forest.
  • The domain controller that currently owns FSMO roles is being taken offline for scheduled maintenance and you need specific FSMO roles to be assigned to a “live” domain controller. This may be required to perform operations that connect to the FSMO owner. This would be especially true for the PDC Emulator role but less true for the RID master role, the Domain naming master role and the Schema master roles.

Microsoft recommend that you seize FSMO roles in the following scenarios:

  • The current role holder is experiencing an operational error that prevents an FSMO-dependent operation from completing successfully and that role cannot be transferred.
  • A domain controller that owns an FSMO role is force-demoted by using the dcpromo /forceremoval command.
  • The operating system on the computer that originally owned a specific role no longer exists or has been reinstalled.

The partition for each FSMO role is in the following list: 

FSMO role
Partition
Schema
CN=Schema,CN=configuration,DC=microsoftguru,dc=com,dc=au
Domain Naming Master
CN=configuration,DC=microsoftguru,dc=com,dc=au
PDC
DC=microsoftguru,dc=com,dc=au
RID DC=microsoftguru,dc=com,dc=au
Infrastructure DC=microsoftguru,dc=com,dc=au

How to View/create/remove a new global catalog on the destination global catalog server

  1. On the domain controller where you want the new global catalog, start the Active Directory Sites and Services snap-in. To start the snap-in, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  2. In the console tree, double-click Sites, and then double-click sitename.
  3. Double-click Servers, click your domain controller, right-click NTDS Settings, and then click Properties.
  4. On the General tab, click to select the Global catalog check box to assign the role of global catalog to this server. Deselect the Global Catalog check box to remove GC from the DC.
  5. Restart the domain controller.

 How to view and transfer FSMO roles in Windows Active Directory

  1. Click Start, and then click Run.
  2. Type regsvr32 schmmgmt.dll in the Open box, and then click OK.
  3. Click OK when you receive the message that the operation succeeded.

Transfer the Schema Master Role

  1. Click Start, click Run, type mmc in the Open box, and then click OK.
  2. On the File, menu click Add/Remove Snap-in.
  3. Click Add.
  4. Click Active Directory Schema, click Add, click Close, and then click OK.
  5. In the console tree, right-click Active Directory Schema, and then click Change Domain Controller.
  6. Click Specify Name, type the name of the domain controller that will be the new role holder, and then click OK.
  7. In the console tree, right-click Active Directory Schema, and then click Operations Master.
  8. Click Change.
  9. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the Domain Naming Master Role

  1. Click Start, point to Administrative Tools, and then click Active Directory Domains and Trusts.
  2. Right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller.
    NOTE: You must perform this step if you are not on the domain controller to which you want to transfer the role. You do not have to perform this step if you are already connected to the domain controller whose role you want to transfer.
  3. Do one of the following:
    • In the Enter the name of another domain controller box, type the name of the domain controller that will be the new role holder, and then click OK.
      -or-
    • In the Or, select an available domain controller list, click the domain controller that will be the new role holder, and then click OK.
  4. In the console tree, right-click Active Directory Domains and Trusts, and then click Operations Master.
  5. Click Change.
  6. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the RID Master, PDC Emulator, and Infrastructure Master Roles

  1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  2. Right-click Active Directory Users and Computers, and then click Connect to Domain Controller.
    NOTE: You must perform this step if you are not on the domain controller to which you want to transfer the role. You do not have to perform this step if you are already connected to the domain controller whose role you want to transfer.
  3. Do one of the following:
    • In the Enter the name of another domain controller box, type the name of the domain controller that will be the new role holder, and then click OK.
      -or-
    • In the Or, select an available domain controller list, click the domain controller that will be the new role holder, and then click OK.
  4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Master.
  5. Click the appropriate tab for the role that you want to transfer (RID, PDC, or Infrastructure), and then click Change.
  6. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer FSMO roles using ntdsutil

  • Click Start, click Run, type ntdsutil in the Open box, and then click OK.
  • Type roles, and then press ENTER
  • Type connections, and then press ENTER
  • Type Connect to Server ServerName and Press Enter
  • At the server connections prompt, type q, and then press ENTER
  • Type transfer role, where role is the role that you want to transfer. For a list of roles that you can transfer, type ? at the fsmo maintenance prompt, and then press ENTER,
  • At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility

To seize the FSMO roles by using the Ntdsutil utility, follow these steps:

  • Click Start, click Run, type ntdsutil in the Open box, and then click OK.
  • Type roles, and then press ENTER.
  • Type connections, and then press ENTER.
  • Type connect to server servername, and then press ENTER, where servername is the name of the domain controller that you want to assign the FSMO role to.
  • At the server connections prompt, type q, and then press ENTER.
  • Type seize role, where role is the role that you want to seize. For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press ENTER,
  • At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.
    Notes

Important KBs and Readings

 

Repadmin Examples and Dcdiag Examples

Best Practices Analyzer for Active Directory Domain Services

Microsoft Premier Field Engineering Platform Reporting Tool (MPS_REPORTS)

Microsoft Product Support Reports Viewer 2.0

Best Practice Active Directory Design for Managing Windows Networks

Windows 2000 Active Directory FSMO roles

FSMO placement and optimization on Active Directory domain controllers

Flexible Single Master Operation Transfer and Seizure Process

Phantoms, tombstones and the infrastructure master

How to view and transfer FSMO roles in Windows Server 2003

Managing Operations Master Roles

How to remove data in active directory after an unsuccessful domain controller demotion

FSMO placement and optimization on Windows 2000 domain controllers

Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller

Microsoft Active Directory—Best Practice

In this article, I am writing an overview of Microsoft Active Directory. You might be thinking; well you know everything on Active Directory. I would recommend you to go through this article and revisit your own Active Directory infrastructure. You will improve Active Directory performance, enhance Active Directory infrastructure and rectify so many misconfiguration you have made over the years. 

Windows Server 2012 Step by Step

Lets start with basic question, What is Microsoft Active Directory? Active Directory is Microsoft’s adoption of IEEE X.500. you can use Active Directory Domain Services (AD DS) as the central repository or database for user, group, and computer accounts as well as for application, shared folders and printers. With the adoption of Active Directory on Windows server 2000, Microsoft enhanced Active Directory on Windows Server 2003 and Windows Server 2008. Having the ability to manage these resources from any domain controller within your domain allows you to greatly reduce your administrative overhead.

Active Directory creates a secure boundary for an organization providing log on authentication. Active Directory creates a hierarchical containment structure includes the Active Directory forest, domains in the forest, DNS and organizational units (OUs) in each domain. Feature of Active Directory includes:

  • A set of rules that is the schema, that defines the classes of objects and attributes
  • A global catalog that contains information about every object in the directory.
  • A query and index mechanism, so that objects and their properties can be published and found by network users or applications.
  • A replication service that distributes directory data across a network and all domain controllers (writable and RODC) 
  • Operations master roles (flexible single master operations or FSMO roles).

What’s new in Windows Server 2008 R2 Active Directory? I reckon, since the adoption of Microsoft Active Directory in Windows Server 2000, the Active Directory has become the fundamental pillar of windows network infrastructure. AD has grown and become a mature technology on windows server 2008 R2 release. There are new features in Windows Server 20008 R2. They are as follows

  • Active Directory Application Mode (ADAM).
    Active Directory Federation Services (AD FS)
  • Active Directory Rights Management Services (AD RMS)
  • Active Directory Certificate Services (AD CS)
  • Read -only domain controllers (RODCs)
  • Active Directory on Windows Server Core installation

Active Directory has been partitioned in four important parts. Domain controllers in Active Directory typically contain the following directory partition replicas or naming context replicas:

  • Configuration: The configuration partition or naming context (NC) contains objects that relate to the logical structure of the forest, structure of the domain, and replication topology. Each domain controller in the forest contains a read/write copy of the configuration partition. Any objects stored in the configuration partition are replicated to each domain controller in each domain, and in a forest.
  • Domain: The domain partition or naming context (NC) contains all objects that are stored in a domain. Each domain controller in a domain has a read/write copy of the domain partition. Objects in the domain partition are replicated to only the domain controllers within a domain.
  • Schema: The schema partition or naming context (NC) contains objects that can be created in the Active Directory directory, and the attributes which these objects can contain. Domain controllers in a forest have a read-only copy of the schema partition. Objects stored in the schema partition are replicated to each domain controller in domains/forests.
  • Application: The application partition is a new feature introduced in Windows Server 2003. This partition contains application specific objects. The objects or data that applications and services store here can comprise of any object type excluding security principles. Security principles are Users, Groups, and Computers. The application partition typically contains DNS zone objects, and dynamic data from other network services such as Remote Access Service (RAS), and Dynamic Host Configuration Protocol (DHCP).

image

Flexible Single Master Operations (FSMO): The Active Directory extends the single-master model found in earlier versions of Windows to include multiple roles, and the ability to transfer roles to any domain controller (DC) in the enterprise. Because an Active Directory role is not bound to a single DC, it is referred to as a Flexible Single Master Operation (FSMO) role. Currently in Active Directory there are five FSMO roles:

  • Schema master
  • PDC emulator
  • Domain naming master
  • RID master
  • Infrastructure master

Active Directory ISTG: For inter-site replication, one domain controller per site has the responsibility of evaluating the inter-site replication topology and creating Active Directory Replication Connection objects for appropriate bridgehead servers within its site. The domain controller in each site that owns this role is referred to as the Inter-Site Topology Generator (ISTG). Inter-site connection objects are created by the Inter Site Topology Generator (ISTG) and not the KCC. The first domain controller in a site has the role of Inter Site Topology Generator. There is only one ISTG within a particular site. It is the ISTG that is responsible for ensuring that the site has a replica of the configuration, domain and schema partitions.

KCC Replication: The Knowledge Consistency Checker (KCC) is an Active Directory component that is responsible for the generation of the replication topology between domain controllers. This article describes the role of one server per site, known as the Inter-Site Topology Generator, which is responsible for managing the inbound replication connection objects for all bridgehead servers in the site in which it is located.

The current ISTG notifies every other domain controller in the site that it is still present by writing the “inter-Site Topology Generator” attribute on “CN=NTDS Site Settings,CN=SiteName,CN=Sites,CN=Configuration,DC=Mydomain,DC=com” under its domain controller object in the Configuration naming context in Active Directory at a specified interval. You can modify this interval using the following registry value (which is not present by default, it must be added):

Key: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters
Value Name: KCC site generator renewal interval (minutes)
Value Data: 30 (in minutes)

As this attribute gets propagated to other domain controllers by Active Directory replication, the KCC on each of these computers monitors this attribute to verify that it has been written within a specified amount of time. If the amount of time elapses without a modification, a new ISTG takes over. You can modify this time interval using the following registry value:

Key: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters
Value Name: KCC site generator fail-over (minutes)
Value Data: 60 (in minutes)

Active Directory Replication Topology Options: Active Directory Sites and Services are the logical presentation of physical WAN connectivity and switching of your LAN and WAN. The Active Directory replication topologies typically are:

  • Ring Topology: With intra-site replication, the KCC creates a ring topology that defines the replication paths within a site. In a ring topology, each domain controller in a site has two inbound and outbound replication partners. The KCC creates the ring so that there is no greater than three hops between domain controllers in a site.
  • Full Mesh Topology: This topology is typically utilized in an organizations where redundancy is extremely important for all sites. You can configure full mesh if you have IPWAN or MPLS connections in all sites. A mix of MPLS and ADSL or other method of connectivity do not constitute full mesh. A full mesh topology is quite expensive to manage and is not scalable.
  • Hub And Spoke Topology: This topology is typically implemented in large organizations where scalability is important consideration. In this topology, one or multiple hub sites exist that have WAN connections to multiple spoke sites. The hub sites are usually connected to each other through high speed WAN connections.
  • Hybrid Topology: The hybrid topology is combination of any of the above topologies. This is not a recommended topology even if you have high speed duct fibre or other WAN connectivity. 

You can download Microsoft Active Directory Topology Diagrammer and find out your topology you have configured in Active Directory. I would recommend you not to configure configure full mesh topology in Active Directory. Mesh topology often lead you to a mess in active directory. It better to be simple as Hub and Spoke topology.

FRS and DFS replication: Windows Active Directory domain controllers use FRS to replicate system policy and login scripts for Windows servers and clients. However, because system policy and login script replication is performed by Active Directory replication, it is not affected by the following information. However, you can use DFS to replicate across domain controllers.

Domain and Forest Functional Level: Domain and forest functionality, which is available in Windows Server 2008 R2 AD DS, provides a way to enable domain-wide features or forest-wide Active Directory features in your network environment. Different levels of domain functionality and forest functionality are available, depending on your network environment. To check your domain functional, open dsa.msc>Right click on Domain Name>Click Raise Domain Functional Level>Select preferred functional level and click ok.

4

5

If all the domain controllers in your domain or forest are running Windows Server 2008 R2 and the domain and forest functional level is set to Windows Server 2008 R2, all domain-wide features and forest-wide features are available. When your domain or forest contains Windows 2000, Windows Server 2003 or Windows Server 2008 domain controllers, Active Directory features are limited. For more information about how to enable domain-wide features or forest-wide features, Understanding Active Directory Domain Services (AD DS) Functional Levels and Raise the Domain Functional Level

Domain Naming System (DNS): The Domain Name System (DNS) is a hierarchical, distributed database that contains mappings of DNS domain names to various types of data, such as Internet Protocol (IP) addresses. DNS allows you to use friendly names, such as http://www.microsoft.com, to easily locate computers and other resources on a TCP/IP-based network. When planning a secure DNS server deployment, first collect information about your environment. This information should include the structure and hierarchy of your internal and external domains, identification of DNS servers that will be authoritative for these domain names, and the DNS client requirements for host resolution on your network. After you collect this information, review the guidance in this topic to determine which tasks to perform so that you can deploy a secure DNS infrastructure.

10

To check DNS functional level, open DNS Manger>Expand Forward lookup zone>right click on domain name>Click property>Click Change on Replication: All DNS servers in this forest>Select to all DNS servers running in the domain controllers in this forest. Click OK.

11

12

Select appropriate scavenging time to scavenge DNS records.

13

If you have more than one domain controllers, all domain controllers must be registered as authoritative Name Server (NS)

14

15

17

Consider the following when planning a secure DNS deployment: The following design choices can affect security of your DNS deployment

  • Communication with the Internet. If your network hosts are not required to resolve names on the Internet, eliminate all communication between internal DNS servers and the Internet. In this DNS design, you can use a private DNS namespace that is hosted entirely in your network where internal DNS servers host zones for the root domain and top-level domains. In this configuration, your DNS servers will not use Internet root name servers. For more information about root hints, see Configure Internal Root Hints.
    If your network hosts are required to resolve names on the Internet, configure a group of DNS servers in the forest root domain (FRD) to forward queries for external names to an external DNS server. Configure DNS servers in a child domain to only forward queries to DNS servers in the FRD. Protect communications between internal and external DNS servers by configuring a packet-filtering firewall to only allow UDP and TCP port 53 communications. For more information about using forwarders, see
    Configure a DNS server to use forwarders
  • DNS namespace. If your organization’s DNS namespace is split into internal and external domains, host your internal DNS namespace on DNS servers located on the internal network and the external DNS namespace on DNS servers located on a perimeter network. Protect internal DNS servers by placing them behind a firewall. If internal client computers are required to resolve hosts in the external namespace, your internal DNS namespace can be a subdomain of your external DNS namespace. For example, if the Internet DNS namespace for your organization is MicrosoftGURU.com.au, then the internal DNS namespace for your network might be corp.MicrosoftGURU.com.au. If internal network hosts do not need to resolve hosts in the external domain, then your internal DNS namespace can be distributed the same as the Internet DNS namespace. However, you should use a differing set of domain names for internal and external hosts so that the two domains do not overlap. For example, if your organization’s parent domain name is MicrosoftGURU.com.au, you can use an internal DNS domain such as corp.MicrosoftGURU.com.au. By keeping your internal and external namespaces separate and distinct in this way, you enable simplified maintenance of configurations such as domain name filter or exclusion lists.
  • Restricting zone transfers. For increased security, disable all zone transfers unless they are required. If required, configure this setting to allow zone transfers only to specified IP addresses. Allowing zone transfers to any server may expose your DNS data to an attacker attempting to footprint your network. By default, zone transfers are disabled for zones that are AD integrated. For non-AD integrated zones, default settings allow zone transfers only to servers that are listed in the name server (NS) resource records of the zone. For more information, see Restrict Zone Transfers.
  • Configuring AD integrated zones. Security enhancements that are available when using directory-integrated zones include access control lists and secure dynamic updates. You cannot use directory-integrated zones unless the DNS server is also a domain controller. For more information, see Configure AD Integrated Zones.

11

  • Configuring the Discretionary Access Control List (DACL). You can use the DACL to secure a dnsZone object container in the directory tree. This feature provides granulated access to either the zone or a specified resource record in the zone. For example, the DACL for a zone resource record can be restricted so that dynamic updates are only allowed for a specified client computer or a secure group such as a domain administrators group. This security feature is not available with standard primary zones. For more information, see Configure the Discretionary Access Control List (DACL).
  • Allowing only secure dynamic updates. Dynamic updates can be secure or non-secure. To help protect DNS servers from DNS spoofing attacks, you should only use secure dynamic updates. DNS update security is available only for zones that are Active Directory integrated. For more information, see Allow Only Secure Dynamic Updates.20
  • Configuring the Global Query Block List. The global query block list is a new security feature introduced with the Windows Server® 2008 operating system. Use the global query block list to prevent malicious users from registering a host name that might have special significance for certain applications and allow them to divert network traffic. For more information, see Configure the Global Query Block List.
  • Configuring the socket pool. The socket pool enables a DNS server to use source port randomization when issuing DNS queries. This provides enhanced security against cache poisoning attacks. You can also customize socket pool settings. For information, see Configure the Socket Pool.
  • Configuring cache locking. When you enable cache locking, the DNS server will not allow cached records to be overwritten for the duration of the time to live (TTL). Cache locking also provides for enhanced security against cache poisoning attacks. Cache locking is available if your DNS server is running Windows Server 2008 R2. You can also customize the settings used for cache locking. For more information, see Configure Cache Locking.
  • Restricting DNS responses to selected interfaces. By default, a DNS server that has multiple network interfaces, or is configured with multiple IP addresses on a single interface, will respond to DNS queries sent to all its IP addresses. To improve security of the DNS server, restrict the DNS service to listen only on IP addresses that are used by the server’s DNS clients as their preferred DNS server. For more information, see Restrict DNS servers to listen only on selected interfaces.
  • Configuring internal Root Hints. When the DNS Server service is running on a domain controller, root hints are read from Active Directory first. If the DNS Server service is not running on a domain controller or no root hints exist in Active Directory, root hints are implemented using a file, Cache.dns, stored in the %windir%System32Dns folder on the server computer. Root hints normally contain the name server (NS) and address (A, AAAA) resource records for the Internet root servers. If, however, you are using the DNS Server service on a private network, you can edit or replace Root hints with similar records that point to your own internal root DNS servers. This prevents your internal DNS servers from sending private information over the Internet when they resolve names. For more information, see Configure Internal Root Hints.
  • Disabling recursion. To protect DNS servers, disable recursion on all servers that are not required to perform recursive queries. Recursion is a name-resolution technique in which a DNS server queries other DNS servers on behalf of the requesting client to fully resolve the name and then sends an answer back to the client. If enabled, an attacker can use the recursion process to cause domain names to resolve to the wrong IP address. By default, the DNS server performs recursive queries on behalf of its DNS clients and DNS servers that have forwarded DNS client queries to it. For more information, see Disable Recursion on the DNS Server.
  • Securing the DNS Cache. By default, the DNS Server service is secured from cache pollution, which occurs when DNS query responses contain non-authoritative or malicious data. The Secure cache against pollution option prevents an attacker from successfully polluting the cache of a DNS server with resource records that were not requested by the DNS server. Changing this default setting will reduce the integrity of the responses that are provided by DNS Server service. You can restore the default setting if it was previously changed. For more information, see Secure the DNS Cache.

Active Directory Sites and Subnets: In Active Directory Sites and Subnets, you have to create various sites as per your real organization structure, add domain controller for authentication in that site and declare real network subnets assigned for sites. you have to create replication topology in active directory inter site links. 

Sites: A site can be defined as a grouping or set of Internet Protocol (IP) subnets that are connected by a highly reliable, fast and inexpensive link. This is usually a local area network (LAN) or metropolitan area network (MAN). Domains can have domain controllers in multiple sites. A site can have domain controllers from multiple domains. In Active Directory, sites have the following main roles or purposes:

  • A site determines the closest domain controller at workstation logon.
  • A site operates as a replication boundary. As a replication boundary, a site optimizes replication between sites because it can be used to improve on and more efficiently manage Active Directory replication.
  • A site also functions as a resource locator boundary. Clients are only able to access resources that are accessible in a particular site.

6

Site Links: Site links are logical connections that are established between sites is Active Directory that define a path between these sites. A site link defines the direction of Active Directory replication between sites. You can use either RPC over IP or SMTP as the transport protocol for moving replication data over a site link. Site links are assigned the following:

  • Cost: With replication, the concept of cost indicates the cost of the physical link between two Active Directory sites and is utilized to detail optimal connection paths between one site and another site. When a site link is assigned a cost, the type of connection is taken into consideration. For replication, the lower costing links are used over higher costing links. A general method of calculating cost is Cost=1024/WAN Bandwidth. By default cost is 100.
  • Interval: Replication over a site link takes place at predetermined time intervals. When assigning the replication interval, it is important not to set the value to too high or too low. An exceptionally high value means that changes take a longer time to be replicated, while an exceptionally lower value means that replication occurs too regularly.
  • Schedule: A replication schedule and interval are basically used together. An interval is associated with a schedule. A schedule deals with when the replication of data is going to occur. I do not recommend to schedule and replication. Keep it as default.

3

Site link bridge: In Active Directory, you can use a site link bridge to link sites that share common Active Directory data but who do not have a site link. The data typically shared by these sites is the Application directory partition.

1

Connection objects: In Active Directory, domain controllers replicate with specific replication partners. The partners that domain controllers replicate with are defined by connection objects. Connection object enable data to be replicated in Active Directory because they define inbound replication paths. Domain controllers and their associated connections are defined in a topology map. The Directory Replication Agent (DRA) handles replication between domain controllers. The Directory Replication Agent uses the connection objects in the topology map to find out those partners that are relevant when replicating changes to directory partitions. The DRA sends a replication request to the partners of a domain controller when the domain controller needs to update its copy of Active Directory. Administrators can manually create connection objects, or they can leave these objects to be created by the Knowledge Consistency Checker (KCC). When the KCC creates connection objects, it is an automatic process. The KCC runs on all domain controllers in Active Directory. As an Administrator, you can create a manual connection object between any two domain controllers in a forest. If you want data to flow in two directions, you should create two connection objects. You can create manual connection objects between domain controllers in the same site or in different sites. The Knowledge Consistency Checker by default creates automatic connection objects. It references the site topology and then uses the information on sites and site links to automatically create connection objects. The KCC checks the site topology at regular intervals to determine whether the connection objects are still valid, and then changes connection objects based on its reviews. It is the KCC that is accountable for making certain that data in the directory partitions are replicated in sites. You can disable the automatic creation of connection objects on a per site and forest wide basis.

3

Planning AD SYSVOL:  SYSVOL is a collection of folders that contain a copy of the domain’s public files, including system policies, logon scripts, and important elements of Group Policy objects (GPOs). The SYSVOL directory must be present and the appropriate subdirectories must be shared on a server before the server can advertise itself on the network as a domain controller. Shared subdirectories in the SYSVOL tree are replicated to every domain controller in the domain. Sometimes systems administrator tent to utilize FRS functionality of Active Directory SYSVOL to keep software packages, application and files in SYSVOL. later on deploy these packages from SYSVOL. This is completely a wrong approach that lead to replication issues among domain controllers. the bigger the sysvol the greater possibility of replication failure. Remember that FRS has to replicate entire data of SYSVOL across domain controllers in a forest. If you have less bandwidth, your replication might goes into queue. Deploy packages from a different DFS share and keep un-related files and folder out of SYSVOL.   

SYSVOL data and the File Replication Service (FRS): The system volume contains scripts and group policies. SYSVOL data is hosted on every domain controller. Changes to SYSVOL are replicated to domain controllers within the same domain via File Replication System (FRS) replication. With FRS replication, the full file is replicated and not just the actual changes that were made to the file. This differs to Active Directory replication. With Active Directory only the changes that were made to Active Directory objects are replicated.

When you relocate folders, you use the first three levels of subdirectories to properly update the path locations that DFS Replication uses. These levels are affected by junction points and parameter settings. These folders include the following:

  • %windir%SYSVOL
  • %windir%SYSVOLdomain
  • %windir%SYSVOLdomainDfsrPrivate
  • %windir%SYSVOLdomainPolicies
  • %windir%SYSVOLdomainscripts
  • %windir%SYSVOLstaging
  • %windir%SYSVOLstagingdomain
  • %windir%SYSVOLstaging areas
  • %windir%SYSVOLstaging areas<FQDN>, where FQDN is the fully qualified domain name of the domain that this domain controller hosts, for example, Microsoftguru.com.au.
  • %windir%SYSVOLsysvol
  • %windir%SYSVOLsysvol<FQDN>, where FQDN is the fully qualified domain name of the domain that this domain controller hosts, for example, Microsoftguru.com.au.

Dynamic Host Configuration Protocol and Active Directory:  Windows Server 2008 provides integrated security support for networks that use Active Directory Domain Services (AD DS). This support adds and uses a class of objects that is part of the base directory schema, providing the following enhancements:

  • A list of IP addresses available for the computers that you authorize to operate as DHCP servers on your network.
  • Detection of unauthorized DHCP servers and prevention of their starting or running on your network.

18

19

20

21

22

26

27

The authorization process for DHCP server computers depends on the installed role of the server on your network. A DHCP server can be installed on a domain controller, a member server or standalone. If you deploy AD DS, all computers operating as DHCP servers must be either domain controllers or domain member servers before they can be authorized and provide DHCP service to clients.

Although it is not recommended, you can use a stand-alone server as a DHCP server as long as it is not on a subnet with any authorized DHCP servers. When a stand-alone DHCP server detects an authorized server on the same subnet, it automatically stops leasing IP addresses to DHCP clients.

Do you need an WINS server anymore?  Today, numerous Microsoft customers deploy WINS technology in their environment. WINS is an alternative name resolution protocol to DNS. It is an older service that uses NetBIOS over TCP/IP (NetBT). WINS and NetBT do not support IPv6 protocols and both are entering legacy mode.  To help customers migrate to DNS for all name resolution the DNS Server role in Windows Server 2008 supports a special GlobalNames Zone (GNZ) feature. Some customers in particular require the ability to have the static, global records with single-label names that WINS currently provides. These single-label names typically refer to records for important, well-known and widely-used servers for the company, servers that are already assigned static IP addresses and are currently managed by IT-administrators using WINS. GNZ is designed to enable the resolution of these single-label, static, global names for servers using DNS.

GNZ is intended to aide retirement of WINS. It is not a replacement for WINS. GNZ is not intended to support the single-label name resolution of records that are dynamically registered in WINS, records which typically are not managed by IT administrators. Support for these dynamically registered records is not scalable, especially for larger customers with multiple domains and/or forests. This deployment guide is designed to help customers understand how to deploy the GlobalNames Zone in a variety of scenarios.

To Enable the GlobalNames Zone functionality, Open a command prompt, Click Start>right click Command Prompt>click Run as Administrator. Type the following, and then press Enter:

Windows Server 2012 Step by Step

Dnscmd ServerName /config /Enableglobalnamessupport 1

To Create the GlobalNames Zone using the Windows Interface, Open the DNS console. In the console tree, right-click a DNS server, and then click New Zone to open the New Zone Wizard> Create a new zone and give it the name GlobalNames. Choose Active Directory storage method and AD replication scope for the zone

newzone

globalnames

Note: Microsoft recommend that you store the zone in AD DS and replicate it to all domain controllers that are DNS servers in the Forest. This will create a new AD DS‑integrated zone called GlobalNames which is stored in the forest-wide DNS application partition.

For a customer with many domains, managing a suffix search list for all clients can be cumbersome, and client query performance is also somewhat lowered when querying a single-label name with the list of domains. For environments that require both many domains and single-label name resolution of corporate server resources, GNZ provides a more scalable solution.

Setting Organizational Unit: OUs organize resources like computers, users, servers and printers. The more you organize OU the better you can manage Active Directory. OU also help you to segregate control and permission through delegation. This requirement could be the result of management wishes for delegation, or to give control over OUs to specific administrators based on corporate policies or because of the acquisition of other companies.

image

 Active Directory Group Policy Object:  Group Policy enables administrators to manage configurations for groups of computers and users, including options for registry-based policy settings, security settings, software deployment, scripts, folder redirection, Remote Installation Services, and Internet Explorer maintenance. By using Group Policy, you can deploy software packages and secure computers and users . Because of factors such as the large number of policy settings available, the interaction between multiple policies, and inheritance options, Group Policy design can be complex. By carefully planning, designing, testing, staging and implementing a solution based on your organization’s business requirements, you can provide the standardized functionality, security, and management control that your organization needs. Do not use Windows XP GPMC to deploy software and any security. Use Windows 7 or Windows Server 2008 GPMC to deploy group policy. Why is that? When you use Windows XP GPMC to create group policy it copies ADM folder to newly created GPO folder which resides in SYSVOL. ADM folder is just a template not real GPO. If you continuously create GPO using XP GPMC you will be copying 4MB extra files in SYSVOL which is un-necessary. However, using windows7 GPMC does not copy ADM template into new GPO folder. Its saves disk space and create less mess in GPO SYSVOL. If you are heavily dependent on GPO, you can utilize advanced group policy management to fulfill your requirements.

Read Only Domain Controller (RODC): RODC is highly  advantageous for branch deployment where physical security isn’t guaranteed and no system administrator is present to maintain domain controller whereas you want an reliable authentication provider. Microsoft has introduced the read-only domain controller (RODC) with the release of windows server 2008. The RODC contains a read-only copy of the Active Directory database that cannot be directly configured. This increases security, especially in areas where the physical security of the domain controller cannot be guaranteed.This functionality is gained by the RODC introducing technologies such as the following:

  • Read-only AD DS database
  • Unidirectional replication
  • Credential caching
  • Administrator role separation
  • Read-only DNS

 windows server 2008 domain controller installation wizard, simply select RODC to install RODC.

RODC

Tombstone Life Cycle: Depending on your system environment and business practices, you can increase or decrease the deleted object lifetime and the tombstone lifetime. If you want your deleted objects to be recoverable for longer than the default 180 days, you can increase the deleted object lifetime. If you want your recycled objects to be recoverable (through authoritative restore) for longer than the default 180 days, you can also increase the tombstone lifetime. I would not recommend to setup tombstone life is 3 days or a week though for weird reason I found systems administrator does this mistake. To modify Tombstone life using ADSIEDIT.msc follow the screenshot

Tombstone

Tombstone2

To modify the deleted object lifetime by using the ADSIEDIT.msc
deleted object

 Active Directory Core Installation : In keeping with Microsoft’s ongoing battle against all things security (whether implied or true), the company has introduced a new type of server for 2008. Windows 2008 Server Core is a Windows server that does not contain a GUI. All administration of Server Core is performed via the command line or via scripting. You may also administer some functions by connecting to Server Core from another server’s Microsoft Management Console (MMC) utility. Server Core was introduced for many reasons:

  • Reduced attack surface
  • Reduced management
  • Less disk space
  • Reduced maintenance

What you should do before implementing Active Directory:  When working with any design, make sure you have a good framework from which to work. You need to plan, design, develop and deploy. Risk assessment vital for any project you do. For Microsoft Active Directory risk assessment is crucial stage. When you design Active Directory, you must keep in mind fault tolerance, highly available proportionate systems that meet your business needs. 

Active Directory Post Consideration: Once you have deployed Active Directory, revisit your plan and follow what you have done practically. You must stick with your plan to minimize risk might have. The following would be a good best practice for post deployment consideration.

  • Setup appropriate security in Active Directory and DNS
  • Tighten up security for computers and users using GPO
  • Delegate controls for OU
  • Configure Sites and Subnets
  • Setup correct replication policy
  • Setup Audit policy in Active Directory
  • Setup patching schedule

Patching Domain Controller using WSUS: Microsoft releases hotfixes, patch and service pack for Microsoft Windows operating system. Its necessary to keep yourself up to date with Microsoft products. Subscribe Microsoft security bulletins to get an updates from Microsoft Corp. Microsoft release updates in the third quarter of each month. A common patching involve asses, identify, evaluate and plan and than deploy. To follow a best practice, you must create a staging area separated from your production Active Directory infrastructure where you can stage an domain controller patching using WSUS.  Staging will eliminate any unnecessary risk and avoid catastrophe. visit this URL to learn more about WSUS. 

AD DS Port: AD DS port management is vital for AD administrator. By default ldap is configured with port 389. Its not a best practice to change port number to new port number. However if you do change port number for security reason, make sure you unblock that port in FF TMG and firewall and keep a record of the change. Occasionally, I found that  systems administrator change ldap port in Active Directory DNS and security administrator block new ldap port in firewall. I would recommend you to get more information on AD DS port requirement from TechNet and deploy AD port as appropriate.

port

Microsoft Active Directory— DO and DONT:

KISS (Keep it simple & sweet) Policy: The first bit of advice is to keep things as simple as you can. Active Directory is designed to be flexible, and if offers numerous types of objects and components. But just because you can use something doesn’t mean you should. Keeping your Active Directory as simple as possible will help improve overall efficiency, and it will make the troubleshooting process easier whenever problems arise.

Avoid mixing up server roles  and app with domain controller: Avoid mixing up other server roles with Active Directory Domain Controller. For example, installing FF TMG , SQL server, exchange or IIS FTP on domain controller server is an worse idea. This will create a complete chaos among all these infrastructures. Domain controller will not perform at its best. Adding additional roles to a domain controller can affect the server’s performance, reduce security, and complicate the process of backing up or restoring the server.  

Use the appropriate site topology: Although there is definitely something to be said for simplicity, you shouldn’t shy away from creating more complex structures when it is appropriate. Larger networks will almost always require multiple Active Directory sites. The site topology should mirror your network topology. Portions of the network that are highly connected should fall within a single site. Site links should mirror WAN connections, with each physical facility that is separated by a WAN link encompassing a separate Active Directory site. Keep adding all the new subnets in the appropriate sites.

Branch domain controllers:  Having a read only domain controller in a branch is always good idea. However, if you want to setup a writable domain controller in branch than make sure you have tightened security and delegation in place. 

DNS & GC Server: Microsoft recommend that you make all domain controller global catalog server. I found systems administrator install domain controller without integrating DNS with AD. you must integrate Active Directory with DNS. If you have a single DNS server and that DNS server fails, Active Directory will cease to function. Its better to have a more than one Active Directory, GC and DNS to obtain redundancy.

Virtualized Domain Controllers: : One of the main reasons organizations use multiple domain controllers is to provide a degree of fault tolerance in case one of the domain controllers fails. However, this redundancy is often circumvented by server virtualization. I often see organizations place all their virtualized domain controllers onto a single virtualization host server. So if that host server fails, all the domain controllers will go down with it. There is nothing wrong with virtualizing your domain controllers, but you should scatter the domain controllers across multiple host servers.

Maintain FSMO roles (backups): Although Windows 2000 and every subsequent version of Windows Server have supported the multi-master domain controller model, some domain controllers are more important than others. Domain controllers that are hosting Flexible Single Master Operations (FSMO) roles are critical to Active Directory health. Active Directory is designed so that if a domain controller that is hosting FSMO roles fails, AD can continue to function — for a while. Eventually though, a FSMO domain controller failure can be very disruptive.

I have seen sys admin say that you don’t have to back up every domain controller on the network because of the way Active Directory information is replicated between domain controllers. While there is some degree of truth in that statement, backing up FSMO role holders is critical. I once had to assist with the recovery effort for an organization in which a domain controller had failed. Unfortunately, this domain controller held all of the FSMO roles and acted as the organization’s only global catalog server and as the only DNS server. To make matters worse, there was no backup of the domain controller. We ended up having to rebuild Active Directory from scratch. This is an extreme example, but it shows how important domain controller backups can be. You can deploy Symantec live state backup for physical server or VCB backup for  virtual DC.

Plan your domain structure and stick to it: Most organizations start out with a carefully orchestrated Active Directory architecture. As time goes on, however, Active Directory can evolve in a rather haphazard manner. To avoid this, I recommend planning in advance for eventual Active Directory growth. You may not be able to predict exactly how Active Directory will grow, but you can at least put some governance in place to dictate the structure that will be used when it does.

Have a management plan in place before you start setting up servers: Just as you need to plan your Active Directory structure up front, you also need to have a good management plan in place. Who will administrator Active Directory? Will one person or team take care of the entire thing or will management responsibilities be divided according to domain or organizational unit? These types of management decisions must be made before you actually begin setting up domain controllers.

Try to avoid making major logistical changes: Active Directory is designed to be extremely flexible, and it is possible to perform a major restructuring of it without downtime or data loss. Even so, I would recommend that you avoid restructuring your Active Directory if possible. I have seen more than one situation in which the restructuring process resulted in some Active Directory objects being corrupted, especially when moving objects between domain controllers running differing versions of Windows Server.

Domain controller & NTP: It’s not bad to make domain controller a NTP. Its better to have a separate NTP server if you can. But you will be experience event  log in domain controller. It would not be a good idea to make a virtualized domain controller having an NTP role. 

Relevant Study:

Active Directory Domain Services Guide

Microsoft Active Directory Topology Diagrammer

Risk and Health Assessment Program for Active Directory (ADRAP) – Scoping Tool v1.6

Active Directory Domain Services in the Perimeter Network (Windows Server 2008)

Read-Only Domain Controller (RODC) Branch Office Guide

Windows Server 2008 Remote Server Administration Tools for Win 7

Installing or Removing the Remote Server Administration Tools Pack

Planning and Deploying Read-Only Domain Controllers

Infrastructure Planning and Design

 

Optimizing Microsoft Active Directory FSMO roles

There are five Active Directory Flexible Single-Master (FSMO) roles in the domain and forest. The Active Directory Installation Wizard defines five FSMO roles: schema master, domain master, RID master, PDC emulator, and infrastructure. The schema master and domain naming master are per-forest roles (eg. www.A.com). The remaining three, RID master, PDC emulator, and infrastructure master, are per-domain roles.

A forest with one domain (eg www.A.com) has five roles. Every additional domain in the forest adds three domain-wide roles. The number of FSMO roles in a forest and potential FSMO role owners can be determined using the formula ((Number of domains * 3)+2). A forest with three domains (A.com, with child and grandchild domains of B.A.com and C.B.A.com) has eleven FSMO roles:

Schema master – forest-wide A.COM
Domain naming master – forest-wide A.COM
PDC emulators (A.com, B.A.com, and C.B.A.com)
RID masters (A.com, B.A.com, and C.B.A.com)
Infrastructure masters for each respective domain. (A.com, B.A.com, and C.B.A.com)

FSMO scenario:

  • In a Single domain with only one domain controller: holds all five FSMO roles.
  • If a domain has more than one domain controller, use Active Directory Sites and Services Manager to select direct replication partners with persistent. You may select specific roles to specific domain controller and distribute it.
  • The standby server may be in the same site as the primary FSMO server for faster replication convergence consistency over a large group of computers, or in a remote site in the event of a site-specific disaster at the primary location.
  • Where the standby domain controller is in a remote site, ensure that the connection is configured for continuous replication over a persistent link. (support tools> replmon.exe to check replication)
  • FSMO placement:

  • Place the RID and PDC emulator roles on the same domain controller. It is also easier to keep track of FSMO roles if you host them on fewer machines. If the load on the primary FSMO load justifies a move, place the RID and primary domain controller emulator roles on separate domain controllers in the same domain and active directory site that are direct replication partners of each other. Example, I have four domain controllers and two of them holds FSMO roles. rest are stand by in case of failure I can move them.
  • Infrastructure master must not be a Global Catalog (GC). Because the global catalog server holds a partial replica of every object in the forest, the infrastructure master, if placed on a global catalog server, will never update anything, because it does not contain any references to objects that it does not hold. Two exceptions to the “do not place the infrastructure master on a global catalog server” rule are:
  • Single domain forest: In a forest that contains a single Active Directory domain, there are no phantoms, and so the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.
  • Multidomain forest where every domain controller in a domain holds the global catalog:  If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain.
  • the schema master and domain naming master roles should be placed on the same domain controller. Additionally, the domain naming master FSMO should also be a global catalog server. Certain operations that use the domain naming master, such as creating grand-child domains, will fail if this is not the case. In a forest at the Forest Functional Level Windows Server 2003, you do not have to place the domain naming master on a global catalog.
  • You may use the Ntdsutil.exe utility to transfer or to seize Flexible Single Master Operations (FSMO) roles.

    Transfer FMSO Roles: It is recommend that you transfer FSMO roles in the following scenarios:

  • The current role holder is operational and can be accessed on the network by the new FSMO owner.
  • You are gracefully demoting a domain controller that currently owns FSMO roles that you want to assign to a specific domain controller in your Active Directory forest.
  • The domain controller that currently owns FSMO roles is being taken offline for scheduled maintenance and you need specific FSMO roles to be assigned to a “live” domain controller. This may be required to perform operations that connect to the FSMO owner. This would be especially true for the PDC Emulator role but less true for the RID master role, the Domain naming master role and the Schema master roles.
  • Log on to a Admin PC or domain controller that is located in the forest where FSMO roles are being transferred as a Enterprise Admin and Schema Admin rights. Microsoft recommend that you log on to the domain controller that you are assigning FSMO roles to. However, its not necessary if you know what you are doing.

  • Click Start, click Run, type ntdsutil.exe in the Open box, and then click OK.
  • Type roles, and then press ENTER.
  • Type connections, and then press ENTER.
  • Type connect to server servername, and then press ENTER, where servername is the name of the domain controller you want to assign/transfer the FSMO role to.
  • At the server connections prompt, type q, and then press ENTER.
  • Type transfer role, where role is the role that you want to transfer. For a list of roles that you can transfer, type ? at the fsmo maintenance prompt, and then press ENTER, Syntax Example,
  • transfer rid master

    Transfer PDC

    Transfer Schema Master

    transfer domain naming master

    transfer infrastructure master

    At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.

    Seize FSMO roles: Seizing FSMO roles is a critical decision. Perform Seizure operation if you fail to demot a domain controller gracefully that holds FSMO roles or if one of domain controller (holds FSMo roles) is completely failed to communicate with another domain controller in a forest. In this case you have no option but to seize FSMO roles.

  • Click Start, click Run, type ntdsutil in the Open box, and then click OK.
  • Type roles, and then press ENTER.
  • Type connections, and then press ENTER.
  • Type connect to server servername, and then press ENTER, where servername is the name of the domain controller that you want to assign the FSMO role to.
  • At the server connections prompt, type q, and then press ENTER.
  • Type seize role, where role is the role that you want to seize. For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press ENTER, Syntax are:
  • seize rid master

    seize PDC

    seize Schema Master

    seize domain naming master

    seize infrastructure master

  • At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.
  • Global Catalog: Double check, schema master and naming master is a GC. To check whether a domain controller is also a global catalog server:

  • Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • Double-click Sites in the left pane, and then locate the appropriate site or click Default-first-site-name if no other sites are available.
  • Open the Servers folder, and then click the domain controller.
  • In the domain controller’s folder, double-click NTDS Settings.
  • On the Action menu, click Properties.
  • On the General tab, view the Global Catalog check box to see if it is selected.
  • Metadata Clean up: Perform this operation if you fail to demot a DC from a forest otherwise not.

    1. Click Start, point to Programs, point to Accessories, and then click Command Prompt.
    2. At the command prompt, type ntdsutil, and then press ENTER.
    3. Type metadata cleanup, and then press ENTER.
    4. Type connections and press ENTER.
    5. Type connect to server servername, and then press ENTER.
    6. Type quit, and then press ENTER. The Metadata Cleanup menu appears.
    7. Type select operation target and press ENTER.
    8. Type list domains and press ENTER. A list of domains in the forest is displayed, each with an associated number.
    9. Type select domain number and press ENTER, where number is the number associated with the domain the server you are removing is a member of. The domain you select is used to determine whether the server being removed is the last domain controller of that domain.
    10. Type list sites and press ENTER. A list of sites, each with an associated number, appears.
    11. Type select site number and press ENTER, where number is the number associated with the site the server you are removing is a member of. You should receive a confirmation listing the site and domain you chose.
    12. Type list servers in site and press ENTER. A list of servers in the site, each with an associated number, is displayed.
    13. Type select server number, where number is the number associated with the server you want to remove. You receive a confirmation listing the selected server, its Domain Name System (DNS) host name, and the location of the server’s computer account you want to remove.
    14. Type quit and press ENTER. The Metadata Cleanup menu appears.
    15. Type remove selected server and press ENTER. You should receive confirmation that the removal completed successfully. If you receive the following error message, the NTDS Settings object may already be removed from Active Directory
    16. Type quit, and then press ENTER
    17. In the DNS console, use the DNS MMC to delete the A record in DNS. The A record is also known as the Host record. To delete the A record, right-click the A record, and then click Delete. Also, delete the cname record in the _msdcs container. To do this, expand the _msdcs container, right-click cname, and then click Delete. Important If this is a DNS server, remove the reference to this DC under the Name Servers tab. To do this, in the DNS console, click the domain name under Forward Lookup Zones, and then remove this server from the Name Servers tab.
    18. If the deleted computer is the last domain controller in a child domain, and the child domain was also deleted, use ADSIEdit to delete the trustDomain object for the child. To do this, follow these steps:
    • Click Start, click Run, type adsiedit.msc, and then click OK
    • Expand the Domain NC container.
    • Expand DC=Your Domain, DC=COM, PRI, LOCAL, NET.
    • Expand CN=System.
    • Right-click the Trust Domain object, and then click Delete.

       19.  Use Active Directory Sites and Services to remove the domain controller. To do this, follow these steps:

    • Start Active Directory Sites and Services.
    • Expand Sites. Expand the server’s site. The default site is Default-First-Site-Name.
    • Expand Server.  Right-click the domain controller, and then click Delete.

    Verifying Flexible Single Master Operations (FSMO)

    %Program File%>Windows Resource Kits>Tools>Replmon

    netdom command syntax 

     netdom query fsmo /domain:yourdomain.com.au

     dsquery command syntax

     dsquery server -hasfsmo schema

    dsquery server -hasfsmo name

    dsquery server -hasfsmo infr

    dsquery server -hasfsmo rid

    dsquery server -hasfsmo pdc

     DCDiag Command Syntax

     dcdiag /test:knowsofroleholders /v

     dumpfsmos.cmd Command  Syntax

     dumpfsmos.cmd yourdomain.com.au

    Further Study:

    Microsoft Active Directory

    Keywords: Microsoft Active Directory, FSMO roles.

    Active Directory health check

    Events View

    Check event log in all DCs to find everything ok specifically DNS, system and Application events.

    Dcdiag.exe

    This is a must and will always tell you if there is trouble with DCs and/or services associated with it

    Netdiag.exe

    This will let me know if there are issues with the networking portion on the DC.

    Netsh dhcp show server

    This command identify DHCP in in AD infrastructure.

    Repadmin /showreps

    This shows all replication among DCs.

    repadmin /replsum /errorsonly

    reapadmin /syncall /AdeP

    This will identify any issues with replication among DCs.

    Active Directory DNS Check

    Dnslint /ad domain_controller_ip_address /s dns_server_ip_address

    third-party tools

    Manage Engine AD Manager Plus, Wise Soft Bulk user Admin, Solarwinds Engineer’s toolset, Active Directory Cleaner are very handy tools to monitor and manage Active Directory.

    These are little things that give me peace of mind. I reckon “assume nothing, believe nothing, check everything…..” is the best way to prevent disaster.