OpsMgr 2012: Powershell Cmdlet Get-MonitoringPropertyValue removed – but how to get these values now?

Some OpsManager 2007 cmdlets have been removed in OpsManager 2012. But what if you used those in your scripts?
You will need to replace them.

One example is the cmdlet get-monitoringpropertyvalue. Where you can read values OpsManager has stored in a property.

Here is a script that shows how this value can be read within SCOM 2012:

$computername = “servername.abc.de”
$class = get-scomclass -Displayname “Classname”
$agent = get-scomclassinstance -class $class | where {$_.Displayname -like $computername}
$prop = $agent.getmonitoringproperties() | where {$_.Displayname -like ‘Propertyname’}
$agent.getmonitoringpropertyvalue($prop)

General Operations Manager 2012 upgrade tipps

Here are some general tipps if you upgrade or plan to upgrade from Operations Manager 2007 to 2012.

1. Supported configuration
   If you recognize that your servers do not meet the required supported configurations, then do not upgrade windows. I would recommend to build a new machine and move the role to the new server.
2. Operations Manager 2007 PowerShell snapin
   If you have PowerShell scripts running in your management packs, that utilize the Operations Manager 2007 snapin, then check that the snapin is still available on the upgraded servers.
   Open Powershell and enter get-pssnapin -registered. If you see the following lines then you can use the OM2007 cmdlets.
   Name: Microsoft.EnterpriseManagement.OperationsManager.Client
   PSVersion: 1.0
   Description: Microsoft Operations Manager Shell Snapin
   Otherwise you will need to register the snapin (also possible on management servers!).
   You will need to copy the files from a om 2007 server with the operations manager shell installed.
   You can follow this blog:
   http://derekhar.blogspot.de/2007/07/operation-manager-command-shell-on-any.html.
   You will get more time to update your scripts and management packs if you can use the old snapin in the meantime.
3. AD Integration
   If you use AD integration in your environment then check your agents after the upgrade! I saw some strange behaviour.
   Agents that are multi-homed lost their AD integration setting. The manual added management group entry was still in there but the AD integration checkbox was empty.
   Servers with the operating system Windows Server 2003 SP2 could not read the SCP entries anymore, so we had to switch them to manual configs.  The error looked like this:
   Event ID 2000
   Source: HealthService
   Description: The Management Group failed to start. The error message is: The environment is incorrect (0x8007000A). A previous message with more detail have been logged.
   There was no previous message. Microsoft had no reason for that.
4. Agent Error: Management Group cannot be saved
   
   I had this error (the management group configuration could not be saved) on one machine when I entered the management group information manually and clicked on apply. The solution was easy: Reinstall the agent. It looked like that the upgrade was not really successful.
   If that does not help try to delete the following registry keys and restart the healthservice.
   HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\[MG name]
   HKLM\System\CurrentControlSet\Services\HealthService\Parameters\Management Groups\[MG name]
5. Fix Bug: https://systemcentertipps.wordpress.com/2012/12/17/scom-2012-upgrade-bug-health-service-ping-diagnostic-fails/

How to solve empty ENU display names of user roles in Operations Manager 2007 R2?

To upgrade Operations Manager 2007 R2 to version 2012 all user roles need to have display names in the ENU locale. Otherwise the upgrade fails.

The following blog describes how to find out if all user roles have the correct display names: http://blogs.technet.com/b/mihai/archive/2012/05/23/know-issues-when-upgrading-from-om-2007-r2-to-om-2012.aspx. For non default roles it is also possible to open up the user roles in a console which is installed on a machine with the ENU locale and simply change something in the description. This also creates the missing ENU display strings.

In our environment we had something strange.  A default role “Operations Manager Report Security Administrators” had no display name. How can I solve that, because I cannot delete the role?

Go to SQL server management studio and run the following command against the OpsManager DB:

select * from Localizedtext where LTValue like ‘%Operations Manager Report Security Administrators%’

The result only shows entries from the DEU languagecode. So update the entries with the following query:

update LocalizedText set LanguageCode = ‘ENU’ where LTStringId = ‘50585907-7858-4488-AB9C-13E0EAAC08BE’

Now the language code is set to ENU, which is supported and the upgrade should run without a problem.

How to get an AD integrated SCOM agent to connect to the correct management server?

What if you have an ad integrated SCOM agent, that has received the AD policy correctly but still tries to connect to the old management server?

How can this happen?

During the upgrade of SCOM 2007 R2 to SCOM 2012 it can be that you need to move your agents to other Management servers, because the old ones do not  meet the requirements. So you change your agent assignement settings, but not all agents fall over to the new servers. Why?

It could be that the ports are not opened correctly if they are behind a firewall. Example: the new management servers were added to the rules, but the old ones got removed also. So the agent cannot connect to the old servers anymore. In our scenario I saw that the AD cache entries in the registry were not updated correctly after the upgrade to 2012. So I had to change that manually to connect to the new management servers.

Scenario:

Management Group: XY
Old management servers: OldMS1.abc.de, OldMS2.abc.de (still on SCOM 2007R2)
New management servers: NewMS1.abc.de, NewMS2.abc.de (SCOM 2012)

You will see the following error in the OpsManager event log of the agent, because it tries to connect to old management servers which are not part of the 2012 environment anymore:

Event Type: Error
Event Source: OpsMgr Connector
Event ID: 21006
Description:
The OpsMgr Connector could not connect to OldMS1.abc.de:5723.  The error code is 10061L(No connection could be made because the target machine actively refused it.).  Please verify there is network connectivity, the server is running and has registered it’s listening port, and there are no firewalls blocking traffic to the destination.

How to solve that?

First step is to stop the “System Center Management” service (Healthservice).

Then open up the Registry through regedit.exe and change the entries in the following keys:

HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\XY\AD Cache\Primary SCP Info\Service DNS Name

Old entry: OldMS1.abc.de
New entry: NewMS1.abc.ad

HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\XY\AD Cache\Secondary SCP Info Root\Secondary SCP Info 1\Service DNS Name

Old entry: OldMS2.abc.de
New entry: NewMS2.abc.ad

HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\XY\Parent Health Service\AuthenticationName

Old entry: OldMS1.abc.de
New entry: NewMS1.abc.ad

HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\XY\Parent Health Service\NetworkName

Old entry: OldMS1.abc.de
New entry: NewMS1.abc.ad

Now you can start the “System Center Management” service (Healthservice) again.

The agent should now fail over to the new management servers.