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.
– 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
Date: 2/7/2012 10:49:06 AM
Event ID: 4618
Task Category: None
Error occured on database connection:
ODBC Error: 207
ODBC State: 42S22
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name ‘DescHash’.
Statement: create procedure spInsertString
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.
This posting is provided "AS IS" with no warranties, and confers no rights.