Here is another short article from the "Behind the scenes" series, this time about Exchange test environments. I often have a need for an Exchange test environment, so what could be more obvious than automating the installation?
Foreword
Essentially, a test environment for me always consists of a domain controller and an Exchange server. Occasionally, there are also larger labs with several domain controllers and Exchange servers, sometimes in different domains. I install the labs on my workstation as Hyper-V VMs.
Maybe some of you are interested in how to automate the installation of a lab on your own computer and since I was in the process of adapting the environment for Exchange 2019 anyway, here is an article about it.
I realized the automatic Lab installation with 4 PowerSchell scripts, if you want to know how exactly this works, just read on.
However, the scripts cannot be used generally and require customization to your own needs. There are various paths and queries that relate to my workstation, but with a little effort this can also be adapted to your own environment.
The requirements
I have created a template for each operating system and combined the VHDX files in a folder. The templates only contain the operating system and a few small adjustments, for example I deactivated the automatic start of the Server Manager and installed the latest Windows updates:
When I start one of these templates, for example, a fresh Windows 2016 server boots with the latest updates. For me, this is easy to use, I only need to install the operating system once as a template and customize it to my liking. If there are new Windows updates, I only need to boot the template, install the updates and I can install new labs based on the current template.
So that there are no problems with the installation of domain controllers or members, I run Sysprep with a response file before shutting down a template. This generates a new SID and also directly sets the local administrator password, which I can use for the installation.
All scripts can be found at the end of the article.
Furthermore, there are additional VHDX files in a separate directory that are used by the scripts:
ExchangeDisk.vhdx is simply an empty 200 GB disk formatted with NTFS. ExchangeDisk.vhdx does not contain any data, but is used by the scripts for the installation of Exchange Server. The ResourceEX20XX.vhdx files contain the prerequisites for Exchange (UCMA, NET Framework) and the Exchange ISO itself:
The advantage for me here is that I can simply replace or add individual components. For example, if there is a new Exchange version, I simply replace the ISO in theEXxxxx.vhdx resource. The same applies to other components such as Visual C++ 2013 Runtime. Since the Visual Studio Runtime is recently a prerequisite for Exchange Server, I simply added the package to Resource Disk and extended the script for installing the package.
The scripts
Automation takes place via four Powershell scripts:
- New-ExchangeLab.ps1
- New-VMFromTemplateV2.ps1
- New-DomainControllerVM
- New-ExchangeServerVM.ps1
The script New-ExchangeLab.ps1 basically only asks for the parameters for the installation of the Lab environment and lists the SSDs of my workstation so that I can select on which SSDs the Lab should be deployed. New-ExchangeLab.ps1 then executes the three other scripts with the specified parameters.
New-VMFromTemplateV2.ps1 clones the corresponding VMs from the selected templates and configures the host name and IP address for the VM.
New-DomainControllerVM installs the domain controller role and upgrades the server to domain controller.
New-ExchangeServerVM.ps1 installs the Exchange prerequisites and installs Exchange Server.
There is also the file Deploy.xml and sysprep.bat. Sysprep.bat starts Sysprep and expands to the file C:\Deploy\deploy.xml. I use these two files for the templates to complete the installation.
The scripts are not generally ready for use but must be adapted to the respective environment.
In my defense: Some parts of the scripts are quite old and I have rewritten them over and over again, so there are some parameters/functions/variables that are no longer used and also a few static paths and queries that refer to my environment. The many sleeps in the scripts are also dirty, I will improve this when I get the chance. In order for the scripts to run in other environments, some work would have to be done.
I am happy to answer questions about the scripts and the environment, but I require PowerShell knowledge. The scripts are expressly intended for labs only and not for productive environments!
The New-ExchangeLab.ps1 script queries these parameters and then creates a fresh Exchange Lab environment:
Download
The scripts can be downloaded here:
Adaptation to your own test environment
As already mentioned, the scripts must be adapted to your own environment. I can already reveal the following points:
Deploy.xml; line 7, The local administrator password must be entered here; this is queried by the script and then also used as the domain administrator password.
New-ExchangeServerVM.ps1; line 9+10The paths to Resource and ExchangeDisk must be adjusted here.
New-VMFromTemplateV2.ps1; line 16+17The path to the template directory must be adjusted here and the name of the Hyper-V virtual switch must be entered.
On the subject of sysprep.bat and deploy.xmlThese two files are only intended for the templates. So that several domain controllers can be created from the same template, the SID must be different. In addition, the script must know the administrator password in order to execute the commands. After installing the template (or after installing an update), I execute sysprep.bat once. The small batch file starts Sysprep with a response file (deploy.xml). This generates a new SID and sets the local administrator password.
Update 28.08.2018: The script New-ExchangeLab.ps1 was missing in the ZIP, this is now included. Many thanks for the hints.
Da ich mich gerade in Powershell einarbeite, kamen mir die Scripte wie gerufen. Vielen Dank dafür!
Allerdings fällt mir auf, dass Du Powershell Direct verwendest.
Was mich interessiert ist, wie du es hinbekommst, dass die Powershell Direct- (oder VMDirect) Befehle auf Host/Gast
kleiner Windows 2016 bzw. Win10 laufen?
Soweit ich informiert bin läuft ein Invoke-Command auf den Parameter -VMName oder -VMid nur dann, wenn Gast und Host eben 2016 oder unter 10 laufen.
Gruß Patric
Hallo Frank,
in deinem Script sehe ich deinen Kommentar zum Reboot.
Ich hatte mal das selbe Problem und habe es wie folgt gelöst:
$vmCheck = Get-VMIntegrationService -VMName $vmName -Name Takt
while ($vmCheck.PrimaryStatusDescription -ne „OK“)
{
$vmCheck = Get-VMIntegrationService -VMName $vmName -Name Takt
sleep 1
}
sleep 5
Dabei wird das Attribut Takt der VM abgefragt und diese gibt nur „OK“ wenn die Maschine gebootet ist.
Das Sleep am Ende von 5 Sekunden ist nur zur Sicherheit.
Vielleicht macht es sinn nicht den Takt sondern etwas anderes Anzufragen aber damit habe ich bisher keine Probleme gehabt.
Gruß
Felix
Hi Frank,
vielen Dank dafür. Auch ich vermisse die New-ExchangeLab.ps1, kannst du die vielleicht bei Zeiten noch ergänzen?
Gruß,
Stefan
Hallo Lars, Hallo Stefan,
vielen Dank für den Hinweis. Das Script New-ExchangeLab.ps1 ist nun im Archiv enthalten.
Gruß, Frank
Hallo Frank,
vielen Dank für diese gute Anleitung und natürlich für die Bereitstellung deiner Scripte.
Wenn ich die Powershell Scripte allerdings herunterlade fehlt das „New-ExchangeLab.ps1“ Script.
Gruß
Lars
Hallo Frank,
meines Wissens wäre Sysprep doch nur 3x möglich bei deinen Templates. Oder habe ich deine oben beschriebene Handhabung, bezgl. Sysprep, falsch verstanden?
Gruß
Danny