Cravings of OSD

What’s New in Modena RC1 – OSD Tools & Driver Sync

In a few days, we will release our next major milestone release of the Modena tools to our Connect Beta program.  This milestone, “RC1”, is our full feature complete release of our OSD Setup Tools and Driver Sync Tool.  We will continue to iterate towards a final release later this year though most of the additions are “value add” to the Modena tools.

In this post, we wanted to take a few moments to familiarize you with some of the new features added to both the OSD Tools as well as Driver Sync.  In later posts, we will drill down deeper into each of the new features though for now we will focus on “What’s New”

OSD Tools – What’s New

The primary focus of our latest iteration is to broaden the focus of the OSD Wizard experience and to continue our focus on the IT professional’s (e.g. YOU!) ability to customize the OSD tools to your liking.  The primary 3 features added in this release are the following:

    OSD Wizard Silent Feature
    OSD Wizard Pre-Flight Capabilities
    OSD Wizard Application Selection

Let’s take a high-level look at each of the primary scenarios that drive these features in the next few sections…

Silent Feature

As you know, we offer the ability via the XML configuration (e.g. osdConf.xml) to enable or disable any page that is part of the wizard.  When enabled, the page such as Computer Details is displayed to the user.  On the other hand, if the value is disabled then the page itself isn’t displayed to the user and all values for anything that page typically shows to the end user is declared in your task sequence.

The third scenario is a the situation where the wizard is set to a silent mode.  For silent mode, the wizard checks the values of each OSD variable (such as %OSDComputerName%) to validate that the variable is set to a value other than NULL.  If NULL or not declared, the OSD wizard page that is set to silent will halt and show the page to the user requiring them to enter the data necessary for the OSD process to continue. 

For example, let’s say that you have the Computer page set to silent.  On the computer page, the end-user typically sets the variables for Computer Name, Domain/Workgroup, Organizational Unit, and last the credentials to join such domain (if needed.)  If this page is set to silent then the corresponding variables must be set for the end-user to not get prompted, otherwise, we “break silence” and ask the user for the data needed.

We felt this scenario is very useful in zero to light touch environments and can assist you in ensuring that at run-time all variables needed for a successful deployment are gathered.

Pre-Flights:  Go\No Go for Modena

As the heading indicates, this feature focuses on the scenario whereby we have a growing number of “unknown” requirements for the environments where the Modena OSD Tools are used.  For example, we have a requirement at one such customer that they would like to “customize” the machine name at run-time and not give the user the ability to edit the computer name.  In such a scenario, we need to provide the ability for them to run something at runtime in the wizard to gather some data from the machine (like service tag) and populate the %OSDComputerName% variable.  We need an engine that is robust that can handle “unknowns” without requiring a change to our core code in the wizard.

Enters the Pre-Flight page which is a new page in the Wizard that executes a series of tasks, called executables or scripts, and returns a code to the wizard.  Based on the code returned to the wizard, the end-user may or may not continue moving forward in the migration process.  The pre-flight is defined in the osdConf.xml and supports the ability to add $builtin$, stand alone executables, and Windows Script Host (VBS, etc.) scripts.  For each, you define the path to the file and what return codes are valid.  For example, Success is 0, while 1 is “Warning”, and 2 is “Error”.  You can use a wildcard “*” where errors that aren’t known prior to execution are returned thus creating a catch-all bucket that equals error.  For example, you can say as the catch-all to the user “An unknown error occurred, please contact the support desk.” and block the end-user from continuing the OSD process.  The textual string “Success”, “Warning”, and “Failure” determines the behavior the wizard takes.  The following table outlines the behavior per string:

The wizard supports an infinite number of pre-flights though this comes with a caveat.  The more pre-flights equals the longer execution of the wizard and more probability of errors.  If the wizard receives a code that it is unfamiliar with, the wizard will fail so it is up to you to ensure that you have a wildcard listed as a return code and what behavior you expect.

In our RC1 release, we will support the following built-in pre-flights that you can keep enabled or disabled:

The pre-flight page offers the following look and feel to the end-user.  This is just a sample screen shot and the actual page might slightly differ but is very, very close.

This is a very early screen shot and doesn’t actually show that the Next button is grayed out since there was an error.  It does though get disabled in our RC1 build.

The following is a sample XML for a pre-flight from our RC1 build:

Application Selection:  Maximum Choice for End-Users

The last feature added to the OSD Tools was giving you the ability to configure in the osdConf.xml file a list of applications deployable by OSD.  Utilizing a feature in ConfigMgr called dynamic application provisioning, we added to our XML configuration the ability to set the base name and default selections for applications that the wizard will calculate after the user has completed the wizard.  For example, if we have a list of applications that are 1-8 and the end-user selects 1, 5, and 6 then we will pass this to the ConfigMgr dynamic application engine that only installs what the user desires.

This is the next to last page added to the wizard and also supports all features of other pages including enabled, disabled, and the silent feature.  We do not support, though, the locking of particular applications thus giving maximum flexibility to the user.  If you desire to force an application on the end-user we suggest it as a mandatory advertisement and that it not get listed to the end-user in the wizard.

In Modena, we provide a tree view that starts at “Root” and requires at least a single group below it such as HR, etc.  We do not, currently support a flat list without it as then it wouldn’t work in a tree view <grin>.  The following is a mock view of an early screen shot from our RC1 release for Modena.

In order to populate the tree control, we have added to the osdConfi.xml a <applications> element that defines the default data (basevariable & defaultselection) and group names along with each application as a child to the group.  For each application, we offer a App Id, Name, architecture Id (PackageID:ProgramName).

The following is a sample XML for the application page from one of our early RC1 builds:

As you can see, we have been pretty busy and we apologize for not spending as much time blogging as we would like.  However, we had to lock on our features, design them, code them, and lastly test them in a 6-week sprint so our team has been heads down.  We hope that you enjoy these new features as much as we are!

Driver Sync – What’s New

The Driver Sync tool, unlike the OSD Tools, has been "feature” complete since we released it.  We have focused our attention on a lot of tweaks and optimizations in our RC1 build and the one additional piece we added was an installer. 

In the Modena RC1 build, the following features were added:

    Driver Sync Installer
    Driver Sync now utilizes device driver information based on OS
    Driver Sync now has retry logic to avoid failures

The Driver Sync tool is a complicated application that relies heavily on IIS 7.0, .NET 3.5, WSUS, and SQL.  The complexity caused some installation difficulties that we wanted to mitigate using an installer.  The primary two things added in RC1 is a full-blown installer for the Driver Sync Web & SQL services that aids in setup along with the addition of support for operating system scoping.

Our Driver Sync team has worked very closely with our Microsoft production patch team to get Driver Sync running in the infrastructure that runs and patches 130,000 computers at Microsoft.  The tool is optimized in every conceivable way possible though our team is continuing to look for more methods to streamline and improve.  It is ready, as are the OSD tools, for production.

Select whether to install the Driver Sync client and Database components or to install to the Web Server:

Validate that the Server has all the required components on your selection of what to install:

Get the ConfigMgr 2007 Site Database Server & Database Name:

Summary

Our team of Program Managers, Developers, and Testers who have worked long hours with a lot of moving targets is to thank for what we believe are two valuable tools that will help our customers deploy and manage a Windows 7 infrastructure.  We will soon release the RC1 bits to our connect site and will avail ourselves to the world via the Connection Directory soon thereafter.  The BITS for Modena are available today, in Beta form, at connect.microsoft.com.

Give us a try today and let us know what you think!

Our Team – A big Thanks:

• Cameron King
• Ben Shy
• Brian Wishan
• Tim Skudlarick
• Chris Adams
• Susan Foley
• Chris Barrett
• Satya Undamati
• Michael Schmidt