Upgrading System Center 2012 Components to Service Pack 1

Near the end of January I was performing an upgrade to my demo lab for System Center 2012 to SP1 so that I could perform a demo for a client wishing to see Service Manager SP1. Of course, another benefit is that it helps ensure the process works so I can better assist my customers when doing it “for real”!

For me, one of the more exciting parts of this was the fact that the System Center Operations Manager (SCOM) agent could now be installed on the Service Manager servers.

I took the opportunity to start examining the route required to upgrade, and the first disappointing discovery was that there was no stand-alone service pack installation. One of the reasons I had held off on the upgrade was that it appeared the only available media was the application(s) WITH SP1. I reached out to a contact I had met at TechED 2012, and asked about it. At that time, I was informed "one was coming, but not yet publicly released". I prodded a couple more times that first week, but no further information, or links, were available. To date, there has not been one made available that I am aware of. You can still download the media from MSDN or TechNet.

It's important to note, there is a specific path of upgrade that needs to be followed due to the complexity and inter-twining of the components. There are a number of blogs and documents out there to perform this. I followed the official order and documentation from Microsoft (https://technet.microsoft.com/en-us/library/jj628203.aspx) without any issues.

In my lab, I run several components and servers, so I needed to perform my upgrade in the following order:
Orchestrator
Service Manager
Data Protection Manager
Operations Manager

The upgrade was very easy and presented no issues. It was afterwards that I started to experience some interesting challenges!

As mentioned, one of my main goals was to configure SCOM to monitor Service Manager using the agent. For my Service Manager environment, I have 3 servers: 1 Management Server, 1 Data Warehouse Server, and 1 SharePoint Server hosting my Self Service Portal. Up until this time, my SharePoint server has not been monitored due to the SSP being installed on it. After the upgrade, I did not check to see if the agents were installed, or needed configuring, on any of the SCSM servers. I opened my SCOM console and deployed the agent to the 3 servers requiring monitoring. The results were not what I had expected. The agent deployed to the DW server, failed on the SharePoint and management server.

To me, the documentation did not seem clear. I read it over again to determine where I had gone wrong. After searching the document over for the word "agent" and re-reading about the installation, I determined the agent was supposed to have installed with the upgrade. I checked the management server, and indeed, it appeared to have installed. The SharePoint server with the self-service portal did not install, and the push to the DW worked.

After further digging around the internet, I found one bit of information that appeared to say that if it wasn't working, to reinstall the agent, with a suggestion of how to do it. I typically begin my troubleshooting by examining the event viewer on the server in question. I found several interesting events about the configuration of SCOM and how the server couldn't report back. The first error (event ID 2000) shows up as an error, the second and third as informational.

To me, event ID 20063 was the most important indicator here. This led to the ultimate understanding and solution.

When configuring SCOM, it appears that the only way to get the Service Manager agents to check back in is through the configuration of AD DS. I had not originally configured this as I share the AD services of my lab with the remainder of the company, thus it's not really "mine" to play with as needed. After a bit of digging, I figured out that this did need to be done. I worked with our IT Ops people and we configured it. Within 10 minutes, the Service Manager servers started checking in correctly. Even though the DW agent was checking in, I felt it best to keep the servers configured the same, and removed the manual agent configuration. In short order, the AD policy configured the server and everything were on track.

Another important thing to mention is that the SharePoint server has not been configured with a SCOM agent yet. The documentation indicated that the agent would be installed with the media, so I reinstalled the SSP again. For the SSP, the SCOM agent does NOT install with the SP1 media. Once the Service Manager component is installed on the SharePoint server, there is no means of installing the SCOM agent. The methods I tried were to install from the media (again), reinstall the portal, push the agent from SCOM, and to pull the agent via a manual installation command.

I am aware that if you had previously installed the SCOM agent on a server, you could then install a Service Manager component, but not the other way around. I had not done this as it was not required in my original configuration, and I had been aware of the support in SP1.

My next steps are to remove the self-service portal, install the SCOM agent and then reinstall and reconfigure the SharePoint portal.