Using the Microsoft Deployment Toolkit for Windows 7
The Microsoft Deployment Toolkit 2010 is easy to configure and use, but is your deployment process secure? While this latest version of MDT includes numerous improvements, including some important security improvements, there are still some steps you can take to safeguard your IT infrastructure during deployment. Here are five tips for deploying Windows 7 quickly and securely.
1. Physical security trumps everything else
If your deployment servers aren't physically secure — and if the captured images of the reference computers you've built aren't stored securely — your IT infrastructure isn't secure. While MDT 2010 lets you create, test, build and produce deployment shares on a single machine, it's best if you keep your test-bed network (which should mirror your production network), your build lab (where you configure, deploy and capture your reference images) and your production network (where your users live and breathe) all isolated from each other.
2. Don't use admin accounts for deployment
The account used by client computers to connect to your deployment shares doesn't need to be an admin account; it can be an ordinary user account. Similarly, the account used to join client computers to the domain doesn’t need to be an admin account, provided you delegate to that account the ability to create computer objects in Active Directory. Generally speaking, using admin accounts for deployment is risky because if the account is compromised, your entire IT infrastructure is effectively compromised.
For example, during refresh deployments (but not bare-metal deployments) MDT transmits credentials over the network in plaintext form. A sophisticated user running a sniffing program could grab the password and wreak havoc if the build account is admin-level. So always use ordinary Domain User accounts and complex passwords for your deployments, and use a separate account for accessing deployment shares and joining the domain. For even greater peace of mind, disable these accounts when deployment is not being performed.
3. Do domain-joins after deployment
If you're extra paranoid about security (and who isn't nowadays?), you can use MDT to deploy client computers into a workgroup instead of your Active Directory domain. You can join the computers to the domain afterwards.
4. Test thoroughly before final deployment
A little time spent preparing saves lots of time spent troubleshooting. That’s one reason you should test your deployments thoroughly in a lab environment before deploying to your production network. Another reason is that a failed deployment can leave sensitive information on the computer, such as the name of the user account used to connect to the deployment share. While this information would be difficult to find and interpret for most users, a sophisticated user wouldn't have any problem ferreting it out. Ideally, your production deployment should work 100 percent, partly so you don't have to walk around later fixing things, and partly so you can sleep better at night.
5. Use Windows Deployment Services instead of Lite Touch media
Bootstrap.ini is a plaintext file that contains the user name of the account used to connect to the deployment share (see Figure 1). The file may also contain the password for this account. If you start the deployment process manually on client computers by inserting Lite Touch boot media (whether CD, DVD or USB flash drive), this media contains Bootstrap.ini and the information stored in the file. You need to ensure that only trusted people handle such media. Even better: Why not use Windows Deployment Services, a server role in Windows Server 2008 R2, to eliminate the need for such boot media entirely? When using Windows Deployment Services, all you need is someone to turn on the client computers, which will PXE-boot from the network and start the install automatically. Or, you can automate your whole deployment process using Microsoft System Center Configuration Manager.
Figure 1
