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

How to Use Windows 10’s New Sandbox (to Safely Test Apps)

Windows 10’s May 2019 Update (19H1) added a new a new Windows Sandbox feature. Here’s how you can use it on your Windows 10 PC today.

Note: Windows Sandbox is not available on Windows 10 Home. It’s only available on Professional, Enterprise, and Education editions of Windows 10.

What is Sandbox?

In short, Windows Sandbox is half app, half virtual machine. It lets you quickly spin up a virtual clean OS imaged from your system’s current state so that you can test programs or files in a secure environment that’s isolated from your main system. When you close the sandbox, it destroys that state. Nothing can get from the sandbox to your main installation of Windows, and nothing remains after closing it.

How Do I Get It?

All you need is a modern version of Windows 10 running Windows 10 Professional or Enterprise—Windows 10 Home doesn’t have this feature. The Sandbox feature became stable back in May 2019.

Step One: Make Sure Virtualization is Enabled

First, you’ll need to make sure virtualization is enabled in your system’s BIOS. It typically is by default, but there’s an easy way to check. Fire up Task Manager by hitting Ctrl+Shift+Esc and then head to the “Performance” tab. Make sure the “CPU” category is selected on the left and on the right, just make sure it says “Virtualization: Enabled.”

If virtualization is not enabled, you’ll need to enable it in your PC’s BIOS settings before you continue.

Step Two: Turn On Nested Virtualization if You’re Running the Host System in a Virtual Machine (Optional)

If you’re testing out the Insider build of Windows in a virtual machine already and you want to test Sandbox in that VM, you’ll need to take the extra step of turning on nested virtualization.

To do that, fire up PowerShell in the version of Windows running inside the VM and then issue the following command:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

That lets your guest version of Windows in the VM expose the virtualization extensions so that Sandbox can use them.

Step Three: Enable the Windows Sandbox Feature

After making sure virtualization is enabled, turning on the Windows Sandbox feature is a snap.

To do so, head to Control Panel > Programs > Turn Windows Features On or Off. (By the way, we’ve got a full write-up on using those Windows Features if you’d like to learn more.)

In the Windows Features window, enable the “Windows Sandbox” checkbox.

Click “OK” and then let Windows restart.

Step Three: Fire It Up

After Windows restarts, you can find Windows Sandbox on the Start Menu. Either type “Windows Sandbox” into the search bar or dig through the menu and then double-click on the Icon. When it asks, permit it to have administrative privileges.

You should then see a near replica of your current OS.

There are some differences. It’s a clean Windows installation, so you’ll see the default wallpaper and nothing but the default apps that come with Windows.

The virtual OS is dynamically generated from your main Windows OS, so it will always run the same version of Windows 10 you are using, and it will always be fully up to date. That latter fact is especially nice, as a traditional VM requires taking the time to update the OS on its own.

How Do I Use It?

If you’ve ever used a VM before, then using the Sandbox will feel like old hat. You can copy and paste files directly into the Sandbox like any other VM. Drag and drop does not work, though. Once the file is in the Sandbox, you can proceed as normal. If you have an executable file, you can install it in the Sandbox where it’s nicely cordoned off from your main system.

One thing to note: If you delete a file in the Sandbox it does not go the recycle bin. Instead, it’s permanently deleted. You will receive a warning when you delete items.

Once you are done with testing, you can close the Sandbox like any other app. This will destroy the snapshot entirely, including any changes you’ve made to the OS and any files you copied there. Microsoft has been kind enough to provide warning first.

The next time you launch Sandbox, you will find it back to a clean slate, and you can begin testing again.

Impressively, Sandbox runs well on minimal hardware. We performed the testing for this article on a Surface Pro 3, an aging device without a dedicated graphics card. Initially, the Sandbox ran noticeable slow, but after a few minutes, it ran surprisingly well given the constraints.

This better speed persisted through closing and reopening the app as well. Traditionally, running a Virtual Machine called for more horsepower. Because of the narrower use cases with Sandbox (you won’t be installing multiple OSes, running multiple instances, or even taking multiple snapshots), the bar is a little lower. But it is this very specific target that makes the Sandbox work so well.