Imaging from the Cloud – How to setup Powershell Deployment Extension (PSD) for MDT with HTTPS

Create Azure VM

1. Setup a VM in Azure that has a network connected to the internet. You can configure Azure VMs all sorts of ways, but here is my config:
   • VM Type: Standard D2s v3 (2 vcpus, 8 GiB memory
   • OS: Server 2016 Datacenter

   • 

     Networking: Allow RDP and HTTPS inbound
   • Disk: 128 GB Premium SSD (Premium is probably not required but I have it available so why not?  )
2. After the VM is successfully built, click the “Connect” button to download an RDP file
3. RDP into the VM
   

Prep Work

We’ll need to download pre-reqs in order for the hydration script to automatically install and configure everything for you (Full steps are here)

• MDT – Download MDT
• ADK – Download ADK (I’m using the latest, version 2004)
• ADK for WinPE – Download ADKPE (I’m using the latest, version 2004)
• Windows 10 OS ISO – MSDN or Volume License Servicing Center (VLSC)

I put all of these in a folder on the C: drive called “Pre-Reqs”

Install PSD

1. Download the zip from Github and extract.

2. Launch PowerShell window as administrator
3. Browse to the extracted folder and navigate to the “tools” folder (note I’m using a pre-release version of this so the version on Github may differ)
4. Run the script .\New-PSDHydration.ps1

5. 

   When prompted for ADK, select the adksetup.exe file you downloaded

6. I did not pre-download the content files, so click OK for the script to do it for you

7. You will get prompted to select the WinPE installer. Click ok and select adkwinpesetup.exe

8. When prompted, select the MDT installer (MicrosoftDeploymentToolkit_x64.msi)

9. And finally, select the PSDK installer script (Install-PSD.ps1) in the “Installer” folder of the PSD download.

10. I created a new folder that will be used for the Deployment Share and selected it when prompted:

11. Next, complete the OS info:

12. Enter an user with access to the share

13. Enter IIS website info. I changed mine to match the name of my deployment share

14. Then the script will download the necessary bits:

And import the OS

15. Once completed it will show this message:

6. Go ahead and reboot the server
7. When it comes back up you’ll need to re-run the script again. You may have noticed that the previous step said to “re-run this script with the configure option”. This is actually in reference to a different script the main hydration script calls (New-PSDWebInstance.ps1). That’s ok, you can still run the main New-PSHydration.ps1 script after the reboot to complete the config.
   
   In my case it flashed a separate window, did some stuff, and then closed. When I look at the log I can see “Completed the IIS Configuration review the webinstance log for details. “
   
   Note: If for some reason you need to only run the New-PSDWWebInstance.ps1 which configures and sets up IIS for you, you can always run it manually:
   First Time: New-PSDWWebInstance.ps1 -Install
   2nd time (after reboot): .\New-PSDWebInstance.Ps1 -Configure -PSvirtualDirectory “nameofIISwebsite” -psDeploymentFolder “pathToDeploymentShare”. For example:
   .\New-PSDWebInstance.Ps1 -Configure -PSvirtualDirectory “PSDeployment” -psDeploymentFolder “C:\PSDeployment”
   
8. Hydration and setup is complete. Now we can move onto the Deployment Workbench and starting building our task sequences.

Post Install Configurations

1. First, go ahead and launch the Deployment Workbench. You can see that your Deployment Share has been created, your Windows 10 media imported, and task sequences automatically created. Yay!

2. Let’s open up the Windows 10 2004 Enterprise Task Sequence. You’ll notice right away that they look a bit different than the normal MDT task sequences. These have been updated to use the new powershell versions of the vbscripts that are in stock MDT. For example, if you click on the “configure” task, you’ll see that it is calling the PSDConfigure.ps1 file. And not only that, but many of the redundant or unnecessary steps that go in a normal MDT task sequence have been removed so this is a way cleaner TS.

Configure HTTPS

Configuring HTTPS is a crucial part in ensuring all traffic is properly secured. The good news is that it’s not too difficult to setup. In my case, my organization had a wildcard cert setup for one of our lab environments (*.euccafe.com). This cert was exported with the private key as well as intermediate and root trust certs. Note that you can use “Self-signed” certs for this as well, but you’ll still need to register the public FQDN to point to this server. Johan has steps on how to use the self-signed cert. If you need a free public cert, you can get one from letsenrypt.org just keep in mind these expire every 90 days and you’ll need to make sure to renew before they expire. These steps will outline a public cert method. So let’s walk through the steps:

1. Get cert and copy to the VM. This cert was in the .pfx format.

2. Double click the cert and follow the wizard. Select “Local Machine” as the store location. Next.

3. Verify the file name and path
4. Type in the password (if you have one). Leave the “Mark this key as exportable” unchecked. Next.
   

5. Select “Automatically select the certificate store based on the type of certificate”. Next and then finish.
   

5. This will import the cert.
6. Load up MMC and add the Certficiate snap-in to view certificates for the local computer. In my case, I can see that my *.euccafe.com cert is installed in the personal store of the computer. I also verified the Trusted Root and Intermediate Root certs where there as well. 
   

7. You can double click that cert, then click on “Certification Path” to verify that it has the proper chain of trust.
   

Add cert binding to IIS

1. Now that we have installed the cert on the system, we need to add the bindings to IIS.
2. Load up IIS Manager and expand the Sites folder so that you can click on “Default Web Site. Once there, click on “Bindings on the right side.”
   

3. Click Add
4. Select https from the dropdown under Type
5. Configure the hostname you’d like. This can literally be anything you want and does not need to match the hostname of your VM or the name of the deployment share. In my case my VM is called MDT-PSD and my Deployment Share is “PSDeployment”, but I wanted my external DNS hostname to be mdt-bpeppin.euccafe.com. You’ll just need to ensure your DNS is pointing this hostname to the public IP of your server (I’ll talk more on this later).
6. Under SSL certificate, the cert you installed should be in the list. Select it and click ok.

7. Close the Bindings page.
8. Click on “Restart” on the right hand side to restart IIS.
9. Click on your website under “Browse Website” to ensure you can get to it. You should see a prompt for username/password.

10. After entering creds (ones with access to your Deployment Share), it should load:

NOTE: You may need to configure your local hosts file (in C:\windows\system32\drivers\etc) to include the IP address of your server if you haven’t configured external DNS yet.

Configure Read Only MDT User

We need to configure a read only (least privelage) user account on our MDT server so that it does not have modify writes to our share. In my case, I’ve just created a local account called “mdtuser” and created a random password.

Next we need to add this to our boot media.

1. Load up Deployment Workbench and right click on the share and the properties
2. Click on Rules then “Edit Bootstrap.ini” in the bottom right
3. Add the username and password under UserID and UserDomain. Also, while we’re here make sure the PSDeployRoots has your https URL instead of just http.
4. Save and close

5. The hydration kit already created the following security permissions on the deployment share:
   1. System – Full Control
   2. Users – Read and Execute
   3. Administrators – Full Control
6. The share permissions itself gives everyone access. You can look at the very end of the Install-PSD.ps1 script to see the commands run to set these permissions. 
   Your local mdt user (non-admin) should already have permission to read the share.
7. Load a web browser again and verify you can login with the new account you just created.

Update Boot Media with Certificate

Now we need to add the root certificate to the boot image so that WinPE trusts the cert that is presented when doing a connection to the server. In order to do this we’ll be using the “Extra Files” feature for the boot media. We’ll create the extra files folder first and then export the cert.

1. Load up the Certificates MMC for the Local Computer.
2. Navigate to Trust Root Certificate Authorities and find the root CA from your cert. In my case it is “USERTrust RSA Certification Authority”

3. Right click it and select All Tasks > Export

4. Click Next.
5. Under file format, leave default (DER encoded)
6. For file name, click browse. We’ll be using the “Extra Files” feature for the boot media to add the certificate. So create a new folder that has “Deploy\Certificates” structure there. It has to be this exact structure because the PSD startup script searches that location for any certs there and automatically adds them if found (thanks Mikael N!). In my case, I create the following path: C:\ExtraFiles\Deploy\Certificates.
7. Name the file whatever you’d like and click Save.

8. Click next and Finish to complete the wizard. Now we need to configure MDT to add this folder to the the boot media.
9. Go back to the properties of the deployment share and click on Windows PE.
10. Select “x64” as your platform
11. Under extra files, add the directory there (everything before the Deploy\Certificates part)

9. Click Apply to save.
10. You can configure additional boot settings such as background image, drivers, etc. In my environment I also disabled Monitoring since I hadn’t open up those ports to my Azure VM. I may do that later!
11. Right click the Deployment Share and click “Update Deployment Share” to generate the boot media.

DNS

You’ll need to make sure that your FQDN of your PS Deployment Share has DNS properly configured. If you are doing this in a lab and you control your own DNS, this is super easy to do. If you want this to work on the internet you must configure the DNS with whomever manages your domain name. My org controls this domain and so I had someone register my FQDN to the public IP address of my Azure VM.

Download Boot Image and Image Away!

We’re finally here and can now test out the process end to end.

1. Download the boot image iso file to your local system (in my case it’s saved under “C:\PSDeployment\Boot\PSDLiteTouch_x64.iso”).
2. Create a new VM (Hyper-V or VMware workstation)
3. Attach the PSDLiteTouch_x64.iso file and power on.

WinPE Booting

4. The Powershell extensions load

5. Then it connects to your https share and loads up a new menu screen .Success!

6. Select your Task Sequence on the left, type a ComputerName and click Start
7. Imaging begins over the internet! Sweet.

Speeds are pretty good from my Azure VM

And that’s it! The system will image, reboot, and continue the task sequence until complete.

Bonus Stuff

Peer to Peer

Once you get this working, you can explore leveraging P2P solutions like BranchCache (distributed or hosted mode) in order to save bandwidth (and cost) when deployments multiple times in the same location.

Thanks to EucCafe