ConfigMgr 2012: Package Conversion Manager (PCM) & Readiness State
In today’s post, I wanted to take a little bit of time to build a bit deeper on the underlying principles of the “Readiness” state for Package Conversion Manager (PCM) as it is the fundamental to understand. My colleague, Cameron King, outlined in his blog titled “Package Conversion Manager Readiness States & Rules” the actual reasons one package/program might end up in a particular rule.
What I wanted to take a moment today and explain is the design principles taken in building these states, and how they relate to you the ConfigMgr administrator. Let’s get started…
Understanding Automatic: Seamless Migration w/ No Intervention
The driving principles of automatic is to provide as fast of a migration as possible with as limited user interaction possible. This might seem rather “obvious” but there are some key decisions we made as an engineering team that drove the behavior behind automatic. I want all administrators using the tool to understand these decisions as they hopefully will expedite your understanding of PCM & it’s states.
The rule behind automatic is we only display status and that we provide no options to the end-user to change it’s behavior. Thus, automatic is seamless and singular in it’s purpose. We store in ConfigMgr the state, as well as the date we analyzed it, and based on this we decide whether to re-analyze or just convert immediately. In either event, we do check that nothing on the source has change otherwise we will re-analyze and remove it if it still isn’t automatic.
Furthermore, the moving of package & programs to the AppModel doesn’t provide support in automatic to move any collection queries because this *should* require decisions on a package-by-package basis.
The key to understand about Automatic is that it is focused on fast, and no user-interaction.
Getting Started: Converting Automatic Packages & Programs
To start, the first step as an administrator is to start the analysis to find what packages & programs are in the automatic readiness state. The analysis process is, along with any automatic, is a multi-select option for any administrator. Thus, you can select all your packages for analysis and make a decision by filtering those that are automatic and converting them using multi-select.
Let’s walk through doing this…
Analyze
To analyze, you do the following-
- Click Start, Programs, System Center 2012, Configuration Manager, Configuration Manager Console
- After opening the console, and connecting to your 2012 site, click Software Library
- Click Packages
- Highlight the package you’d like to analyze by clicking once. This exposed the Ribbon options as well as the right-click experience as shown below
- Click Analyze
- The package, assuming it meets all the rules, should now show automatic
- Highlight the package and select Convert Package
- To convert, click Ok to start the conversion process
- Click Ok at the confirmation screen
That’s it. The package, program, and the associated settings have been migrated to the AppModel. To confirm this, you can click on the Applications node and verify that there is a application named the same as the converted package and click Deployment Types and see the actual content.
In a later post, I will outline what properties we are currently looking at and moving as part of the conversion process. For now, the most common package/program attributes are moved.
Bring Collection Intent over with Automatic Packages
As we mentioned, automatic was designed to move administrator’s packages/programs as quickly as possible. We made this design decision deliberately. However, we don’t force administrators to always use the “Convert” functionality for automatic, instead, allowing the flexibility to choose whether to use “Convert” or “Fix & Convert” – what does this do?
This allows administrators to make a decision on a package-by-package basis whether to potentially move collection intent from advertisements & collections. As you’ve learned, Global Conditions & Requirements are an important part of the AppModel and if you’ve spent the time putting intent (e.g. 500 GB hard drive space, Vista, or some other embedded intent logic) then we should offer the ability to bring this over.
To do this, you will do the exact same as above though at step 7 you will choose Fix & Convert. You, for most situations, can click next through the wizard experience except when asked to choose collection(s) to move the intent. This screen is shown below.
As you can see, you are given the option of selecting the requirement that you’d like to bring over or you can select all to move. This list only shows the applicable query objects that PCM is looking at. In a later post (in the fix & convert post), I will share more details around what intent objects we look for and will bring over.
That’s it, when you do the conversion you will see that we create a custom Global Condition and a requirement rule is attached to the deployment type for the application.
Global Condition:
Requirement:
Summary
In today’s post, I wanted to spend some time explaining the design of Automatic and then I walked your through the conversion process of an automatic package & program. The purpose of automatic is to spend as little time needed to go from un-analyzed to converted and we feel this has been accomplished.
Beyond this, we provide the flexibility for admins to choose whether to do an automatic conversion. Upon completion of the conversion, we will then show this package as Converted and can choose to delete it or retain for your “records.” Check, that application is done.
Enjoy!
Thanks,
-Chris