Issues with OpsMgr 2012 R2 Upgrade When Management Servers are Load-Balanced

27/01/2014 Update:

A colleague of mine advised me the rsreportserver.config file for the SSRS instance also needs to be updated according to this Technet forum thread. I have updated this article reflecting this additional step.

I just came back to work this week after a 4-week holiday in China. Today I have upgraded work’s OpsMgr 2012 SP1 DEV management group to R2.

I firstly upgraded all 3 management servers, they all went smoothly without problems. but when I tried to run the upgrade for the Report Server and Web Console server (2 separate servers), both servers failed the prerequisites check with the same error:

image_thumb[1]

It’s saying that the management server the report server / web console server is pointing to has not been upgraded.

We have setup a F5 NLB VIP for all 3 management servers, and all management servers are indeed upgraded successfully. The Report Server and the Web Console server are pointing to the NLB for the default SDK (DAS) service. The OpsMgrSetupWizard.log on the report server shows the prerequisite checker cannot connect to the management server:

image_thumb[4]

To workaround this problem, I had to point the report server and the web console server to a particular management server (instead of a NLB address), run the upgrade and then point them back to the NLB address. To do so:

On the Report Server:

1. Change the registry string value “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Reporting\DefaultSDKServiceMachine” from the NLB address to a management server FQDN.

2. Restart SQL Server Reporting Services

3. Run the Upgrade

4. Change the registry value back to the NLB address.

5. Restart SQL Server Reporting Services

On the Web Console Server:

1. Change the registry string value “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center Operations Manager\12\Setup\WebConsole\DEFAULT_SERVER” from the NLB address to a management server FQDN

Updated 27/01/2014:

2. Edit “<SQL SSRS Install Dir>\Reporting Services\ReportServer\rsreportserver.config” file, change the “ServerName” value under the <Security> and <Authentication> tags to the NLB address.

SSRS

2. Edit “<OpsMgr 2012 SP1 Install Dir>\WebConsole\WebHost\Web.Config” file, change the “managementserver name” value within the <connection> tag from the NLB address to a management server FQDN

image_thumb[6]

3. Open a command prompt as administrator and run “iisreset” to restart IIS.

4. Run the upgrade

5. Change the registry string value back to the NLB address.

6. Edit “<OpsMgr 2012 R2 Install Dir>\WebConsole\WebHost\Web.Config” file, change the “managementserver name” value within the <connection> tag from the  management server FQDN to the NLB address (note the location of this file has changed after the upgrade).

3. Open a command prompt as administrator and run “iisreset” to restart IIS again.

After the upgrade, I verified both reporting and web console is working by running a report and logging onto the web console.

7 comments

  1. good article. just a off comment – I have typical high speed internet, and you page load time is very slow…

  2. Also – curious why anyone would setup a F5 NLB VIP for management servers? Are they not naturally load-balanced?

  3. The management server is essentially a proxy for user sessions accessing the SDK, which in turn submits queries to the database and returns the result to the client – it doesn’t do much work in this role from a user session perspective. I’m wondering if load-balancing user sessions to the SDK provides any value? If it’s to provide a common name for users, then aren’t there simpler solutions?

    1. the SDK service is also used for report server, web server and any 3rd party scripts / tools. the SCOM 2012 Unleashed book explained it in details. you can also use Windows NLB, which is a feature comes within the OS, there’s no additional cost for it.

      1. I consider those user sessions, too – there is no core management group processing there. Anyway, I know where you are coming from, and I’m not trying to convince anyone that it’s a bad idea to load-balance. I would be interested in seeing some statistics that could prove benefits of load-balancing the SDK.

        Thanks for the great info you provide on your blog!

        1. For us, from end user point of view, we are dealing with various support teams that have limited knowledge in System Center. We can advice them once the console has been pushed out to their PCs, they can connect the consoles to the NLB address (like currently in 2007 R2, they are connecting to the RMS cluster). This will ensure they’ll always able to connect as long as not all management servers are offline, and the SDK connections are spread across multiple management servers.

Leave a Reply

%d bloggers like this: