Introduction
This the fourth part in a multi-part set of articles on building a test lab with Hyper-V and PowerShell. See the following prior articles in this series.
- The purpose of these scripts/articles: http://www.tfl09.blogspot.co.uk/2013/01/building-hyper-v-test-lab-on-windows-8.html.
- Creating a reference VHDX ( http://www.tfl09.blogspot.co.uk/2013/01/building-hyper-v-test-lab-on-windows.html)
- Creating VMs (http://www.tfl09.blogspot.co.uk/2013/01/building-hyper-v-test-lab-on-windows-8_16.html).
Creating the DC
The starting point for creating a DC is having a simple work group VM created and run. In the last article I covered how to build a Hyper-VM Based a differencing/parent pair of disks. That process generates a work group computer, with a known IP address, a known hostname and a known user id/password set of credentials. The VM that is created has just the standard set of services and features that the base installation process generates (i.e. the same as if you just click next/next/next installing a VM from a DVD).
In Windows Server 2012, the process of creating a DC has changed quite considerably from earlier versions of Windows Server. DCPromo.exe is no more – you now promote a server by using PowerShell cmdlets (although I suppose you could use the GUI – but where’s the fun in that?).
The installation process for a new DC in a new forest comprises two simple steps:
1. Using Install-WindowsFeature to add the AD-Domain-Services and related management tools.
2. Using Install-ADDSForest, create a new domain and domain controller, install DNS, and set the domain/forest modes (i.e. what DCPromo.exe used to do in years gone past).
Using remoting to perform the DC promotion
In the first two scripts that create and start up the VM, I created a function that I then ran on the local system, i.e. the host you are using to run Hyper-V. All the development was done using Windows 8 and Server 2012 which both run Hyper-V. The remainder of the scripts to setup and configure the domain and servers is done using remoting plus some local hyper-v stuff. Basically, the remaining scripts all have the following pattern:
a) Create a script block containing PowerShell code to perform some configuration on a server.
b) Use Invoke-Command to run that script block on a remote server (i.e. one or more of the Hyper-V VMs you are building/configuring.
This process is flexible and allows me to do things before invoking the script block. For example, to install SQL, Exchange and Lync, I need to have the product CD inserted in the D: drive. For Exchange, I have to load some pre-requisites onto the server, for example bits of IIS, etc. In that case, my published script file can create a couple of script blocks to divide up the work.
When I am building out a new set of VMs, I open ALL the scripts in the ISE on the Hyper-V host (which in most cases is actually being used via a terminal services window!) With all the scripts up, I just work through them, building the base disk, building then promoting DC1, finishing off DC1 configuration, configuring a CA, Configuring the IIS servers, etc.
Promoting with PowerShell
The PowerShell code to carry out the promotion is as follows:
Install-WindowsFeature –Name AD-Domain-Services –IncludeManagementTools
$PasswordSS = ConvertTo-SecureString -string 'Pa$$w0rd' -AsPlainText -Force
Install-ADDSForest -DomainName Reskit.Org –Force –InstallDNS `
-SafeModeAdministratorPassword $PasswordSS -DomainMode Win2012 `
-ForestMode Win2012
The first step involves windows loading the necessary components to enable the host to be configured into some sort of DC as well as all the management tools. The second step involved creating a new domain in a new forest. In my case, I set both the forest and domain into Win2012 mode (why not?) as well as specifying a safe mode password.
Completing the DC Promotion
After running these few lines of PowerShell, the Install-ADDSForest cmdlet reboots the machine. At which point, assuming nothing hairy has gone on, you now have a DC. It has one main user, Administrator, whose password is the same as the local machine’s Administrator password (in my case Pa$$w0rd).
Unfortunately, for scripting purposes, the reboot is an asynchronous event – there’s no easy way for a PowerShell script to wait for the reboot and continue. Sure – you can use work flows for that, but I don’t (well not yet!). So to finish off the process of configuring the DC, I’ve created a couple more scripts. The first of these, which I’ll describe later, is one you run after the DC has rebooted. This second script does a bit more configuration on the DC, including adding any users, OUs, computers, etc. that might be needed. The second, at least in my case, is adding a Certificate Authority to the DC. I’ll look at both of these scripts in future articles.
Getting the Scripts
I have published the full set of deployment scripts to my web site, at http://www.reskit.net/powershell/vmbuild.zip. Note that some of the scripts in this zip file are still works in progress. I reserve the right to change any of all of them from time to time. I will try to blog any important changes.
I am also publishing the individual scripts over on my PowerShell Scripts Blog:
No comments:
Post a Comment