So I just stumbled upon this and thought I’d share…

When developing a Management Pack, it is considered best practice to declare Classes using the following format:

Microsoft.Office.Communications.Server.2007.ServerRole

What you will notice is the inclusion of a full-stop (.) to seperate the key words in the Class name above. I won’t go into why, but suffice it to say it has it’s purpose ( FYI, the “FriendlyName” would generally be Microsoft Office Communications Server 2007 ServerRole).

Whilst on a consulting gig recently, I discovered and interesting anomaly in the OCS Management Pack that caused some issues.

Background

My client utilises EMC Ionix as a “Manager of Managers”, thus all alerts from OpsMgr are fed up to it via a connector. Ionix then applies alert filters based on the Class derived from each alert (hopefully that makes sense).

The Symptom

After importing and tuning the Office Communication Server 2007 Management Pack, we failed to see any alerts appearing in Ionix despite alerts being raised within OpsMgr.

The Solution

Upon investigation, I discovered that the Class naming convention within the OCS MP uses an underscore (_) rather than a full-stop (.). Using the class above as an example of a properly formed class, the convention actually utilised in the OCS MP is Microsoft_Office_Communications_Server_2007_ServerRole. This applies to ALL declared class!

I know this is generally not a big deal, unless of course you are relying on uniformity of the class naming convention. We had a few options (export, alter, increment, seal and import the offical MP), but in the end we were able to alter the filtering within Ionix to account for this (Ionix was replacing the underscore (_) with a space, thus striping out everything after the first underscore).

Exciting news in the world of tech books… I spotted a Facebook post by Marcus Oh announcing that Amazon are now accepting pre-orders for the upcoming release of System Center Opalis Integration Server 6.3 Unleashed. There is a long list (by book standards) of contributing authors including one of the hardest working women in IT, Kerrie Meyler; 2 Technical Evangelists from Microsoft (Mark Gosson and Charles Joy); and 3 guys best known for their work within the  System Center Operations Manager community, MVPs Pete Zerger, Marcus Oh and David Allen.

I have to admit, the lineup of authors for this book almost guarantees quality and clarity.

Get in early and reserve your copy… I have!

Get the book on either Amazon.com or Amazon.co.uk

dir cert:\currentuser\my | Where-Object { $_.hasPrivateKey } | Foreach-Object { [system.IO.file]::WriteAllBytes(“C:\Certs\$($_.Subject).pfx”, ($_.Export(‘PFX’, ‘<PASSWORD>’)) ) }

You will need to change <PASSWORD> to a password of your choice.

This code is using the Subject as the file name and outputs to C:\Certs. The filename will include CN=, to remove this navigate to the folder containing the certificates and then run the following code:

dir | where{$_.name -like “*.pfx”} | foreach{move-item $_.name $_.name.replace(“CN=”,”")}

For those that can’t make it to the Microsoft Management Summit (MMS) this year, but want to know about all the news and product gossip then there is only one source you need to turn to, the System Center Podcast. Being launched at this years MMS, the System Center Podcast will be a monthly produced podcast featuring some of the most respected and knowledgeable MVP’s and experts in the community. The first episode will come live from MMS and will provide an analysis of the event, including Keynotes and product announcements. The panel will include Pete Zerger (OpsMgr MVP), Roger Zander (SCCM MVP), Maarten Goet (OpsMgr MVP) and Andy Dominey to name just a few.
We will be publishing more information about the who, where & when for episode 1 prior to MMS, so please visit www.systemcenterpodcast.com for all the latest details.
Designed to provide relevant and informative information about the System Center suite of products, the podcast aims to assist organisations with maximizing their System Center investment through sound advice and expertize from MVP’s and experts who bring a wealth of knowledge and a combined experience that is unparalleled.

Service Pack 1 (SP1) for Windows 7 and for Windows Server 2008 R2 is now available. This service pack is an update to Windows 7 and to Windows Server 2008 R2 that addresses customer and partner feedback.

SP1 for Windows 7 and for Windows Server 2008 R2 is a recommended collection of updates and improvements to Windows that are combined into a single installable update.

Windows 7 SP1 can help make your computer safer and more reliable. Windows Server 2008 R2 SP1 provides a comprehensive set of innovations for enterprise-class virtualization. This includes new virtualization capabilities with Dynamic Memory and Microsoft RemoteFX.

Consumer end-users can find general information about Windows 7 SP1 at the following Microsoft website:
http://windows.microsoft.com/windows7sp1

I came across this issue earlier this week when attempting to install OpsMgr R2 on an instance of SQL 2008 R2 Reporting Services. There are actually a couple of symptoms that are related to this issue.

Symptom 1

During the setup you are presented with a dropdown list asking for the instance of Reporting Services that you want to use. After selecting the instance and clicking next, setup will freeze (I have tested this and left it running over night).

Solution 1

I found that if I killed the msiexec.exe process (using approx. 78Mb RAM), setup would continue.

Sympton 2

After inputing the remaining information, the setup would start but ultimately fail with the following message box:

Solution 2

This info comes from Microsoft KB 2425714:

On the SQL Server Reporting Services server, rename the local group SQLServerReportServerUser$<hostname>$MSSRS10_50.<SQLInstanceName> to SQLServerReportServerUser$<hostname>$MSSRS10.<SQLInstanceName>

Most organisations have a process for decommissioning servers. Some have it documented and implemented as policy, while others take a more ad-hoc approach. Whichever method you employ, when implementing OpsMgr in your environment, you must give some consideration to the decommissioning process within OpsMgr.

As one of the final steps in the decommissioning process, you should log in to the OpsMgr Console and under the Administration tab, Agent Managed you should right click the server in question and select Uninstall. This will remove the OpsMgr agent from the server, and conversely remove the server from OpsMgr. A point of clarification, whilst the agent is removed from OpsMgr, the data is retained in the DataWarehouse database until all data is purged based on your data retention policy.

By including these steps in your Decommission process, it will assist in maintaining a clean console (fewer greyed out agents) and will also assist in reducing management overhead and licensing costs.

If however, you find yourself as I did, faced with the situation were you have several hundred decommissioned servers (in my case over 600) that still exist in OpsMgr, then you have a mammoth cleanup task ahead of you. You could do it the long way and remove them individually from the console but hey, we’re in IT right?! A quick Google search and I found a couple of resources that go some way to doing what I need, but fall short of a one stop solution. SO, when all else fails, do-it-yourself!

Below is a script that will check if the server is truly decommissioned and if so, will remove it from OpsMgr. I don’t take credit for the whole script, as sections have been taken from a script originally created by Satya Vel. His post can be found here. I have made some modifications to his original script to accommodate the ability to read in a text file, verify the server is unavailable and to log the output. Other functionality included is outlined below (taken from the PowerShell script):

# —————————————————————————————-
# – Name:    Delete-Agent.ps1                                                            -
# – Author:  Dan Kregor (1E – daniel.kregor@1e.com | dan@kregor.net)                     -
# – Purpose: This script is designed to remove decommissioned servers for OpsMgr         -
# -                                                                                      -
# —————————————————————————————-
# -                                                                                      -
# – NOTES:                                                                               -
# – Original Script by Satya Vel | Program Manager | System Center Product Team          -
# – More info at <a href=”http://bit.ly/cnjVTL”>http://bit.ly/cnjVTL</a>                                                    -
# -                                                                                      -
# – Modifications: * Included step to check if server is still active (pingable)         -
# -                * Can use SQL, Text File or manually typed source                     -
# -                * Included a number of switches to suit different purposes            -
# -                                                                                      -
# —————————————————————————————-

<#

.SYNOPSIS
This script is designed to remove decommissioned agents from OpsMgr
(both the database and console). It will also test that the agent is offline.

.DESCRIPTION
This script is designed to remove decommissioned agents from OpsMgr
(both the database and console). It will also test that the agent is offline

.PARAMETER CONFIG
Use the -CONFIG switch to set the RMS, SQL Server and Database for both your
Lab and Production environments. This information can also be manually
updated by editing the Delete-Agent.ini file in the script directory.

.PARAMETER FILE
Use the -FILE switch to include a text file containing a list of servers.
Each server must be on it’s own line.

.PARAMETER AGENT
Use the -AGENT switch to manually enter the name of 1 or more Agent Managed
servers (see examples for more info).

.PARAMETER SQL
Use the -SQL switch to query the OpsMgr Database for Agents that have not
heartbeated prior to 30 days ago.

.PARAMETER PROD
By default, this script is designed to run against a Test/QA/LAB envirnoment.
Use the -PROD switch to run it against your Production environment.

.PARAMETER WHATIF
Use the -WHATIF switch to run the script without performing the delete action.
The script will populate the Log files but not take any action.

.EXAMPLE
./Delete-Agent -FILE “C:\temp\servers.txt”
Use the -FILE switch to read in a plain text file list of
servers. Each server must be on it’s own line within the
text file.

.EXAMPLE
./Delete-Agent -AGENT server.domain.com
Use the -AGENT switch to manually enter the name of a server
to be removed from OpsMgr.

.EXAMPLE
./Delete-Agent -AGENT server1.domain.com, server2.domain.com
You can also enter multiple servers to be removed. Servers must
be separated by a comma.

.EXAMPLE
./Delete-Agent -SQL
Use the -SQL switch to query the OpsMgr Database for Agents that have not
heartbeated prior to 30 days ago

e.g. If today is August 15th, it will look for Agents that did not
heartbeat prior to July 16th

.NOTES
Removing an agent from OpsMgr does not delete it’s historical data. All historical data
is kept in the DataWarehose database for the period of time as determined by your data
retention policy.

************************************** IMPORTANT **************************************

Your use of these items is at your sole risk.

All items are provided “as-is”, without any warranty, whether express or implied,
of accuracy, completeness, fitness for a particular purpose, title or non-infringement,
and none of the items are supported or guaranteed by 1E.

1E shall not be liable for any damages you may sustain by using these items,
whether direct, indirect, special, incidental or consequential, even if it has been
advised of the possibility of such damages.

.LINK

More information can be found at: <a href=”http://opsm.gr”>http://opsm.gr</a>

#>

You can download the file below. If you like the script or find any issues please provide your feedback in the comments section below.

Below are the symptoms I have seen, all of which were resolved by implementing the registry changes suggested by Patrick

SYMPTOMS

• The OpsMgr RMS appears as Greyed out or Unavailable.
• Alert Notifications are not being sent via the SMTP channel (other may be affected though)
• The following event appears a number of times in the Operations Manager event log:

  Event Source: Health Service ESE Store
  Event Category: Transaction Manager
  Event ID: 623
  Description: HealthService (<PID>) The version store for instance <instance> ("<name>") has reached its maximum size of <value>Mb. It is likely that a long-running transaction is preventing cleanup of the version store and causing it to build up in size. Updates will be rejected until the long-running transaction has been completely committed or rolled back. Possible long-running transaction:
  SessionId: <value>
  Session-context: <value>
  Session-context ThreadId: <value>.
  Cleanup:<value>

RESOLUTION

As Patrick has done a great job documenting the solution, I won’t reproduce his fantastic work. You can find the solution on his blog here.

I have finished coding v1.5 of the 1E System Center Watcher Service (OMWatcher) and have done some preliminary testing. So far… so good.

Some new features that are included:

• Support for clustered RMS (no remedial action is taken though emails are sent and events are logged)
• Checks the availability of the OperationsManager database (no action taken, email alert only)
• Checks if the RMS is in maintenance mode (no action taken, email alert only)
• Checks the status of the RMS HealthService [greyed out] (no action taken, email alert only)

I am now looking for people to assist beta testing this new version. Ideally I’m looking for people who can test it against a clustered RMS (all other features will work irrespective of RMS configuration).

If you are interested in helping, please indicate by leaving a comment below. By doing so, I will have your email address (required to comment) and will contact you once beta testing is ready.

From the official Microsoft techNet article:

The Microsoft System Center Operations Manager 2007 SP1 Cumulative Update 1 resolves many issues that are found in System Center Operations Manager 2007 SP1. A prerequisite for installation of the Cumulative Update 1 is installation of System Center Operations Manager SP1 Update (KB 971541 (http://support.microsoft.com/kb/971541/ ) ). Cumulative Update 1 addresses the following issues:

• The Active Alerts report from the data warehouse includes auto-resolved alerts that are no longer active in the Operations Manager Console.
• The Generic performance report consumes lots of temporary database space and can fail in some instances.
• The agents that are taken out of maintenance mode revisit old entries in the Application log in certain cases. When this occurs, incorrect alerts are generated.
• When Antigen Enterprise Manager (AEM) is set up to use SharePoint, reports from Watson are blocked.
• Reports for Operation Manager 2007 SP1 fail when you use a shared data warehouse after you upgrade a Management Group to System Center Operations Manager 2007 R2.
• Because of a thread-locking issue, the SDK service stops responding in certain cases.
• The color of the chart lines does not match the legend in Performance views when the Web Console is used.
• ACS stops collecting data when the event log uses auto-backup.
• The Alert View link in the notification emails shows the list of active alerts, instead of the detailed alert description.
• The allow anonymous discovery property in the Internet Information Services (IIS) Management Pack is incorrect in the console.
• Management Pack discoveries fail when a double-byte character exists in string data that is returned.

For more information and to download a copy, go to http://support.microsoft.com/?kbid=2028594