Tag Archives: MimboloveSCOM Update Rollup
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.
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.
01. I firstly duplicated the ConfigMgr source content of the original agent application to another folder.
02. Placed the agent UR2 updates in the AMD64 and i386 folders:
03. 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.
02. created an identical application as described in Part 2 of the original post. -Of course, the application name is changed to something like:
03. 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”
04. 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”
05. Distribute it to appropriate DP and test it!
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.
OpsMgr 2012 Sp1 Update Rollup 3 has been released for about a month now. Today I had some time after dinner so I thought it’s time for me to get my lab environment updated.
In the past, I’ve been updating the OpsMgr server roles manually and using ConfigMgr Software Update (SUP) to apply the agent and console updates.
While I was downloading the updates manually from WSUS (so I can manually update server roles), I noticed the console update is pretty big (621.5MB):
This is because it contains updates for different languages. If I manually download it, I’ll see a list of same update, for different languages:
As shown above, there are 2 updates for each language (both 32 bit and 64 bit). My environment only requires the English version (enu). so when I tried to download it in ConfigMgr, I only selected English. I noticed it took a bit too long to download over the ADSL 2 connection I have at home. When it’s done, the confirmation window shown it has successfully downloaded the update to the deployment package that I specified, for English Language only:
The update list I created in ConfigMgr only contains this one update, and the deployment package is brand new as well (does not contain updates from other update lists):
I then had a look at the package source folder for this deployment package and guess what?
it contains not only the English one, but also everything else!
For example, the first folder on the list contains the 32bit Russian version:
Looks like the OpsMgr 2012 Update Rollup updates do not honour the language selection in WSUS. This may not be an issue if all your ConfigMgr distribution points are connected to your site server over fast and reliable links and storage on your DP’s are not an issue. If the network link and the storage is an issue with your DP’s, this may be something you need to be aware of. Personally, I’d explore other options when next time I apply OpsMgr 2012 update rollup for console updates. On top of my head, I can think of two alternative approach straightaway:
- Package it up as a normal package in ConfigMgr.
- Since this update is in .msp format, I can easily create my own update using the System Center Update Publisher 2011 (SCUP) that is connected to my ConfigMgr 2012 SP1 hierarchy.