Promotion of Objects Part 2

Last week I started this series of posts by looking at why managing the promotion and change management around releasing ConfigMgr objects is important for some environments such as in banking and other high risk industries. Today we will be looking at how we can perform this promotion technically.

Before we look at the solutions available to us from a technical perspective, I just want to share a quick diagram of exactly what we want to achieve here.

Outline Diagram

I know this diagram is very simple but diagrams personally always help me visualize how things will work. So basically we are defining promotion here as lifting an object from TEST_CM1 and putting it in PROD_CM1. This object could be an applications, package, driver package, boot image or task sequence and all it’s related content.

The dotted line could be a physical network boundary if the client has segregation between test and production or it could be two domains in the same forest or anything like that. In all the future labs and publications I will show you everything will be on the same physical network but the domains will be separate with trust down from production to the test environment but test will not trust production.

Technical Solutions

When I was initially thinking about this process it was pre-SP1 days so at the time we could not use the built-in functionality of connecting the migration utility to another ConfigMgr 2012 SP1 hierarchy. So as well as that, we have other options available to us.

  • PowerShell
  • C#
  • Orchestrator

We could use PowerShell for instance kick off the migration job in a Windows task scheduler job by looking at the SMS_MigrationJob WMI class. We could also use the PowerShell cmdlet’s in SP1 to initiate an Export/Import job in PowerShell.

We could also use something similar in C# but use a bit more intelligence and maybe a database backend to keep track of the migrations. However for this series I want to keep it simple and more importantly supported by the vendor.

This leaves us with some PowerShell scripting and some work in Orchestrator to kick off the migrations.


So now we have some outlines of what we can do technically, part 3 and part 4 will look at using PowerShell and Orchestrator respectively to complete these tasks.


Tags: , , , , , , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: