Part 5: Deploy and Configure the Host Guardian Service

Previous Post in Series: Part 4: Deploy and Configure a 3 Node 2016 Hyper-V Cluster

Welcome to Part 5 of the Server 2016 Features Series. In this section we’re going to work through an entire end-to-end deployment of the Host Guardian Service, including Hyper-V, SCVMM and in Part 6, VM template configuration and deployment of Virtual Machines using SCVMM.

You can jump to any of the sections covered in this post using the links below:

• Prerequisites
• Configure the First HGS Node
• Install the HGS Into its Own New Forest
• Initialize the HGS Server Using TPM Trusted Attestation
• Installing a Root Certification Authority
• Create HGS Certificate Template
• Create Signing and Encryption Certificates
• Initialize the HGS Server Using TPM Trusted Attestation (Continued)
• Import HGS Certificates and Apply Service Account Permissions
• Configure DNS for the Guarded Host Fabric
• Check Hyper-V Host TPM State
• Capture and Apply the TPM Identifier for Each Host
• Create and Apply a Code Integrity Policy
• Create and Apply a TPM Baseline
• Confirm Host Can Attest Successfully
• Configure Hyper-V Host Guarded Status Within SCVMM
• Configure Additional HGS Nodes

Before we dive into things, it bears mentioning that there are two attestation modes available using the Host Guardian Service, these are:

Admin-Trusted (AD Mode)

Host attestation is controlled by placing the computer object of a Hyper-V host in a security group created in Active Directory. A trust relationship is required between the Host Guardian forest and the fabric Active Directory. This mode of attestation is relatively easy to setup and has no special hardware requirements.

TPM-Trusted (TPM Mode)

Hosts that are guarded using TPM mode use technologies built into the Windows Server operating system such as secured measured boot and code integrity policies. TPM mode has a much more involved deployment when compared to AD Mode, it also has specific hardware and software requirements. The upside of this mode though is that it offers the strongest possible protection.

For this guide we will be concerning ourselves with the TPM mode of attestation as it by far the most secure option and the one I would put into production. It also makes for a much more interesting deployment 🙂

Before continuing through this guide, I would strongly recommend giving THIS post a read. If you’re not a reader though, don’t worry, following this step-by-step should still net you a Guarded Fabric by its end 🙂

 

Prerequisites

A we’re going to be using TPM mode for this deployment, there are a few prerequisites to be aware of.

Hyper-V hosts (I’ve included links if you want more detail on each item):

• IOMMU (Input-Output Memory Management Unit) and SLAT (Second Level Address Translation)
• TPM 2.0 (Trusted Platform Module) – without TPM 2.0 you’ll be forced to use Admin-mode (out of scope for this guide)
• UEFI 2.3.1 or later
• Configured to boot using UEFI (will not work using BIOS or Legacy mode)
• Secure Boot must be enabled
• Running Windows Server 2016 Datacenter Edition
• Running the latest Cumulative Update

Host Guardian Servers

• HGS can be physical or virtual, however physical is recommended as it’s the more secure option
• In a Highly Available physical HGS deployment, hardware between the nodes should be as close to identical as possible
• Running Windows Server 2016 Standard or Datacenter
• Running the latest Cumulative Update

Now that we’ve got the boring stuff out of the way, let’s get to the deployment 🙂

 

Configure the first HGS node

The first thing we need to do is prepare the HGS by installing the Host Guardian Service role. Run the following code in an Elevated PowerShell console, the server will restart when complete, so go grab a coffee because you’re using a physical server…right?

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

 

Install the HGS Into its Own New Forest

Now that we’ve installed the role, we can install the HGS service. This can be installed into an existing forest or (as is recommended) installed into a forest of its own. For this guide, we’ll be installing the HGS into a new forest of its own.

The code below will install the HGS into a domain named “hgsbastion.local”, the password specified here is for the DSRM (Directory Services Restore Mode) only and will not change the password you’re logged on with.

$AdminPassword = ConvertTo-SecureString -AsPlainText "Password" -Force
Install-HgsServer -HgsDomainName "hgsbastion.local" -SafeModeAdministratorPassword $AdminPassword -Restart

Again, the server will restart, when back up, log in as the domain administrator using the same password you used previously for the local administrator account (pssst, this server is now a domain controller on the hgsbastion.local domain) 🙂

 

Initialize the HGS Server Using TPM Trusted Attestation

Before we can initialise the HGS, we’ll need to source a signing and encryption certificate. These need to be one of the following:

• Issued by your own Public Key Infrastructure (PKI)
• A certificate backed by a Hardware Security Module (HSM)
• Self-signed certificates – these should only be used for Proof of Concept deployments

For the purposes of this guide we’re going to deploy a Certificate Authority onto the hgsbastion.local domain we just created and issue our own certificates from there.

NOTE: Your chosen certificates must support RSA 2048 bit keys and their key-usage policy (EKU) must permit digital signing and encryption

 

Installing a Root Certification Authority

Log onto the HGS you just deployed and open “Server Manager”. Click “Add roles and features” located under “Quick Start” and click “Next” 3 times

Select “Active directory Certificate Services”. When prompted, click “Add Features”, now click “Next” 3 times

Select “Certification Web Enrollment” and click “Add Features” when prompted. Now click “Next” 3 times….that damned Next button!

Now click “Install”

Now click “Configure Active Directory Certificate Services…”

Verify that the account showing under “Credentials” is the domain Administrator account and click “Next”

Select both “Certification Authority” and “Certification Authority Web Enrollment” and click “Next”

Select “Enterprise CA” and click “Next”

Now select “Root CA” and click “Next”

Select “Create a new private key” and click “Next”

Select “RSA” for the cryptographic provider, “2048” for the key length and “SHA256” for the hashing algorithm and click “Next”

Accept the defaults for the CA Name and click “Next”.

Specify a validity period that makes sense for your organisation and click “Next”, I stuck with the default value of 5 years.

Specify a location for the CA database and database log, or accept the defaults and click “Next”

Click “Configure” and review the results screen before clicking “Close”

 

Create HGS Certificate Template

Now that we’ve got our Certificate Authority up and running, we can go ahead and issue the certificates we need for initialising our HGS.
We’re going to create a new certificate template for this to make sure the issued certificates are of the correct type

Click on the Start Menu and type “certtmpl.msc” and press enter to launch the “Certificates Template Console”

We’ll start by duplicating an existing certificate template to work as our base, I used the “Computer” template.

Right-click the “Computer” template and select “Duplicate Template”

Change both Compatibility Settings to “Server 2016” as we’ll only be using this CA for issuing the HGS certs and don’t need to worry about backwards compatibility issues.

On the “General” tab, change the “Template Display Name” to something that makes more sense, I went with “HGS Certificates”

Change the “Validity period” to something that works for your organisation, I went with 2 years.

On the “Request Handling” tab, make sure purpose is set to “Signature and encryption” and that “Allow private key to be exported” is ticked

On the “Security” tab, give “Authenticated Users” “Enroll” permissions

On the “Extensions” tab, click “Key Usage” and select “Edit”

Ensure “Digital Signature” is ticked and tick “Allow encryption of user data” and click “OK”

On the “Subject Name” tab, select “Supply in the request” and click “OK”

Now we have to issue the certificate to the Certificate Authority

Click on the start menu and type “certsrv.msc” and press enter to launch the “Certification Authority” console

Right-click on “Certificate Templates”, click “New” and “Certificate Template to Issue”

Select the HGS template you just created and click “OK”

Nice, we can now issue our certificates 🙂 we’re getting there.

 

Create Signing and Encryption Certificates

On your HGS/Certification Authority server, click start and type “certlm.msc” and press enter

Right-click on “Certificates” and select “All Tasks”, “Request New Certificate”

Click “Next” on the “Before You Begin” screen.

Make sure “Active Directory Enrollment Policy” is selected and click “Next”

Tick “HGS Certificates” template (or whatever you named your new template 🙂 Now click the “More information is required…” link

Select “Common Name” from the “Subject Name” drop-down. Type “signing.domainFQDN” in the “Value” field and click “Add>”

Select “DNS” from the “Alternative Name” drop-down. Type “signing.domainFQDN” in the “Value” field and click “Add>”

On the “General” tab, type a “Friendly name” for your certificate. I went with “signing.hgsbastion.local2017”. Now click “OK”

Making sure your certificate template is ticked, click “Enroll”

Review and click “Finish”

Repeat the above process but using “encryption.FQDN” as the “Common Name” value and “DNS” value

Now we want to export the signing and encryption certificates as .PFX

Still within the Certificates – Local computer console, navigate to “Personal”, “Certificates”

Right-click on the signing.FQDN certificate and select “All Tasks”, “Export”

Click “Next” on the welcome screen.

Select “Yes, export the private key” and click “Next”

Accept the defaults on the next screen and click “Next”

Tick the “Password” box and enter a password for your certificate and click “Next”

Type a file path to save your .PFX file to and click “Next” and “Finish”

Repeat the same process for your encryption certificate.

Now, I’m not sure if the following step is strictly required but I always now delete the signing and encryption certificates from the Local Store before proceeding. My thinking here is that if we obtained these certificates from any other Certification Authority, they wouldn’t be installed on the server before running the upcoming Initialize-HgsServer command.

This was always worked for me in the past and has actually failed when I didn’t (pretty sure that was a bug though), but I’ll let you make up your own minds 🙂

 

Initialize the HGS Server Using TPM Trusted Attestation (Continued)

Armed with our certificates, we can now process with Initializing our first HGS server.

The PowerShell you’ll be running below requires the following information:

• A name for your HGS service – This is the distributed network name of the cluster and CANNOT be the FQDN. Use “HGS” for example
• Path to your signing PFX
• Path to your encryption PFX
• The password used when exporting your signing and encryption certificates
• Chosen attestation mode – We’re going with TPM Mode here

Open an elevated PowerShell console and run the following code:

$CertificatePassword = ConvertTo-SecureString -AsPlainText "CertificatePassword" -Force
Initialize-HgsServer -HgsServiceName "Chosen Name" -SigningCertificatePath "C:\Temp\signing.hgsbastion.local.pfx" -SigningCertificatePassword $CertificatePassword -EncryptionCertificatePath "C:\Temp\encryption.hgsbastion.local.pfx" -EncryptionCertificatePassword $certificatePassword -TrustTPM

 

Import HGS Certificates and Apply Service Account Permissions

On your HGS/Certification Authority server, click start and type “certlm.msc” and press enter

Right-click on “Certificates” and select “All Tasks”, “Import”

Click “Next” on the welcome screen. Now click “Browse” and located your signing PFX file and click “Next”

Type the password you used when exporting the certificate, click “Mark this key as exportable…” and click “Next”, “Next” and “Finish”

Repeat the same process for your encryption PFX

Now that our certificates are imported, we need to give the HGS service account Read permissions over the private key

Still within the Certificates – Local computer console, navigate to “Personal”, “Certificates”

Right-click on the signing.FQDN certificate and select “All Tasks” and “Manage Private Keys”

Click “Add”, change the “Object type” scope to “Service Accounts” and type “hgs” in the “Enter the object names to select” box.

Now click “Check Names” and “OK”

The Service account should be added with “Full Control” by default, untick this, leaving “Read” and click “OK”

Now repeat the process for your encryption certificate

Nicely done, your first HGS server has been deployed and configured…coffee time!

 

Configure DNS for the Guarded Host Fabric

For HGS to work correctly, your fabric DNS needs to be able to resolve to your HGS bastion domain. The easiest way to achieve this is by creating a “Conditional Forwarder” on your fabric DNS.

If you have permission to do this yourself, great. If not, pass these instructions on to your Active Directory/DNS administrator.

From a DNS server on your fabric domain, click the start menu, type “dnsmgmt.msc” and press enter.

Expand a domain controller on the left pane and right-click “Conditional Forwarders” and select “New Conditional Forwarder”

Type the name of your HGS bastion domain into the “DNS Domain” field

Type the IP address of your first HGS server into the “IP Address” field and press “Tab”

If like me, you haven’t configured a reverse DNS zone and record on your HGS bastion domain yet , then the IP will fail to resolve to a DNS record. You can ignore this for the time being.

Tick “Store this conditional forwarder in Active Directory…” and select “All DNS servers in this forest” from the drop-down or whatever makes the most sense for your organisation. Now click “OK”

To test that this is working as expected, open an administrative command prompt and flush your DNS cache by typing “ipconfig /flushdns”

Now try pinging your HGS bastion domain

All going well, you should see something similar to this:

 

Check Hyper-V Host TPM State

Let’s check the state of the TPM on each of our Hyper-V hosts before continuing.

Click the start menu and type “tpm.msc” and press enter

We want these to be showing a status of “The TPM is ready for use”.

If the status shows “Reduced functionality”, click the “Clear TPM” action and reboot your host. Here’s how it should look after a reboot but hopefully before if you’re lucky 🙂

 

Capture TPM-mode Information Required by HGS

Before grabbing the necessary information from each host, here is a brief explanation of why we need it.

As previously discussed, we’re going with TPM mode as our method of attestation. TPM modes uses a TPM identifier which is also called a platform identifier OR endorsement key (EKpub), we’ll just stick with TPM Identifier. This identifier is used to determine whether a host is considered “guarded”. This mode of attestation uses both secure boot and code integrity measurements to ensure that the host is in a healthy state and is running only trusted code. Before HGS can understand what we deem to be trusted and healthy, we need to capture some information from our Hyper-V hosts.

TPM Identifier (EKPub) – this is unique to each host

TPM Baseline (Boot Measurements) – Only required once for each class of hardware. e.g. Once per server make and model

Code Integrity Policy (Whitelist of allowed binaries) – Required once for Hyper-V hosts that share common hardware and software

It is recommended that for the TPM baseline and CI Policy you use one host as a “reference” that is representative of each unique class of hardware/software within your datacentre.

Capture and Apply the TPM Identifier for each host

Run the following PowerShell from your SCVMM server in an elevated PowerShell console (providing it has the required networking to your Hyper-V hosts configured).

The PowerShell below assumes that the only Hyper-V hosts being managed by your SCVMM server are the ones we built as part of this guide, if that is not the case, remove:
“(Get-SCVMHost).Name”
and replace it with the host names separated by a comma:
(Invoke-Command -ComputerName HyperVHost1, HyperVhost2, HyperVHost3 {(Get-Platform…)

The script will also ask for credentials, enter Domain Admin credentials. If you’re logged onto your SCVMM server as a Domain Admin, you can remove -Credentials from the command as you’ll already have the required permissions.

$Creds = Get-Credential
Invoke-Command -ComputerName (Get-SCVMHost).Name {(Get-PlatformIdentifier -Name $env:COMPUTERNAME).InnerXml | Out-file C:\Temp\$env:COMPUTERNAME.xml -Encoding UTF8} -Credential $Creds

Each host should now have a file named HOSTNAME.xml in C:\Temp\, copy these files from all hosts across to C:\Temp\ on the HGS server.

Log onto your HGS server and launch an elevated PowerShell Console

NOTE:  Make sure there are no other .xml files in C:\Temp\ (other than the hostname.xml files you just copied across

$TpmHostXMLs = (Get-ChildItem -Path C:\Temp\*.xml).Name
foreach ($XML in $TpmHostXMLs)
{
($XML_Less = $XML.TrimEnd(".xml"))
(Add-HgsAttestationTpmHost -Name $XML_Less -Path C:\Temp\$XML -Force)
}

 

Create and Apply a Code Integrity Policy

The following code will only need to be run on one host if all hosts in the cluster have identical hardware and software, see above.

Here is a quick breakdown of the options we’re setting against our created policy:

Level: Publisher

This is a combination of the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. This rule level allows organizations to trust a certificate from a major CA (such as Symantec), but only if the leaf certificate is from a specific company (such as Intel, for device drivers).

From <https://technet.microsoft.com/itpro/windows/keep-secure/deploy-code-integrity-policies-policy-rules-and-file-rules>

Fallback: Hash

Specifies individual hash values for each discovered binary. Although this level is specific, it can cause additional administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update.

From <https://technet.microsoft.com/itpro/windows/keep-secure/deploy-code-integrity-policies-policy-rules-and-file-rules>

A new CI Policy will be created and converted to a binary format that can be read in and measured by Windows and the HGS

$Model = (Get-WmiObject Win32_ComputerSystem).Model
$CIName = $Model + "CIPolicy1.xml"
New-CIPolicy –Level Publisher –Fallback Hash –FilePath "C:\Temp\$CIName" -UserPEs
$XML_Less = $CIName.TrimEnd(".xml")
$CIExport = $XML_Less + ".p7b"
ConvertFrom-CIPolicy –XmlFilePath "C:\Temp\$CIName" –BinaryFilePath "C:\Temp\$CIExport"

NOTE: Keep a hold of the CIPolicy .xml file as you’ll need this when making changes to the policy or when you want to enforce it (See below)

Copy the .p7b to the HGS server C:\Temp\

Log onto your HGS server and launch an elevated PowerShell Console and run the following:

Add-HgsAttestationCIPolicy -Path C:\Temp\NameofyourPolicy.p7b -Name "PolicyName like model name and number"

To apply the policy, copy it across to “C:\Windows\System32\CodeIntegrity\SIPolicy.p7b” on each host that you want guarded

Although you need to restart the host to apply the policy, hang fire on that for a bit, we’re gonna have to reboot in a little while anyway.

NOTE:  Notice the file has been renamed, that’s both deliberate and required.

—————————————————————————————————————-

The above policy is created in audit mode (logging only) as per Microsoft documented best practice. It is advised that test the CI Policy by running typical workloads like VMs, management agents, backup agents etc. Before putting the host into production though, audit mode should be removed from the CIPolicy which would then enforce any violations.

When you’ve finished your deployment and have tested the CIPolicy to your satisfaction, run the following against your original CIPolicy .xml file (See, told you you’d need to keep it):

Set-RuleOption -FilePath "C:\Temp\NameofyourCIPolicy.xml" -Option 3 -Delete
ConvertFrom-CIPolicy –XmlFilePath "C:\Temp\NameofyourCIPolicy.xml" –BinaryFilePath "C:\Temp\NameofyourCIPolicy_Enforced.p7b"

To apply the enforced policy, copy it across to “C:\Windows\System32\CodeIntegrity\SIPolicy.p7b” on each host that you want guarded

Restart the host to finish applying the new policy.

——————————————————————————————————————

 

Create and Apply a TPM Baseline

Before we can grab the TPM baseline on our reference host, we have to install the Host Guardian feature

Put the first Hyper-V host into maintenance mode within SCVMM, then log on and run the following PowerShell

Install-WindowsFeature HostGuardian -IncludeManagementTools -Restart

Once the host has come back up, open an elevated PowerShell console and run the following:

$Model = (Get-WmiObject Win32_ComputerSystem).Model + ".tcglog"
Get-HgsAttestationBaselinePolicy -Path C:\Temp\"$Model" -SkipValidation

NOTE:  You will need to provide the -SkipValidation flag if the reference host does not have a CIPolicy enforced or Secure Boot enabled. These validations are there to make you aware of the minimum requirements running a shielded VM, but do not affect the output of this cmdlet. If you’ve been following the guide though, you should be good 🙂

Now copy the TCGlog file to “C:\Temp\” on your HGS server.

Back to your HGS server and open an elevated PowerShell console.

The following code will add the baseline policy you created as an authorized baseline for attestation purposes:

$TPMPolicy = (Get-ChildItem -Path C:\Temp\ | where Name -Like "*.tcglog").Name
$TPMPolicyName = $TPMPolicy.TrimEnd(".tcglog")
Add-HgsAttestationTpmPolicy -Path C:\Temp\$TPMPolicy -Name $TPMPolicyName

We’re now in a position to check that our HGS is working as intended, still within the same PowerShell console, run the following command:

Get-HgsTrace -RunDiagnostics

You should see the following output:

 

Confirm Host Can Attest Successfully

So now that we know our HGS is working as intended, lets makes sure our first Hyper-V host is too.

Although this section can be done using SCVMM, I feel this give a better understanding of how it’s all put together.

Back at Initialise the HGS Server Using TPM Trusted Attestation (Continued) you selected a name for your HGS Service, you’ll need this name here, in my example I called it “hgs”. The Key Protection and Attestation URLs you’re about to configure will make use of this, so for my example those URLS will be:

-AttestationServerUrl “http://hgs.hgsbastion.local/Attestation“

-KeyProtectionServerUrl “http://hgs.hgsbastion.local/KeyProtection“

With that in mind, log onto your reference Hyper-V host, open an elevated PowerShell console and run the following:

Set-HgsClientConfiguration -AttestationServerUrl "http://HGS Service FQDN/Attestation" -KeyProtectionServerUrl "http://HGS Service FQDN/KeyProtection"

Other than the configured URLs, your output should be identical to this:

Nice, so it looks like everything is working thus far. Now we need to get the other hosts in the cluster up to the same level.

Repeat the steps below on all remaining hosts that you want to guard:

Put host into maintenance mode in SCVMM
Install the Host Guardian feature and restart the host

Install-WindowsFeature HostGuardian -IncludeManagementTools -Restart

When the host is back up and running, configure it’s Attestation and Key Protection URLs

Set-HgsClientConfiguration -AttestationServerUrl "http://HGS Service FQDN/Attestation" -KeyProtectionServerUrl "http://HGS Service FQDN/KeyProtection"

Makes sure the observed output is the same as your reference host above.
If the “IsHostGuarded” status shows as “False”, try an “ipconfig /flushdns” and ping your hgs service DNS name, assuming it responds, run “Get-hgsClientConfiguration” from PowerShell to recheck.

If is doesn’t respond, then there is a good chance you have an issue with DNS resolution between your host fabric and your HGS bastion domain.  Put your HGS service name into the hosts file on your Hyper-V host and recheck.

If “IsHostGuarded” now shows as “True”, then troubleshoot your DNS 🙂

Now that all hosts are configured and are attesting successfully, let’s get SCVMM up to the same level and give it control over our guarded hosts and CI Policy.

 

Configure Hyper-V Host Guarded Status Within SCVMM

SCVMM has awareness of the Host Guardian status of our Hyper-V hosts, it also has the ability to manage and push out our Code Integrity policies.

Because we’ve set everything up using PowerShell, SCVMM is a little out of the loop at present, but we can fix that fairly easily.

First of all, this should be the status of your hosts within the SCVMM console:

When viewing one of the hosts properties, we can see the reason for “Needs Attention” is (as mentioned above) because SCVMM hasn’t yet been configured to deal with our guarded hosts.

To resolve this, we’re going to make SCVMM aware of our Attestation and KeyProtection URLs and also give it control of our (already applied) Code Integrity policy.

For SCVMM to push out our CI Policies, they have to sit on a file share that is read accessible to both your SCVMM and Hyper-V host computer accounts.

For this example, I’ve created a file share on the SCVMM server itself, you could make this a highly available share though by placing it on the Scale-Out file server you created earlier.

Once you’ve created the share, copy your CI Policy to it (The .p7b file you created earlier and before you renamed it to SIPolicy.p7b)

With that in mind, navigate to “Settings”, “General” and open “Host Guardian Service Settings”

Enter the Attestation Server and Key Protection Server URLs you configured earlier

Now click “Add”, enter the a name for your CI Policy and place the path to your file share stored CI policy (including file name) in the “File Path” field

NOTE:  Do not use quotes in your file path, even if your path has spaces in it, SCVMM will handle this. Using quotes will cause it to fail.

Now click “Finish”

After 30 seconds or so, your host status should change to “OK”.

Now that we’ve enabled support for the Host Guardian Service within SCVMM, all that’s left to do is enable the use of our CI policy.

Being that we’ve already taken care of this out-with SCVMM, the host won’t actually reboot it’ll just give SCVMM control.

To do this, place your first host into maintenance mode.

Right-click on the host and select “Properties” and click “Host Guardian Service”. It should look something like this:

Place a tick in “Use a Code Integrity policy to restrict the software…” and click “OK”

This will kick of a job that applies the correct URLs and CI policy (which we’ve already done), hence no reboot 🙂

You receive a warning, more of an information popup really 🙂 This can be ignored by clicking “Yes”

Stop maintenance mode on the host and repeat the above process for the remaining hosts in your guarded cluster.

CONGRATULATIONS, you how have a work HGS cluster (single node) and a guarded host cluster 🙂

Now you’ll notice that I said HGS was currently a single node, in a production environment, you’ll want at least two nodes in that cluster to make your attestation service highly available.

The process below details how to add a second node to your HGS.

 

Configure Additional HGS Nodes

Spin up your second HGS node following the same prerequisites you used for the first node.

Once the server is back up from patching, open an elevated PowerShell console and type the following:

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

Configure your management NIC to use the first HGS server for its DNS resolution.

The code below will install the HGS into the bastion domain created with your first HGS node, the password specified here is for the DSRM (Directory Services Restore Mode) only and will not change the password you’re logged on with. Update the code with the correct password and name of your bastion domain before running.

$AdminPassword = ConvertTo-SecureString -AsPlainText "Password" -Force
$ADCred = Get-Credential "BASTIONDOMAIN\Username"
Install-HgsServer -HgsDomainName "hgsbastion.local" -HgsDomainCredential $ADCred -SafeModeAdministratorPassword $AdminPassword -Restart

Again, the server will restart, when back up, log in as the domain administrator using the same password you used previously for the local administrator account (pssst, this server is now a domain controller on the hgsbastion.local domain) 🙂

The following PowerShell will Initialize your second HGS node, update password and IP for your environment.

$Creds = Get-Credential "domain\Administrator"
Initialize-HgsServer -HgsServerIPAddress "IP address of first HGS node"

Now allow up to 10 minutes for the signing and encryption certificates to be replicated to your second HGS node.  In my deployments, this didn’t seem to happen as expected, if happens, repeat the steps in the  Import HGS Certificates and Apply Service Account Permissions section.

Well, that’s it for the deployment and configuration for the HGS infrastructure, now comes the tenant piece.

I’ve decided to split that out into another post as this one ended up a fair bit longer than I expected.

The next post will cover the following items:

• Create Template Disks
• Create a VM shielding helper disk for SCVMM
• Create a Shielding data file
• Create shielded VMs using VMM

I may add a post at a later date covering the deployment and configuration of shielded VMs from the Azure Pack Portal.

I’ll see you in Part 6