When running multiple OpsMgr Management Groups sharing the same Data Warehouse, the MP Reports do not deploy and aren’t to be seen in the OpsMgr Console.
This happens in OpsMgr SP1 and OpsMgr R2.
KB962967 describes this issue and has a hotfix for download.
How to go about it? There are multiple ways to address it. I will describe one workable solution for it.
Be aware that this process has to be scheduled on the RMS and causes some overhead. However, when the RMS is reasonably dimensioned it shouldn’t be any problem.
| param ($rootMS) #Initializing the Ops Mgr 2007 Powershell provider |
| $Alerts = get-alert -criteria 'Name = ''Script : Failed to login''' | Where {$_.ResolutionState -eq 0} |
Now this script has to be put in the right folder and scheduled on the server. I will not explain that since I presume one knows how to go about it. However two more advises:
Example script can be downloaded here (ChangeResState.ps1). You know the drill: it is provided as is, no warranties, test it first in a test environment before putting it into production…
This posting will give advise in order to get filled reports. Some of it will be very obvious but sometimes the most obvious is ignored. Therefore sometimes it will be like ‘Duh! Like I Didn’t Know That!’ but please bear with me. 
1: Report Details Pane: Read it!
The Report Pane is divided in five sections. Four of them are important for the reports: On the top left there is the Report Tree, based on the imported MPs (that is when the MP contains reports). On the right side is the Actions Pane. In the middle top section are the available reports per imported and selected MP shown. The section on the bottom is called Report Details.
And this section is the most neglected one, while it contains very useful information about the selected report. Not only what type of information the report shows, but also what the report needs in order to get filled and also what type of objects need to be selected. Let’s take a look at this screenshot, taken from the Windows Server 2003 Operating System MP, report ‘Disk Performance Analysis’: 
There is a Summary to be found, describing how the report works, the header ‘How to use this report?’ what objects to select, the header ‘What parameters are offered?’ tells how many parameters are available in this report and the last header ‘Configuration’ tells what needs to be in place in order to get a filled report.
Not every report shows all these headers. Besides that sometimes not all the displayed information is complete, but at least it gives you the direction where to look.
2: ‘Add Group’ vs. ‘Add Object’
When a report is selected, a new window is opened. It shows the available options for the report AKA the Parameter Area. Here one has to select the group or object(s) which the report has to run against.
But beware. There is a significant difference between both options. Where 'Add Object' option just adds an object - nothing less and nothing more -, the 'Add Group' option adds all contained classes (= objects) within that group.
Take a look at these examples.
First I choose as object a server (normally a server isn’t selected as an object but I do it here to make a point), SRV01. Here only the server object will be chosen. Look at the column 'Include'. Is states that it only contains the object SRV01. Nothing more. 
When running a report, it ends up empty: 
However, when I select the ‘Add Group’ option, and select the same server as well (SRV01), it will also add all contained classes (=objects) by that group: 
When running a report, it will be filled: 
When running a Report it is better to use the ‘Add Group’ option and select the server(s) with the Object Class ‘Windows Computer’. This way the report will most of the times be filled because Windows Computer has a parent relationship to almost all other classes, also the class needed to get a filled report.
3: Using the Microsoft Generic Report Library
Default in OpsMgr there is the ‘Microsoft Generic Report Library’ available. These reports are easily to be customized to the organizational needs & requirements.
Cameron Fuller has written a very good article about how to create a Free disk space report. Of course other counters and performance objects can be selected as well.
Take some time to experiment with it since it is certainly worthwhile the time taken for it.
One of them is the needed size of the databases for OpsMgr. It depends on the count of Agents reporting to the OpsMgr environment and the time the data will be kept in the databases. For the Operations Manager DB this is default 7 days and for the Data Warehouse DB (used for reporting) this is default 400 days.
During the installation of OpsMgr the initial size of the databases has to be set. It is important to get it right from the start since it will create a single, arranged and unfragmented file where as later changes can fragment it which may cause performance problems in the future.
Gladly enough there are multiple good sources to be found which will aid you in estimating the needed sizes of these databases. I’ll list them here.
However, there is theory and practice. For the latter check out this thread on the TechNet OpsMgr forum. Here Kevin Holman gives some good advises how to go about it. Absolutely worth while to be read.
But also hardware is very important. Check here for hardware guidance for OpsMgr.
When everything is installed and working properly, it still needs attention. Kevin Holman (who else :) ) has written some good postings about it. Look here for these postings.
The start for both versions of OpsMgr (SP1 or R2) is the same: start an elevated command-prompt. Afterwards it is different:
Now the OpsMgr Agent installation wizard will start.
Source: OpsMgr Forum, this thread.
Taken from the MP guide itself:
MP to be downloaded here.
Even though the R2 Console allows a direct import of this MP via the web service catalogue, it is better to download the MP, unpack it (for example with a MSI-packager program as I blogged about) RTFM in order to get a full understanding of what this MP does and than to import it.
Many times the cause is to be found in KB954049 which also has some prerequisites to comply with of which most hotfixes do match the hotfixes as mentioned in the other KB article.
On top of it, people ask me when to install these hotfixes, or better, with what OpsMgr (server)roles. Actually, these hotfixes (if applicable) need to be installed for any OpsMgr server role or Agent.
With answering the question what hotfixes to install the version of OpsMgr comes also into play, as well the SP level that Windows 2008 is on.
With two tables I hope to clear things up. But first take a good look at #1:
| W2K08 before SP2 level | W2K08 on SP2 level |
| KB951327 KB952664 KB953290 | All the in the left column mentioned hotfixes are included in SP2 for W2K08. So they don’t need to be installed. |
| W2K08 before SP2 level | W2K08 on SP2 level |
| Besides the earlier mentioned hotfixes in the first table, also KB951116 is needed. | All the in the left column mentioned hotfixes are included in SP2 for W2K08. So they don’t need to be installed. |
So when running OpsMgr R2 on Windows 2008 servers at SP2 level, none of the mentioned hotfixes (for OpsMgr or Windows 2008) is needed.
Want to know more about SP2 for Windows 2008?
One of them is Graham Davies and he is from the UK. He has great knowledge on OpsMgr and every thing related with it.
Until recently he didn’t have a blog. But that has changed. Go check it out since it is a good blog with many good postings and links to other articles and interesting ‘need-to-knows’. His blog is to be found here.
I have already added him to my personal blog roll.
The following Connectors are included:
27-07-2009 Update: By accident I gave the wrong hyperlink to the online MP guides of Microsoft (Advise # 5). This is corrected with this update.
Importing a new MP or updating a MP which is already present, is not something to be taken lightly. When this is not properly done it can cause the OpsMgr administrators many additional hours of work.
With OpsMgr SP1 one had to download a msi-package containing the needed MP, unpack it and than import it. Even though it seems like a lot of work, there is one advantage: the related MP guide is also to be found in this msi-package. Of course, one still has to READ it.
With R2 MPs can directly imported from the Console itself. But this way, no MP guide is to be found. So this new functionality can cause a lot of additional work when not done properly.
Here are some advises how to go about importing new MPs or updating existing ones. These advises are viable for OpsMgr SP1 and R2 environments.
On Friday the 24th the new SQL MP has been released, version 6.0.6648.0. This MP mainly resolves issues with monitoring clustered SQL servers.
Kevin Holman has written a very detailed posting about it where he also writes about the undocumented features.
Advise: read his posting first, afterwards the SQL MP Guide included with the msi-file containing the new SQL MP, before importing this MP into your OpsMgr environment.
Even though the R2 Console allows a direct import of this MP via the web service catalogue, it is better to download the MP, unpack it (for example with a MSI-packager program as I blogged about) RTFM in order to get a full understanding of what this MP does and than to import it.
Before I start first some history about Reporting.
The Beginning
In MOM 2005 it was already present, also as an ‘extra’. However it worked much different compared to OpsMgr nowadays.
First of all, it wasn’t ‘real-time’. The database used for MOM 2005 Reporting got filled by an automated process which queried the MOM 2005 Operations database on a daily schedule (default at night). So when a report was run, it showed data which was at least a day old. And we all know that IT can change within a day, so sometimes these reports didn’t live up to the expectations.
Besides that, the nightly process could be problematic and was prone to errors. Many times it didn’t run and needed attention.
OpsMgr Reporting vs. MOM 2005 Reporting
In OpsMgr there is a separate Data Warehouse which gets filled with data, along side the OpsMgr database itself and on a 24/7 basis. So the OpsMgr database isn’t queried anymore to get the Data Warehouse filled. Therefore the Data Warehouse has been constructed in a different manner in order to accept huge loads of data in a short time frame.
Besides the obvious advantage that filling the Data Warehouse has become an automated process which doesn’t need that much attention (when setup properly), it also provides near real-time reports. So what get’s in now, is to be found back in a report a bit later. That’s nice!
Another advantage is that the Data Warehouse can collect totally different information compared to the OpsMgr database. Where as the OpsMgr database is filled with operational information (how are the monitored servers/services doing?) is the Data Warehouse filled with statistical information (How did the servers/services perform during a specific timeframe?). This also enables to tell what a server/service will do in the future.
MOM 2005 reporting also had another issue. The reports were a bit static and didn’t leave much room for adjustments. So many reports were displaying information which didn’t always met up to the requirements set out by the organization. Also referred to as Wallpaper For the IT Managers. (It hasn’t a real function but makes it looks like the IT Manager is really involved.)
Whenever people wanted to run other reports they needed to dive deep into reporting and hoping that the information needed was really present in the database. If not, no report. Simple but frustrating.
With OpsMgr Reporting became way much more flexible which made the reports more spot on. However with enabling the OpsMgr user to get their reports as needed, a new challenge was created.
The OpsMgr Data Warehouse contains much information. Only the challenge became how to get it out? What class does one have to select in order to get a filled report? This challenge can translate itself in reports ending up empty. And no, that is not nice.
Object Picker
So one of the most heard complaints about OpsMgr Reporting is that they end up empty. Since Microsoft isn’t deaf they picked this one up as well. So in OpsMgr R2 the Object Picker module for the Reports is to be found.
The idea is good: it allows to show only the relevant classes of objects which are needed for a certain report. However, there is a small downside to it at this moment:
The list of supported classes has to be defined in the MP in order to take full advantage of the Object Picker.
Yep. You already felt this one coming: today not all Microsoft’s MPs do have this feature yet. But it will certainly come.
Where to find it?
The Object Picker is available under the button ‘Options’for the ‘Add Group’ and ‘Add Objects’ functions when making a Report.
and here is the Object Picker module: 
But as stated before, at the moment many MPs do not fully support this feature yet. This support will certainly come however.
So upcoming postings about this topic will show some tips and tricks in order to get filled reports.
First something about OpsManJam, taken directly from their site:
“On this site you will find unofficial management packs, management pack authoring tutorials and guidance, featured articles on everything OpsManager 2007, command shell scripts, and more.”
and
“The content on this site comes from Microsoft Consulting Services, Microsoft IT and the Operations Manager Product team. While the content that you will find here is not supported by Microsoft, it has been used in the field and is used everyday inside of Microsoft. Consider it to be useful tidbits from the experts.”
The updated extended MPs are:
| Item | OpsMgr SP1 | OpsMgr R2 |
| Simultaneous Operations consoles | 50 | 50 (*) |
| Agents reporting to a Management Server | 2000 | 3000 |
| Agents reporting to a Gateway Server | 800 | 1500 |
| Agentless Exception Monitored (AEM)computers per Management Server | 25,000 | 25,000 |
| AEM computers per Management Group | 100,000 | 100,000 |
| Multi-homed Agents | 4 | 4 |
| Agentless Managed computers per Management Server | 10 | 10 |
| Agentless Managed computers per Management Group | 60 | 60 |
| Collective client monitored computers per Management Server | 2,500 | 2,500 |
| Collective client monitored computers per Management Group | 10,000 | 10,000 |
| Agent Managed computers per Management Group | 6000 | 10,000 (*) |
| UNIX or Linux computers per dedicated Management Server | N.A. | 500 |
| UNIX or Linux computers per dedicated Gateway Server | N.A. | 100 |
| URLs monitored per dedicated Management Server | Unknown | 3000 |
| URLs monitored per dedicated Management Group | Unknown | 12,000 |
*: 50 Open consoles with 6000 total agents and UNIX or Linux computers per Management Group or 25 Open consoles with 10,000 total agents and UNIX or Linux computers per Management Group
It is all about MP authoring. Another good thing is Management Pack University. Even though it is aimed at developers working on building management packs, good things are to be learned here for OpsMgr users as well.
Go check it out!
But what if you have worked all your IT career with Microsoft products ‘only’? And don’t know much about ‘The Others’? Can get a bit scary huh? Gladly enough there is something like the internet so there are multiple good resources to be found how to go about it.
Here are some good resources:
Whenever new links are to be found I’ll update this posting with them.
In the event logs nothing is to be found. Removing the cache file of the Console doesn’t work.
Solution
All is well again. Now the Topology Views are functional again and the Diagram Views are also working.
At a site I was importing/configuring the native Exchange 2007 R2 MP. All just went fine. However, the mailboxservers returned errors when trying to run certain scripts.
The OpsMgr eventlog of these servers showed these events: 
Somehow the Exchange Snap-in ‘Microsoft.Exchange.Management. Powershell.Support’ failed to load. Strange. These servers had certainly the Exchange Management Tools installed.
So I ran some checks. And indeed the needed dll (Microsoft. Exchange.Management.Powershell.Support.dll’) for this snap-in wasn’t there at all. When I ran this PS-cmdlet ‘Get-PSSnapin –reg’ this is what I got:
Name : Microsoft.Exchange.Management.PowerShell.Admin
PSVersion : 1.0
Description : Admin Tasks for the Exchange Server
So the Admin snap-in was in place, but the other wasn’t. Than I started to ask questions (a bit late, duh!) and I was told the Exchange 2007 environment was still at RTM level…
So besides RTFM there is also AANP (Always Ask, Never Presume)
The MP is still in place but I have disabled certain aspects of this MP and put these into a special MP which is to be removed when SP1 for Exchange has been rolled out.
Here I will describe the way I approached it at a customers site which did the trick. Feel free to comment on it when you know some tricks as well. Keep me sharp!
First of all some history on OpsMgr. When it became RTM there were certain issues which needed attention. SP1 addressed these. And when applying certain hotfixes (check out this blogposting of Kevin Holman on this topic), OpsMgr became way much better.
So whenever there are certain issues with an OpsMgr SP1 environment check it’s patch level and double check it by looking into the file versions on the RMS, Management Servers and Gateways. For Agents this process can be automated. Check this posting of mine how to go about it.
Other items worth looking at are:
A nice View to build in the OpsMgr Console is a Performance View which shows the cpu usage of the process HealthService.exe. Alexandre Verkinderen (OpsMgr MVP) has written a good blogposting about it.
So whenever complaints about slow server performance do get in, with this View it is easy to checkout whether the OpsMgr Agent is the culprit.
17-08-2009 Update: In Step 4 the SRSUpgradeTool.exe is used. There are some bugs in this tool. Microsoft has acknowledged it and is working on a new version of this tool. In this blog posting of mine I write about and refer to a webpage of Microsoft where a workaround can be found.
In three previous blog postings I already wrote about the upgrade process:
This posting will tell the whole story together about how to go about it. In the end I will add certain aspects which I myself would do.
All steps described here are based on OpsMgr R2. If you are still on OpsMgr RTM/SP1 STOP NOW.
Step 1: Preparation
Every upgrade needs preparation, no matter how small or big the upgrade is going to be. When upgrading to SQL 2008 I see it as rather big from an OpsMgr point of View since no SQL = no OpsMgr.
So run validated backups of the databases and database server as well. To be safe, make backups of the unsealed MPs and the RMS. Better safe than sorry. When SQL Reporting Services is hosted on another server, backup this server as well.
Read Part I for some additional information.
Step 2: Pre-upgrade steps – SRSUpgradeTool.exe
When OpsMgr Reporting services is being used, before upgrading to SQL 2008, a certain tool has to be run.
This tool restores three config files which were backed up during the installation process of OpsMgr Reporting.This needs to be done. When the SQL 2008 installation detects the customized security extensions it will block the upgrade, until they are removed.
Run this tool (SRSUpgradeTool.exe) on the SRS server:
SRSUpgradeTool.exe /InstanceName:<SQLInstance> /Action:
PreSQLUpgrade
Now the upgrade documentation tells to restart SRS services and open Reporting Services Configuration afterwards. Don’t be alarmed when an error is displayed in that console. Check Part II for more information.
Step 3: Upgrading to SQL 2008
Upgrade to SQL 2008 NOT to SQL 2008 with SP1. If you do, the SRSUpgradeTool.exe won’t work anymore!
Read Part I about how to upgrade to SQL 2008 (do’s and don'ts) and where to find more information about how to upgrade to SQL 2008.
Step 4: Post-upgrade steps – SRSUpgradeTool.exe
Now the SRSUpgradeTool.exe has to be run once again, in order to update the registry entries for the installed components of OpsMgr Reporting to point to new SRS folder location.
Run this tool (SRSUpgradeTool.exe) on the SRS server:
SRSUpgradeTool.exe /InstanceName:<SQLInstance> /Action:
PostSQLUpgrade
Step 5: Post-upgrade steps - SRSUpgradeHelper.msi
Now the tool SRSUpgradeHelper.msi has to be run in order to place the OM reporting files on the new SRS folder and set the SRS configuration.
Run this tool (SRSUpgradeHelper.msi) on the SRS server:
SRSUpgradeHelper.msi DATAREADER_DOMAIN=<DOMAIN> DATAREADER_USER=<DATAREADERUSERACCOUNT> MGSERVER=<RMSSERVER> SRS_SERVER=SRSSERVER
Step 6: Install SP1 for SQL Server 2008
A good idea is to make a backup of the SQL server and related databases first before starting the installation of SP1 for SQL 2008.
Check Part III about an error message which might popup after the upgrade to SP1 for SQL 2008.
When all is well, everything is working correctly: SQL 2008 SP1 is up and running and OpsMgr is doing fine. To be sure, open the OpsMgr Console and go through it. Check whether all is working as it should.
Go to the reporting pane and make a report to see whether all is working.
Advise
So when all is OK, you want to monitor this SQL 2008 server as well since it is the heart of OpsMgr. When you haven’t already imported the MP for SQL 2008 remember to install SQL Distributed Management Objects (SQL-DMO) on the SQL server. Otherwise OpsMgr cannot monitor SQL 2008 Server.
In the MP guide delivered with the SQL MP there is a detailed explanation where to get this software and how to install it. Believe me after upgrading to SQL 2008 this is child's play. :)
Strangest thing was that only hotfix KB954903 got installed, but the others (KB957511 & KB958490) weren’t. No errors what so ever in the event logs.
Fix
So I checked one of mine test environments to see if there were any differences. And yes, there was. The problematic staging folder had an extra msp file for KB956240.
This is strange since this hotfix isn’t meant for Agents but for Management Servers only. In combination with this hotfix a sql-query has to be run on the OpsMgr database as well. However, none of it is OpsMgr Agent related.
So I removed those files (Q956240-x64.msp and Q956240-x86.msp) from the Agent staging folder and pushed an Agent to another server. Yes! All hotfixes got installed. Even double checked it by looking at the file versions.
This posting isn’t meant as a replacement for the guide included with this MP. So RTFM this guide since it contains lot’s of good and needed information about how to configure this MP.
Secondly:
This posting describes how to get the core-monitoring running based on normal privileges. The optional monitoring isn’t described here, nor the usage of a low-privilege action account. For that: RTFM.
Okay, let’s start.
Before importing the MP do this:
MPs are imported. Now what?
Start with an override on the discovery ‘Exchange 2007 Discovery Helper’. This discovery runs normally every 24 hours which is too long at the first time. When all is working properly the override can be removed. For now set the discovery to run every 15 minutes. Save the override in it’s own MP so you can later easily delete it, without effecting other overrides.
Now the components for core monitoring have been configured and the Views (State, Alerts and so on) are getting filled. Some time later the topology view is working as well. From here you can go further with configuring the optional monitoring components. This way you get the most out of this great MP.
Okay, it has taken a long long time before a native MP for Exchange 2007 came out. Having said that, this MP is not JASMP (Just Another Shitty MP) but of such a level that I hope it will become a standard for the way Microsoft builds it’s future MPs.
Why? Most rules/monitors are disabled by default. So when having imported this MP there is no need to disable/adjust all kinds of monitors and rules.
On top of that, the documentation makes a good distinction between core monitoring and optional monitoring. So one can choose – based on the organizational needs – what kind of monitoring is a must-have or a nice-to-have.
Those monitors are simply switched on – or built based on some new monitoring templates delivered with this MP – the others (the not wished/needed for) are simply left as they came: disabled by default.
With only the core monitoring options enabled (which are easy to configure) one obtains a very good monitoring view of the Exchange 2007 environment.
In another posting I’ll talk about the needed steps to get the core monitoring functional. Of course, RTFM (Read The Friendly Manual) is still needed.
20-07-2009 Update: Unfortunately increasing the WMI buffers doesn’t always help. So as a workaround a scheduled restart of the WMI-service can be created.
Many OpsMgr users are familiar with this Alert:
WMI Probe Module Failed Execution. Object enumeration failed. Query: 'Select Name, Shutdown, Paused from MicrosoftDNS_Zone'. HRESULT: 0x80041001.Details: Generic failure
I already blogged about it, thinking the recompiling of DNS MOF would do the trick. However, it didn’t. After some weeks the same alerts came back.
Gladly Kevin Holman blogged about it and it seems like it he has found multiple ways to troubleshoot it for good. For me the only thing left to do was adding more WMI buffer space as he describes in his blog.
Here are the related blog postings of Kevin Holman to be found:
and
All credits go to Kevin Holman for these postings. All I want to do is to give it more exposure.
In my test environment the installation of SP1 for SQL 2008 went smoothly. Soon I got the message the update operation had completed successfully: 
But when I started the OpsMgr Console, or better tried to start it, I got all kinds of errors. The OpsMgr eventlog of the RMS was even worse: only errors to be seen and sometimes a warning. Nothing informational what so ever.
When trying to start SQL Server Management Studio I also got errors and wasn’t able to connect to the SQL Server instance.
This was not good. So I backtracked it to the first error in the OpsMgr event log of the RMS and this is what I found:
Login failed for user '...'. Reason: Server is in script upgrade mode. Only administrator can connect at this time
So apparently the update process was still running even though the screen stated otherwise.
After a couple of minutes the OpsMgr eventlog of the RMS started to show progress: less errors and warnings and more informational events.
When I started the OpsMgr Console it showed no more errors and it was functional again. Also SQL Server Management Studio became operational.The OpsMgr eventlog of the RMS only showed Informational events.
So whenever running the installation of SP1 for SQL 2008 be aware that – even after the message the update has run successfully – there are still some updatescripts running in the background. As long as these are running, no additional connections are allowed, thus causing OpsMgr to become non-operational. After some time (minutes) all is well again.
Microsoft has written a good solid KB about it. To be found here: KB321185. Always handy queries like these.
For instance, when upgrading the SQL Reporting Services part of OpsMgr R2 to SQL 2008, a tool (SRSUpgradeTool.exe) has to be used BEFORE and AFTER the upgrade to SQL.
When running this tool before the upgrade the document states that afterwards it has run successfully, SQL Reporting Services service has to be restarted. Than Reporting Services Configuration has to be opened in order to verify the configuration.
But when Reporting Services Configuration is opened and one has connected to the right instance this is shown:
At first my alarm bells went off. Oops! Something has gone wrong! Nothing in the Upgrade guide mentions this. But when googling I found this about this tool:
This (the tool) will basically restore the three config files we backed up during the initial installation of OM. This is necessary because SQL 2008 install detects are custom security extensions and blocks upgrade until they are removed.
Aha! So this is by design and can be safely ignored. Phew! So this is a potential pitfall to be reckoned with.
Only question I got is why the Upgrade guide doesn’t mention this at all? It could save people time and worries…
KB972821 tells what to do.
In an upcoming blogposting I will go into the technical details about this upgrade process like the needed preparation, the order in which to perform the upgrade and so on (I found one of mine OpsMgr test environments to be running on SQL 2005 so this is a good candidate for this upgrade).
But before that I want to have answered, or better, try to answer this question – which is very important –
Why upgrade to SQL 2008?
Actually there are multiple reasons, some are business related:
Other reasons are technology related. SQL 2008 has not only enhancements to features already present in SQL 2005, but has also a whole lot of new features like these ones:
Besides reasons to upgrade to SQL 2008 there might be valid reasons not to do so.Like third party MPs with related databases and it’s vendor doesn’t support SQL 2008 (yet). Another valid reason might be the SQL server itself: it is hosting databases for other applications as well which don’t support SQL 2008.
As with every other upgrade, preparation is the keyword. And testing it – after a good solid upgrade plan has been written – is also very important.
Nowadays with virtualization a good testlab is easily built: P2V the SQL server, P2V a DC (needed for authorization), P2V the RMS and put these three virtualized servers in their own VLAN, completely separated from the rest of the IT environment. Snapshot them and off you go. If you wreck anything, find out why, rewrite that part of the upgrade plan and test it again until all is OK.
Some helpful links:
However, this can be a process which takes time and not be done within a day. In order to keep a good overview of the OpsMgr Agents which aren’t at R2 level a simple State View within the Monitoring Pane can be built. This way one has a quick view of what OpsMgr Agents still need an update.
Steps to build such a State View:
Example of the View:
Tip: to ‘catch’ Agents with lower Agent Versions as well, one can use this Criteria Description instead (without the quotes): ‘6.0.%’. This way OpsMgr RTM Agents will be shown as well.
After the upgrade I checked all OpsMgr eventlogs and found nothing not to be OK nor dysfunctional at any level. Tested the ‘home-grown’ MPs, monitors, reports and all is still working.
So the upgrade process from R2 Eval to R2 Full Version is a bit dull. :)
Of course I do know that most OpsMgr upgrade paths will be from OpsMgr SP1 to OpsMgr R2 (Full Version). But until now I haven’t run there into a snag as well, as long as one takes the time needed for the preparation for the upgrade and takes notion what Microsoft has written down into the online upgrade guide.
For the weeks to come I will upgrade multiple customer sites from OpsMgr SP1 to OpsMgr R2. When there is something noteworthy to be notified of, and the customer agrees with having it put on this blog, I’ll let you know.
Check out these links to ‘know-it-all’:
Suppose you have an environment with multiple Management Groups and are using Multi-homed Agents. When the upgrade to R2 is started, there is a change these Agents will be of an older version than one or more of the Management Groups they have to report to.
So will these Agents be able to communicate with the upgraded Management Group(s) or not? To answer this question Microsoft has released an easy to understand graphical representation of the possible mixes and whether or not it will work:
More information to be found here.
22-09-2009 Update: Travis Wright (Senior Program Manager Lead on the Service Manager product development team) has left a comment referring to a blogposting of himself about the WHY behind the name change of these services. Check it out here. Thanks Travis for your feedback.
Cameron Fuller has already posted about it. But since I do get many questions about it, I have decided to post it as well in order to give it a bit more exposure.
With R2 the OpsMgr service names have been changed. This is pure cosmetically since the underlying processes are still the same. The table in this posting displays the name changes.
| OpsMgr – RTM/SP1 | OpsMgr R2 |
| OpsMgr SDK Service | System Center Data Access |
| OpsMgr Health Service | System Center Management |
| OpsMgr Config Service | System Center Management Configuration |
HOT HOT HOT !!!
Thursday evening late I got this from the OpsMgr forum : 
It will take about 48 hrs to replicate to all MVLS locations. Checked it out myself. At the moment we are downloading it.
HOT HOT HOT !!!
But on the OpsMgr community an interesting thread popped up: a member - Alain Cote – has built his own HP EVA MP Performance MP. And he is sharing it with everyone.
I haven’t had the time nor the hardware to test it, but the community is very positive about it. So go and check it out yourself.
An OpsMgr MVP, Alexandre Verkinderen, has blogged about, to be found here.
All credits go to Alain Cote. Keep up the good work!
