Many services that have traditionally been run on premises are now being moved to public or private clouds, but not every workload is suitable for such a move due to dependencies upon infrastructure components that simply do not work well in the cloud. One such infrastructure component is Active Directory
When Microsoft was preparing to release Office 365, the company knew that it would require Active Directory to function in the cloud. This isn't a big deal for standalone deployments, but many organizations rely upon hybrid deployments in which some Exchange, SharePoint and Lync servers exist on premises while others reside in the Office 365 cloud. These types of deployments require Active Directory synchronization between the on-premises domain and the cloud domain being used by Office 365.
The synchronization process isn't pretty. It is messy to set up and the synchronization only works in one direction. Even so, the Office 365 experiment gave Microsoft some invaluable experience with cloud-distributed Active Directory deployments, and this experience was put to good use in Windows Server 2012.
One of the most important Active Directory features in Server 2012 is the new deployment Wizard. This Wizard, which is built on PowerShell, changes the way in which domain controllers are provisioned. For starters, the Wizard performs a number of prerequisite checks so that issues that might have otherwise caused problems with the new domain controller or with the Active Directory as a whole can be avoided. More importantly however, the new deployment Wizard is designed to work remotely. In other words, you no longer have to run the deployment Wizard directly on the server that is being promoted to a domain controller. Thanks to remote PowerShell, cloud-based servers can be promoted to domain controllers.
Upon completion, the Wizard gives the administrator the option of viewing a PowerShell script that contains an exact copy of the commands that were used to provision the domain controller. This script can be used to automate the provisioning of additional domain controllers, thereby making it very easy to perform large-scale Active Directory deployments. Although script generation is new to Windows Server, it is not new to Microsoft. Both Exchange Server 2007 and Exchange Server 2010 are designed to provide administrators with PowerShell cmdlets for operations that were performed through the graphical user interface. It is really nice to see this type of PowerShell output finally put to work in Windows Server.
Another Windows Server 2012 feature that lends itself well to Active Directory is Deployment with Cloning, which allows the administrator to deploy new domain controllers by simply cloning an existing domain controller.
The process works by setting up a virtual server as a domain controller. After doing so, you can create a copy of the domain controller and then authorize the original source domain controller to be cloned. Windows Server 2012 offers the option of providing a configuration file containing information that can be used in the cloning process such as computer names, IP addresses and DNS servers to be used by cloned domain controllers. However, such a configuration file is not mandatory. If you do not provide Windows with a configuration file the system will attempt to automatically provision cloned domain controllers with computer names, IP addresses, etc.
Clearly, Microsoft has done a lot of work around the domain controller deployment process in Windows Server 2012. It is now more practical to operate hybrid domains in which domain controllers are located both on-premises and in the cloud.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for TechTarget sites.
This was first published in July 2012