There is much to tell so let’s start.
Like any other update, preparation is crucial so:
- Backup both SCOM SQL databases;
- Make a snapshot of the VMs running the Management Servers.
This way there is way back when things turn sour.
Now, download all the update components for UR#2. Say what? You downloaded them some time ago already? Nice! Delete them and DOWNLOAD them again. Simply because I’ve heard that the update bits have been updated as well…
This isn’t very exciting actually. Just follow the procedures outlined in KB2929891 and you’ll be fine, basically meaning this order of updating:
- Firs the SCOM 2012 R2 server infrastructure:
- Management server or servers
- Gateway servers
- Web console server role computers
- Operations console role computers
- Apply BOTH SQL scripts (one for the OpsMgr database and the other for the DW);
- Manually import the management packs.
- Apply the agent update to manually installed agents, or push the installation from the Pending view in the Operations console.
So that’s easy isn’t it? Yeah, it SHOULD be but as already stated by other bloggers, like Stanislav Zhelyazkov, there are some serious caveats to reckon with…
The caveats and the work arounds
Ouch! Guess QC slipped (again) at Microsoft. Cloud is top priority and anything else comes second .
- Agents AREN’T updated through the Console
Yes, that’s bad. The Console tells you the pushed Agents were updated successfully BUT they aren’t! For now the ONLY work around is to run a REPAIR and now the pushed Agents will be updated. I am not the first one sharing this information but please spread the word!
- SCOM Gateway Server doesn’t update the Agent staging folder
This is an old one, already present in old updates for SCOM 2007 R2. And it seems it’s back! Basically it means that the folder containing the Agent installers for the Windows Servers AREN’T updated. So this requires a MANUAL copy & paste action (can be scripted) of the related MSP files to the correct folders on the Gateway Servers…
- Agents running APM require a REBOOT of the whole server
Bummer! An old one as well (in SCOM 2007 R2 this was introduced with UR#2 or UR#3 and fixed in UR#5) and now it’s back as well. And this is REALLY bad. Work around? Postpone the reboot to more suitable time frames…
UR#2 isn’t bad on itself. But again QC has slipped here and introduces the three earlier mentioned issues. IMHO these issues SHOULD have been avoided and not put onto the plate of the customers. Therefore always WAIT a few weeks (at least) before rolling out updates like these.