Once you have got started with MDT 2010, you will want to start playing with its more advanced features and functions. I may have mentioned that one of the scenarios for MDT is to deploy a base OS and install its applications automatically, instead of capturing a reference PC. This approach is ultimately the one you would follow in a situation where you don’t have access to a reference PC for each different hardware platform that you are deploying on (by which I mean different hardware combinations such as motherboard make/model, installed hardware devices etc) or software requirements (you may have a lab that requires only specific software, and some classroom computers that don’t for example). If you can package up all the deployment scenarios into tasks in MDT then you can ease the requirement to continually update reference images with new software as it is deployed. Since each reference image has first to be deployed to a reference PC, updated, and then captured before deployment, the MDT base-plus-apps scenario would save a lot of time spent in updating these images as requirements change or new software is released. This presupposes that reloading is the best scenario for deploying updates, as opposed to deploying them through Group Policy or installing them to individual machines. MDT also eases the deployment of drivers as they aren’t required to be injected to individual installs. MDT provides for the scenario where you may need to inject, say, RAID drivers into the boot CD image in order to be able to deploy the base OS image from the server, but it handles driver installation requirements for Windows itself by maintaining these in its own database on the deployment share, so all the administrator has to do is to import these drivers once, and then let Windows Setup handle the download of these drivers from the share during the hardware scan. Importing for say an HP laptop that comes with the drivers in C:SWSetup would be as easy as pointing the driver import wizard to that folder and letting it handle the import – provided all the drivers are compatible.
I guess one immediate thought that came to mind was whether MDT would be powerful enough to support differencing, that is, the ability to roll out updates to machines that haven’t got them installed, as opposed to a full reload. I’m guessing that this capability isn’t offered at the level that MDT operates at; this is neatly handled by Group Policy for MSI based deployment, or the more sophisticated System Center. Still, it is an interesting thought. The constraints of packaging applications for deployment via MDT are likely to be the availability of applications that can be packaged into a deployment task, with the usual issue being whether an MSI based install is available and whether it can be scripted sufficiently. As an example I have had trouble recently using Group Policy to install the Maori Keyboard driver files, because the silent install goes by default to per user rather than per machine. However I have yet to work fully through the MDT documentation to confirm my expectations of how it will work.
Another scenario for MDT is to automatically update a PC from Windows XP to Windows 7. That doesn’t sound like much, surely you would just put the Windows 7 CD in and upgrade? Unfortunately that is not so simple, as there is no upgrade path from Windows XP to Windows 7. As such the MDT provides for the option to automatically archive and migrate user data using the User State Migration Tool , before it wipes off XP and clean installs 7 then restores this data. This is a scenario we probably won’t bother with too much, if at all, because our migration scenarios at this stage are based on installing Windows 7 onto clean new machines as they come up for replacement. Still, it’s good to see the depth of functionality and features which are being provided for in MDT. Another nice feature is a customisations database using SQL Server Express (which is free) that streamlines keeping track of the customisations for different computers or groups. Like WDS, putting in SQL Server Express is an option I will look at when we set up a more formal setup server later this year. Putting in the MDT database will be the prerequisite for customising installation parameters rather than mucking about with the default ini files that are provided with MDT so I won’t be installing that feature just yet.
My next stage of learning MDT will be to look further into a base OS plus applications plus drivers installation. The extent to which we can use this depends on the degree of application install support for the kind of automated install scenarios that MDT requires. I’m guessing some legacy apps won’t be very supportive so it may not be so easy unless a repackager like WinInstall LE can be deployed. Ultimately we will probably opt to deploy a reference image where there are significant numbers of applications that cannot easily be automated to deploy, and while this is less flexible, it can be customised with installable apps the same way as a base OS install can be. We have the advantage of not too many different software configurations so reference imaging might work better for us in MDT at this stage, with customisation of Office installation for different requirements (staff vs students) being the main application deployment add on to a reference image. I would expect that the Selection Profiles capability of MDT would enable us to choose the option for deploying different Office install customisation files.