Business Value of Application Replacement
Who cares? That is the thought that went through my mind last night a few hours after I posted the last of my five part series on Dynamic Operating System Deployment and application replacement. Even if you don’t now, you SHOULD care. Let’s see if I can convince you…
Let me give one example of the difference that the concepts in that series made at a company. I had a client recently who was performing a company-wide Windows 7 rollout…migrating from Windows XP. This coincided with a PC replacement cycle, so this rollout was predominantly a “Computer Replace” scenario…so replacing the old XP box with a new Win7 box. After replacement, users obviously needed to be able to do their jobs on the new Win7 system…which meant that they needed some key applications that had previously been installed on their Windows XP system…but these apps had been installed on a case by case basis previously. The company has not implemented role-based application deployment at this time.
And THAT is where the problem arose. MANY of these applications are not in the core Windows 7 image for obvious reasons. (Visio, Project, Creative Suite, Oracle apps, numerous internal apps) For that matter, many of the apps that were installed in Windows XP were being replaced with a newer version in Windows 7 for application compatibility reasons. For this company it meant that when they performed the Windows 7 refresh on a location, they flew two employees to the refresh location to perform the upgrade. The PRIMARY reason that they needed to do this was so that the two employees could re-install applications on the user’s Windows 7 computer post-install on a case by case basis. This resulted in significant business problems including:
- User downtime because necessary applications weren’t installed on their new Windows 7 system.
- IT staff were pulled away from their day-to-day job for a week at a time to drive the migrations…mainly because of the need to install additional applications.
- The Windows 7 migration for the company was taking SIGNIFICANTLY longer than desired because of these limitations (both app installs and a limited number of employees to travel to numerous locations).
- Significant additional costs were associated with all of this (travel, time, delays, loss of user productivity)
Quite simply it was an unacceptable situation. Way too much wasted time and effort. That’s when they called us to see if we could help them streamline this process. I implemented the steps I outlined in posts 1, 2, 3, 4, and 5. The client saw some very significant improvements from a business value perspective…including…
- A VERY significant reduction in the number of special post-image application installations.
- Automated re-installation of required applications without the need for IT staff intervention.
- Significant reduction in user downtime as a result of the migration process.
- Consistency from an end user perspective. (i.e. My computer used to have Program X and it still does.)
- Smoother Windows 7 migrations.
- The company expects that significantly less travel will be required to perform the Windows 7 migrations.
- Cost savings…both travel related and time related.
So…should you care about making your operating system deployments dynamic and adding the application replacement functionality to the process? If cost and time savings mean anything to you, then yes you should. Don’t know about you, but I’ve got better things to do with my life than to babysit an OS deployment! :-)
OSD and the MDT Database (5 of 5)
This is the last of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Modifying the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
So, up to this point in this series we have put most of the pieces in place that are necessary to allow both Dynamic operating system deployments that are driven by the MDT database as well as perform Application Replacement during both Computer Refresh and Computer Replace scenarios. Now we need to tie all of this together and make it work together.
The two remaining pieces of the puzzle are:
- Create the CustomSettings.ini File
- Set up the Task Sequence to Process the Database Settings
Application Replacement (4 of 5)
This is the fourth of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Modifying the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
In the previous post we modified the SQL stored procedure to make Package Mapping work for both a Refresh and Replace scenario. However neither scenario will work until we populate the PackageMapping table in the MDT database.
Populating the PackageMapping Table
The PackageMapping table has two columns: ARPName and Packages. Each entry in the table creates a correlation between a piece of installed software (ARPName) and a Configuration Manager Package/Program (Packages).
The values in the ARPName column come from the values in the Uninstall registry key. (HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall OR HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall). MSI installs will be GUIDs. Non-MSI installs will be other names…not necessarily the DisplayName from Add/Remove Programs. The value in this field corresponds with the SMS_G_System_ADD_REMOVE_PROGRAMS.ProdID field in the Configuration Manager database which is gathered by Hardware Inventory.
The Packages column contains the PackageID and Program Name for a Configuration Manager Package. The proper format for this column is: “XYZ00000:Program Name” where XYZ00000 is the Package ID, and “Program Name” is the exact name of the Configuration Manager Program Name in the package. Of particular importance, the values in the Packages column are case sensitive.
We need to do four things in order to populate this table:
- Obtain the ARPNames that we care about
- Obtain the Package:Program combinations that we will correlate to the ARPNames
- Correlate which ARPNames should install which Package:Program.
- Add the ARPName = Package:Program to the table
Application Replacement (3 of 5)
This is the third of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Modifying the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
In the first post in this series, we set up the MDT database in our already functional Configuration Manager environment. The second post showed how to populate the MDT database in order to make our OSD process much more dynamic. This post will show the Application Replacement functionality.
Background:
For a while now MDT has included the ability to dynamically replace applications during a computer refresh scenario. (i.e. if the computer being reimaged has Visio installed, dynamically install Visio as part of the reimage) In a MDT only scenario, this is done with the UDI wizard via the Application Discovery pre-flight check. This can also be done using the integration with Configuration Manager…basing the software reinstall on the Configuration Manager inventory. While this functionality has been there for a while, I have found two pieces of it lacking:
- How to do this is buried in documentation that makes it a bit challenging to implement. (The MDT document that talks about this is a 497 page Word doc…good luck.)
- The process only works for a computer refresh scenario. It does not work in a computer replace situation…which is fairly common with my clients. They are not upgrading older Windows XP systems to Windows 7…they are replacing the computer. But they still need the user to have access to their current applications after the upgrade.
That is the reason for this blog post. First I want to show how to do this without having to dig through a huge doc. Second, I want to show how to modify this feature to allow for doing application replacement in both the Computer Refresh and the Computer Replace OSD scenarios.
Dynamic OSD using the MDT Database (2 of 5)
This is the second of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement #1…this post is the reason I started the series. Deals with necessary modifications to the RetrievePackages stored procedure.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
In the first post in this series, we set up the MDT database in our already functional Configuration Manager environment. (Check the assumptions section of the previous post.) Now let’s look at populating the database with information that will make our OSD process much more dynamic.
Populate the MDT Database:
The MDT database can be used to customize the deployment of systems. Customization can be based on Location, Make/Model, Roles, or tied to a specific Computer via Asset Tag or MAC address. The customizations available are numerous and include software installation as well as various AD and OS settings.
Configure Locations
Locations in the MDT database are set up based on Default Gateway.
- Select Location, then click “New”. Continue reading
Configuration Manager and the MDT Database (1 of 5)
This is the first of a five part series on utilizing the MDT integration into Configuration Manager to improve your Operating System Deployment functionality. These processes will make your OSD setup much more dynamic. The series will be:
- Assumptions and creating the MDT database
- Dynamic OSD using the MDT Database
- Application Replacement…this post is the reason I started the series. This will discuss configuring the application replacement functionality (also referred to as package mapping)…one of the more powerful components of OSD once it is working correctly! In a nutshell, it is a process for dynamically replacing applications during a computer refresh or replace scenario. For example, if a computer has Visio installed and I re-image it…ensure that Visio is re-installed. Or…if Acrobat 6, 7, 8 or 9 is installed…replace it with Acrobat X. VERY nice! This post will detail the necessary modifications that must be made to the RetrievePackages stored procedure in order for this to work for both a Refresh and Replace scenario.
- Application Replacement #2. Populating the PackageMapping table.
- OSD and the MDT Database…connecting all the dots from the previous four posts. Setting up a task sequence to use the MDT database.
While the end goal of this series is to show you how to use the MDT database to perform dynamic application replacement in your Configuration Manager task sequence, there is a lot that must be put into place before we get there. First let’s deal with a few assumptions that I am making.
Assumptions:
- Configuration Manager 2007 is installed and functional
- OSD is functioning at a basic level…image is imported and can be deployed via a standard deployment task sequence
- MDT 2010 Update 1 is installed on the site server
- “Configure Configuration Manager Integration” has been run on the site server
- An MDT Task sequence has been created and the wizard has built packages for:
- USMT
- MDT Toolkit
- Custom Settings
- A boot image has been created using the “Create Microsoft Deployment Boot Image” wizard. During the wizard, ADO support must be added to the boot image. ADO support is required to be able to query a database from Windows PE. Any necessary Mass Storage and Wired NIC drivers should also be added to the boot image.
Creating the MDT Database:
- Log on to the server where MDT is installed with an account that has rights to create a database on the SQL server.
- Open the Deployment Workbench
- Right click “Deployment Shares” and choose to create a New Deployment Share
- Walk through the rest of the wizard. Take note of the share name (the default share name is “DeploymentShare$”) as we will refer to that later. There is no need to populate the deployment share like you would need to do if just using MDT. Uncheck all of the checkboxes in the wizard (image capture, admin password, and product key).
- Expand Deployment Shares | MDT Deployment Share | Advanced Configuration | Database
- Right click Database, select New Database. Follow the New DB Wizard
- Enter the SQL server that will host the DB. Choose “Named Pipes” for the Network Library. I have seen others who have commented that TCP/IP can be problematic. These were mostly old posts, so it may not be an issue any more. Whichever is used, be sure it is enabled on the SQL server.
- Choose to create a new database. Give it a name that makes sense. (e.g. MDTdb)
- On the SQL Share screen, choose any share that exists on the SQL server. This is only used for establishing that the credentials can work. It can be any share. In a single server scenario where the MDT Deployment share is on the server, you can use DeploymentShare$ that was created when you created the Deployment Share in step #3 above. If a special share is created just for this purpose, then a file should be created in the share to indicate its purpose to protect against accidental deletion because someone thinks it is not being used.
- Continue through the wizard to finish. The new DB connection will appear in the Deployment Workbench.
Summary:
This post walked through the background requirements and the initial creation of the MDT database…the necessary pre-reqs for the Application Replacement / Package Mapping functionality to work. The next post in the series will show you how to populate the MDT database to set the stage for customizing your OSD deployments.
Windows 7 Customizations
Over the last few years as a consultant I’ve had numerous engagements where clients wanted to customize the look/feel/settings in Windows 7. Different clients had different requirements around which customizations, whether it was permanent or a preference, etc. Below is a list of several customizations that I have helped clients perform. Many of these are found at various locations in forums, blog posts and Microsoft documentation. My goal is to gather these into one location so that it is easier for some of the more common (and for that matter some of the more obscure) customizations to be found. These are in no particular order. I will update this list from time to time. If you have any favorite customizations that you’d like to pass on, email me on my contact form and I’ll add them in. This post is REALLY long, so click the “Read More” link if you want to see the customizations.
UDI Application Weirdness
One of the really cool aspects of MDT 2010 Update 1 is the integration of what was formerly known as Modena…now named “User Driven Installation”. This provides a very slick looking wizard that can pop up at the beginning of a task sequence to allow for customization of the OSD process. There is a lot of functionality there around computer naming, domain/workgroup joining, OU selection, adding a user to the local admin group, language selection, and others. The feature that most of my clients are interested in however is the ability to customize application deployment for apps that are not in the image (Project, Visio, Acrobat, etc).
There has been one aspect of this that has caused issues on multiple occasions that I figured was worthy of a detailed blog post. The issue comes up if you use the default configuration file (UDIWizard_Config.xml) as your starting point when you run through the UDI Wizard Designer. After customizing the applications section, you still see the default applications screen when the wizard runs…either using the “Preview OSDWizard” command or running it in a Task Sequence. What you see is:
Digging into that default XML file shows us why this issue comes up. First you will notice that one of the “Preflight” checks that is performed is the “Application Discovery” check.
This allows you to configure app replacement in a re-image scenario (i.e. if Office 2007 is installed, install Office 2010…if Acrobat 9 is installed, install Acrobat X…if EditPlus is installed, install Notepad++). This really is a cool feature. However…if you haven’t configured this aspect it’s not necessary to run the check, so you can just delete it. However…deleting that from the Preflight does not clean up the other references to it in the XML file. If you edit the XML directly you will notice the following lines down in the Application configuration section. Note that there is still a reference to the AppDiscovery preflight check.
<Page Name="ApplicationPage" Behavior="enabled">
<Applications Link.Uri="preflight\AppDiscovery\AppDiscoveryresult.xml" TsAppBaseVariable="PACKAGES" RootDisplayName="Applications">
Removing the reference in the “Link.Uri” attribute resolves the issue. That section should look like:
<Page Name="ApplicationPage" Behavior="enabled">
<Applications Link.Uri="" TsAppBaseVariable="PACKAGES" RootDisplayName="Applications">
After doing so, you will see the customized application section that you configured using the wizard:
Subscribe
Recent Comments
-
The Realm of the Verbal Processor 