Well today was the second meeting of the SCOM 2012 CEP on 23 August.
This time we had the pleasure of seeing Nishtha Soni and Rob Kuehfus present jointly and answering questions at the same time. It was a nice team effort to see.
Here are some of the notes I made during the session. Some entries are just things that were noted during the session and do not always belong to the topic at hand at that specific point in the presentation, but are valuable to know anyway.
So the topics:
Install prereqs for software were discussed. There is good documentation out there already on the product so it is good to check up there for any OS and software related prereqs that might be needed.
Running through the installer.
There is no separate prereq checker anymore, it is included in the setup wizard.
A change is that you can now pick a remote SQL server right from the setup on another server (like the MS you are installing on). It does a lot of checks in the background, for instance to see if the full txt search is installed.
In SCOM 2012 the datawarehouse is now a requirement, not optional.
There is an option to create a new datawarehouse or you can use an existing datawarehouse from a different management group. Keep in mind that with using one datawarehouse for several management groups you can not go over supported limit of number of agents to the datawarehouse.
Configuring accounts comes together on one screen. It does validation of these accounts.
The sdk and config account needs local admin on all management servers. SQL rights get set during install.
You get the choice to create a new mangement group or add to an existing management group. Select the operationsmanager database that belongs to this management group.
Multihoming
SCOM 2012 agent talking to SCOM 2007 R2 management group is supported.
SCOM 2007 R2 agent talking to SCOM 2012 management group is not supported.
The SCOM 2012 agent deployment will upgrade an existing 2007R2 agent and multi-home the agent if you are at the same time creating another mnagement group. For instance during beta it is best to create a second SCOM 2012 beta management group next to your SCOM 2007 R2 management group if that one is still monitoring and have your agents multi-homed.
Upgrade SCOM 2007 R2 to 2012 beta upgrade paths
If you have SCOM 2007 SP1 you can move to SCOM 2012 RC when it is released. Not to SCOM 2012 beta. Towards SCOM 2012 beta upgrade is only from SCOM 2007 R2. It is possible to go from SCOM 2007 R2 to SCom 2012 beta to SCOM 2012 RC and from there to SCOM 2012 RTM. Direct from beta to RTM is not supported. Later direct upgrade from SCOm 2007 R2 to SCOM 2012 RTM is possible. Look at the picture below:
32 bit management server is not supported for upgrade. All machines need to be 64 bit. Check that all components are SCom 2007 R2 and 64 bit.
In this case Rob starts explaining with a management server to upgrade to SCOM 2012. The trick to the story is to first update management servers and gateways and agents over to 2012 versions and only at that point run the upgrade on the RMS (which will also upgrade the databases). When upgrading a manageneht server, agents will go into pending state to push agents. You can also do this with all MS and GW and agents. It is backward compatible.
What is left is the DB’s and RMS for the full upgrade.
If you do not upgrade this way and you do the upgrade of the database it will use a different schema and agents will not understand it if they are an older version.
The setup will check if all MS and GW are at SCOM 2012 level otherwise it will block the upgrade of the RMS/DB. It will also notify you for old agents, but no hard block there.
After the upgrade is ready everything will be SCOM 2012. Just the old R2 consoles will not connect to the SCOM 2012.
After this step you can upgrade the reporting server. And upgrade the webconsole. Keep in mind that when upgrading the web console it will actually be removed. There have been too many changes to it. So first remove and install the new Web Console.
If you have a clustered RMS (or if the RMS doesnt conform to standards – for instance when it is 32 bit machine) you can run the upgrade from the secondary Management Server. This will remove the old RMS from the management group. After this the old RMS cluster can be shutdown. This is an easier proces than to promote another and decomission the cluster from SCOM.
The RMS emulator.
Where you run the management group upgrade from will become the RMS emulator. This is only for backwards compatibility for management packs that target the RMS. Exchange 2007 and 2010 mps are examples of this and they will publish a list of known MP’s with similar targetting.
There are flow diagrams for the beta upgrade process. Available on Technet. This is very nice indeed. All steps will have links to the relevant Technet pages. Using the flow diagram will help you avoid reading too much as well, which is a bonus! Best advice is to use they diagrams when upgrading.
As the post is getting kind of long I decided to split it into two parts. You can read part 2 of this story over here.
Have fun!
Bob Cornelissen
