Packaging OpsMgr 2012 R2 Agent WITH Update Rollup in ConfigMgr 2012

Background

About 6 months ago, I wrote a 2-part blog series on deploying OpsMgr 2012 R2 agents using ConfigMgr  (Part 1, Part 2). Since then, Update Rollup 1 and Update Rollup 2 has been released. Because UR1 did not include agent updates, I didn’t have to patch any agents. The most recent release of Update Rollup 2 does include agent updates, I’ll have to get the agents patched.

For me, and the project that I’m working on, this is a perfect timing, UR2 was release right before we production transitioning our newly built OpsMgr 2012 R2 management groups and we are just about to start piloting, so I have quickly patched all OpsMgr 2012 R2 management groups with UR2 and from agents point of view, UR2 would now become part of our baseline (for now).

I have determined that the best way for me to incorporate UR2 agent updates to the current agent application in ConfigMgr is to somehow “Slipstream” the update into the agent install. This is due to the size, nature of the environments, and the release management and patch management policies that I can’t comment on.

When I said “Slipstream”, OpsMgr 2012 agents UR updates can’t really be slipstreamed into the agent install msi. So what I have done is to create an application in ConfigMgr that will install the agent AS WELL AS the update.

I’ll now go through the steps I took to setup the ConfigMgr application object.

Instruction

Note: The steps I took are largely the same as the Part 2 of the original post. I will only go through the changes I have made based on the original package rather than documenting it again from scratch.

1. I firstly duplicated the ConfigMgr source content of the original agent application to another folder.

2. Placed the agent UR2 updates in the AMD64 and i386 folders:

AMD64:

i386:

1. Place the newly created “CM12_OM12AgentInstall.vbs” on the root folder:

Note: Please ignore the other 3 scripts in the above screenshot, they were from the 2007 package I created in the original blog post Part 1. They are not required here.

1. created an identical application as described in Part 2 of the original post. -Of course, the application name is changed to something like:

1. Modify the deployment type for the 64 bit machines:

Remove “\AMD64” from the end of the content location field.

Change the installation program from the “msiexec /i ….” to Cscript /nologo CM12_OM12AgentInstall.vbs “64-bit”

1. Modify the 32 bit deployment type the same way as the 64 bit one:

Remove “\i386” from the end of the content location field and change the installation program to Cscript /nologo CM12_OM12AgentInstall.vbs “32-bit”

1. Distribute it to appropriate DP and test it!

Conclusion

The script used for the installation basically installs the MOMAgent.MSI and then UR2 agent update. It can be modified for installing other previous and future agent UR updates by changing the file names on line 59 and 64

When the application is deployed to a ConfigMgr client, the script creates few log files under C:\Temp:

Same as my original post Part 2, the application package does not configure agents to report to any management groups. This is because in my environment, there are multiple management groups, so I am using ConfigMgr Compliance Settings (aka DCM) to configure the agents. this is also documented in the Part 2 of the original post. If you’d like use the same application package to configure the agent, you can simply modify the CM12_OM12AgentInstall.vbs to also combine with the OM12AgentConfig.vbs that I’ve created in Part 1 of the original post. or create a separate application package and specify the dependency between these packages.