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.
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.
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.
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.