Hyper-V MP not discovering all Hyper-V servers.

Had this strange issue: loaded the newly released Hyper-V MP. Behind an OpsMgr Gateway server six identical Hyper-V servers (based on W2K08 core) were being monitored.

The MP however only discovered one of these six Hyper-V servers. And these servers are exactly the same: hardware, OS, OpsMgr Agent, QFE’s, W2K08 related update for OpsMgr. Also the network- and firewall settings were exactly the same.

The eventlogs of these servers showed no problems what so ever. All MPs were neatly downloaded to these servers and all other discoveries (like W2K08 Core Installation) ran fine. Just the Hyper-V MP got this nagging issue.

Stopped the health service on these servers, deleted the HealthState folder but all to no avail. Rebooted the server during midnight but still no discovery of Hyper-V.

Finally I removed the OpsMgr Agent, reinstalled it with all related QFE’s and W2K08 related update for OpsMgr.

And guess what: The servers are now being properly disovered ad Hyper-V servers.

I am puzzled since all other MPs ran like clockwork and no errors (eventlogs,  OpsMgr Console) showed up.

But hey, it is working now.

Six questions I get the most whether or not to upgrade to OpsMgr R2

Yes, Microsoft has published much about the benefits of R2 compared to OpsMgr SP1.

And yet, I do get questions whether or not to upgrade. When a company has a SA (Software Assurance) there isn’t really any good reason NOT to upgrade.

I know, it takes time to run an upgrade. As with all other upgrades, preparation is the keyword. Knowing what components are in place in the OpsMgr environment, identifying potential weak spots (like outdated third party MPs), fixing them, running AND checking backups of all critical OpsMgr components takes time.

As far as I am concerned, the preparation is default to ANY upgrade and not OpsMgr specific. So the preparation needed for upgrading to R2 cannot be an argument to postpone it.

Below I have put the six questions I do get the most about whether or no to upgrade to R2.

1. We started with OpsMgr RTM. Had a lot of issues which were solved after applying SP1 and some hotfixes/QFE’s. So should we wait with R2 until a new SP comes out for this version?
   
   To be straightforward, yes OpsMgr RTM did have certain issues which were solved with SP1 and some post SP1  hotfixes/QFE’s. R2 is the next generation of OpsMgr. So all the lessons learned with OpsMgr RTM and SP1 were accounted with and have been applied in R2 as well. And not just that, R2 contains a LOT of improvements compared to OpsMgr SP1.
   
   
2. We have heard that a post SP1 Rollup Package will come soon available. Will OpsMgr become the same like R2 after having applied this Rollup Package?
   
   It is true that there are rumors about this Rollup Package. However, until now I am not sure whether this package will come out. And when it does it will certainly not deliver the same functionality as a R2 will do. Only R2 will have added features where as a Rollup Package will contain the Post SP1 hotfixes/QFE’s and some new hotfixes as well. And when it contains new functionality it will be at a much lower level than R2 does.
   
   
3. We want to monitor non-Microsoft Operating Systems like Linux. Until recently there were beta’s of the Xplat MPs available for OpsMgr SP1. We still use these MPs in an OpsMgr SP1 testenviroment. However, Microsoft states that this functionality is only available in OpsMgr R2. However, when I import the last beta of these MPs into our OpsMgr SP1 production environment I have the same functionality. So why upgrade to R2?
   
   It is true that the beta’s of the Xplat MPs were available for OpsMgr SP1. However, when R2 hit RTM, the beta’s were withdrawn since the Xplat functionality is integrated within R2. And not just that, the way it is integrated is way much better and safer than in OpsMgr SP1 was the case. For instance, the Administration Pane in OpsMgr SP1 was locked so no additional programming was allowed. This caused the Xplat MPs in OpsMgr SP1 containing all account information in the Monitoring Pane, a potential security issue. Besides all this, you don’t want to run beta’s into a live/production environment. So monitoring non-Microsoft OS is ONLY possible AND supported by Microsoft with R2.
   
   
4. It took us much time (and sometimes frustration) to get the Notifications/subscriptions working properly. The upgrade documentation of Microsoft tells to disable ALL of them during the upgrade. Will they still work after the upgrade and having enabled them again?
   
   Yes, they will. Even better, in R2 the Notification/Subscription Model has been much improved. So a more granular subscription is possible because the MOM 2005 functionality has made a comeback: one-click subscription to Alerts is possible again. My guess is that with R2 new subscriptions will come in place and the ‘old’ ones, built in OpsMgr RTM/SP1 will be discarded eventually. And not just that, in R2 Operators themselves can subscribe themselves to the Alerts which are important to them.
   
   
5. We are monitoring Exchange 2007 with an older version of the Exchange 2007 MP. Finally Microsoft has released the native version of this MP. Only to find that it works with OpsMgr R2. Is this because Microsoft wants to push everyone to start using R2?
   
   No, that is not the case. The newly released Exchange 2007 MPs uses certain OpsMgr components which are only present in OpsMgr R2. Besides the question whether or not to upgrade to R2, I always advise my customers to use native MPs as much as possible. Main reason for it is that the native MPs are designed for OpsMgr where as converted MPs come from MOM 2005 which is totally different compared to OpsMgr, so they lack OpsMgr functionality.
   
   
6. Microsoft claims that R2 is faster, has a better performance, is capable of monitoring more objects per Management Server, has integrated SLA monitoring and so on. Sounds like the Marketing department of Microsoft has gone loose. How much of it is true?
   
   As a matter of fact, all of these claims are true and none them is exaggerated. R2 just delivers more value for it’s money.

Error ‘loading reporting hierarchy failed’

At a customers site the Reports wouldn’t load in the Console anymore. The above mentioned error showed up. The Root Management Server was in a critical state as well.

There can be multiple reasons for this error. In this particular case it was easily solved. The Health Explorer showed this description: ‘Report deployment process failed to request management pack list from SQL RS Server. The operation will be retried. Exception 'SoapException': Server was unable to process request. ---> Could not find file 'C:\WINDOWS\TEMP\lbnfb-tk.dll'’
  
Resolution:
A quick search revealed the C:\ drive of the SQL Reporting Server was full. After freeing up some space all was well again.

Object enumeration failed Query: 'Select EventLogLevel from MicrosoftDNS_Server' HRESULT: 0x80041001

The DNS MP can generate the above mentioned error, even when KB933061 has been applied, found here. I blogged about this KB earlier, found here.

The Alert name is ‘WMI Probe Module Failed Execution’. The real cause is not the MP itself but DNS and WMI on the mentioned server.

The solution for this is straightforward. In an earlier blogposting of mine I already mentioned this solution for another issue with DNS/WMI as well, to be found here.

Run from the command-prompt on the server experiencing these issues these commands:

Command 1: CD %windir%\system32\wbem
Command 2: mofcomp dnsprov.mof

Restart afterwards the related services:
- DNS
- WMI
- Operations Manager Health Service

Monitoring SCVMM with OpsMgr between two separate forests without any trusts

Recently I bumped into this situation: Forest A with OpsMgr installed, Forest B without OpsMgr but with Hyper-V servers and SCVMM to administer these Hyper-V servers and their guests. A dedicated server in this forest is VMM.

Between these forests A and B no trust exists nor will there ever be. However, the administrators wanted to use SCVMM (Forest B) in conjunction with OpsMgr (Forest A) so the PRO-tips could be used.

However, the run-as account of VMM needs access to the OpsMgr Management Group (MG) and the OpsMgr Action Account needs VMM Admin access. Since there is not a full trust between both Forests this wasn’t going to work.

The only two options which remained were:

1. Building a new OpsMgr Management Group in Forest B and use this MG together with the SCVMM MP for the PRO-tips. And use the OpsMgr MG in Forest A as a looking glass by using the option ‘Connected Management Groups’ in OpsMgr.
   
2. Building an OpsMgr Gateway Server in Forest B and use this Gateway Server to monitor the Hyper-V hosts but not SCVMM nor using the PRO tips.

In the end, option 2 was chosen.

So whenever OpsMgr needs to work in conjunction with SCVMM, both solutions need to be in the same Forest or – when residing in different forests, a full trust between both Forests needs to be present. Otherwise it will not work.

Hyper-V MP released

Microsoft released on the 19th of June the newest version of the Hyper-V MP. This MP is capable of monitoring Hyper-V servers based on W2K08 core as well. First this wasn’t possible.

MP to be downloaded from here.

Alert: ‘Communication with TS Session Broker’

At a customers site this issue occurred:

When the Terminal Server MP is loaded for monitoring Windows 2008 based terminal servers the Alert ‘Communication with TS Session Broker’ might pop-up. The Alert Description is as follows:

Event ID: 1014 -- Description: The server failed to retrieve the security identifier (SID) of the TS Session Broker server. Win32 error code: 0x534.

After some searching the cause seemed to be that the FQDN was used for the TS Session Broker name in the GPO, assigned to all W2K08 based terminal servers.

After changing this FQDN to the HOST name all was well again and the Alerts didn’t come back.

Special thanks to the owners of the blog Adventures of an IT Pro, article about this issue to be found here.

OpsMgr R2 and Ubuntu

Eventhough OpsMgr R2 officially doesn’t support monitoring of Ubuntu, Daniele Muscetta has written a good blogposting about it.

Be aware though this is not officially supported by Microsoft. Look here for the posting.

All credits go to Daniele Muscetta.