***UPDATE*** Microsoft have also released MDT v8450 for Windows 10 v1709 deployment. Get the latest installer here:
It’s been a while since I’ve played with Windows 10 Deployment…
One of the problems you may come across when upgrading your images to Windows 10 v1709 (fall creators update) is that to capture the gold master image, you’ll need to update your ADK installation.
On your deployment server, head to Control Panel, Programs and Features – then remove the old ADK program.
Download and install the new build of WDS from here:
Once installed; open the deployment workbench, right click on MDT Deployment Share and select update. This can take some time.
When complete; open Windows Deployment Services; replace the boot image with one you’ve just generated.
Finally, head over to your gold master image; make sure its fully patched (and you’ve performed a disk clean up); and run the litetouch.vbs script (\\deploymentserver\deploymentshare$\scripts\litetouch.vbs).
If you’re looking to PXE boot between VLAN’s (ie. a vlan for servers and a vlan for clients), you’ll need to add a couple of extra options into your DHCP server settings.
Its an easy enough process, following these steps should get things working for you:
In Windows DHCP, expand your VLAN’s DHCP scope, and select scope options.
add option 66 – enter the FQDN of your deployment server.
add option 67 – enter \boot\x64\wdsnbp.com (or if you’re deploying 32bit images: boot\x86\wdsnbp.com).
For reference you’ll find this file is in your deployment servers REMINST directory.
When you boot up your client computer, it will now receive the correct tftp response and will be able PXE boot!
In this article, I’m going to show you how to maintain a driver library within MDT and use one Task Sequence for all hardware models.
Separate your drivers out to avoid conflicts and reliability issues. This also makes it easier to update manufacturer drivers.
In this article, I’m going to demonstrate how to configure WSUS to work with MDT (or rather MDT to work with WSUS).
Now, updating the odd computer with the latest updates isn’t really an issue, even on the slowest of internet connections. But what if your trying to update tens, or hundreds of client computers during your image deployment? Every one of those clients is going to individually attempt to contact Microsoft and download necessary updates. You’ll find this quickly bottlenecks your internet feed, even on the fastest of connections.
What’s a WSUS?
No, cast that image that weedy person to one side!
Because we’re talking about Microsoft WSUS!!
In the first of this new multi-part series, I will show you how to take you Windows Deployment to the next level.
(For this series, we're assuming your running Server 2012 R2 with the latest updates, and the latest release of MDT 2013).
This article looks at locking down the os.deploy account that you use to automatically join computers to the domain.
So, let us improve the security of the mdt join account. This account which we have specified in CustomSettings.ini (Windows Deployment, Part 1: Configuring the Deployment Environment) and which is used by MDT to join the target computer to the domain.
If we leave this account as a Domain User, then MDT will be able to join the first few computers it installs into the domain but then will fail to join any others.
This is because by default Domain Users can only join 10 computers to the domain.
In our initial article, we made the account a member of the domain admins group – of course, perfectly acceptable in a lab environment, but not so in the real world.
This is because of these three facts:
- The domain admin password is visible in the customsettings.ini
- The domain admin password is sent in plain text across the network
- The domain admin password is temporarily stored on the remote pc
So, how do we overcome this??
Windows Deployment, Part 12: Further Reading
My initial install of WDS was damaged (PXE clients were not receiving a response). I cured this problem by removing and reinstalling the WDS role / feature and unchecking the “Configure DHCP options to indicate that this is also a PXE server”. This is in WDS, right click on dc.demo.local and select properties, then select the DHCP tab.
Also, you need to see if anything else (ie a router) is giving out DHCP addresses. If so, either turn off DHCP on that device, or edit the DNS address it gives out to match your server.
Windows Deployment, Part 11: Capture your gold master image
In the final article of this series, I will show to how to capture your gold master image and deploy it as a test.
Once you’re ready (don’t forget to perform any reboots Windows updates wants you to do), open the deployment share of your server. \\dc\deploymentshare$
Enter your domain account details.
Find the scripts folder.
Run the LiteTouch.vbs script (note that you want .VBS, not .WSF) (again enter your credentials).
Windows Deployment: Part 10: Create your gold master image & prep MDT & WDS for capture
The first step is to build your GOLD MASTER image. You should do this on a virtual machine (use Hyper-V or VMWare for this). This will make sure you are not redeploying for example, Dell drivers and Dell specific software onto a HP client.
Tip: If you’re creating a “GOLD” master image for capture, then please make sure you use a virtual machine (not Virtual Box as it uses weird BIOS emulation!).
You could use your deployed OS in the previous section as the basis of your GOLD MASTER. However, the machine must NOT be joined to the domain. Put it in workgroup mode!
Tip: If you prefer to build your gold master from a DVD or ISO of Windows 8, rather than the deployment task, you will likely need to change a script as per this documentation: http://support.microsoft.com/kb/2797676
Windows Deployment, Part 9: Deploying a vanilla build of Windows 8.1
We are now going to complete our WDS setup by deploying a vanilla build of Windows 8.1.
I’ll cover capturing and deploying your Gold Master Image in a later post.
First, boot a computer with PXE. In this example, we are using a VM.
Boot the VM.
Press ENTER for network service boot (This would be F12 on a legacy machine).
Windows Deployment, Part 8: Automating our OS Deployment
Now we need to get our OS deployment as automated as possible.
First of all, right click on the Windows 8.1 Deployment Share and select properties.
Select the Rules tab
In the rules tab, you will see a small selection of commands to automate our install.