Cravings of OSD

Getting Started with Modena – Step 4 – Introduction to OSD Designer

Thus far we’ve focused on getting you setup with Modena RC2 and correctly building your Modena OSD packages and importing the task sequence.  The real power of Modena cranks up with OSD Setup Wizard (e.g. user experience) configuration capabilities offering you maximum flexibility to provide your end-users with the right interaction.  The configuration, although stored in readable XML, is very complex and as such we built the Modena OSD Designer to greatly simplify the process for creating configurations to fit your environment.

In today’s getting started blog post, we’re going to provide you an overview of the OSD Designer Administration UI.  This is the pre-cursor to cutting you loose to build your configuration needed to use the Modena OSD wizard.

Getting Started with the OSD Designer

The designer is installed as part of the Modena RC2 installer, setup.exe.  It is located in your %programfiles%\Modena directory and available via the programs menu on your computer.  After opening the designer, you will be on the Home page of the designer that should show you our posts from this blog.

The OSD Designer has a vast array of options, selections, menus, and configuration settings available to you.  To simplify your ramp up, we’ve recorded this quick 20 minute video to get you everything you need to know in order to dive right into building your configuration files.  The OSD Designer is the cornerstone of Modena and is the primary place you will live when setting up Modena for your deployments.  Let’s get started…

Summary

Over the coming days, we will dig deep into the building of powerful configuration files to deploy the OSD Setup Wizard with Modena.  It is important to better understand the primary tool for creating the configuration file that abstracts you from understanding the underlying XML – the OSD Designer.

Thanks,

MPSD Engineering

Getting Started with Modena – Step 3 – Importing Task Sequence

The power of System Center Configuration Manager’s (ConfigMgr) Operating System Deployment (OSD) feature begins and ends with the task sequence.  The task sequence is the heart of any OS deployment for users of ConfigMgr.  Modena is fully built to utilize a great deal of this power and in today’s getting started, we explore the exported task sequence in depth.  In today’s demonstration, we will assist you in correctly importing your task sequence provided to you by the Modena RC2 installation.

Pre-Requisites for the Modena RC2 Task Sequence

As mentioned in our video demonstration below, the Modena RC2 task sequence has two required pre-requisites in order to effectively start deploying Windows 7.  First, you are required to already have a WIM image created and available to you that has correctly been built using whatever technology you so choose.  For more information on creating Windows 7 WIM images, see the following TechNet article.

The next requirement is a valid Configuration Manager client (ccmsetup) package exists in your site.  This is required for the installation of the client during the task sequence. 

To review, you will need to have the following available to successfully save your task sequence provided to you for Modena:

1. WIM Image
2. ConfigMgr Client Package

Optional Pre-Requisites – Language Packs

For some of you deploying Windows 7, you have a requirement to provide end-users the opportunity to select the appropriate Windows 7 language pack and locale.  The Modena RC2 task sequence is already setup for language packs minus you will need to have created the appropriate ConfigMgr package.  This step is optional unless your deployments require language pack support.

Editing the Modena Task Sequence

A common question often asked to the Modena engineering team is help in the configuration of the task sequence.  It is often phrased in the form - “I imported the task sequence, now what?” as we haven’t been crystal clear on the correct way to update the task sequence with the associated packages.  This was all covered in our deployment guides but often was missed.  The following table should assist you in mapping the errors to the associated package provided to you by the Modena RC2 installation.

NOTE:  For more information on how to create your Modena RC2 packages, see our Getting Started demonstration blog here.

Step Name	Package Mapping
GetGuid	PreReqScripts
Run OSD Setup Wizard	SetupWizard
Format Target Drive	PreReqScripts
Cache OSD Scripts	ScriptsCache
Cache OSDSetupWizard	SetupWizard
Format Target Drive	PreReqScripts
Cache OSD Scripts	ScriptsCache
Cache USMT	USMT
Cache OSD Results	OsdResults
Setting Failover Logs Directory	ScriptsCache

Putting is all Together

To simplify things, we’ve put together this simple 7 minute video to help you walk through the process of importing your task sequence.

Thanks,

MPSD Engineering

Getting Started with Modena – Step 2 – Create OSD Packages

In today’s Getting Started with Modena, we will step through the second step required to get Modena up and running and deploying Windows 7 in your System Center Configuration Manager 2007 environment.  As we outlined yesterday, the installation will deploy a set of files to your local server in the %programfiles%\Modena directory.  The second step after installation is to create the associated packages in ConfigMgr.  This is needed prior to moving to step 3 – importing your Task Sequence.

Creating Modena OSD Packages

The steps to create the OSD packages are very, very simple.  All of the files needed are located in a directory installed on your workstation, as shown in Figure 1:

The packages folder, which exists under ModenaWizardFiles, contains the source files needed to create the OSD packages.  You need to create all 5 packages and point each package to the appropriate source directory.

The steps shown in the following video are:

1. Copying the ModenaWizardFiles to your Site Server (required to use Local drive on Site Server option in Configuration Manager console)
2. Creating Package for OSDResults
3. Creating Package for PreReqScripts

Creating Packages for Modena OSD

NOTE:  These packages require no program name as the source files contain all the binaries needed to execute via the task sequence

Summary

In today’s getting started, we walked you through creating the packages needed to successfully import the task sequence.  Stay tuned for tomorrow’s blog that will show how to effectively import your task sequence and point the broken items to the correct package.

Thanks,

MPSD Engineering

Getting Started with Modena – Step 1 – Installing Modena RC2

This week, our team will do a series of post titled – Getting Started with Modena – aimed at helping those new users of Modena to quickly and efficiently get their deployments started.  The only pre-requisite are the following and are outside what is included in the Modena setup program:

1. A working System Center Configuration Manager 2007 Service Pack 2 infrastructure
2. Windows 7 WAIK installed on the Site Server (or another server)
3. A pre-created Windows Image (WIM)

The steps to get Modena up and running and deploying Windows 7 are simple and straight forward, we think.  To simplify things, though, we wanted to start with the simple installation as it is the first step.

Installing Modena RC2

After downloading setup.exe, you will now have this file located on your workstation.  It is important to note that you don’t need to move setup.exe to your Central or Primary Site.  You will install Modena RC2 to your local workstation prior to interacting with your infrastructure.

Step 1:  Download (copy the WAIK files to your local workstation) for Windows 7

Step 2:  Run Setup.exe

Step 3:  Remove Web Services & Database during installation (future Blog Post)

Step 4:  Validate Modena installed properly

Summary

In today’s post, we helped you get started by downloading the Modena RC2 bits and get them setup on your personal workstation.  This installation sets up the Modena OSD Designer along with the various files necessary to implement Modena into your Configuration Manager infrastructure.  These files are located at %programfiles%\Modena.

Modena RC2 Help Documentation Preview Released

As often is the case, unfortunately, supporting documentation for releases come after major milestones are hit in software.  Modena RC2 release was prioritized as opposed to documentation hence causing us to slip the release of the documentation.  We realize the inconvenience this causes though we’ve certainly prioritize it this past week.  The documentation is released and available on our connect site and available for download.

Utilizing Modena RC2 Documentation

To better understand the documentation we put together, we wanted to briefly explain what to expect from each piece of the documentation.

Downloading Modena RC2 Documentation

To download the documentation, please join our Connect beta program and use the downloads tab to get the Modena RC2 documentation preview.

Modena Team

Modena RC2 Feature Complete & Released to Microsoft Connect

Modena focuses on “extending” some of the functionality already available in System Center Configuration Manager 2007’s OSD features.  Developed internally at Microsoft as the first solution used to deploy 10,000+ Windows 7 images, the MPSD Engineering team is sharing it as one blueprint for your Windows 7 deployment.  The Modena solution focuses on enabling user-driven upgrades for Windows 7 clients and with this release is feature complete.  You can take Modena for a test-drive today utilizing all the features available by joining our Connect Program and downloading the RC2 bits.

What’s new in RC2

This list is long, we promise.  Modena isn’t an overly complex set of technology but instead was a small number of custom-built components that are very, very feature rich.  Beyond that, the components are utilized and tested at one of the largest Configuration Manager customer’s in the world – Microsoft Corporation.  A large set of the functionality in Modena focuses on returning information workers to work as quickly as possible, with as little required fit-and-finish work for the user.  We feel like we accomplished a great deal of that with our new features.

Enhanced Application support including Dependency, Exclusion, Locking, Filtering, and Topological Sorting

We've added the much desired functionality to the Wizard to support Application dependencies and exclusions.  This powerful feature allows you, the administrator, to setup your configurations where applications that have dependencies such as Live Meeting Add-ins (who "depends on" Office 2007) to properly display to the end-user in the OSD Setup Wizard's Application Tree.  Beyond dependencies, we've added exclude functionality where applications that are not supported are excluded when end-users select applications with an exclude rule.  For example, when an end-user selects Office 2003 the OSD Setup Wizard automatically disallows Office 2007.  When users select applications included in dependency or exclusion rules, they are notified of the rule and ask to select whether to continue or remove the application selected.

The Wizard also supports locking, the ability to require applications and not allow the end-user to interact with the applications.  This is useful for ensuring applications such as key security tools are installed automatically and without user choice.

The Wizard will also remove applications whose bitness (e.g. 64-bit application) isn't supported by the hardware which the wizard is running on.  This ensures applications do not fail due to incompatible hardware.

Last, the OSD Setup Wizard now supports topological sorting.  What is topological sorting?  Using Configuration Manager 2007's Install Software task sequence functionality dynamically installs applications.  This is nice except it does so with no intelligence of what order the applications should get installed in due to dependencies.  With the new dependency functionality, the Wizard will ensure that the install order is written out to the task sequence variables in the correct order based on dependencies.  Using the above

Application Discovery Pre-Flight

A key scenario for Modena is to remove any unnecessary user tasks after the migration is complete.  This is common with many Windows 7 deployments as users spend a large amount of time re-installing applications they need to do their job.  Application Discovery (AppDiscovery) removes this requirement if you utilize Configuration Manager’s software package features to distribute and deliver software to end-users' computers.  AppDiscovery runs as a pre-flight check in the OSD Setup Wizard and scans the local system for ConfigMgr software packages or MSI product IDs, and upon detection, marks them for re-install.  AppDiscovery also honors any of the dependency and exclusion rules by ensuring that conflicting values do not break the wizard.  This greatly simplifies the experience for the end-user by removing them from knowing what applications are installed and letting AppDiscovery detect it for them and ensure those applications are re-installed.  AppDiscovery even supports deprecated software detection logic to allow “upgrades” to the latest version.  For example, a common Enterprise application is Adobe Reader and with a large number of versions spread through the enterprise.  During the image process, detection of Adobe version 5, 6, 7, and 8 can be replaced with the latest offering (Adobe 9.x) and this is all made possible using AppDiscovery.

Powerful WMI Query Language (WQL) Support

Beyond application re-configuration, AppDiscovery also supports custom WMI query definitions to support almost end-less possibilities for administrators.  Why support this functionality?  There are several scenarios where application delivery is dependent on hardware specific values, such as Manufacturer and Model Types.  Using WQL queries, an administrator can easily determine the Make & Model and set application delivery specifically for that model.  In short, driver payload(s), OEM specific applications are deliverable only if the WQL query returns true otherwise the applications are not delivered.

Friendly, easy-to-understand, Results of OSD Imaging

A key piece of feedback delivered about the Modena solution is that upon completion end-users were “unaware” if the migration was successful without returning to Configuration Manager and reviewing built-in or custom reports.  This information, of course, isn’t user friendly and thus we built an application called “OSD Results” that uses or custom-branding information in the registry to share results with the end-user on key questions.  OSD Results shares a nice, friendly introductory text that is configurable by you along with system information and domain join information.  The number one ask is the ability to share success or failure for installation of applications which OSD Results does along with giving some helpful information such as error codes, etc. to provide to help desk interactions.  OSD Results offers a lot of the same configurable options such as branding to allow you to use it with your IT branding.

Welcoming the Modena OSD Designer

In RC2, we are happy to welcome the OSD Designer user interface to simplify deployment of OSD Setup Wizard configuration and Application Management.  There are two pieces of configuration that are extremely important for users of Modena to understand, configuration for OSD Setup Wizard and another for Application Discovery.  OSD Setup Wizard depends on the configuration file to provide the correct selections and options to the end-user at run-time hence the first steps for any Modena user is to build their wizard configuration.  AppDiscovery, on the other hand, uses configuration files to determine the master list (we will blog about this soon!) of applications to detect.  The OSD Designer simplifies the creation of the configuration and allows you to quickly ramp-up on Modena and quickly start using the user-driven OSD experience.

The OSD Designer allows you, as an OSD administrator, to do the following:

• Allows you to create new or update existing OSD Setup Wizard configuration files
• Save configuration files locally or publish to the Modena Online Service
• Enable or disable any OSD Setup Wizard pages
• Enable or disable any page configuration fields (e.g. computer name, etc.)
• Connect to Active Directory and setup Domains and Organizational Units in OSD Setup Wizard configuration files
• Connect to System Center Configuration Site Servers and retrieve packages enabled for OSD
• Attach x86 and x64 applications and configure dependencies, exclusions, and set application packages as required
• Configure Application Discovery matching criteria for ConfigMgr packages and MSI product Ids

The OSD Designer is any OSD administrators 2nd favorite tool behind Configuration Manager console.  It greatly simplifies your preparation for delivering operating system images using OSD.

Modena (Configuration for Wizard & AppDiscovery) Online Services

As an Configuration Manager administrator for OSD services, the management of applications is a full-time job.  This task is very cumbersome when introducing OSD and utilizing the Install Software step of the task sequence.  For example, let’s assume that you manage applications for software distribution and OSD.  When new applications are released that update OSD apps, you have to manage this in the configuration for Application Discovery’s configuration to detect the updated version, package identification, or program name and do so a per-package level.  This requires updates are done and then refreshed on all the DPs in your hierarchy with the package and this is cumbersome and prone to error.

Simplifying this process was the focus of the Modena Online Services using commonly available infrastructure already present in most data centers.  The online services provide a web service for AppDiscovery to utilize to look up it’s master list online rather than from local configuration files allowing you to easily centralize your application configuration list in a single location.  For each application package change, you update it once in the OSD Admin Designer and publish online (or update) and your done.  This keeps replication and synchronization out of the way and simplifies the management of hundreds of applications, as we’ve had to do. 

The Online Services require Windows Server 2008 (or greater) with the .NET Framework 3.5 feature installed along with IIS 7.0.  It also relies on SQL Server 2008.  All of the online components are setup automatically at install time to simplify the setup of your online infrastructure.

Simplified Cancellation Functionality

The OSD task sequence and Wizard are now updated to support graceful cancellation.  This improved functionality simplifies reporting and ensures the preferred user experience for end-users when they are not willing to continue the wizard.  The difference between a failed task sequence (unknown root cause) is vastly different from an end-user who decides to cancel the wizard or doesn’t meet the requirements.  This shuts the task sequence down gracefully and ensures to report the information accurately.

Quick and Easy Installation & Setup

Modena’s OSD Tools is now wrapped into a nice, tightly integrated installation package that will simplify deployment.  The installation will setup and configure the OSD Admin Designer, Online Services (if desired), and documentation (coming in our final release).  The primary benefit to the installer is to simplify getting your files deployed for the task sequence, installing the Admin Designer, and setting up the Online Services.

Downloading Modena RC2

The biggest question to date is where can I get Modena RC2.  The steps are simple to download the RC2 version at http://connect.microsoft.com/Downloads/Downloads.aspx?SiteID=868 and if you have any problems with this release, please feel free to contact us at win7osd.

Summary

The MPSD Engineering team has been extremely busy finalizing all the features necessary to deploy Windows 7 to our customers and hopefully yours as well.  The features, as mentioned, offered in Modena are concentrated on improving the end-user experience and application management available to users of System Center Configuration Manager 2007 OSD.  The next steps are to continue to sore our numbers for deployments at Microsoft and push on to 20,000 and expand to international deployments.  In the mean time, we welcome your suggestions and feedback and furthermore employ you to take Modena and customize to your environment and kick-off your Windows 7 deployments right along with us.  We bet that over the coming months you will be as satisfied as we are with Modena, and if not, please share with us what we could do better.

Thanks,

MPSD Engineering

Modena RC2 Bug: Failure to install 64-bit Applications for configurations created by OSD Designer

We want to thank everyone for downloading the RC2 release of the Modena Tools suite.  In this release we’ve introduced a new tool called the OSD Designer to help aid the design and management of the OSD configuration files that drive the Wizard experience.  The tool was developed to bring your attention to problems in the configuration files while they are being created instead of after it’s been deployed to users in the enterprise.

During the development process we stress our tools through a number of test scenarios designed to catch problems before they are released to our customers.  As with any software product certain classes of problems elude testing and show up in the released software.  Thanks to your feedback we were able to uncover one of these issues shortly after we released the suite last week. 

Problem Description

The problem we discovered is related to the architecture platforms that can be selected when configuring your image and associated platform architectures.  The OSD Designer allows you to specify an image index that corresponds to either a 32-bit or 64-bit architecture.  Historically, 64-bit architectures have been referred to by one of several abbreviations including both x64 and amd64.  The issue that’s been discovered is that the OSD Designer will write out the keyword, x64, when specifying the architecture for the image; however, it uses the keyword amd64 when writing out the architecture for applications.  As you may know the Wizard intelligently determines which applications to instruct the Task Sequence to install based upon the image selected by the user.  When reading the XML configuration file into memory the Wizard only looks for amd64 keyword.  The result is that when the Wizard runs and a 64-bit image is selected, no applications will be presented to the user for installation.

Workaround

The good news is there is a workaround, the bad news is that it requires a small edit directly to the XML before distributing it with your Task Sequence.  Below are instructions to work around the issue.

1. After using OSD Designer to create your XML you should save the work to your local hard drive using the Save Configuration As… option from the File menu
2. Open the configuration file in your favorite text editor, Notepad should do just fine for this
3. Navigate down to the node <Page Name=”VolumePage”/>.  Depending on your image options, you should see a section that looks similar to the below XML

   1:  ...

   2:   <Page Name="VolumePage" Behavior="enabled">

   3:     <Setter Property="minimumVolumeSize">10737418240</Setter>

   4:     <DataCollection Name="ImageSelection">

   5:       <DataItem DisplayName="Windows 7 RTM (x86)">

   6:         <Setter Property="index">1</Setter>

   7:         <Setter Property="architecture">x86</Setter>

   8:       </DataItem>

   9:       <DataItem DisplayName="Windows 7 RTM (amd64)">

  10:         <Setter Property="index">2</Setter>

  11:         <Setter Property="architecture">x64</Setter>

  12:       </DataItem>

  13:     </DataCollection>

  14:  ...

You will want to change each <Setter Property=”architecture”/> node that contains x64 for the inner XML to amd64.  The above snippet has been corrected in the example below. (The difference is on line number 11)

   1:  ...

   2:   <Page Name="VolumePage" Behavior="enabled">

   3:     <Setter Property="minimumVolumeSize">10737418240</Setter>

   4:     <DataCollection Name="ImageSelection">

   5:       <DataItem DisplayName="Windows 7 RTM (x86)">

   6:         <Setter Property="index">1</Setter>

   7:         <Setter Property="architecture">x86</Setter>

   8:       </DataItem>

   9:       <DataItem DisplayName="Windows 7 RTM (amd64)">

  10:         <Setter Property="index">2</Setter>

  11:         <Setter Property="architecture">amd64</Setter>

  12:       </DataItem>

  13:     </DataCollection>

  14:  ...

Summary

We’re sorry for any inconvenience this issue may have caused you.  We are working on a fix for this issue and should have an updated release available in the near future.

Thanks for your continued support of the Modena tools and please don’t hesitate to contact us with any questions you have during your deployments.

Collecting USMTv4 Stats using ConfigMgr 2007 when deploying Windows 7

If you are using ConfigMgr to deploy Operating systems, and leveraging USMT (User State Migration Tool) for User State migration, you would be very much interested in finding out answers for the following questions.

1. How long did USMT take to capture the User State data on a system?
2. How long did USMT take to restore User State data back on a system?
3. What was the size of the data that was migrated on each system?

Hopefully you have used USMT 4.0 with its hard link capabilities to speed things up in contrast with copying data over the network onto a remote share. Regardless of the method you had chosen for your USMT implementation, trying to capture the USMT usage statistics isn’t as simple as it sounds for all systems across your environment.

In this post, we will share the process we chose to use at Microsoft for collecting USMT statistics.

Overview of the Process

At a high level, the process of collecting USMT usage statistics can be broken down as below:

• 1. Collect USMT usage statistics from USMT logs
• 2. Store collected values into Task Sequence Variables
• 3. Store Task Sequence Variables’ values into the Registry
• 4. Use ConfigMgr inventory mechanism to report data from Registry keys.

Except for the last step of collecting inventory data using ConfigMgr, the first 3 steps are basically task sequence steps within the OS deployment task sequence.

Collect USMT usage statistics from USMT logs

This step is where we will parse USMT logs to get the required details that will be reported back to ConfigMgr site. To start with we need to know the location of the logs where the USMT executables are configured to write. Based on our configuration, the progress logs are written to %usmtlogs%\Scanprogress.log & %usmtlogs%\loadprogress.log as indicated by the command lines below.

"%usmtbits%\scanstate.exe" "%usmtsafe%" /o /c /hardlink /nocompress 

/efs:hardlink /i:"%usmtconf%\MigDocs.xml" /i:"%usmtconf%\SelfHostApps.xml" 

/i:"%usmtbits%\MigApp.xml" /offlinewindir:"%2" /localonly /uel:45 /v:13 

/L:"%usmtlogs%\Scanstate.log" 

/progress:"%usmtlogs%\Scanprogress.log" 

/ListFiles:"%usmtlogs%\ListFiles.txt"

"%usmtbits%\loadstate.exe" "%usmtsafe%" /hardlink /nocompress /lac /c /v:13 

/i:"%usmtconf%\MigDocs.xml" /i:"%usmtconf%\SelfHostApps.xml" 

/i:"%usmtbits%\MigApp.xml" /L:"%usmtlogs%\loadstate.log" 

/progress:"%usmtlogs%\loadprogress.log"

After locating the log files, now let’s see where the information about ‘how long it took to capture’ and the ‘size of data captured’ is hidden. For simplicity sake, we will consider only scanstate information; however the same logic is applicable for loadstate as well.

If you search for a string “, totalSizeinMBToTransfer,” in ScanProgress.log, you will locate a line that looks something like the one below. The value next to the string (16605.29) is the size of data that is captured as part of scanstate in MB. Now, it is just a matter of reading that value alone using any scripting method, and storing this value as a Task Sequence variable.

11 Sep 2009, 23:34:52 +05:30, 00:02:23, totalSizeInMBToTransfer, 16605.29

The same logic goes for finding the ‘time it took to capture the user state’, except that, this time you will be looking for a string “, errorCode,” in the same ScanProgress.log. It is usually the last line in the log with an error code of 0 if all went well. Again, using any scripting method you need to pick up the value just before the string “, errorCode”, which is 00:06:34 in the sample below.

11 Sep 2009, 23:39:02 +05:30, 00:06:34, errorCode, 0, numberOfIgnoredErrors, 0, message, "Successful run"

Store collected values into Task Sequence Variables

Before we get into, how we store the values into Task Sequence variables - why we store these data in Task Sequence variables and then move them again into registry deserves some attention.

Even though USMT data is the focus of this post, there is lots of other information that we capture which is relevant to OS deployment process. To name a few - information like OSD Start & End times, Old & New computer Names, and OSD Image Package ID are captured that are already either part of default or custom Task Sequence Variables in our deployment process. Hence, to keep the complete tracking of data in cohesion, we chose to populate USMT data also in Task Sequence Variables, and at a later state all the Task Sequence Variables’ values are collectively written to registry. So, in short, you could technically skip this step, and directly populate the USMT values into registry and jump to the last step of ‘Use ConfigMgr to report data’.

Now, let’s come back to ‘how we store values’ into Task Sequence Variables. This is a relatively easy step with only few lines of code that can do the trick. Assuming the USMT_ScanTime, USMT_ScanSize, USMT_LoadTime & USMT_LoadSize are already populated from the earlier step; it can be directly assigned to the variables after instantiating the TSEnv object as shown below.

SET TSEnv = CreateObject("Microsoft.SMS.TSEnvironment")

wscript.echo "--------------- Updating Task Sequence Variables 

--"

TSEnv("USMT_ScanTime") = 

USMT_ScanTime

TSEnv("USMT_ScanSize") = 

USMT_ScanSize

TSEnv("USMT_LoadTime") = 

USMT_LoadTime

TSEnv("USMT_LoadSize") = 

USMT_LoadSize

The entire script is available from our Connect site and instructions for joining that program can be found here.

Store Task Sequence Variables’ values into the Registry

With the required data in the Task Sequence variables, we are now onto the stage where we need to move them into Registry keys; which will be later collected via ConfigMgr inventory process.

Reading Task Sequence environment variables are very much similar to the method, which we saw in the earlier step. Basically, you start with instantiating Task Sequence Environment, and looping through the variables you can read them and perform any action that is required. In the snippet below, you will notice that after reading the variables, a MatchMaker function is used to compare the value against a mapping of values which need to be included or excluded.

Dim oTSE    : SET oTSE = CreateObject("Microsoft.SMS.TSEnvironment")   

For Each tV in oTSE.GetVariables() 

    IF (MatchMaker( tV, incArray ) = TRUE) Then

        IF (MatchMaker( tV, excArray ) = FALSE ) Then

            Call BrandValue( tV, oTSE(tV) )

        End IF

    End IF

 Next

If it meets the inclusion criteria and is not part of the Exclusion criteria, a function by name BrandValue is called; which will populate the registry key as seen below. Based on prior evaluation of OS architecture (64/32 bit system), appropriate reg.exe is used and the registry location is chosen.

' ////////////////////////////////////////////////////

    ' Brand a name and value to registry

    ' ////////////////////////////////////////////////////

    Sub BrandValue( theName, theValue )

    Dim retVal : retVal = 0

    Dim runCmd : runCmd = REGBRAND & " ADD " & REGBRANDPATH & " /F /V " & theName & " /T REG_SZ /D """ & theValue & """"

    Wscript.Echo " Branding : [" & runCmd & "]"

    retVal = oWSH.Run( runCMD, 0, True )

    Wscript.Echo " Result   : [" & retVal & "]"

    End Sub

This step is typically the last step in our task sequence to ensure we capture all the Task Sequence Variables onto registry for inventory purposes. With the data now in registry keys, we are now ready to collect that data using ConfigMgr.

Use ConfigMgr to report data from Registry Keys

Finally, after all the pre-requisite work of populating the required data in the registry of machines, we will see what needs to happen next to get that data into the ConfigMgr database for easy retrieval in the form of reports.

As with any inventory data collection using MOF in ConfigMgr, retrieval of USMT values from Registry Key here is no different. However for the sake of completeness, we will see how this is actually done within ConfigMgr. There are set of MOF files named Configuration.MOF and SMS_DEF.MOF, which control what data is collected as part of inventory agent by ConfigMgr clients. Configuration.MOF instructs ConfigMgr clients to create WMI class, and SMS_DEF.mof tells ConfigMgr clients what to pick up from the WMI class and report to ConfigMgr site up the hierarchy.

The snippets available below, pretty much do the job of collecting inventory information and reporting them to ConfigMgr site. You would need to append these snippets into the respective MOF files at the site server. Of course, after tweaking to meet your needs and testing it.

As mentioned earlier, our approach of data collection is more than just USMT and hence you see those additional lines which are not related to USMT.

Configuration.MOF snippet

#pragma namespace("\\\\.\\root\\CIMV2")

#pragma deleteclass("HWINV_OSD_Details", NOFAIL)

[DYNPROPS]

class HWINV_OSD_Details 

{

[key] string KeyName = "";

string TSType;

string TSVersion;

string OSDImagePackageId;

string OSDBitlockerStatus;

string OldComputerName;

string OSDComputerName;

string OSDJoinAccount;

string OSDStartTime;

string OSDEndTime;

string OSDInstallLP;

string OSDGUID;

string USMT_ScanTime;

string USMT_ScanSize;

string USMT_LoadTime;

string USMT_LoadSize;

};

[DYNPROPS]

instance of HWINV_OSD_Details 

{

KeyName = "HWINV_OSD_Details";

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|TSType"),

Dynamic, Provider("RegPropProv")] TSType;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|TSVersion"),

Dynamic, Provider("RegPropProv")] TSVersion;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|OSDImagePackageId"),

Dynamic, Provider("RegPropProv")] OSDImagePackageId;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|OSDBitlockerStatus"),

Dynamic, Provider("RegPropProv")] OSDBitlockerStatus;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|OldComputerName"),

Dynamic, Provider("RegPropProv")] OldComputerName;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|OSDComputerName"),

Dynamic, Provider("RegPropProv")] OSDComputerName;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|OSDJoinAccount"),

Dynamic, Provider("RegPropProv")] OSDJoinAccount;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|OSDStartTime"),

Dynamic, Provider("RegPropProv")] OSDStartTime;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|OSDEndTime"),

Dynamic, Provider("RegPropProv")] OSDEndTime;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\MPSD\\OSD|OSDInstallLP"),

Dynamic, Provider("RegPropProv")] OSDInstallLP;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\MPSD\\OSD|OSDGUID"),

Dynamic, Provider("RegPropProv")] OSDGUID;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|USMT_ScanTime"),

Dynamic, Provider("RegPropProv")] USMT_ScanTime;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|USMT_ScanSize"),

Dynamic, Provider("RegPropProv")] USMT_ScanSize;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|USMT_LoadTime"),

Dynamic, Provider("RegPropProv")] USMT_LoadTime;

[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MPSD\\OSD|USMT_LoadSize"),

Dynamic, Provider("RegPropProv")] USMT_LoadSize;

};

SMS_DEF.MOF snippet

#pragma namespace("\\\\.\\root\\CIMV2\\SMS")

[ SMS_Report (TRUE),

SMS_Group_Name ("HWINV_OSD_Details"),

SMS_Class_ID ("MICROSOFT|HWINV_OSD_Details|1.0") ]

class HWINV_OSD_Details : SMS_Class_Template

{

[SMS_Report (TRUE), key ]

string KeyName;

[SMS_Report (TRUE) ]

string TSType;

[SMS_Report (TRUE) ]

string TSVersion;

[SMS_Report (TRUE) ]

string OSDImagePackageId;

[SMS_Report (TRUE) ]

string OSDBitlockerStatus;

[SMS_Report (TRUE) ]

string OldComputerName;

[SMS_Report (TRUE) ]

string OSDComputerName;

[SMS_Report (TRUE) ]

string OSDJoinAccount;

[SMS_Report (TRUE) ]

string OSDStartTime;

[SMS_Report (TRUE) ]

string OSDEndTime;

[SMS_Report (TRUE) ]

string OSDInstallLP;

[SMS_Report (TRUE) ]

string OSDGUID;

[SMS_Report (TRUE) ]

string USMT_ScanTime;

[SMS_Report (TRUE) ]

string USMT_ScanSize;

[SMS_Report (TRUE) ]

string USMT_LoadTime;

[SMS_Report (TRUE) ]

string USMT_LoadSize;

};

After the site server had a chance to create new inventory policies for clients; clients during its next inventory cycle will send the data up to its ConfigMgr site server. Once the data is processed by the data loader thread (one of the threads of SMS_Executive service), the data finally shows up in SQL database. Based on the class name we used, the below query will show data in ConfigMgr DB.

   1: SELECT * FROM V_GS_HWINV_OSD_Details

Summary

To summarize what we have seen so far - We went through the process of parsing the USMT logs for specific strings to identify the values we need to collect. After that is done, based on our implementation approach, we populated those values into Task Sequence variable and then to registry. Finally, using standard inventory collection process of ConfigMgr we saw how the MOF needs to be updated to see the data in ConfigMgr database and hence reports.

We hope this was helpful in identifying the hidden information of USMT usage statistics using few simple scripts as Task Sequence steps and the standard inventory process of ConfigMgr.

Application Discovery & OSD Results

We’ve had a great deal of customers using Modena utilizing our release on Microsoft Connect.  OSD tools and Driver Sync provide many IT administrators the ability to successfully deploy Windows 7 using the blueprint developed at Microsoft for Microsoft.  Although Windows 7 has RTM’d and is now available to business customers, the work here at Microsoft and with Modena isn’t complete.  Today’s post will outline some of the details of what we are currently working on and sharing with everyone when we expect all work completed.

Application Discovery

We’ve had requests for our internal customers that requests that, as part of the OSD process, we determine what ConfigMgr packages are installed on the computer prior to the migration to Windows 7 and flags them for re-install by OSD.  The application discovery functionality is built as a pre-flight in the OSD Wizard that executes prior to the migration.  The application discovery pre-flight (appscan.exe) executes utilizing either a local AppScanMaster.xml file that represents the <application> node that, by default, is located in the osdConf.xml configuration file or utilizing a Web service using WCF and IIS7.  For the latter, you use appscan.exe http://mywebserver/foo and the AppScanDownload.xml file is pulled from the remote web service.

To summarize the scenarios, let us explain -

1. You can build an XML file called AppScanMaster.xml and include it in the OSD package where OSD Wizard is packaged and AppScan will scan the local SCCM repository and determine what packages are present
2. You can install IIS7 and SQL server (we are planning to build an installer for this) and then store in a database the XML file that is downloaded by AppDiscovery from the Web service using URL

Why would one utilize #1 or #2?  I’m glad that you asked…

For some of our internal support needs, we needed a method that would allow administrators to manage the “master list” of packages in a more dynamic fashion without a refresh of the ConfigMgr OSD packages which is required for option #1.  If your environment is similar where packages are often added to your environment for software distribution then you should enable the Web service and utilize it as you update once and AppDiscovery honors it.  For less “dynamic” environments, you can always select option 1 as to avoid having to manage additional IIS or SQL resources.  AppDiscovery honors both the online and offline modes when executed, first attempting to use the Web service first and falling back to look for AppScanMaster.xml in the root directory where AppDiscovery is executing.

Enabling Application Discovery

Application Discovery is a single pre-flight executable that provides no User interface and depends, currently, on the OSD Wizard for the User interface.  As such, we are modifying the behavior of the OSD wizard for the applications node where an external location for the application is usable.  This is important to allow AppScan.exe to write the file to a location and for the OSD wizard to utilize it.  The current OSD Wizard locks the configuration file and thus requires another file to read in order to overwrite the default settings stored in the wizard’s configuration.

We’ve added functionality to the XML configuration and the corresponding logic in the wizard to support the ability to “link” another external file.  This is exposed in the <application> node and is indicated by remoteFile=”{filename}” as shown in the following example: [NOTE – Schema is slightly changing and this blog will be updated to reflect the new schema at a later date]

   1: <applications remoteFile=”fileName” basevariable="APPS" defaultselection="4" >

   2:  <group name="Human Resources" >

   3:   <application appid="1" name="HeadTrax" x86id="MSD0001:Headtrax Setup" x64id="MSD0011:HT64Setup" />

   4:   <application appid="2" name="Money Maker" x86id ="MSD0002:MoneyMaker2010" x64id="MSD0002:Setup" />

   5:   <application appid="3" name="Peoplesoft" x86id ="MSD0003:Peoplesoft_Setup" x64id="MSD0013:Setup" />

   6:   <application appid="4" name="Surefire" x86id ="MSD0004:SF_Setup" x64id="MSD0004:SF_Setup" />

   7: <group/>

   8: </applications>

This functionality allows the actual filename such as AppScanResults.xml to instruct the wizard to look for this file and load the data starting at the <applications> element.  After reading this file into memory, AppDiscovery will then utilize it to do a comparison against the currently installed applications.

In short, the following graphic should illustrate the pecking order of events though some of the events may occur asynchronously -

As indicated, the final step is to display to the end-user the application selection list that has been altered by AppDiscovery.  The behavior to the end-user is completely the same yet the default selection is now altered by AppDiscovery.  In short, all applications outlined in the Master List is always displayed to the end-user while any applications that were “discovered” by AppDiscovery are selected.

Why are the applications discovered selected?  The goal at the completion of the migration is to put the end-user right back to the state at which they were prior to the upgrade.  Though, with one noticeably bit difference, they are now running Windows 7.  If the user does “nothing” then that is the exact state they will end up in.

Getting Insight into your Migration Status – Using OSD Results

The last piece of completed, working functionality that we are readying for release is OSD Results.  At Microsoft, we focused a lot of time on getting the right blend of interaction with our end-users up front.  This is the very reason that we built the OSD Wizard that many of you are currently enjoying today.  However, we felt there was still “something” missing and it was really starting to bother many of us (ok, ok, lets just say it was bothering me the most but nonetheless we digress).  At Microsoft, we had a lot of upgrades where end-users were going from Windows 7 (Pre-RTM) to Windows 7 (RTM) and because of this they often never knew if everything worked during the migration unless the end-user poked around a bit after logging in.

Understanding that there was information we would love to communicate, we seeked out options to provide a “completion” screen when were were completed.  This was the birth of OSD Results…

How does OSD Results Work?

Utilizing a “hook” available in Windows Vista & Windows 7, we build a stand-alone Windows Presentation Foundation (WPF) application that displays a few available tabs to the end-user.  The “Tabs” are the communication channel to let the end-user know that the Deployment completed and what was the status of the key steps to the migration.  For example, we display to the end-user the Time to Complete (end-to-end), domain join information, as well as the computer system information.  We also display to the end-user the applications we installed and whether they were successful or failed.

The primary mechanism used is straight-forward and utilizes two registry keys -

1. HKLM\SYSTEM\Setup /v CmdLine /d %windir%\modena\OSDResults.exe /f
2. HKLM\SYSTEM\Setup /v SetupType /d 2 /t REG_DWORD /f

Why OSD Results?

As mentioned, we wanted to share with the end-user that we are “done” with our migration and that when they are ready to start working then move forward.  Leaving them at the “default” CTRL+ALT+DEL simply didn’t feel as friendly as we would have liked nor did they know whether we “succeeded” to do everything we promised to do.  Thus, the last step we execute is to do the following -

1. Spawn an application that monitors for OSDSetupHook.exe to exit (e.g. we are watching for the task sequence to complete)
2. We write our registry keys (see above) for OSD results to get executed
3. We restart the computer

The end-user is then watching the system re-do the initial configuration (it really isn’t doing anything) and then WinLogon will execute the commands we put in place before reboot.

How is OSD Results getting its Data?

OSD Results doesn’t interact, currently, on the wire as we didn’t want this to take place since we are doing all of execution prior to any login as the end-user.  OSDResults.exe runs prior to any user context thus we don’t have any hyperlinks as they would fail since the user isn’t logged in.

For simplicity, we stored all of our data in the registry.  This isn’t the most robust solution but it works.

Summary

The first question often asked is where are these bits.  We haven’t completed our final milestone, in this case, M6 that will be our feature complete.  We will finalize this over the next couple of months and will release in early November in our final, pre-RTW release.  Nonetheless, we are working to add some additional functionality that you will have in your hands real soon.

The final pieces of functionality we are putting together coming in Nov. are the following:

1. Re-write of our underlying Wizard Schema
2. Expanding AppDiscovery to support WQL filters as well as Many-to-One mappings
3. Changing our Application screen in the OSD Wizard to support Application Dependencies/Exclusions/Filtering/Locking
4. Building a Administration Tool & Installer to simplify the time to deploy for Modena’s OSD Tools

Enjoy!

-Chris

Joining Modena RC1 Tools Program

We have had a lot of discussion around the topic of our Beta program of Modena.  We are currently in a Beta released state on Microsoft’s Connect site though we are an invitation-only program.  This means that those of you who frequent Connect will not locate our beta as it is not listed in the directory.

Does this mean you can’t participate?  The answer is absolutely, positively… Well, gotcha going a bit so just so you know this is wide-open.  There are some legal things you need to do when you request your participation.

How to participate in Modena

Modena is a “collection” of tools aimed at simplifying your deployment tasks when using Configuration Manager 2007 Service Pack 2.  With Service Pack 2 (currently in Beta), you can utilize the OSD framework to deploy Windows 7 to your enterprise.  Modena, with OSD Tools and Driver Sync, includes the blueprint we use at Microsoft to deploy Windows 7.  We provide our end-user experience, exported task sequence, pre-flight scripts, and our driver sync tool to simplify management of drivers in your enterprise.

To participate in Modena RC1, the following steps should get you going:

1. Join Configuration Manager 2007 Service Pack 2 Open Beta
2. Using Connect, locate MPSD (under Server) and click Apply Now

Thanks,

-Chris

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

Understanding the Volume Page in the Modena Beta OSD Setup Wizard

One of the features enabled in the PXE experience (bare metal) is the volume page.  This page is disabled by default when running from Run Advertised Programs (RAP) or ARP as all the information is available from within the operating system.  In this post, I’m going to focus on explain our Modena OSD Setup Wizard’s volume page such as how to enable it but more importantly what is going on in the background based on selections made in the wizard.

Volume Checks

The first thing to note is the fact that the OSD Setup Wizard requires an NTFS partition exist otherwise we will throw an error.  This isn’t a bug in the actual OSD Setup Wizard but instead is a requirement for ConfigMgr 2007 OSD.  Thus, their is no support for RAW drives and the wizard will produce the volume page but it will be grayed out and give the warning message that no NTFS volume is present.

To resolve this problem, it is pretty straight forward using these commands:

In short -

1. Open Diskpart by typing Diskpart
2. Type:

Sel Disk 0

Create Par Pri

Format fs=ntfs quick

assign letter=c:

Now give it another try and you should see the drive listed as an available volume.

WinPE vs. Full OS Configuration

It should be noted that, with our Modena Beta OSD Setup Wizard tools we deliver two configuration files.  The purpose of this is to show how to effectively have a configuration file for the wizard that supports the bare-metal experience versus the scenario where a user is running the wizard from a full OS.

Enabling the Volume Page in the Configuration File

The purpose of this blog is to just make sure that those participating in the Modena Beta understand how to test and configure the OSD Setup Wizard tools.  This is the key to us getting good feedback that can drive some design changes (if necessary) that will make this wizard as useful as possible.  For this example, I’m going to outline how to modify the XML configuration file to enable the Volume page.

To enable the volume page, do the following:

1. Open the XML configuration file (osdConf or osdConfWinPE) using your favorite XML editor
2. Locate the <pages> element (e.g. CTRL+F)
3. Modify the Volume page to say enabled
4. Save the file

The enabled volume page XML should look like the following upon completion:

- <Page>

  <Option name="WelcomePage" mode="Enabled" text="Welcome." /> 

  <Option name="ComputerPage" mode="Enabled" /> 

  <Option name="NetworkPage" mode="Enabled" /> 

  <Option name="LanguagePage" mode="Enabled" /> 

  <Option name="VolumePage" mode="Enabled" /> 

  <Option name="SummaryPage" mode="Enabled" /> 

  </Page>

The disabled volume page XML should look like the following upon completion:

 <Page>

  <Option name="WelcomePage" mode="Enabled" text="Welcome." /> 

  <Option name="ComputerPage" mode="Enabled" /> 

  <Option name="NetworkPage" mode="Enabled" /> 

  <Option name="LanguagePage" mode="Enabled" /> 

  <Option name="VolumePage" mode="Disabled" /> 

  <Option name="SummaryPage" mode="Enabled" /> 

  </Page>

Multiple Image Options Available for X64 Machines

A often asked question is around how the wizard determines what to show in the Image list.  For example, a WIM might combine both a Vista & Win7 image hence leading to the user having multiple options such as:  Windows 7 (x86) and Windows Vista (x86).  This could balloon up to 4 or more options in the drop down such as the case where Vista & Win7 are offered on a x64 machine – Windows 7 (x86) and Windows Vista (x86), Windows 7 (x64) and Windows Vista (x64).

To avoid confusion by end-users, the image selection field can be locked to ensure that they are only offered what they should get.  However, in a very flexible environment where the end-users are knowledgeable, this option becomes very nice.

-Chris

Modena (OSD Tools & Driver Sync) Private Beta Released

On June 2nd, the Modena team at Microsoft reached a pivotal milestone by releasing our first semi-formal release to external users.  This is a great milestone that our team set out to accomplished back in January when we formed our engineering team.  The vision is that we develop tools that not only are used at Microsoft and our external customers but also are delivered as to customers to expedite and accelerate their deployments.  We aren’t the solution accelerator team who focuses heavily on this very goal – though often we find we have to add some additional value to their tools to meet Microsoft requirements.  As a value-add, we decided to share our tools with our customers as a way to enhance the experience you might have with our tools.

Microsoft Code-named “Modena” Beta Tools

The first thing that often comes up is what is your name.  We don’t have a name right now and may never have one.  We do have a code-name though and that is what the cool people do so we are happy.  Modena is one of the project internal names we selected and is currently our master project to deliver a enterprise-ready Configuration Manager 2007 Operating System Center (OSD) solution (wow, say that backwards 3 times!) at Microsoft.  It is comprised of two tools that each solve a particular problem at Microsoft:

Modena Beta OSD Tools

This packaged release is three parts – our custom OSD Setup Wizard – that offers a flexible, usable user experience to end-users though fully supports the powerful capabilities of ConfigMgr 2007’s task sequence engine.  For example, IT administrators can add a simple task sequence step that will show the wizard user interface as well deploy a pre-populated configuration to support different sites.  At Microsoft, we have various ConfigMgr hiearchies that cause us to have various pieces of data to offer the end-user and we can change this configuration without ever re-compiling the wizard.  I will talk more about this below. 

Beyond the wizard, we offer a set of pre-flight tools (scripts, etc.) that will enhance the user experience to ensure that a user doesn’t install Windows 7 (or another OS) when they don’t have the right set of conditions.  These conditions could be available memory, bandwidth, or A/C power.

We also deliver an exported task sequence that can easily (we think) get imported and uses the OSD Setup Wizard along with the pre-flights so that you can run with it and test to your hearts content.

Modena Beta Driver Sync Tool

Deploying Windows 7 at Microsoft posed some unique challenges that I know the rest of the world has faced.  We all know that drivers are a non-trivial activity when it comes to ensuring that machines have the right driver.  We had a hard requirement to ensure that we delivered drivers to client machines not only during OSD (think Driver Catalog) but also after Windows 7 is up & running.  For this, we developed the Driver Sync Tool. 

The Driver Sync Tool marries together three separate products, Windows Update/Microsoft Update (WU/MU), Windows Server Update Services (WSUS), and ConfigMgr 2007.  The logic between marrying these with a “tool” is that we already have all the data needed for our clients in our ConfigMgr database and all we need to do is put that together with WU/MU and push to WSUS.  Thus, just like a user is patched today using WSUS we could also provide the same experience to ensure they are provided updated drivers.

We built the Driver Sync Tool using Internet Information Services (IIS) 7.0, .NET Framework 3.5 Service Pack 1 (specifically, Windows Communication Foundation), and SQL Server 2008.  The only requirement is that you, when you download, already have a Windows Server 2008, WSUS v3 Service Pack 1, & SQL Server 2008 licensed server(s) available in your enterprise.  The Driver Sync Tool will then communicate directly to your ConfigMgr infrastructure and obtain all broken drivers and locate the best driver for that device Id (it uses a combination of device Id, compatible Id, and hardware Id’s) and then notifies your WSUS infrastructure to pull down the Update Id for that driver.  It’s that simple…Not really, but you get the point!

For more details, see this blog post that talk a bit more about how we “enabled” the Driver Sync Tool and look for future posts that talk more in-depth about our design and solution.

In order to obtain the Modena Beta Tools you will have to already be a member of the ConfigMgr 2007 SP2 Open Beta Program that is available via the Microsoft Connect site.  This is required as our tools are developed in lieu of their update (excluding Driver Sync Tool).

Modena Beta OSD Setup Wizard

Unless you attended Microsoft Management Summit in late-April, you probably have no idea what this OSD Setup Wizard is.  You might have also attended our Technet webcast on the topic and see the demonstration as we use it there.  As mentioned above, the OSD Setup Wizard is a development effort by my team at Microsoft that solves the age old dilemma of providing a nice, intuitive, yet robust user experience (UX) for clients.  We targeted the OSD Setup Wizard for Windows 7 but there isn’t anything stopping it from working fine on Windows XP, Windows Vista, etc. though obviously I would tell you that you are crazy for not deploying Windows 7 – it rocks!

The goals of the wizard are broken up today (and future) sections:

1. Welcome
2. Future - (it’s a secret)
3. Computer
4. Network
5. Language
6. Volume
7. Future - (it’s a secret)
8. Summary

The purpose of these sections are to logically place the UX together based on the purpose.  As an IT Administrator, it is easy to disabled any of these sections/pages as well as set the default configuration such as the OU, etc.  For example, look at this snippet from the osdConf.xml:

    <PageSettings>

      <Page>

        <Option name="WelcomePage" mode="Enabled" text="Welcome to the Windows7 OSD Setup Wizard."/>

        <Option name="ComputerPage" mode="Enabled"/>

        <Option name="NetworkPage" mode="Enabled"/>

        <Option name="LanguagePage" mode="Enabled"/>

        <Option name="VolumePage" mode="Disabled"/>

        <Option name="SummaryPage" mode="Enabled"/>

      </Page>

    </PageSettings>

    <ConfigSettings>

      <Domain>

        <Option default="true">

          <Name enabled="true">fabrikam.com</Name>

          <OU>

            <Option default="true" enabled="true">OU=Workstations,OU=Machines,DC=fabrikam,DC=com</Option>

          </OU>

        </Option>

        <Option>

          <Name>europe.fabrikam.com</Name>

          <OU>

            <Option default="true" enabled="true">OU=Workstations,OU=Machines,DC=europe,DC=fabrikam,DC=com</Option>

          </OU>

        </Option>

      </Domain>

This would produce the following Wizard page:

As an IT professional, though, I don’t have time to learn C/C++ which is what our wizard is developed in so I need an easy way to update the actual OU’s as we just added an IT department (great idea!).  Easy, no problem…update osdConf.xml in your package and re-distribute to the DPs and away you go:

    <PageSettings>

      <Page>

        <Option name="WelcomePage" mode="Enabled" text="Welcome to the Windows7 OSD Setup Wizard."/>

        <Option name="ComputerPage" mode="Enabled"/>

        <Option name="NetworkPage" mode="Enabled"/>

        <Option name="LanguagePage" mode="Enabled"/>

        <Option name="VolumePage" mode="Disabled"/>

        <Option name="SummaryPage" mode="Enabled"/>

      </Page>

    </PageSettings>

    <ConfigSettings>

      <Domain>

        <Option default="true">

          <Name enabled="true">fabrikam.com</Name>

          <OU>

            <Option default="true" enabled="true">OU=Workstations,OU=Machines,DC=fabrikam,DC=com</Option>

          </OU>

        </Option>

        <Option>

          <Name>europe.fabrikam.com</Name>

          <OU>

            <Option default="true" enabled="true">OU=Workstations,OU=Machines,DC=europe,DC=fabrikam,DC=com</Option>

          </OU>

        </Option>

        <Option>

            <Name>southamerica.fabrikam.com</Name>

               <OU>

                   <Option default="true" enabled="true">OU=Workstations,OU=Machines,DC=southamerica,DC=corp,DC=microsoft,DC=com</Option>

               </OU>

        </Option>

      </Domain>

This would produce the following wizard with the newly updated

Beyond just seeing that we have the OU hard-coded, notice that we have disabled the entire selection.  The scenario here is the users at a specific site are always placed in a special OU that they shouldn’t change.  No problem, we can lock this using the enabled=”false” feature in the osdConf.xml as such:

            <Option default="true">

                <Name enabled="false">redmond.corp.microsoft.com</Name>

                <OU>

                    <Option default="true" enabled="true">OU=Workstations,OU=Machines,DC=redmond,DC=corp,DC=microsoft,DC=com</Option>

                </OU>

            </Option>

Trust us when we say we did this without re-compiling a single line of code… <g>

Branding the Wizard

As we mentioned, we set out from the start to “share” everything with the world so we always went through the thought process of how to make things simple.  When we release our RC1 in mid-July, we will have made everything in the wizard configurable so that it gives complete control to the IT professional (you).  This is crucial to ensuring that we reduce our coding churn and that you get the maximum flexibility – wise, ay?

The common thing that occurs is that you don’t want to assume “our” Microsoft branding.  As we demo’d this is pretty simple to do using the same configuration file, osdConf.xml and it is done using this XML:

    <Banner>

      <FileName>Header0.bmp</FileName>

    </Banner>

This is currently using this file for the Branding -

This file, called Header0.bmp, would produce the following Welcome page:

Let’s assume you didn’t like this and wanted to change this to another header, such as Header 1.  The only requirement is that you make the .bmp 630x100 (if you make it bigger, we will show it so take our advice as we probably aren’t going to fix this bug!!!!) and off you go.  So, for example, I prefer to show this Bitmap for the Europe users.  I would create a new osdConf.xml for the Europe site and I would set the <banner> section to use header1.bmp which produces the following wizard branding:

    <Banner>

      <FileName>Header1.bmp</FileName>

    </Banner>

The Image:

This would produce the following Wizard branding:

Summary

We are working hard on some further investments in our M5 engineering milestone and we think that we are working on the features for both our OSD Setup Tools as well as our Driver Sync Tool that you (yes, you!) want.  We do though have a beta that you could participate in if you are part of the ConfigMgr 2007 SP2 beta.  If you are a part of this program, email me and feel free to request joining our beta and we will share our bits.  Beyond that, we are reaching out and asking for folks to share what they think would be enterprise scenarios for both OSD Tools & the Driver Sync Tool.

-Chris

Deploying Win7 using OSD at Microsoft Webcast Q & A – Part III

As we mentioned, we recently gave a talk as part of the Microsoft IT Showcase series that focused on what we have built for Microsoft clients with OSD.  A great number of questions were asked during this presentation and due to time constraints we were unable to answer them.  We promised to share them in a upcoming blog.  This is the final of a 3-part series where we asked the question and answered it.  Part I and Part II are available as well on our blog.

Q:  How many applications did you approve for Windows 7?

A:  We reviewed most, if not all, of our currently packaged applications and determined that none were packaged in such a way that there issues with User Account Control (UAC) or OS targeting.  Thus, though we reviewed 15 number of applications required for Microsoft IT users, we had none that failed to work properly on Windows 7.

Q:  Is Microsoft IT using XP Mode or App-V for the applications that aren’t Windows 7 compliant?

A:  We are currently not using XP Mode for our user base at Microsoft.  This is specific, though, to our environment of users who are managed using ConfigMgr and doesn’t represent all of MS IT.  We do offer users a virtual application, Adobe Reader, for 32-bit clients but we don’t require they use the application.  For compatibility purposes, App-V isn’t the right application to use but instead users should use Microsoft Enterprise Desktop Virtualization (MED-V) as this is designed to solve OS compatibility issues.  App-V is designed to solve application compatibility issues.  We currently are testing MED-V and will look to deploy later this year.

Q:  Did Microsoft IT package up all the applications used as part of the OSD process?

A:  We “packaged” all the ConfigMgr packages but the actual software packaging process (such as building of the MSI, etc.) came from several different sources.  In short, we packaged some but not all of the actual packages used in the OSD process.

Q:  Are users responsible for reloading any application not delivered during the installation process?

A:  Yes, this is correct.  We will restore application-specific data using USMTv4 but we don’t guarantee to lay back down the application.

Q:  If we have WinRE partitions, how are those migrated to Windows 7 using OSD?

A:  For WinRE-enabled clients, this fell into a bucket that we couldn’t support at Microsoft because it was considered a dual-boot scenario.  If this was the case and we detected it via our OSD Setup Wizard, we exit and advise the user that we detected two operating systems on either the same volume/partition or another partition (this is rather trivial using bdeedit like functionality) and would exit.  For these scenarios, the user would have to select to format completely their volumes (option in our wizard) or they would need to remove the WinRE (Windows Recovery) partition\volume and then go through the wizard process again.  This is not the most graceful of scenarios but, unfortunately, some of the underlying technologies (WinPE) have difficulty in dual-boot scenarios so we didn’t tackle this problem at Microsoft.  Sorry!

Q:  Why is Microsoft IT running bare metal user experience and asking them for a user Id/password?  Why not ask for a userid and try to provision based off of Active Directory (AD) information?

A:  We are sure we completely understand the question but we will give it our best shot.  The question, we believe, ask why during the WinPE bare-metal experience do we ask for the domain username and password in the OSD Setup Wizard.  The reason this occurs is due to the fact that machine objects in Active Directory are owned by the end-user who created them originally.  Thus, if the user during a bare-metal experience selects a computer name that already exists in the Active Directory OU then we need to validate they own that object.  If they do not, we either error out and ask them to select a new name or depending on the configuration of the wizard we will generate a name for them and continue own.  For those interested, we modify the configuration in osdConf.xml that is provided for the wizard.

Q:  Does ConfigMgr 2007 SP2 handle packages that are advertised to allow user interaction and work with OSD?

A:  We don’t allow packages to be used that are not hard-coded to silent so, unfortunately, we can’t really speak to it with a great deal of certainty.  At this time, we would speculate it would be no problem at all though we haven’t had this experience at Microsoft or elsewhere thus leading us to have to give you our best guess.  You might can find someone on the ConfigMgr forums who has done it this way and can give you concrete advice.

Q:  Of the 120 machines, what % do you support with ConfigMgr driver packages?

A:  We have the luxury of having a hardware team at Microsoft who owns the relationship with our various OEMs and this team provided a setup tool to our team that provision drivers on a per-model basis.  This tool was a step in our task sequence thus mitigating the requirement that we have multiple driver package payloads to support in ConfigMgr 2007.  This is possible to do though would get very, very non-trivial fast and offer a lot of possible scenarios that could easily break.  Depending on the number of models at play here, we would probably recommend you keep your driver packages low (like we did) if you have a high number of skus and have a special step that provisions (either a script or a EXE, or something) specific drivers on a per-model basis.

Q:  Could the machine that Microsoft IT do not load ConfigMgr driver packages for get their driver support through an internal company WU/MU?

A:  Yes, absolutely possible and how we are actually doing it at Microsoft.  The key to our Microsoft Driver Sync Tool is to ensure that WSUS 3.0 SP1 or SP2 has the correct drivers for the hardware we have in our enterprise.  This is a crucial step and Windows Server Update Services (WSUS) represents the WU/MU service but at the enterprise level allowing for some key management necessary for many enterprises.

Q:  Will a customer be able to host an Internal MU for driver installations for break\fix later on?

A:  This is actually called Windows Server Update Services (WSUS) and it is the only method to bring something in-house that works with Windows Update (WU) & Microsoft Update (MU).  We aren’t currently aware of this infrastructure WSUS –> WU/MU changing in the near-term thus the reason we built our Driver Update Sync tool.  As for the OSD process, we have a script (we will share later via a blog) that we run as the final step in our task sequence that grabs all critical, important, and optional security patches and drivers from WU/MU so that our clients have the necessary updates installed or available.  We are currently investigating further ways to make this more robust (a future post) but for now this is our method for ensuring that working drivers exist upon completion of the installation of Windows 7.

Q:  Our current experience with SMSTS.log is it doesn’t contain all the entries from a new computer nor are the messages in the history of the SMSTS.log.  Can you explain a bit about this?

A:  Yes, they roll over after so many entries. This is why we copy our logs off to various directories throughout the imaging process. This not only captures the logs before they roll over, but it also makes it nice as they are organized in directories with the name of each phase from which the logs were generated (Install OS, Setup Windows etc.). This is done by running cmd /c xcopy /E /C /I /Y %_SMSTSLogPath% %OSDStateStorePath%\Logs\StateCapture for example where %_SMSTSLogPath%  is location where logs are always kept.

Q:  How do you make the SMSTS.log grow as large as needed?

A: We believe this can be set through HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\TaskSequence. There are entries like LogLevel, LogMaxHistory, LogMaxSize. This would require that the boot image is changed and the OS during that portion of the install. So you could either A) mount the boot and install image and then load the boot image registry hive and make the change B) Make the registry change on the fly by doing a reg import or add.

Thanks,

-Chris

Deploying Win7 using OSD at Microsoft Webcast Q & A – Part II

As promised, my team wanted to follow up with everyone regarding questions asked during our Webcast last week on How Microsoft IT deploys Windows 7 using Operating System Deployment.  In this blog we will focus specifically on the questions and provide answers to those questions so please excuse us if we don’t have anything “technical” in this as we are just going down the list of questions.

Q:  If multiple users use a single machine, does USMTv4 from WinPE backup all data related to all user profiles

A:  Yes, USMTv4 can obtain all data for all users who have currently used the client that is getting migrated to Windows 7.  This is highly configurable though via the command-line switch and for Microsoft we provided a switch for that said only migrate local and domain users who have been active in the last 45 days.  In the below example, the /uel:45 indicates to the scanstate how far to go back when migrating user profiles whether local or domain:

In the case above, you can change the /uel to something other than 45 and grab all profiles.

Q:  What are the pre-reqs for the OSD Setup Wizard demo’d during this presentation?

A:  The OSD Setup Wizard has no pre-requirements other than having the typical ConfigMgr 2007 SP2 needed for OSD.  The wizard is completely self-contained and is made up of a single .exe (OSDSetupWizard.exe) and a customizable XML configuration file.  This wizard can run within Windows PE or via a full operating system though the behavior is slightly different but still fully controlled using the configuration file.

Q:  It sounds like there are pre-reqs for ConfigMgr 2007 Service Pack 2 for deploying Windows 7, is this correct? 

A:  This is correct.  The only supported method for deploying Windows 7 is to first deploy Configuration Manager 2007 SP2.

Q:  Can I use more than one profile when using USMTv4?

A:  As mentioned above, absolutely.  USMTv4 supports both local and domain profiles and is flexible in it’s ability of which profiles to migrate.

Q:  Is the OSD Wizard a part of ConfigMgr 2007 or a stand-alone product?

A:  The wizard shown was a separate, downloadable, piece of software that is packaged up as an add-on for Configuration Manager 2007 SP2.  We will make it available along with a whitepaper soon for select customers and later broadly if possible.  It doesn’t have any plans currently of shipping as part of the ConfigMgr 2007 or later products.

Q:  If we are involved in the ConfigMgr SP2 TAP program, are these wizards and toolsets available to us?

A:  Yes, absolutely.  If you contact us via our blog (or directly via email) we will be happy to provide you the link to join our beta program to test the wizard and provide us feedback.

Q:  Will this OSD setup wizard work for creating images of XP or only Windows 7?

A:  The OSD setup wizard we showed works fine with any operating system as long as you have the configuration files setup properly and the appropriate WIMs to support the other operating systems.  As demo’d by Cameron, you can easily include additional images (via the index number) that would offer the end-user Windows XP, Windows Vista, and Windows 7 and let them select accordingly.  The wizard has only a dependency on SP2 when & if it is used for deploying Windows 7.  The wizard would work with OSD out-of-box for other operating systems.

Q:  What about security groups?

A:  This is tough for us to answer here as we can get “references” to exactly what is meant by the question.  However, if you are referring to whether the wizard could be used to join security groups the answer is currently no.  This isn’t something that we typically have a need for at Microsoft though with enough feedback we could certainly considering adding such functionality if needed.

Q:  What the name of this XML file?

A:  The default name for the OSD Setup wizard’s XML file is osdConf.xml though this is really irrelavant.  For multiple hiearchy environments in ConfigMgr, the support exists to specify per the task sequence the wizard and include the custom configuration file for that location, site, etc.  For example, you could have two XML files – osdConfUSA.xml and osdConfEurope.xml – and use them accordingly by specifying to use the correct configuration file.  For example, osdSetupWizard.exe /xml:osdConf.xml.

Q:  Does the OSD Setup Wizard work with Microsoft Deployment Toolkit (MDT) 2008/2010?

A:  This is untested on our part, unfortunately, so we really can’t speak to whether it would work or not.  We are in discussions with the MDT team currently and will hopefully share more going forward about how well the integration does work and make plans to simplify that since we do realize that MDT is a very popular method for deployments.

Q:  Why does the XML have to appear in that command-line?  The task sequence “Apply Operating System Image” option allows the user to enter the unattended.xml in the GUI.  Why is this different and will this difference still exist in ConfigMgr 2007 SP2?

A:  To clarify, there are two configuration files in play here.  We demo’d the use of osdconf.xml (osdSetupWizard /xml:osdconf.xml) as part of the XML configuration for the OSD setup wizard (not the operating system configuration) that sets the appropriate tas sequence variables at run-time.  This configuration changes or manipulates the behavior of the wizard as it is shown to the end-user and impacts the overall user experience.  On the other hand, the IT professional build the OSD task sequence can supply a custom unattend.xml to modify\change the operating system at run-time to match it’s desired configuration.  This is a separate discussion around how to automate the deployment of Windows 7 using the Windows Automated Installation Kit (WAIK) and was outside the scope of what we were showing.  The goal of our wizard is to provide a great user experience that is fully customizable yet returns the outcome the user desires upon completion of the OSD process.

Q:  I have noticed that you have to create an exclusion list of NIC MAC addresses in ConfigMgr 2007 to avoid every machine from booting directly to OSD when plugged into the network.  Is there a specific reason for this?

A:  This is the base functionality offered by ConfigMgr 2007 unknown clients (PXE support).  This is simply a behavior that can’t be avoided if you advertise to the unknown clients in Configuration Manager.  If you don’t want this behavior, remove any advertisement and the exclusion problem will cease to exist.

Q:  Where can I get my hands on ConfigMgr 2007 SP2 to start testing Windows 7?

A:  The ConfigMgr TAP program is available on connect.microsoft.com by entering your Windows Live ID and searching for System Center Configuration Manager.

Summary

For now, we are going to close down and we will answer one set of last questions tomorrow from the webcast.  Though we hope these are helpful!

-Chris