...Because someone's gotta tell the story...


To return to the main Blog List, click Full Blog Listing.


Domain Controller
PS without BS

PS without BS: Building MDT and WSUS on Server Core

Monday, February 26, 2018 in Technical Articles (Views: 91)
I have to say that I love challenges, especially ones that hold a large benefit at the end. For those who have been following or just outright cyberstalking, I've been getting into Server Core a lot more lately, and discovering the benefits that it can hold for not only performance but significant decrease on the attack space. More on that in another blog.

Enter today's challenge: I was asked to help hydrate servers with MDT, the ADK, and WSUS. After looking around, I couldn't fun a support statement on MDT on Server Core. So, why not give it a shot? A full disclaimer: Not all features are supported on Server Core, but in this case, I can only think of and see one that is: WDS. So, without WDS on Server Core, we will not be able to PXE boot.

Of course, the standard disclaimer applies: Use this on a test system in a lab, although really low risk other than a loss of time and since WDS won't work, you won't image the wrong box due to a PXE response. Your results may vary, but all this worked just fine for me.

So why do this?

Beyond the standard nerd answer of "because I can", there are many benefits to using Server Core vs. the full GUI. I'll be transparent in saying that mixed results would be quite a spin to the positive about Server 1709 removing the GUI, but once you get past the learning curve, it's not so bad.

In my labs, the performance difference is staggering: Memory usage is about 1.2GB vs. 4-6GB with the GUI. Disk space on the OS partition is greately reduced, and the time to evaluate a task sequence and deploy an operating system is drastically reduced. Keep in mind that I don't have 10,000 clients hitting this server, but even then, the results are plainly visible.

What I used for testing

This is what the blog was written on:
  • ADK for Windows 10, Version 1709
  • MDT version 8443
  • Windows Server 1709

How I made this work

First, If you're going to try following along via the good old "copy and paste the script" method, you'll need to read this blog a bit more carefully. The script does reference files in specific places, as I am sharing with you a script I wrote for myself, please season it to your tastes and naming conventions (or lack thereof).

But how do I actually use it? You install the tools on a GUI based system, so Deployment Workbench and the Windows Server Update console. You'll also need to install the ADK on this same box as well for MDT support.

Setting the table

My Windows Server is split into 2 disks. Disk 0 is on premium SSD space and is meant for performance with the OS and apps. Disk 1 is on slower magnetic space and is meant for data and storage, which WSUS and MDT will eventually use a lot of. So in my script, you will see a lot of D: references. Honestly, this is the only reason I see splitting disks anymore with a few exceptions like domain controllers.

For my installs, I used the following:
  • A folder called D:\Install that held everything
  • In the root of the install folder, I placed the installitall.ps1 (the script below), and the MicrosoftDeploymentToolkit_x64.msi
  • I created a folder called ADK, which held the extracted and downloaded Windows 10 1709 ADK (not the stub download)
  • WSUS is part of the server OS, so no downloads needed.

The scripting core

First, I went after and installed the ADK. I'll just leave command lines and PowerShell as spoilers so you can BYOB (build your own batch), so to speak. ADK, I used this command line: adksetup /quiet /installpath (path you wanted ADK installed to, i.e. D:\ADK_Win10).

Note: I didn't add any of the features, and when I tried, what I wanted wasn't supported. You just need the support files anyway. If you have some trouble installing the ADK, the logs are in the user temp directory under the folder adk. The log file will be called Windows Assessment and Deployment Kit___Windows_10_(dateandtimestamp).log.

Next, comes MDT. This was a simple one, classic Windows Installer. msiexec /i MicrosoftDeploymentToolkit_x64.msi /q

Now, there is some work to do: Creating the Deployment Share has to be manual. I will leave that in the PowerShell script but wanted to give it honorable mention here.

WSUS can go one of two ways, either via the WID or remote SQL. Either way, the PowerShell to start the WSUS install is the same: Install-WindowsFeature -Name UpdateServices -IncludeManagementTools. As for configuring WSUS, the decsion goes one of two ways, with the assumption that D:\WSUS is where you will be storing WSUS data:

Local WID:
wsusutil.exe postinstall CONTENT_DIR=D:\WSUS

Remote SQL (in my case the SQL Server is called "SQL"):
wsusutil.exe postinstall SQL_INSTANCE_NAME="SQL" CONTENT_DIR=D:\WSUS

For a named instance, say WSUS on server named SQL:

...and for a shameless plug at my other blog, you can also configure WSUS in this PowerShell script as well. Read my blog entitled PS without BS: Managing WSUS

Below is the script and let the variables be your guide:
$DeploymentShareName="Base Deployment Share"

write-host "Build MDT/WSUS script v1.14"
write-host "Written by Lee Stevens - 2/2018"
write-host ""

# Set $WSUSSQLServer to "local" if you want to use WSUS and WID,
# else set it to the name and instance of your SQL Server

write-host "Installing ADK to $InstallADKTo"
write-host "Command Line: $InstallFolder\ADK\adksetup.exe /quiet /installpath $InstallADKTo"
Start-Process -FilePath "$InstallFolder\ADK\adksetup.exe" -ArgumentList "/quiet /installpath $InstallADKTo" -Wait -WorkingDirectory "$InstallFolder\ADK"

write-host "Installing MDT"
write-host "Command Line: c:\windows\system32\msiexec.exe /i $InstallFolder\MicrosoftDeploymentToolkit_x64.msi /q"

Start-Process -FilePath "c:\windows\system32\msiexec.exe" -ArgumentList "/i $InstallFolder\MicrosoftDeploymentToolkit_x64.msi /q" -Wait -WorkingDirectory "$InstallFolder"

write-host "Creating Deployment Share"
Add-PSSnapin Microsoft.BDD.PSSnapIn
New-PSDrive -Name $DeploymentShareID -PSProvider "MDTProvider" -Root $DeploymentShareRoot -Description $DeploymentShareName -networkpath $DeploymentShareNetPath | Add-MDTPersistentDrive
New-SMBShare -Name $DeploymentSMBShare -path $DeploymentShareRoot -ChangeAccess "Authenticated Users"

md $WSUSContentFolder

Write-Host "Install WSUS"
if ($WSUSSQLServer.ToUpper() -eq "LOCAL"){
Write-Host "Installing WSUS and dependencies with local WID Database"
Install-WindowsFeature -Name UpdateServices -IncludeManagementTools

Write-Host "Configuring WSUS with local WID Database"
Start-Process -FilePath "C:\Program Files\Update Services\Tools\wsusutil.exe" -ArgumentList "postinstall CONTENT_DIR=$WSUSContentDir" -Wait -WorkingDirectory "C:\Program Files\Update Services"
else {
Write-Host "Installing WSUS and dependencies with Remote SQL at $WSUSSQLServer"
Install-WindowsFeature -Name UpdateServices-Services,UpdateServices-DB -IncludeManagementTools

Write-Host "Configuring WSUS with Remote SQL at $WSUSSQLServer"
Start-Process -FilePath "C:\Program Files\Update Services\Tools\wsusutil.exe" -ArgumentList "postinstall SQL_INSTANCE_NAME=""$WSUSSQLServer"" CONTENT_DIR=$WSUSContentDir" -Wait -WorkingDirectory "C:\Program Files\Update Services"

Some last minute thoughts and reminders

I'm not going to use this to document how to perform all these steps, but some things to remember to make your deployment successful...
  • WDS isn't supported, so you will need to use ISO/USB boot media to deliver an OS Deployment.
  • Don't forget to change the CustomSettings and Bootstrap to your liking.
  • Don't forget to update the deployment share and regenerate the boot images, this will bake in your configuration changes.
  • When finished, use the LiteTouchPE_(architecture).iso to boot into a VM or create a USB key.

So folks, it can be done - MDT, WSUS, and the ADK - all on Server Core.


Related Blogs You May Be Interested In:

To leave a comment, please log in and/or register.