Windows Deployment: Advanced Part 3 – Driver Injection. UPDATED for 2018.

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.

Continue reading

Windows Deployment – Advanced Part 2: Using WSUS to inject updates during OS deployment

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!

WeedyMan

Because we’re talking about Microsoft WSUS!!

WSUS Logo

Continue reading

Windows Deployment – Advanced – Part 1. Performing Domain Joins Securely

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??

Continue reading