Downloading Package Conversion Manager 2.0.1

Please visit the PCM Home page to get started or follow the links below to download PCM for any of the appropriate languages:

· English

· Chinese

· German

· French

· Japanese

· Russian

Getting support for PCM 2.0.1

PCM 2.0.1 will be fully supported through CSS just as 1.0 was.  This support will be valid for 1 year from it's release date.

Due to differences between ConfigMgr 2012 RTW and SP1 the same PCM code base needed to be compiled differently for these versions.  This means that the installer needed to determine which set of binaries to install on a machine based on the Configuration Manager console version.  To determine this the installer looks at the version of Microsoft.ConfigurationManagement.exe and then installs the appropriate set of binaries.  The installer is looking in the default location, %programfiles(x86)%\Microsoft Configuration Manager\AdminConsole\bin, for this binary and if it doesn't find it the installer still appears to install successfully.  However, PCM wasn't actually installed at all.

The Workaround 

Before I get into the actual workaround let me just say there have been a few people who I talked to about the problem and they all asked, "Do I really need to uninstall my console and reinstall it to the default location?"  No, you do not need to reinstall your console to the default location.  Yes, that will work, but we should be able to get it to work without reinstalling the console at all.  Currently the best workaround to get the appropriate set of PCM binaries installed is to copy the Microsoft.ConfigurationManagement.exe from wherever the console is currently installed into %programfiles(x86)%\Microsoft Configuration Manager\AdminConsole\bin (creating the directories if you have to) then run the installer.

We are still checking into our options, but in the meantime I hope this helps those of you that are running into this issue.

Thanks,

Cameron

System Center 2012 Service Pack 1 has been released.  This release of  Package Conversion Manager (PCM) supports that release.  PCM was originally released to support RTM of ConfigMgr 2012 and due to changes made in service pack 1 we had to update PCM. 

Download Package Conversion Manager 2.0 from the Microsoft Download Center today.

2.0 Changes

Although there have been a few bug fixes, the main difference between PCM 1.0 and 2.0 are small changes required to support ConfigMgr SP1.  However, some of these changes are not compatible with the RTM version of ConfigMgr 2012.  Despite this we have been able to get PCM into a single installer which supports both ConfigMgr 2012 RTM and SP1.  Therefore, you can use a single download of PCM for either RTM or SP1 for any of the languages which are supported.

Downloading Package Conversion Manager 2.0

Please visit the PCM Home page to get started or follow the links below to download PCM for any of the appropriate languages:

· English

· Chinese

· German

· French

· Japanese

· Russian

Getting support for PCM 2.0

PCM 2.0 will be fully supported through CSS just as 1.0 was.  This support will be valid for 1 year from 2.0's release date.

Package Conversion Manager (PCM) makes it easy to move to this new model by allowing you to convert your collection queries at the same time as converting your packages to app model applications. In this blog post we will walk through some examples of collection queries and program requirements being converted into global conditions or requirements and finally what the finished product looks like with requirement rules added to your application.

Collection Queries

First lets walk through a couple of collection queries which we will use to convert to global conditions and requirement rules and how these queries are chosen for conversion during the process. When an application is selected for the fix and convert process, Package Conversion Manager will interrogate the collections that the package's program(s) are deployed to in order to present the PCM admin doing the conversion with a list of queries which can be converted to global conditions and requirement rules.

Say for example there is a collection which contains a couple of queries used to populate the collection.

One for adding devices which contain 2 processors:

select R.ResourceID,R.ResourceType,R.Name,R.SMSUniqueIdentifier,R.ResourceDomainORWorkgroup,R.Client from SMS_G_System_COMPUTER_SYSTEM as G inner join SMS_R_System as R on G.ResourceID = R.ResourceID where G.NumberOfProcessors = 2

The other collection query for adding a computer with a specific name:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_SYSTEM where NetBiosName = 'pcmdemo'

Of course you probably have queries which are a lot more complex, but these are just a couple of simple examples of collection queries which can be converted. We will discuss how these queries will be converted when we discuss the fix and convert process below.

Note: Not all queries can be converted and I have added a few examples of queries which can't be converted in the FAQ section below.

Program Requirements

Now that we have briefly covered a couple of collection queries which can be converted let's talk about one other piece of information which can be converted. If you have set OS requirements on programs PCM will allow you to also convert these requirements to the app model. Below is an example of a program requiring any 64 bit Windows 7 OS which can be converted over to the app model. 

We will walk through how this requirement can be converted below when we walk through the Fix and Convert process.

Fix and Convert - How to move collection queries and program requirements to the app model

In this section we will walk through how the above collection queries and program requirement can be converted into global conditions and requirement rules using PCM's Fix and Convert wizard and where these requirements land in the app model after the conversion. Now let's walk through converting the above queries to global conditions and requirement rules at the same time as we convert a package and its program(s) to an application and deployment type(s).

The first thing you will do is find and select the package that you would like to convert to the application model. It is important to remember that collection queries are only converted to the app model while converting a package which contains one or more programs which are deployed to the collection containing queries. Likewise requirements will only get converted if a package's program(s) contain OS requirements. Of course you could also manually set these up, but PCM does this automatically for you when converting your packages to applications using the Fix and Convert Wizard. The important thing to understand is PCM doesn't provide a way to convert collection queries or program requirements outside of converting packages to applications. Additionally you may be thinking that the fix and convert wizard is only for converting those applications which are broken or have a state of manual, but this isn't always the case. If you want to convert your collection queries or program requirements into global conditions and requirement rules then you will need to use the fix and convert wizard.

Once you have identified the package that is tied to a collection query or OS requirement that you would like to convert you can select the Fix and Convert option from either the ribbon item or right clicking menu.

Walk through the wizard which will display until you get to the Requirement Selection page. From this page you can select each of the programs which will be converted to deployment types in order to select the collection queries and program requirements that will be converted to global conditions and requirement rules. Below is an example of the page which is displayed allowing you to select the different collection queries and program requirements available from each program.

From this page you can pick and choose which collection queries and Program Requirements you would like to convert during the conversion process. Once you select the queries and requirements you would like to convert and finish out of the wizard, PCM will create the applications, Deployment Types, Global Conditions and then add these as requirements to the converted Deployment Type(s).

Additionally if we look at the global conditions after the conversion process completes for the above application we can see that a custom global condition has been created from the NetBIOS Name collection query.

Additionally if we open up the converted application we can see that the collection queries and program requirements which we selected and created during the conversion process all show up as requirements on the application.

Note: If you analyze a package and it has a readiness state of automatic you will still need to use the fix and convert wizard in order to convert the collection queries and program requirements to global conditions and requirement rules. I know that I stated this above, but thought it was important enough to mention again. 

FAQ

In this section I have added a few FAQs specific to converting collection queries and requirement rules along with their answers.

Will PCM successfully convert multiple programs with different OS requirements and attach the appropriate requirements to the appropriate DTs which were converted?

When walking through the fix and convert wizard the requirement selection page will allow you to select a DT, which will be created from the program, and then allow you to select the requirements which you would like to convert and add to the deployment type's requirements. Yes, you can pick and choose which requirements to add to each of the deployment types and these will get added.

Which Collection queries will not be converted?

Here are a few examples of queries which won't get converted as they really don't tie to software requirements and shouldn't be converted to global conditions or requirement rules:

• Select * from SMS_R_UnknownSystem where Sitecode = 'abc'
• select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SystemGroupName = 'abc'
• select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where LastLogonUserDomain = 'Redmond'
• select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMSAssignedSites = 'ABC'

There are also queries which can't be converted as deconstructing the queries would be very difficult. One example of this type includes queries which contain multiple select statements.

Additional there are keywords which PCM doesn't support in queries:

• Sort By
• Ascending
• Descending
• Is Not Null
• Within
• Group
• In

What happens if I already converted a collection query to a global condition and then convert another package\program which is deployed to the same or different collection which contains the same query?

Regardless if a collection query is on one or multiple collections it will only be converted once. If you convert a second application which is deployed to a collection containing that same collection query the previously converted global condition will be added as a requirement to the converted deployment type.

• an analysis engine, bulk analyzer, Package Conversion dashboard which helps in determining the state of a package and where you are in the overall process of converting your packages to applications
• The PCM plug-in which helps convert custom script wrappers to applications
• And of course the conversion process - Convert or Fix and Convert

 With System Center 2012 SP1 Configuration Manager Beta being made available there is a new version of Package Conversion Manager. Please take a look below for the appropriate version of PCM to download and install.

Download

In order to install Package Conversion Manager the ConfigMgr console must be installed. To find out more about the requirements for the ConfigMgr console please take a look at the information found here. There is a version of PCM for ConfigMgr 2012 and a version for ConfigMgr SP1 Beta. So depending on the version of the Configuration Manager console which is installed will depend on the version of PCM you will need to download. The sections below outlines each of the downloads that are available for PCM.

PCM Download for System Center 2012 SP1 Configuration Manager Package Conversion Manager 2.0 Beta

System Center 2012 SP1 Configuration Manager Package Conversion Manager 2.0 Beta has released and is available from the download page here. There are no new features or functionality in the 2.0 version of PCM over the previous version, however as there were a number of changes made in System Center 2012 Configuration Manager SP1 Beta, which are incompatible with the previously released version of PCM, a new version of Package Conversion Manager was required to be released. If you have System Center 2012 Configuration Manager 2012 RTW then please take a look at the section below. It is important to note that this version of PCM is available in English only. 

To find out more about System Center 2012 SP1 Beta and the various files that can be downloaded take a look here.

PCM Download for System Center 2012 Configuration Manager  

If you have System Center 2012 Configuration Manager RTW you should not use the SP1 version above as it is not compatible, but instead should use the previously released version available here. As mentioned above there are no changes as far as features between the previously released version that is available in this section and the 2.0 version available above other than compatibility between consoles.

Additional Information

• For more information on PCM take a look at the information available from TechNet here in a previous blog post available here,
• In this blog post I provide a high level overview of Package Conversion Manager (PCM) as well as talk a bit about how you can migrate your packages from 2007 to 2012.
• To find out more on migrating objects from ConfigMgr 2007 to  2012 you can look here.
• To find out more about the various readiness states and the rules as to why a package would be set to a given state please take a look at this blog post.

I have been meaning to write this blog for a while. Through the UDI Designer there is no way to add additional stage or stage groups. However, this doesn’t mean that it can’t be done. This just means that you must do it manually.

It is a very simple process to add in additional stages or stage groups and once done you can use these stage groups or stages with the designer like any of the existing stage or stage groups and you can use stages with the wizard like any other stage.

To add in a stage group simply edit your configuration file in your favorite XML editor, copy and paste an existing stage group (these are all defined at the bottom of the XML) in the order you would like your stage group to appear among the other stage groups and then rename the stage group to something unique then save the config file.This same process applies to stages only stages should be copied under a stage group.

Example

Here is an example of how we would copy the Replace stage group and rename it along with its stages to make a new stage group and stages.

Copy the Replace Stage group and its Stages:

   1: <StageGroup DisplayName="Replace">

   2:   <Stage Name="REPLACE" DisplayName="Replace, in full OS">

   3:     <PageRef Page="WelcomePageReplace" />

   4:     <PageRef Page="ConfigScanPage" />

   5:     <PageRef Page="RebootPage" />

   6:   </Stage>

   7:   <Stage Name="REPLACE.WinPE" DisplayName="Replace, in WinPE">

   8:     <PageRef Page="UserCapturePageOldPC" />

   9:     <PageRef Page="ProgressPage" />

  10:     <PageRef Page="RebootAfterCapture" />

  11:   </Stage>

  12: </StageGroup>

Paste the stage group and rename it and its stages appropriately:

   1: <StageGroup DisplayName="Replace">

   2:   <Stage Name="REPLACE" DisplayName="Replace, in full OS">

   3:     <PageRef Page="WelcomePageReplace" />

   4:     <PageRef Page="ConfigScanPage" />

   5:     <PageRef Page="RebootPage" />

   6:   </Stage>

   7:   <Stage Name="REPLACE.WinPE" DisplayName="Replace, in WinPE">

   8:     <PageRef Page="UserCapturePageOldPC" />

   9:     <PageRef Page="ProgressPage" />

  10:     <PageRef Page="RebootAfterCapture" />

  11:   </Stage>

  12: </StageGroup>

  13:     <StageGroup DisplayName="MyNewStageGroup">

  14:   <Stage Name="NEWSTAGE1" DisplayName="New stage 1">

  15:     <PageRef Page="WelcomePageReplace" />

  16:     <PageRef Page="ConfigScanPage" />

  17:     <PageRef Page="RebootPage" />

  18:   </Stage>

  19:   <Stage Name="NEWSTAGE2" DisplayName="New stage 2">

  20:     <PageRef Page="UserCapturePageOldPC" />

  21:     <PageRef Page="ProgressPage" />

  22:     <PageRef Page="RebootAfterCapture" />

  23:   </Stage>

  24: </StageGroup>

In the above example line 13 through 24 shows the new stage group.

Once you have done this you can use the stage groups and stages as you could any other stage or stage group in the designer and wizard.

If you are using MDT 2012 Update 1 UDI and are configuring language settings, you may have run into the problem setting up your User Locale. In MDT 2012 Update 1 Beta the UDI wizard was setting InputLocale when it should have been setting UserLocale. As this was found at the last minute before releasing there was a workaround put in place in order to set the appropriate task sequence variable. Rather than changing this variable in compiled code which is a bit more costly and risky the workaround was added to the UDI Wizard script wrapper (UDIWizard.wsf). The script wrapper would simply read what the UDI Wizard set the InputLocale task sequence variable to once it exited and then set UserLocale to that same value.

Why is this a problem? It is a problem because the wizard was fixed in the released version of MDT 2012 Update 1, but the script wrapper was never fixed to remove the line which sets UserLocale with the value of InputLocale. So what does this mean? It means that the wizard sets the UserLocale correctly based on what the end user selects when the wizard exits, the script wrapper will then read InputLocale, which is no longer set, and sets UserLocale with this value. Thus UserLocale is always set to blank.

The Solution

Luckly this problem is very easy to fix. You simply need to modify the script wrapper, udiwizard.wsf file, in the toolkit package under the scripts directory and either comment out or remove the following line:
oEnvironment.Item("UserLocale") = oEnvironment.Item("InputLocale") 

Don't forget to update your distribution points on your MDT Toolkit package once you make this change.

Additional Notes about Language Settings

Variables used on the language page:

• Language pack to install: UILanguage
• Time and Currency Format: UserLocale
• Keyboard Layout: KeyboardLocale
• Timezone: OSDTimeZone

Language pack to install

Customer's have asked how do I default language options to the default language set on a machine. UDI doesn't provide any detection for determining which language had been set on a machine. However, it does provide a way to default to a language setting. So if you have added logic to a script you can simply set the appropriate task sequence variables prior to the wizard loading in order to default to those settings. The one thing to call out here is that the values used in task sequence variable must match the case of the values in the dropdown list in order to default to a value. In other words if you want to default to French for a language pack to install that language pack must be available in the list, and you must set UILanguage to FR-FR not fr-FR.

Keyboard Layout

Additionally if you wanted to set the keyboard layout to French for example you should set the KeyboardLocale variable to either 040c:0000040c or 0000040c. Do not set the variable to the following format 0x0000040c.

Enhancements and New Feature Details

• Support for Windows 8 and Windows Server 2012.
• Support for System Center 2012 Configuration Manager SP1 CTP: Added support in MDT for deploying Windows 8 and Windows Server 2012 with Configuration Manager SP1 CTP, while supporting all new Configuration Manager functionality (offline BitLocker, UEFI, and Assessment and Deployment Kit).
• Support for the DaRT 8 Beta: Updated MDT to support DaRT 8 for Windows 8 deployments, while continuing to support DaRT 7 for Windows 7 deployments. Added DaRT support for Configuration Manager scenarios.
• New “Build Your Own Pages” User-Driven Installation (UDI) feature: Enhanced the UDI wizard and designer to enable IT pros to design their own wizard pages with little effort.
• Other improvements: Added support for Windows PowerShell 3.0, reworked Roles and Features installation logic for Windows 8, improved “boot from VHD” deployment scenarios, and added support for Configuration Manager monitoring.
• And More... 

UDI Specific Features and Enhancements 

Now let's get into the details of the UDI enhancements a bit more. There is a lot to talk about here so I will just give a high-level overview and save the details for additional blog posts.

Windows 8 and  2012

With Windows 8 and 2012 releasing to PC OEM and manufacturing partners, more information for which can be found here for Win8 and here for Server 2012, we are excited to be able to support deployments of these operating systems as well as provide support for some of the key new features they provide. Of course UDI allows for backing up and restoring data using the newest version of USMT, but how about Windows 8 apps?

If you are using the Application Catalog and are using Configuration Manager 2012 Service Pack 1 (the SP1 is required for deploying Windows 8 apps from ConfigMgr) then you can take advantage of allowing users to select Windows 8 app package (.appx) as part of their OS deployments from the software page of the UDI wizard. Some of you may ask, but how is that going to work as the selected apps and packages will install as part of the task sequence which doesn't support installing Windows 8 apps as they need to install as a user. However, UDI tags these apps differently and doesn't attempt to install these types of apps as part of the task sequence. Instead it uses a tool called AppInstall.exe which interfaces with Configuration manager's app catalog in order to trigger an install for app model apps, including Windows app packages (.appx), after the user logs in. To hear more about how to setup applications as well as leverage AppDiscovery to detect applications for reinstall I have put together a video covering this topic here.

To find out more information about how to prepair for deploying these type of apps check out this blog post which talks about everything from how to sign the apps to the group policy needed in your environment for deploying these type of apps. 

Build Your Own Pages (BYOP)

Although I will talk in detail about BYOP in future blog posts and videos, the BYOP feature will allow you build pages by simply dragging a set of controls onto a page and setting the appropriate information around those controls such as which task sequence variable should be set or the default for the control. Controls which you can drag onto a BYOP page include CheckBoxes, ComboBoxes, Lines (used to section a page out), labels, radio buttons, Bitmaps, and textboxes.

Although there are any number of pages which you could build using BYOP you can also use this powerful feature with your Windows 8 deployments. As an example the simple page in the screenshot above is an example of how you could allow a user to select whether to enable pushbutton reset as part of their Windows 8 deployment which would allow them to rollback to a fresh version of their operating system if enabled. To see more information on push button reset see the following TechNet article here.

Start Using MDT 2012 Update 1 UDI Today

Put your users or deployment techs in the driver's seat by downloading MDT 2012 Update 1 and starting your deployments with UDI today.

In this video we discuss how to configure the Replace scenario for UDI which allows you to capture user state and data from your old PC and replace it on your new PC. The first part of the Replace scenario is configured in 2 stages called Replace and Replace.WinPE while the second part of this scenario uses one of the 2 New Computer stages to restore user state during an OS deployment to a New PC. For more detail on the New Comptuer stages discussed in this video check out the following blog covering the New Computer scenarios found here.

As part of this video we talk through what the minimum pages needing to be configured for the Replace stages. This really boils down to configuring the user state page if you would like to make capturing user state to network locations available to your end users. There are a number of factors which affect the user state page such as the mode the page is set to (capture or restore), environment the wizard is launched from (WinPE, or the full OS), and whether the format checkbox is checked or unchecked. These are outlined in this video and will be covered in more detail in a later blog. Additionally the user state page encrypts the user state data and hashes the directory the user state page is captured to when capturing to a USB or network location which is also discussed in this video.

In addition we discuss that you will have to have your applications configured and set with mappings if you would like to discover your installed applications on your old PC and have these default selected for reinstallation during a deployment on your new PC. For more information on how to configure software installation with UDI and setup Application Discovery to discover software for reinstall checkout the Application Discovery video in the UDI Video Series.

To help you get started in configuring the Replace Scenario please check out this video:

Configuring-MDT-2012-UDI-Replace-Computer-Scenario

One thing that was left out of this video was the option to prompt and format the USB drive from the user state page. This ensures that only one set of user state data is on the USB drive when capturing and restoring during an OS deployment. These options are available for configuration in the USB Combo Box on the User State (Select Target) page in the designer.

I hope you enjoy this video and please check back to see additional videos covering User Driven Installation.

Updated in MDT 2012 UDI Update 1: One of the things that was enhanced in Update 1 UDI was the ability to seperate the credentials used for connecting to a network location and the credentials used for encrypting the data and hashing the directory in which it is stored. In MDT 2012 these weren't seperated and caused problems when attempting to image multiple machines at the same time while using a network location for capturing and restoring user state. I will be putting together a seperate blog post on how this is configured in the future.

In this video we discuss how to configure UDI for New Computer scenarios used to deploy to bare-metal devices with no operating system installed on the hardware. The New Comptuer stages discussed in this video are also used in the second part of the replace scenario in which user state is captured from an old PC and replaced on a new PC. A blog covering the replace scenario can be found here.

As part of this video we talk through what the minimum pages needing to be configured for both the New Computer and New Computer.Prestaged stages are and what the diffences are between the two. This video doesn't talk through User Device Affinity (UDA), but I have put together a blog post available here discussing UDA. I will point out that UDA only works in the New Computer scenario however.

To help you get started in configuring either of these New Computer scenarios please check out this video: 

Configuring MDT 2012 UDI for Pre-Staged New Computer

Please check back to see additional videos covering User Driven Installation.