The road to Operations Manager 2012 – Upgrading ACS


Last Edited May 10th, 2012

These days are the days of System Center 2012 adoption, as I wrote in the past every product has its own upgrade and/or migration path. For Operations Manager 2012 the in place upgrade is a risky but viable solution to keep all your data. This post is about my experiences performing an in place upgrade of ACS infrastructures.

If you follow the upgrade guide for Operations Manager 2012 (http://technet.microsoft.com/en-us/library/hh205974.aspx) you know this is a bottom up upgrade. Since Management Servers (with the exception of the RMS) are the first infrastructure components to be upgraded, the ACS collector is probably upgraded at an early stage (remember it need to be installed on a MS). You can opt to delay the ACS collector upgrade since it is still a  separate component.

The ACS upgrade process is pretty simple, but troublesome.  Planning for the upgrade you must remember the following topics:

-          when the ACS collector is upgraded the database schema is upgraded as well, so you better have some database recovery plan in place. Given the average size of an ACS database this need some planning.

-          The ACS forwarders are upgraded at agent upgrade time, the collector is backward compatible so you can take your time. Nevertheless I advise to upgrade the agents as soon as you can.

-          If you’re using the xPlat ACS integrations you must remember to upgrade those as well, it’s a separate item in the install splash screen. There’s no auto-detection of installed modules implemented.

clip_image002[6]

-          If the ACS collector is also an ACS forwarder the update process will set the forwarder service startup to manual. You must manually set I t back to automatic and start the service

- Uprading the agent the ACS forwared gets disabled (oh yes) so  you need to track which forwarders are enbaled before the upgrade and re-enable them immediately after the upgrade

- If you set up a custom WMI query filter on the collector it will be lost, so you need to dump it before the upgrade and then reimport it when the upgrade has finished

In one occasion the ACS DB schema didn’t go as expected and it left my ACS infrastructure not operative. If this happens you’ll get the following error in the Operations Manager Event log

Log Name:      Operations Manager

Source:        AdtServer

Date:          2/7/2012 10:49:06 AM

Event ID:      4618

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      OpsMgr-SV.pre.lab

Description:

Error occured on database connection:

 Status:        0x0409C082

 ODBC Error:        207

 ODBC State:        42S22

 Message:        [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name ‘DescHash’.

 Database:        SqlWriter

 Connection:        Maintenance

 Statement:        create procedure spInsertString

    @iId                    in

Since the upgrade completed with success trying to upgrade again the infrastructure won’t solve the issue, to get rid of this you need to perform the following steps:

1.       Stop the ACS collector service

2.       In the ACS database identify the active partition with the following query: select PartitionId from dbo.dtPartition where status=0

3.       Run the following statement against the partition you got ion step 2.: alter table dbo.dtString_[PartitionID here] ADD DescHash binary(20);

4.       Restart the ACS collector service and check the eventlog for any error

As usual: totally unsupported do it at your own risk.

Another issue I’ve experimented is the DbCreatePartition.sql file not being upgraded (the file is located in c:\windows\system32\security\AdtServer), this causes the above error not only for the current partition, but for every new partition created. I suspect this can be related to the application of KB 2663919. If you find yourself in this situation you just need to copy the correct DbCreatePartition.sql file  from the setup folder (ACS\AMD64 in the OpsMgr DVD/ISO). And yes, you don’t need to apply KB 2663919 anymore, the issue has been fixed.

Eventually the team has implemented the constraint I suggested in this old post "ACS queries speed up", now query performances are pretty linear with the selection time window.

 

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

About these ads
  1. #1 by Daniele Grandini on March 15, 2013 - 7:09 am

    Glad to be helpful 😊

  2. #2 by Marie-anne on March 14, 2013 - 8:38 pm

    We were going thru the same situation as explained in your last paragraph below no.4 of this post
    after having applied cu7 on our scom 2007r2… It had nothing to do with KB2663919
    We realised that the cu7 update did not replace or copy over the DbCreatePartition.sql in\\windows\system32\security\adtserver folder and other .sql files that were manually modified for specifc reason. We found a copy of the dbcreatepartition.sql from the cu7.msi. So it is good to copy the adtserver folder content before doing an upgrade…
    Thank for the blog on the issue, it saved us problems

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 348 other followers

%d bloggers like this: