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 -
- 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
- 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 -
- HKLM\SYSTEM\Setup /v CmdLine /d %windir%\modena\OSDResults.exe /f
- 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 -
- Spawn an application that monitors for OSDSetupHook.exe to exit (e.g. we are watching for the task sequence to complete)
- We write our registry keys (see above) for OSD results to get executed
- 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:
- Re-write of our underlying Wizard Schema
- Expanding AppDiscovery to support WQL filters as well as Many-to-One mappings
- Changing our Application screen in the OSD Wizard to support Application Dependencies/Exclusions/Filtering/Locking
- Building a Administration Tool & Installer to simplify the time to deploy for Modena’s OSD Tools
Enjoy!
-Chris
