Right now I have literally a ton of items I need to get done in the next week. The first which is the most important is solidifying our deployment methods. We used to be a Ghost shop but I’ve since experimented with Microsoft Deployment to remedy problems we observed with Ghost:
- Inability to regenerate SIDs and other registry entries (wreaks havoc on systems in a networked environment)
- Inability to abstract hardware from the image (we had to make one image for every type of hardware configuration)
- Inability to easily add network drivers to the boot image and necessity of doing so (a pain!)
Deployment does a great job of abstracting hardware. The way I currently have it setup, you can choose your OS (Vista Business x64 or XP SP2, currently) and then choose from a list of applications that are silent installs personally prepared by me. The process is not blindingly fast — Ghost was limited only by hard drive speed and network speed — but it provides a level of customization that we didn’t have before.
Eventually I hope to research and define “systems” in Deployment to represent a type of PC for a particular type of employee. Our Admins might only need the accounting software, Adobe Acrobat Pro, and image scanning software for SP2 whereas our hardcore CAD users will need Vista Biz x64, AutoDesk Architecture 2008, so on and so forth. That way when we have a list of applications 100 items long it doesn’t become prohibitively time-consuming to choose the applications we need to install.
We’ve run into our first problem using Deployment and it has everything to do with the driver database. Frankly, the driver database is implemented extremely poorly or I just don’t understand how to use it. Actually, I have a list of reasons why it’s inadequate:
- “Groups” are not visible in the default view of the Driver Database:
- There is no “date added” attribute
- There is no search (!!!!)
Now let me explain why these two issues are such a big deal to me. Let’s start with Groups. Groups allow you increased granular control over the LiteTouch ISO which is necessary for booting clients (PXE hasn’t been conquered on our network yet — more on that at a later date). Once could conceivably burn an ISO that has network drivers for a specific Group which could have all drivers for a particular hardware set.If you wanted to see which drivers belong to certain Groups, it would be fantastic to have a “Group” column visible.
Now to understand why a date attribute would be useful, I’ll explain a problem my team ran in to on Friday: conflicts with different drivers competing during client booting and thus stalling the entire imaging process. If we generate an ISO with all network drivers (which is perfectly possible), I would expect the correct driver to be chosen from the CD when the client workstation boots. The process has error’d a number of times, failing at a particular .sys file, which is nowhere to be found in the Driver Database. Let’s say that the driver database was recently updated with drivers for a new model of PC we’re deploying and this error in imaging occurs after that update. It would be *awesome* to reference the newly created drivers in the database as the problem. As it stands now, I have no way of doing this unless I export the database and cross-reference a manually generated list of the drivers I recently added (hinging on me remembering what model I added drivers for).
Search is the single most important aspect of any sort of application, no matter what it is. If you can search data, what’s the point of having it in the first place? Microsoft Deployment has no search or “find” feature for the Driver Database. Even if I get a screen displaying the driver file the imaging process failed on, I couldn’t search the database through the Deployment Workbench without exporting the entire driver list to some sort of Excel-compatible document format. While there is a “date” field, it refers to the date of the driver and not the date the driver was imported into the database.
In order to resolve this problem of the process freezing, I’m going to have to remove all of the drivers and unfortunately it will ruin the groups I’ve created. Thankfully we have a storage location for drivers and their associated hardware that I can easily import. This time, I will make sure to create drivers for each class of hardware in case this happens again in the future so instead of burning the LiteTouch image with all drivers in the database (networking and storage controller-related), I’ll just burn in image for that specific piece of hardware. Though this is a “hack” or a work-around, it shouldn’t matter once we actually get PXE booting to work properly.
More about Deployment after I experiment some more…
