Friday, July 31, 2009

New KB article: Expected reports for installed management packs are not visible

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.

PowerShell: Changing the Resolution State

Suppose you have multiple Alerts coming in and want to change the Resolution State automatically from New to something like DBA for instance.

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.

  1. Create the Resolution State (when not present) in the Administration Pane > Settings > Alerts. As an example I create the Resolution State DBA with ID 40:
    image 
  2. Also in this example I target the Alerts based on their name. Here I chose the Alerts with the name ‘Script or Executable Failed to run’. This name will be used in the PS script. 
    image
  3. Now I start in good old Notepad with the PS script being used to change the Resolution State of this Alert from New to DBA. Since I will use the regular Task Scheduler of the Windows Server I will run it from the command prompt. As we all know OpsMgr adds certain PS extensions to the regular PS. And we need those in order to get the script running. So this script has to load these extensions as well. Secondly, the script needs to connect to the RMS. There are two ways to go about it: hardcode it in the script or use a parameter. I prefer the latter since it makes the script more transferable to other Management Groups as well. This is the first section of the script just doing these actions:

    param ($rootMS)

    #Initializing the Ops Mgr 2007 Powershell provider
         add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
         set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
         new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin ;
         set-location $rootMS -ErrorVariable errSnapin ;


  4. Now I need the second part of the script. PS has to look for new alerts with the name ‘Script or Executable Failed to run’. When found the status has to be changed to ‘DBA’. The script also needs a loop in order to handle multiple Alerts with the same status and name:

    $Alerts = get-alert -criteria 'Name = ''Script : Failed to login''' | Where {$_.ResolutionState -eq 0}
    foreach($Alert in $Alerts)
    {$Alert.ResolutionState = 40
    $Alert.Update("Resolution State Changed")}


  5. I put these two parts together in one script and save it as a .ps1 file (ChangeRState_01.ps1) on the RMS. From the cmd-prompt I test it. Since I have parameterized the name of the RMS I have to use the FQDN of the RMS as well:
    Syntax: Powershell <location and name PS script> –rootMS <FQDN RMS>

    In my case it becomes:

    Powershell c:\ChangeRState_01.ps1 –rootMS srv01.systemcenter.org 
    image
  6. Script has run successfully:
    image

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:

  1. Do not run this script to often (every 15 minutes should be sufficient).
  2. Run this scheduled script with an account that has sufficient authorizations (but not more!) within OpsMgr. Operator Permissions should do the trick.  

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…

OpsMgr and empty reports – Part 2 – Tips & Tricks

----------------------------------------------------------------------------------
Postings in the same series:
Part I   – The Introduction.
Part III – Targeted Reports 
Part IV – Examples for Disk Reports
Part V  – Scheduling / Publishing Reports and some tricks
----------------------------------------------------------------------------------

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.
image 

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’:
image 
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.
image
When running a report, it ends up empty:
image

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:
image
When running a report, it will be filled:
image 

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.

Thursday, July 30, 2009

OpsMgr database and log sizes

During the design of an OpsMgr environment many important questions need to be answered.

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.

  1. Official Microsoft website for OpsMgr
    Mapping Requirements to a Design for OpsMgr

  2. Microsoft System Center Capacity Planner 2007 Model
    Downloaded here.
    Needs a good understanding before it can be put to use. However, on the internet many explanations are to be found.

  3. SCOM Unleashed
    As stated before, my personal SCOM Bible. The authors also run a blog on which they publicly share some good information from the book. Found here. (When you don’t have the book, buy it now since it is very very good and soon the edition covering R2 will come out as well!)

  4. System Center Central
    Multiple Excel sheets are to be found there. One needs an account to download these sheets though, but the account is free.
    - SCOM2007DBestimatorv1.xls
    - OpsMgr2007_20DB-DW_20Size_20Calculator.xls

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.

Wednesday, July 29, 2009

Modifying an OpsMgr Agent on Windows 2008 server

When modifying an OpsMgr Agent installation on a Windows 2008 server it can’t be done from the Control Panel since UAC is blocking it. So it has to be done in a different manner.

The start for both versions of OpsMgr (SP1 or R2) is the same: start an elevated command-prompt. Afterwards it is different:

  1. OpsMgr SP1:
    msiexec /I{768DB8BD-CB3A-43F4-9A4C-BA2921D27AD3}

  2. OpsMgr R2:
    msiexec /I{25097770-2B1F-49F6-AB9D-1C708B96262A}

Now the OpsMgr Agent installation wizard will start.

Source: OpsMgr Forum, this thread.

Tuesday, July 28, 2009

New ISA 2006 MP released

On Monday the 27th of July the new ISA 2006 MP has been released. It now supports ISA 2006 SP1 servers. Besides that certain bugs have been fixed.

Taken from the MP guide itself:

image  
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.

OpsMgr and Windows 2008: What hotfixes do I apply?

Even though the related KB articles seem to be clear on this topic (KB953141 and KB954049), I do get questions about what hotfixes to apply when running Windows 2008.

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:

  1. OpsMgr hotfix KB954049 is only needed when OpsMgr isn’t at R2 level.

  2. Needed W2K08 hotfixes based on KB953141:
    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.

  3. Needed W2K08 hotfixes based on KB954049
    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?

  1. Hotfix List for Windows Server 2008 SP2 (Excelsheet)
  2. All about SP2 

Monday, July 27, 2009

New OpsMgr blog

On the Microsoft TechNet OpsMgr Forum there is much information to be found. Many people with much knowledge on OpsMgr are active here in order to help people out who have questions on OpsMgr.

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.

R2 Connectors are released

The Connectors for OpsMgr R2 have been officially released by Microsoft. More information? Look here.

The following Connectors are included:

  • Connector for IBM Tivoli Enterprise Console
  • Connector for HP OpenView Operations for Unix
  • Connector for HP OpenView Operations for Windows
  • Connector for BMC Remedy ARS
  • Universal Connector
Kevin Holman has blogged about these Connectors. Check out his posting for more detailed information on this topic.

    RTFM (Read The Friendly Manual) and other advises when importing MPs

    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.

    image

     

     

     

     

    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.

    1. Does the MP work in your OpsMgr environment?
      With the release of R2 there are two versions of OpsMgr now: OpsMgr SP1 (with certain hotfixes) and OpsMgr R2. Certain MPs work only with R2 (native MP for Exchange 2007) or with R2 and SP1 with certain hotfixes applied. (newly released MP for SQL). So always ascertain yourself that the MP to be downloaded/updated works with your environment as well. 

    2. First thing sfirst 
      Importing/updating a MP is always the LAST step in the process of deciding whether or not to use a certain MP. So do not use the import MP functionality lightly. Do not import a MP because ‘you can’ or ‘because it sounds nice’ or ‘it seems to look good’. Use a MP because the organization needs it and is ready to invest the needed time for it.

    3. Second phase 
      When a MP is imported a new chain of processes will start: configuring the MP in order to make it match your environment. This process isn’t done within a couple of hours. Depending on the MP, the complexity of the environment where it is applied, the monitoring needs of the organization, the skills of the people working with OpsMgr and so on, it can take some days.

      This doesn’t mean that one is working a couple of days only with this MP, but after the initial configuration process, additional configuration is needed when certain Alerts do get in.

    4. One by one
      Always import MPs one by one. See advise #3 why. When the last imported/updated MP is properly configured and running as it should, the next MP can be imported. 

    5. Import a MP when you are familiar with it
      For this the guide of the related MP is needed. However, when importing directly from the Console there is no way to download the guide as well. There are two ways to go about it: go to the website where the guides are to be found of the most common MPs of Microsoft, or download msi-file containing the MP and guide from the catalogue, unpack it as I described in an earlier blogposting of mine, and RTFM.

    6. Updating already imported MPs
      Even when already imported MPs are to be updated, handle it in the exact same way as new MPs: RTFM.

    7. Change Management
      Document changes of the OpsMgr environment in order to get and maintain a good solid grip on it.

    New SQL MP released

    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.

    Friday, July 24, 2009

    OpsMgr and empty reports – Part 1 – The Introduction

    ----------------------------------------------------------------------------------
    Postings in the same series:
    Part II  – Tips & Tricks
    Part III – Targeted Reports 
    Part IV – Examples for Disk Reports
    Part V  – Scheduling / Publishing Reports and some tricks
    ----------------------------------------------------------------------------------

    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.

    image 
    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.)

    image 
    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.

    image

    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.

    image

    and here is the Object Picker module: 
    image

    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. 

    Thursday, July 23, 2009

    Updated extended MPs by OpsManJam

    Today OpsManJam has released updates to four extended MPs.

    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:

    1. Extended Server 2003 IIS
      Microsoft Extended Windows Server Internet Information Services 2003 Management Pack.

    2. Extended Windows Server OS
      Extended Windows Server Operating System Management Pack.

    3. Extended ADMP
      Extended Windows Server Operating System Management Pack.

    4. SCCM OSD for OpsMgr 2007
      System Center Configuration Manager 2007 OS Deployment Management Pack.

    Wednesday, July 22, 2009

    Scalability OpsMgr SP1 vs. OpsMgr R2

    Since I do get a lot of questions about this I have decided to put it on my blog.


    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

    MP authoring

    A bit late perhaps, but still good to know: http://technet.microsoft.com/en-us/opsmgr/cc671407.aspx

    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!

    http://74.52.12.162/~microsft/conference_agenda.php?cid=19

    R2 – Xplat

    With OpsMgr R2 a whole new field has come into play: non-Microsoft Operating Systems and non-Microsoft enterprise applications, also known as Xplat.

    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:

    1. Webcast, monitoring Xplat with OpsMgr R2:
      http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=37&webcastid=5558

    2. Some datasheets from Microsoft. Some of it is marketing blabla, but also with some ‘nice-to-know’ information:
      Linux Systems with Operations Manager 2007 Cross Platform Extensions
      and
      Datasheet- System Center Operations Manager 2007 Cross Platform Extensions

    3. Microsoft’s Xplat MP authoring guide:
      http://technet.microsoft.com/nl-nl/library/dd919155(en-us).aspx

    4. Daniele Muscetta’s blog, many posts about Xplat:
      http://www.muscetta.com/

    5. David Allen, OpsMgr MVP, has some good field notes:
      http://wmug.co.uk/blogs/aquilaweb/archive/2009/07/21/opsmgr-r2-xplat-agent-deployment-field-notes.aspx
      and
      http://wmug.co.uk/blogs/aquilaweb/archive/2009/09/02/more-opsmgr-x-plat-notes.aspx

    6. Anders Bengtsson, OpsMgr MVP, also blogged about it:
      http://contoso.se/blog/?p=712

    7. The Xplat blog of Bridgeways MPs:
      http://blog.xplatxperts.com/

    Whenever new links are to be found I’ll update this posting with them.

    Tuesday, July 21, 2009

    R2: Crashing Console when running Diagram View of Distributed Applications

    Related to this problem is also that topology views aren’t displayed. Only a gray field is to be seen. When one wants to open a Diagram View the OpsMgr Console crashes.

    In the event logs nothing is to be found. Removing the cache file of the Console doesn’t work.

    Solution

    1. Repair DOTnet 3.5 SP1
    2. Remove the OpsMgr Console
    3. Reinstall the OpsMgr Console

    All is well again. Now the Topology Views are functional again and the Diagram Views are also working.

    Exchange 2007 R2 MP: EventID22401

    Today I learned – the hard way that is – always to ask and never, ever to presume anything.

    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: image
    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.

    Monday, July 20, 2009

    OpsMgr SP1: Is the process HealthService of certain Agents taking away all cpu-cycles?

    The core-process of the OpsMgr Agent is the HealthService executable. Sometimes it can become a ‘run-away-train’, consuming as much as cpu-cycles available.

    image 
    This issue can be hard to trouble-shoot since most of the times there isn’t just one single cause to be found but a combination of multiple causes where every cause on itself wouldn’t be an issue at all.

    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:

    1. How is the server it self performing?
      Stop the HealthService (OpsMgr Health Service) on the server experiencing this issue. Check out how the cpu-load is now. When this is constantly above the 80-90% there are other issues at hand which aren’t OpsMgr related.

    2. Customized MPs
      Have their been modifications of MPs? Or, have their been newly created MPs with custom-made scripts? Especially the latter – when not done properly - can really cause havoc on monitored objects. When newly developed MPs are loaded or some MPs have been modified override these in such a manner that they do not run anymore.

      When the HealthService becomes stable again you know what is wrong.

    3. Old MPs
      In the past there were issues with the DNS and DHCP MPs which caused high cpu-loads on the monitored servers. Check out whether these MPs are up-to-date.

      Be aware though that updating MPs is more than a few simple mouse-clicks: Change Management & RTFM are aspects to reckon with.

    4. Health Service State folder of OpsMgr Agent
      When an OpsMgr Agent is installed, it has it’s own directory (C:\Program Files\System Center Operations Manager 2007). In this folder a subfolder named ‘Health Service State’ is to be found. Here the OpsMgr Agent stores all needed information like what Management Group(s) to connect to, the downloaded MPs and so on.

      Whenever the process HealthService.exe becomes ‘cpu-hungry’ it can help to have this folder recreated by the Agent. How?
      - Stop the Healthservice (OpsMgr Health Service)
      - Rename the folder ‘Health Service State’ to ‘Health Service State_OLD
      - Start the Healthservice

      In the beginning the process HealthService will consume more cpu since the OpsMgr Agent need to download all information. However, this must cause cpu-spikes and not cpu flatliners. Depending on the server hardware and the available resources it can take between 5 to 15 minutes. Afterwards the process should consume not much cpu-cycles.

    5. WMI- I
      On Windows 2003 servers only: WMI can need some patching to make it more stable. But this is only the case when the OpsMgr Console shows multiple Alerts like ‘WMI Probe Failed Execution’. Kevin Holman has blogged about it.

    6. WMI-II
      Recompiling WMI can also do the trick. Check this posting of mine how to go about it (Resetting WMI).

    7. Windows Scripting Host
      On Windows 2003 servers only. WSH versions > 5.7 can cause scripts to run wild. In the earlier mentioned blogposting of Kevin Holman there is also an url to be found for the update of WSH to version 5.7.

    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.

    Thursday, July 16, 2009

    R2 – Upgrading from SQL 2005 to SQL 2008, part IV. ‘The Whole Story’

    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:

    • Part I: Why SQL 2008 and how to test an upgrade?
    • Part II: Potential pitfall after pre-upgrade process
    • Part III: Potential pitfall after installing SP1 for SQL 2008

    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. :)

    OpsMgr SP1: Not all hotfixes are applied to the OpsMgr Agents

    Issue
    At a customers site with OpsMgr SP1 in place there were multiple hotfixes applied on the Management Servers. However, not all of these hotfixes weren’t applied to the newly pushed OpsMgr Agents, even though the Agent staging folder (~\Program Files\System Center Operations Manager 2007\AgentManagement\<architecture>) was correct: permissions OK and all files (msi, msp’s and so on) were present.

    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.

    Wednesday, July 15, 2009

    Quick Guide to get the native Exchange 2007 MP for OpsMgr R2 Up-and-Running for core monitoring

    First of all:

    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:

    • Install OpsMgr Agents on all Exchange 2007 servers
    • Enable Agent Proxying on all Exchange 2007 servers
    • Make sure all Exchange Servers are being monitored correctly
    • RMS: install PowerShell and the OpsMgr Console
    • When using Exchange Clusters, import the Cluster MP and configure it properly. To be downloaded here.

    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.

    • All discoveries within this MP are disabled by default. Except for one, the ‘Exchange 2007 Discovery Helper’. It discovers Exchange 2007 servers without starting monitoring.

    • Verify whether all Exchange 2007 servers are being discovered: Monitoring Pane > Discovered Inventory > right click, choose Select Target Type > type ‘Exchange 2007 Discovery Helper’ > OK. A list of unmonitored Exchange 2007 Servers will appear. Check this list to see whether it is complete or showing servers which aren’t Exchange Servers at all. (*)

      (*: The discovery is based upon the presence of the Exchange 2007 Management Tools. So when these are present on servers which aren’t Exchange Servers, these servers are listed as Exchange Servers. How to go about this? Check here and read the whole conversation.)

    • Enable the discoveries which reflect the Exchange 2007 server structure of your organization. See page 14 of the MP guide. Save these overrides in a new MP.

    • Configure disk monitoring. The Exchange MP is capable of monitoring disks containing mailbox database-/log files and disks containing Hub or Edge Queue files.

      When you don’t want duplicate disk space Alerts when using the Exchange Disk Monitors, you must disable disk monitoring on the Exchange Servers from the Server OS MP. (Read the notes on pages 14 and 15 for why not doing this…)

      Authoring > Monitors > Logical Disk > Windows Server 2003/2008 Logical Disk > Entity Health > Availability: Logical Disk Availability and Logical Disk Free Space. Override these (Enabled = false) for the group ‘Exchange 2007 Computer Group’.

      Same goes for the monitors under Performance: Average Disk Seconds Per Read, Average Disk Seconds Per Transfer and Average Disk Seconds Per Write.

    • Configure Exchange 2007 Disk Monitoring. These monitors have certain thresholds which need to be set in order to reflect your environment.

      Check out Exchange 2007 Mailbox Database Disk, Exchange 2007 Mailbox Log Disk and Exchange 2007 Queue Disk. Under Authoring > Monitors > Disk > … > Availability the monitors are to be found. Override these for all objects of type ‘Exchange 2007 Mailbox Database Disk’ as needed.

      Something to be aware of: The ‘Exchange 2007 MDB Disk Free Space Monitor’ only raises an Alert when the megabytes AND percentage thresholds are exceeded.

    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.

    My personal experiences with the native Exchange 2007 MP for OpsMgr R2

    For a customer I have imported and configured this MP, or better I am in the process of configuring it. And I must say that Microsoft has really done a good job.

    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.

    Tuesday, July 14, 2009

    DNS MP Alerts keep coming back?

    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:

    http://blogs.technet.com/kevinholman/archive/2009/06/29/errors-alerts-from-the-dns-mp-script-failures-wmi-probe.aspx

    and

    http://blogs.technet.com/kevinholman/archive/2009/06/29/getting-lots-of-script-failed-to-run-alerts-wmi-probe-failed-execution-backward-compatibility-script-error.aspx

    All credits go to Kevin Holman for these postings. All I want to do is to give it more exposure.

    Monday, July 13, 2009

    R2 – Upgrading from SQL 2005 to SQL 2008, part III

    OpsMgr R2 runs on SQL 2008 SP1. So when upgrading to this version of SQL, SP1 for SQL 2008 has to be applied.

    In my test environment the installation of SP1 for SQL 2008 went smoothly. Soon I got the message the update operation had completed successfully:
    image 
    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.

    Friday, July 10, 2009

    How to identify the SQL Server version and edition

    Always wanted to know everything about your SQL Server version and edition, but were afraid to ask?

    Microsoft has written a good solid KB about it. To be found here: KB321185. Always handy queries like these.

    R2 – Upgrading from SQL 2005 to SQL 2008, part II

    The main part of the upgrade guide for R2 is very detailed and well written. However, the part about upgrading to SQL 2008 isn’t as complete as it should be. (To be found on pages 49 and 50) 

    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:

    image 
    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…

    Thursday, July 9, 2009

    Hotfix for OpsMgr R2 with SQL 2008 available

    Microsoft has released a new KB article for solving an issue with scheduled reports by using SQL Server 2008 Reporting Services. These reports do not show chart data.

    KB972821 tells what to do.

    Wednesday, July 8, 2009

    R2 – Upgrading from SQL 2005 to SQL 2008, part I

    With OpsMgr R2 support for SQL 2008 (SP1) has been added. So besides the regular upgrade path from OpsMgr SP1 to R2 another upgrade is possible as well: upgrading the underlying SQL-server instance to SQL 2008.

    image 
    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:

    1. Operating costs
      New functions like encryption, Resource Governor and Auditing are natively available so no additional costs have to be made for this kind of functionality.

    2. Mainstream support on SQL 2005
      How long will Microsoft offer Mainstream support SQL 2005? Check here for more information on this topic.

    3. Return On Investment
      With SQL 2008 server hardware can be used for an extended amount of time. It supports hot pluggable cpu's. With Resource Governor one can size it to the company needs.

    4. Third party application support
      Many vendors are working with Microsoft ensuring their products supports and uses the new features of SQL 20008 as well.

    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:

    • Reporting Services
      No dependency of IIS, improved charting and graphing. My personal experience with this component is that is more robust than it was with SQL 2005. For OpsMgr Reporting certainly a good argument.

    • Performance enhancements
      SQL 2008 is faster, so OpsMgr will benefit from it as well.

    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:

    1. SQL Server 2008 Upgrade Technical Reference Guide
    2. SQL Support Blog
    3. To upgrade from SQL Server 2005 to SQL Server 2008

    Tuesday, July 7, 2009

    Upgrading to R2: Quick tip – Making the old OpsMgr Agents visible

    When one is upgrading an OpsMgr SP1 environment to R2 RTM, the OpsMgr Agents need to be upgraded as well.

    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:

    1. Start the Console with Admin permissions

    2. Go to the Monitoring Pane

    3. Make a new folder and put it into a new MP (otherwise the new State View will be stored into the Default MP and we don’t want that)

    4. Right click under the new folder and select New > State View

    5. At the tab Criteria select at the option ‘Show data related to’ the entity Agent.

    6. Under the option Select Conditions, select ‘With specific version

    7. In the box Criteria Description a hotlink appears (specific). Click on it and in the box which appears now this string has to be added (without the quotes): ‘6.0.6278.0’. Click OK.

    8. Give this State View a proper name like Old Agents (OpsMgr SP1 level).

    9. Click OK and this View will be saved. When this View is opened, all the Agents which aren’t at R2 level will be displayed.

    Example of the View:

    image

    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.

    Monday, July 6, 2009

    R2 upgrade experiences from Eval to full version

    This weekend I upgraded one of mine OpsMgr environments from R2 Eval to R2 Full Version. This environment exists out of a RMS, MS, Gateway Server and SQL server with SQL Reporting Services (SRS) installed.
    image 
    The upgrade went really fast and smooth. No snags or what so ever. Of course, I checked the Upgrade Guide only to find nothing note worthy has changed, so my former blogposting about the upgrade process is still OK.
    image 
    The only funny thing during this upgrade was when I wanted to upgrade the Reportingcomponent. These screens were displayed:image
    and
    image 
    Apparently the Reportingcomponent from OpsMgr R2 Eval doesn’t differ from OpsMgr R2 Full Version. For the ‘just-in-case’ scenario I chose the Repair option.

    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.

    Saturday, July 4, 2009

    Updated OpsMgr R2 documentation

    With the full version of OpsMgr R2 being available on MVLS, Microsoft has updated the documentation as well.

    Check out these links to ‘know-it-all’:

    1. Blogposting of the MOM Team about R2 and a quick overview of what it is new in OpsMgr R2:
      http://blogs.technet.com/momteam/archive/2009/05/29/what-s-new-in-r2-deployment-and-upgrade.aspx

    2. OpsMgr R2 Upgrade Guide (online):
      http://technet.microsoft.com/en-us/library/dd861348.aspx

    3. Troubleshooting OpsMgr R2 (online):
      http://technet.microsoft.com/en-us/library/dd883298.aspx

    4. OpsMgr R2 Deployment Guide (online):
      http://technet.microsoft.com/en-us/library/bb419281.aspx

    Multi-homed Agents and different OpsMgr Management Group versions

    Some environments use Multi-homed Agents. These OpsMgr Agents report to more than one Management Group. An OpsMgr Agent can report to a maximum of four different Management Groups.

    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:

    Agent Multihomed Support

    More information to be found here.

    R2: OpsMgr Service Names

    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

    Thursday, July 2, 2009

    OpsMgr R2 Full release is available!

    HOT HOT HOT !!!

    Thursday evening late I got this from the OpsMgr forum :
    image 
    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 !!!

    Wednesday, July 1, 2009

    HP EVA Performance MP

    The original HP EVA MP is rather complex to use and when all is working, not much data is shown.

    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!