Today an interesting Community Evaluation Program session held by Chris Adams, Group Program Manager of the Configuration Manager 2012 team, about the package Conversion and Physical to Virtual Migration Toolkit for Configuration Manager 2012. First news was the fact that “CM CEP leader” Jeff Wettlaufer is leaving Microsoft to join RES Software. Good luck Jeff, we will see you arround at RES!

The agenda of today:

  • App Model 101
  • Migration: Getting to Configuration Manager 2012
  • Converting Application: The Options
  • Manual Migration
  • Package Conversion Manager (PCM

Application Model Diagram

 

  • Detection Method: how does the state based system determine how the app is installed
  • Requirement rules: whether or not the rules do apply for the application
  • Dependencies: chain applications on 2,3 or 4 other app
  • Content: content of the packages

2007 versus 2012 application feature mapping:

Configuration Manager 2007 Configuration Manager 2012
Package & Programs Application & Deployment Types
Advertisements Deployment
Collection Rules Global Conditions & Requirements
Run advertised programs Software Center
X User device affinity (UDI)
X Software Catalog

The Migration experience:

The migration of the legacy packages can be done in three different ways.

  • Migrating
    • Just migrate and use the legacy packages in Configuration Manager 2012
  • Manually convert
    • Convert the package by hand. Difficult process
  • Convert to applications with the Package Conversion Manager
    • Convert the packages with PCM

Migration process to Configuration Manager 2012

The migration process consists of the following phases, Plan, Deploy and Migrate. These phases have the following steps:

  • Assess your current environment
  • Test and proof your plan
  • Design your strategy for migration
  • Configure migration features
  • Enable distribution point sharing
  • Migrate objects
  • Migrate clients
  • Upgrade distribution points
  • Remove configuration Manager 2007 sites

Prepare your environment for the migration:

  • Utilize platform requirements
  • Use UNC path for source locations
  • Use only MSI’s with one unique PID

Migrate packages to applications

While migrating packages you have three options:

  • Do nothing (leave as package and program)
  • Manually convert application
  • Use Package Conversion Manager for conversion of the application

What is good for the application model?

User facing applications that are targeted to users based on the following deployment types:

  • App-v
  • MSI
  • EXE

What it not a good package to migrate to the new application model?

  • system maintenance tools (system based deployments)
  • end of life packages

Package conversion Manager:

  • Analyze & determine readiness to convert classic software packages to Configuration Manager 2012
  • Convert your packages & programs to Configuration Manager 2012 application model
    • Applications
    • Deployment types
  • Migrates machine collection queries to 2012 application model by building (in the future)
    • Global conditions
    • Requirement rules

Summarization feature is also going to be in the Package Conversion Manager.

Analyzing packages can be done in three different ways.

  1. For a single item, manually by the administrator
  2. Run in bulk, using multi select by the administrator
  3. Automatically during the conversion process.

Number 3 means you can run the analysis today and migrate the conversion weeks after the first analysis. During the conversion process another analyzing process is started.

PCM Analysis Readiness States

Before or after the analysis process the packages have a readiness state. The following states apply for the Package Conversion Manager.

  • Unknown: Analysis has not yet been run
  • Not applicable: not appropriate for the application model
  • Manual: needs user input for conversion from the admin (not enough data to perform an automatic migration)
  • Automatic: can be easily converted to the application model
  • Converted: has been converted to the application model

Analysis engine internals (understanding manual verses automatic rules in PCM)

  • Automatic:
    • Package contains only 1 MSI
    • No unconverted dependencies
    • Content is accessible
  • If one of automatic is false the package must be converted manual
  • Manual:
    • Must have content
    • Is software distribution package
    • Contains at least one program
  • If one of Manual is false than the application is not applicable

Detections methods (the main reason your package is manual)

  • Detection methods are important, if you have your detection method wrong you can experience the following:
    • Application will either always install
    • Application will never install
  • Can only be automatically derived from MSI’s
    • EXEs are manual
  • MSI’s with multiple product IDs
    • Pick the first one
  • Uninstall programs will be discorded
    • Automatically derived for MSI

Process of converting a package:

  • Go to application management
  • Go to packages
    • Select Package
    • Select analyze package
  • The Readyness will be updates
  • Select the package with automatic and click Convert Package
    • Analyzed again if the application is not changed
  • The package is migrated successfully

If not applicable check the information on the package conversion status:

For manual you can use Fix and Convert option, this will be in upcoming versions.

When a package has a dependency, the dependency needs to be converted first. The package is first manually; if the depended application is converted the other program will also be automatically converted. You can choose to use or not use the dependencies.

The conversion process: (understanding the conversion process)

Interrogates:

  • Package properties
  • Program properties
  • MSI

The conversion process moves or better translates the data to:

  • Application name
  • Deployment Type name
  • Detection method

Best practices for converting packages to the new application model:

  • Migrate the object
  • Create your applications in the lab
  • Test the applications in the lab
  • Export and import via the native CM 2012 function

If you don’t have a lab environment, you can off course use the Package Conversion Manager in your production environment.

Post migration actions:

  • Convert any dependency applications first
  • Concentrate on your user centric applications
    • Intention for application is user-based targeting
    • You want state-based enforcement
  • Keep tracking your effort (progress of the migration, reporting, charts)
  • Once converted check requirements to make sure they are sufficient

What’s coming up in the next PCM CTP2

  • Fix and convert
    • Helps converting manual packages
  • Bulk analysis
    • Run immediately after install
    • Analyzes all packages
    • Scheduling for analysis during non peak hours
  • Moving collection Query to the Application Model
    • Converting collection Queries
    • Program requirements ANDED with Global Conditions to create Deployment Type requirements
  • Reporting

P2V Migration Toolkit

One of the Configuration Manager 2012 migration goals is maximizing reusability of x64 server hardware. This goal can be accomplished by using the P2V migration toolkit.

The scenario:

  • Remote site server migration
    • Remote, branch office at which you need to persist Configuration Manager 2007 site server at the site during the migration process
    • Provides:
      • Limited local hardware inhibits side-by-side migration
      • WAN bandwidth prevents the utilization of centrally located server
  • How P2V migration Toolkit can help?
    • Eliminate
      • Eliminates the need for parallel physical servers at remote sites
        • Repurpose existing site servers into virtual instances
        • Host Configuration Manager 2007 & Configuration Manager 2012 sites on the same machine using virtualization
        • Simplify & Automate
          • Simplifies  & automates the creation of virtualization task sequence
          • Simple, intuitive user interface to create & deploy the task sequence
        • All the virtualization specified task sequence steps are built-in
        • Limited input needed by remote administrators

Requirements for virtualization

The following requirements are valid:

  • Hyper-v requirements
    • Requires a x64 processor
    • Bios must support
      • Hardware assisted virtualization (Intel VT or AMD-V)
      • Hardware Data Execution Prevention (DEP)
      • Intel XD bit or AMD NX bit
  • Virtual machines will not start unless HAV and DEP are enabled.

P2V Migration options

  • Task sequence with stand alone media
    • Creates a customized task sequence
    • The option automates the entire end-to-end process from OS rebuild to VM creation
  • Bootable media only option
    • Creates a bootable Windows PE disk (requires Windows 7 IAK )
      • Injects toolkit binaries
      • Loads networking stack
      • Launches VHD Capture Wizard
      • This is the capture only option

Task sequence workflow:

The best way to see the task sequence workflow is to view the slide.

The network stack is not migrated in the current version.

Physical to virtual components:

The best way to see the P2V components is to view the slide.

Considerations for P2V Migration Toolkit:

  • Minimum support bar for virtualization is Windows 2003 SP2 or greater (for hyper-v integration)
  • Drive encryption is not supported in the current CTP release
  • Task Sequence Designer requires the Configuration Manager Administrator Console in CTP release
  • WAIK is required for bootable media.

The P2V Migration Toolkit is not a replacement for the P2V in System Center Virtual Machine Manager.

Next session is a Question and Answer session about the Application Management in Configuration Manager 2012 with Brain and Craig and Chris.

Comments