Back when Operations Manager 2007 was released, I blogged here - http://blogs.technet.com/b/mgoedtel/archive/2007/08/06/update-to-moving-operationsmanager-database-steps.aspx regarding
a script that needed to be executed after you moved the OperationsManager database from one SQL server to another.  With Operations Manager 2012, the steps documented here - http://technet.microsoft.com/en-us/library/hh278848.aspx, still overlooks the fact you need to update the Master database on the destination SQL server in order to complete this operation successfully. 

It should be noted the same issue/symptoms will occur after you move the data warehouse database (OperationsManagerDW).

Attached is a .ZIP file containing the two scripts for updating the Master database on the SQL servers hosting either the OperationsManager or OperationsManagerDW database. 

Attached Media: application/zip ( 7 ko)

This is a fix specific to a report that is provided out of the box with the System Center Operations Manager 2012 RTM and SP1 version, specifically the Service Level Tracking Summary Report that is in the Microsoft Service Level Report Library.  If you have ever run this report you will have noticed that the health icon image in the Report Duration column is not rendered as expected (ala skewed):

Since this was not corrected in SP1 and is still an outstanding bug, I figured why not provide a short-term solution to correct it until the report is corrected and a new version of the MP defining the report is released.  In order to modify the report definition, perform the following steps:

1. Start SQL Reporting Services Report Manager by typing its URL in the address bar of a Web browser.  By default, the URL is /reports">http://<webservername>/reports.
2. Navigate to Microsoft.SystemCenter.DataWarehouse.Service.Level.Report.Library.
3. In Report Manager, click Details View option.
4. Select the Microsoft.SystemCenter.DataWarehouse.Report.ServiceLevelTrackingSummary.Detail report definition, click the down-arrow to the right of the RDL and in the context-sensitive menu select the Download option.  Save the RDL file to a directory of your choosing.
5. Before you modify the report definition, make a back up copy in-case you make an error in the proceeding steps.
6. Using your favorite XML editor, open the report definition you downloaded in Step 4.
7. In the XML editor, search for the following text – “SlaConditionImage”.
8. After the XML tag <Image Name=”SlaConditionImage”> remove the following element– <Sizing>Fit</Sizing>.  The following image is a snippet of the XML code displaying what you need to remove:

1. After you remove that element from the code, save it. 
2. Go back to your browser and in Report Manager, click on the Upload File option.
3. In the Upload File option, browse to the folder where the updated report definition is saved and select it.  Check the Overwrite item if exists checkbox before clicking on the OK button.  Click the OK button to upload the updated report definition.

Now when you re-run the report, it will display the health icon correctly as shown in the following example:

Please note that if you are performing these steps on a OM 2012 RTM install base and then apply Service Pack 1, the report will be overwritten and you will have to re-apply the proposed change. 

This posting is provided "AS IS" with no warranties, and confers no rights as specified in the Terms of Use.

Many people have encountered the unfortunate scenario of attempting to upgrade or install the Operations Manager 2012 Agent on a SharePoint Web server hosting the Service Manager Self-Service Portal.  The Windows Installer package for the agent installation checks for the existence of System Center Service Manager and will block the installation if it is detected.  Well, I decided to do a little digging here and I found a work around which allows for successful installation of the OM 2012 Agent (pushed from the console or installed manually).  All you need to do is perform the following steps:

1. Log onto the SharePoint Web server with an account that has local administrative privileges.
2. Open the Registry Editor.
3. In the Registry Editor, navigate to HKCR\Installer\Products\223333EF9E9130B42B84BD23D7699AA2 and rename the key (Append an underscore and the letters BAK to keep this simple).
4. Push or manually install the OM 2012 Agent to the SharePoint Web server or servers involved.
5. Upon successful completion, rename the Registry key to its original name.

So before the Registry modification, the key should look like this -

I tested this on a couple of SharePoint Web servers in my environment hosting the Service Manager 2012 Self-Service Portal and it worked like a charm.

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows Server. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

So this is a topic I have been meaning to post in a while now and finally made the time/effort to write it up.  This is a scenario that is not documented in the Report Authoring Guide for Operations Manager and I had to go through the reports in the Generic Report Library MP in order to find an example and understand how to include the required logic in my custom report in order to provide a textbox control.  I used this object picker in the “Alert by Alert Name “ report in my custom Management Group Health Management Pack found here -http://blogs.technet.com/b/mgoedtel/archive/2012/01/19/custom-operations-manager-reports.aspx.  This particular report allows you to search on a specific alert that has been generated by an alert rule or unit monitor within a given date/time range. 

First we follow the guidance in the Report Authoring Guide under the section Custom Report Parameters found here - http://technet.microsoft.com/en-us/library/gg697751.aspx to configure the custom report to use the smart parameter block for things like the relative date-time picker, since the report requires a start and end date range to return the records within, and include the snippet of XML code included in the above referenced section for the Date Report Controls.  Lastly, we need to add the following snippet of XML code to add the textbox control in the <Controls> element.  This is where the report also filters on the specific alert name and returns all records that match:

The tag <ReportParameter name=“AlertName”> is referencing the parameter used in the SQL query and also matches the data field defined in the report (using either BIDS or Report Builder). 

Now when you run your custom report using the textbox control, it will look like this:

And there you have it folks. 

Today I published on the TechNet Gallery, a custom management pack for providing additional montoring of Exchange Server 2010 with Operations Manager 2007 R2 and 2012. 

The following new features are new in this release of the Extended Exchange Server 2010 Management Pack:

• Includes performance collection rules to sample performance data from the Client Access role for performance reporting.
• Includes performance collection rules to sample performance data from the Mailbox role for performance reporting.
• Includes a new Database Mounted unit monitor that addresses a bug in the currently released Exchange 2010 SP1 management pack.   This monitor runs a script checking that any Mailbox Databases defined on the Mailbox server are successfully mounted, and if not, changes health state and generates an alert.
• Includes a new Active Database Server is Auto-Activation Blocked unit monitor that addresses a bug in the currently released Exchange 2010 SP2 management pack.  This is an event monitor checking for events stating that a mailbox server is set to ‘Auto-Active Blocked’ but is hosting active Databases.    
• Includes a new Outlook Connectivity HTTPS Health State unit monitor that addresses a bug in the currently released Exchange 2010 SP2 management pack.  This is a simple HTTPS check against the Autodiscovery service on the local CAS server.  This may be used in case the ‘KHI: HTTP Connectivity Against Local Server - *’ checks fail to accurately report due to possible security configuration requirements in your environment.
• Includes a new The Exchange store has a high number of MAPI RPC request unit monitor. This unit monitor evaluates how many threads are currently in use on the Mailbox server and changes state if the threshold is exceeded. 
• Includes additional performance reports.

I already have in mind some scenarios to cover and report on in the next version of this custom management pack.  If you have any issues, or specific scenarios you would like to be considered for inclusion in the next version, please feel free to contact me at matthew.goedtel@microsoft.com.

Also note the reports have been tested against SQL 2008 and 2008 R2, not SQL 2005.

You can download the MP here - http://gallery.technet.microsoft.com/Extended-Exchange-2010-9e1d263e

After a brief departure from Microsoft I recently returned and will be actively blogging again.  I just updated the blog post - "Performance Optimizations For Operations Manager 2007 R2" to include guidance for Operations Manager 2012, so please check that out as I know many of you have been asking what is relevant as it relates to the 2012 release. 

I have also been releasing updated management packs to the TechNet Gallery, starting with an updated version of my Extended Microsoft Windows Server OS MP.  Hopefully tonight I'll be rleeasing an Extended Microsoft Exchange 2010 MP that I am putting the finishing touches on. 

Thanks to those who have visited my blog and found the information provided valuable. 

Based off of a recognized demand, I developed a management pack that provides three key reports for Operators and Administrators to leverage.  These reports were based off of queries developed by Kevin Holman and Jonathan Almquist and tuned to support these reports.  The three reports that I have included in this MP are:

1. Maintenance Mode - Agent-Managed Systems in Maintenance:  This report will show the agent-managed systems that are currently in maintenance in the management group.
2. Maintenance Mode - History of Maintenance for Agent-Managed Systems:  This report will show the history of Maintenance Mode activities in the management group for agent-managed systems. and rollup total duration for those systems based on the date/time parameters the report will query within.  This report is based off of an example report that was demontrated by us at MMS back in 2009.  I used this as a foundation for learning to develop custom reports using Report Builder.
3. Management Group Health Report - This hygiene report evaluates key performance metrics that help identify management packs that require additional tuning (discovery, monitors, and performance/alert rules) to ensure optimal health and performance of the management group.  Sure you get this information today by a couple of built-in reports (I don't have access to OM now to reference those specific reports, so please bear with me), but you need to select the specific management packs and other relevant parameters.  Here we have a single report to run to summarize that information as a starting point, and you can use the other built-in reports to further evaluate and determine if additional tuning efforts are required.

No manual steps are required once you import this MP.  The reports are running against the Data Warehouse database, so you don't need to create a custom data source.

Attached Media: application/octet-stream ( 167 ko)

Hello and Happy New Year!

Today's topic is regarding the setup of the SharePoint 2010 Foundation management pack in support of multi-farm monitoring with Operations Manager.  This is a common topic that many people have questions about and some of the blog posts regarding it are not entirely accurate.  My hope here is to help demystify the confusion surrounding this and help you understand the steps necessary to set it up correctly.  Here I'll summarize those steps before we jump right in:

1. Create a domain user account that will have the elevated privileges required in each farm (recommended security practice)
2. Create a Run As account for each farm
3. Create custom groups containing the Windows Computer objects for all the servers in the respective farm
4. Configure the SharePointMP.Config xml file to discover one of the farms (this avoids manually overriding the many discovery rules in the SharePoint 2010 Foundation MP) per the Deployment Guide
5. Execute the task - Configure SharePoint Management Pack to configure discovery and monitoring
6. Update the SharePoint Discovery/Monitoring Account Run As profile to associate the Run As accounts for each farm with the custom groups

By default when you want to monitor a single farm with Operations Manager, the SharePoint 2010 Foundation MP Deployment Guide (starting on Page 15) directs you to create a Windows domain user account that has been granted the following privileges in order for the workflows defined in the MP to complete successfully:

• SharePoint Farm Administrator
• SQL DB Owner for SharePoint SPAdminContent and Configuration databases
• Local Administrator on the SharePoint and respective SQL Servers

You will want to do this for each farm, defining a unique Windows domain user account and granting it the necessary privileges as stated.  Once you complete this step for each farm, you can then create the Run As account(s) in Operations Manager and configure distribution of that account to the specific servers respectively. 

Next you will want to create custom groups for each farm and add all of the servers in the farm to the group.  These groups will be referenced when you configure the SharePoint Discovery/Monitoring Account Run As profile, later in the process.  Identify an appropriate naming standard for the groups display name so you can easily relate the group with the farm.  So if you have Farm A, add the Windows computer object for the SQL and SharePoint servers in that farm to the group (using a dynamic or explicit membership criteria). 

Now we need to modify the SharePointMP.Config file to update the Machine Name tag with the Windows Computers supporting one of the SharePoint farms.  We are only adding the computer objects for one farm in order to obviate the need to manually override the 17 discovery rules in the SharePoint Foundation MP (which is enabling the discovery rule - Discovery For SharePoint Foundation Installed Machine to true, setting the Interval Seconds and SyncTime parameter, and for the other 16 discovery rules setting the SyncTIme parameter.  Those overrides are stored in the writeable MP - Microsoft.SharePoint.Foundation.2010.Override).  Otherwise, you simply override the applicable discovery rules, associate the Run As accounts with the Run As profile and target groups, and wait for discovery to occur.  Back to setting up the config file....  One approach is:

<Association Account="SharePoint 2010 Farm-A Action Account" Type="Agent">
    <Machine Name="SVRSQL01" />        
    <Machine Name="SVRSRPWFE01" />        
   <Machine Name="SVRSRPWFE02" />
</Association>

Next go ahead and copy the .Config file to the RMS, run the task (remember to override the Working Directory parameter), and verify the task completed successfully.  Let the discovery process run to ensure it is successful in discovering and moinitoring the servers in the farm before proceeding with modifying the SharePoint Discovery/Monitoring Account Run As profile.  Now go ahead and modify the properties of the SharePoint DIscovery/Monitoring Account Run As profile, and here we want to associate the respective Run As account defined for each farm to the custom group representing that farm that we created earlier. 

Step 1:  Remove the existing associations first, which are the individual systems specified in the .Config file with the Run As account.

Step 2:  Click on the Add button.

Step 3:  In the Add Run As Account properties box, select the Run As account for the one farm from the list.  Next change the option - "This Run As Account will be used to manage the following objects:" by selecting the radio button "A selected class, group, or object:" and click the Select... button.  When the context-sensitive menu appears, select Group from the list. 

Step 4:  In the Group Search box, select the appropriate group you created earlier.  Press the OK button to save your selection and return to the Add Run As Account properties box.

Step 5:  Press the OK button to save your changes.

Repeat steps 2 - 5 for the additional farms.  Again associating the specific Run As account that has assigned privileges in that farm with the custom group that hosts the Windows Computer objects of that farm. 

Once discovery runs again at its defined interval, check the SharePoint 2010 Products\Servers health state view to verify the servers in the additional farms were discovered successfully and are being proactively monitored by the SharePoint Foundation and SharePoint Server MPs. 

I have successfully utilized this approach with my current customer, monitoring three different farms with about thirty plus servers supporting those three farms.

Good luck and I hope this helps!   Any questions or issues, feel free to ping me.

If you have deployed the Operations Manager 2007 R2 Service Level Dashboard in your environment, you have probably noticed our documentation doesn’t provide any reference or guidance if you decide to move the Operations Manager Data Warehouse database, or the SLDSessionDB database to a new SQL Server.  This is assuming that you have not installed SQL on the same server hosting Windows SharePoint Services, and instead have distributed your workload.  This article is to help you understand what is involved and how to avoid impacting the continued use of your Service Level Dashboard.  Just know that performing this exercise will not require you to perform a re-install of the SLD, however it will require some up-front planning and preparation. 

Here are a summary of steps:

1. Stop the Windows SharePoint Services services and World Wide Web Publishing Service service on your WSS 3.0 server hosting the SLD.
2. If moving the Operations Manager Data Warehouse database to a new server, perform the SQL backup and restore steps as documented here on MSDN. 
3. If moving the Service Level Dashboard database (SLDSessionDB) to a new server, perform the SQL backup and restore steps as documented here on MSDN.
4. Verify the permissions for the SLDSessionDB or Operations Manager Data Warehouse database (depending on which one you moved).
5. Modify the SLD SharePoint Web Part web.config file to reference the new SQL Server. 
6. Restart the WWW and Windows SharePoint Services services.

If you like most of my customers and installed the Service Level Dashboard on Windows SharePoint Services 3.0, then you will want to stop the Windows SharePoint Services services and the World Wide Web Publishing Service service.  Then you can proceed with moving the SLD database or the Operations Manager Data Warehouse database (if moving the Data Warehouse database, be sure to follow the steps here in the Operations Manager 2007 R2 Operations Administrators Guide).  After you successfully backup and restore the database or databases to the destination server, we need to verify the security permissions and ensure they are retained.    

For the Data Warehouse database, verify the following permissions:

1. The Operations Manager Service Level Dashboard Application Pool Identity domain user account  is a member of the SLDReader role.
2. The Operations Manager Service Level Dashboard Application Pool Identify domain user account has login permissions on the SQL Server.  Database Role Membership should be public and SLDReader. 
3. The SLDReader role is an associated security database role. 

For the SLDSessionDB database, verify the following permissions:

1. The Operations Manager Service Level Dashboard Application Pool Identity domain user account has login permissions on the SQL Server.  Database Role Membership should be db_owner.

To configure the SLD SharePoint Web Part to reference the new SQL Server hosting either database, you will need to edit the Web.Config file for the SLD SharePoint site.  You can find the config file for this instance of SharePoint in the following location – ietpub\wwwroot\wss\VirtualDirectories\51918.  The entry defining the connection string for the SLDSessionDB is here:

The entry for the Data Warehouse database is here:

Once you change the Source= argument to match the new SQL Server, you then can proceed with restarting the WWW and Windows SharePoint Services services and verify no errors exist in the Application Event Log on your WSS server and there are no login authentication issues related to the Data Warehouse database or the SLD database on the SQL Server hosting those databases.  If there are no related error events written, then proceed with testing functionality of the Service Level Dashboard.

A customer the other day e-mailed me and asked how he could scope a view in the Operations console to a specific alert.  In this scenario it was the "Database Backup Failed to Complete" alert from the SQL Server management pack and the view would be presented to the SQL DB Admins team.  This is a pretty simple view to create, although perhaps not obvious when sorting through the conditions in the properties of the alert view.  I don't know if others have found this to be a challenge, so forgive me if this is obvious and not worthy of an entry on my blog. 

Perform the following to filter a view on an alert rule:

1. In the Operations Manager Console, Monitoring view, right-click in the left-hand pane and select the option "New\Alert View".
2. In the Properties window, for the option "Show data related to" click on the command button with the ellipse and select the appropriate target if the rule is duplicated between different versions of the application/service (an example would be SQL Server 2005 vs. 2008) for granular filtering, or leave it at the default of "Entity" if you don't want or need to filter.
3. Under the Select conditions section of the window, select the option "with a specific name" and click on the hyperlink under the Criteria description (click on the underlined value to edit) section of the Properties window.
4. In the Alert Name window, enter in the text box the exact name of the alert and press the OK button.
5. In the Properties window, press the OK button to save your changes.

Now when you select that view, you should see the specific alerts that you defined the view for presented for review.  If I filtered the view on the alert rule "Database Backup Failed to Complete", I would see those alerts, if generated, in the view. 

Please Note:  This blog has been updated to provide guidance on which settings are applicable to Operations Manager 2012.

This blog post is based on questions that people who attended our MMS 2010 session BB23 – Operations Manager 2007 SQL Server Configuration for Operations Manager 2007 Administrators. You know as I was typing the name of the session, I realize it is way too wordy.  In retrospect I could have simply named it, “Optimizing SQL Server for Operations Manager 2007”.  Here Chris Cubley and I delivered this at our internal TechReady conference in June with some spit and polish applied, and I did not think of it then. I digress…okay moving on

In our session we covered optimizations that are specific to Operations Manager 2007 R2 and these optimizations are applicable to a management group supporting an enterprise scenario (1,000 – 6,000+ agents). There is no performance benefit to be gained if you apply these settings to a management group that is managing less than 1,000 agents.

Management Server Health Service - OM 2007 R2

The recommended settings highlighted in this section are only applicable to Operations Manager 2007 R2.  In Operations Manager 2012, the default settings for these Registry keys for the Health Service have higher values and are already optimized out of the box (at this point). 

The following are specific settings with recommended values from the product group based on their performance and scalability tests that can reduce resource utilization on the SQL Servers hosting the Operations Manager databases, and the management servers/Root Management Server:

To reduce resource utilization impact on the Root Management Server and management servers caused by the OpsMgr queues, perform these changes on the RMS/MS’s in the management group:

Note: This key does not exist by default and must be created manually.

Management Servers Config Service and Group Membership Calculation - OM 2007 R2 and OM 2012

In an Operations Manager 2007 R2 management group, to reduce resouce utilization on an Operations Manager 2007 R2 Root Management Server, perform the changes highlighted in the following table.  In an Operations Manager 2012 management group, perform the changes highlighted in the following table on all management servers that are a member of the "All Management Servers Resource Pool" (which technically is every management server deployed in your management group, unless you have dedicated one or more management servers to a custom-defined pool for Network Device or Cross-Platform monitoring and have manually assigned management servers to the "All Management Servers Resource Pool").

Note: These Registry keys do not exist by default and must be created manually.

Before changing the Group Calculation interval I should point out a few things to help you make a well informed decision. By default group calculation is performed on the RMS every 30 seconds. In a management group supporting the enterprise scenario, you will typically see many custom groups defined for targeting overrides, scoping of user roles, and for controlling the behavior of notification subscriptions (at a minimum). Group calculation discovery rules can impact the performance of the OperationsManager database, as the behavior characteristics are queries run against the database instance space in the form of multiple read operations. If you have lot of groups and their group calculation criteria are complex, it will have a big hit on database performance. Other operations in the management group could be affected as well, such as slower discovery insertion, degraded console performance, and replication of configuration changes to agents is slower. Precisely how much degradation you’ll see in these other areas is predicated upon how much group calculation is overloaded.

Changing the calculation interval to a greater value could affect any overrides that target a group, since an object that would fall under the criteria of a group would not relate to that group and receive the override until the group calculation is performed. If you can tolerate the latency of group membership discovery, then you can increase the interval/frequency to a less frequent schedule, say every four or eight hours as an example.

Data Warehouse Synchronization - OM 2007 R2 and 2012

For reduced resource utilization impact on the OperationsManager databases caused by DW synchronization rules running on the RMS in an Operations Manager 2007 R2 management gorup or the management servers in an Operations Manager 2012 management gorup, create overrides in the Operations Manager console for the following rules to increase the interval and batch size of those operations:

*Note: This override parameter actually affects three data sources referenced in this rule.

Console Refresh - OM 2007 R2 and OM 2012

The Operations Manager Console refresh interval is every 15 seconds by default. With multiple consoles in an enterprise scenario, this can negatively impact performance. For best performance, turning off Polling or increasing the interval can help. Perform this change on any Windows computer that has the console installed:

Before making any changes, always test first and evaluate the results before implementing them in production.  If you make them in production due to constraints in being able to appropriately test/validate in your test lab, first establish a performance baseline before making any of the proposed changes stated here.  After each change, perform another performance measurement and compare it to the initial baseline statistics to determine if the results are above or below the baseline. 

You probably have noticed that the MPViewer HTML exports for our management packs that were released “back in the day” have not been kept up to date, nor provided for new MP’s released in the library on the OpsManJam website.   Due to the busy work schedule of the UA team who manages the content on this site, it has fallen behind and a few customers have contacted us to inquire what the future holds for this content.  

Based on these inquiries and the value they find in us providing the content, I reached out to the team to ask what the deal was.  After a hearty discussion and understanding that they could use some help, I offered to take on the responsibility of keeping this portion of the library up-to-date.

Last week and this week I started to update the content and reorganize it accordingly.  You will find up there the recent MPViewer HTML exports for the latest Cross-Platform management packs, SQL Server, Exchange 2010, and a couple of others.  My thoughts around this are to maintain two versions of the HTML export for each respective management pack, the latest and the version prior.  You will be able to identify which version is which by the naming convention of the HTML file - <MP Name>_<Version of MP>.html.  So for example, the latest SQL Server management pack is version 6.1.314.36 and the file name in the library is - Microsoft.SQLServer.2008.Monitoring_6.1.314.36.  I still have some work to do ensuring all the exports for the latest MP’s are available on the site, so please bear with me as I work on this off-hours… I do have a day job :)

I would be interested in your feedback as to if you find value in us providing this  when we release a new management pack or updated version of a currently released MP.  Also if you like it in HTLM format or rather Excel (XLS) format.  Any other feedback related to this is appreciated as well.

Here is another Excel spreadsheet from MPViewer that I edited to provide a detailed breakdown of all the Unit Monitors in the Windows DNS 2008  management pack.  While the attached spreadsheet is specific to Windows DNS 2008, it also applies to 2003.

If you find any errors or have questions, please feel free to contact me.

Here is another Excel spreadsheet from MPViewer that I edited to provide a detailed breakdown of all the Unit Monitors in the Windows Server 2008  management pack.  While the attached spreadsheet is specific to Windows Server 2008, it also applies to 2003.

 If you find any errors or have questions, please feel free to contact me.

Attached Media: application/vnd.ms-excel ( 93 ko)

As I work with more and more customers who are using System Center Configuration Manager 2007, I find the teams who are responsible for supporting the servers are more open minded to leveraging Configuration Manager for software update management, DCM, and OS deployment.  In helping our customers understand how to leverage the software update management feature of Configuration Manager, I learn how they approach patch management for the servers supporting different IT services and line of business applications.  

With IT moving towards virtualization, I came to the realization one day that we need to delineate between a virtual guest and the virtual host for software update management.  Therefore I thought about an approach and did some research and identified an appropriate solution to this challenge. 

There is a WMI class that represents the features installed on a computer running the Windows Server 2008 or later operating system called Win32_ServerFeature. Since Hyper-V is a feature of the Windows Server 2008 OS, this can be collected by extending hardware inventory in ConfigMgr (more information on this can be found here - http://technet.microsoft.com/en-us/library/bb680609.aspx.  Therefore, I edited the SMS_DEF.MOF file, which is located on the primary site server in the folder - <Configuration Manager installation directory>\Microsoft Configuration Manager\Inboxes\clifiles.src\hinv, and appended this snippet of code to the end of the file:

After saving this, I forced the ConfigMgr client to update its policy and then forced a hardware inventory re-synch.  Now when I open up Resource Explorer for a managed Windows Server 2008 server, I am presented with the extended class and properties as seen in the following screenshot:

Now we can use this new class when we create our collections for targeting software updates to virtual guests separately from virtual Hyper-V hosts.  And we can also segregate other servers also depending on how you manage software update deployment in your organization.

As promised and avaialble for download, here is the Excel spreadsheet from MPViewe that I edited to provide a breakdown of all the Unit Monitors in the Active Directory management pack.  While the attached spreadsheet is specific to Active Directory version 2003, it also applies to 2008.

 If you find any errors or have questions, please feel free to contact me.

Up next, I think I'll take on DNS and DHCP.

Attached Media: application/vnd.ms-excel ( 222 ko)

Just a quick note here that I’ll be attending MMS 2010 in Las Vegas in April and co-delivering a presentation with Chris Cubley, a colleague from the Operations Manager product group.  Our session is entitled “Operations Manager 2007 SQL Server Configuration for Operations Manager Administrators” and the basic summary is “to provide guidance for customers or consultants who are responsible for the design and implementation, or support of Operations Manager with complex scenarios scaling beyond 500 systems.” 

Our goal is to provide you with the knowledge to help you prevent and identify any performance bottlenecks with your SQL Server configuration, especially around the storage subsystem. 

We hope to see you there!

As you are probably aware, the Deployment Guides that compliment each management pack released by Microsoft do not go into detail highlighting the configuration of all unit monitors defined in a given MP.  This can be a challenge when you are working with a service or application owner where they want to understand what the MP does and how it is configured out of the box, and not have to go through the tiring effort of sitting in-front of the Authoring or Operations Console to review each one.  Remember, it is not recommended to blindly import management packs into our production management group, otherwise alert storms and other implications will negatively affect Operations Manager and your incident/problem management processes. 

While MPViewer helps provide some of the properties the rules, monitors, tasks, etc. in an MP, it does not break out the default configuration of each unit monitor in detail.    This is something unfortunately that MPViewer is not designed to produce when you view or save the management pack configuration settings; however licensed tools such as Silect MP Studio can.   Anyway, back to the heart of the story here.  I have modified the output from MPViewer and added another column with the details for each respective unit monitor from the SQL Server 2005/2008 Monitoring MP.  This was done based on popular demand from my customers and internal colleagues and I determined this is too valuable not to share with the public. 

While the attached spreadsheet is specific to SQL 2008, it also applies to SQL 2005.  I am in the process of doing the same for the Active Directory Management Pack, and should have that done tomorrow evening.  I will see if I can commit to doing one of our product management packs per week, based on demand. 

Attached Media: application/vnd.ms-excel ( 183 ko)

Last week on http://www.opsmanjam.com my Maintenance Mode management pack was published.  However, shortly after releasing it I discovered a couple of bugs, one of which prevents maintenance mode from starting against your targetted set of systems (pretty bad bug) intermitently.  I have addressed those bugs, refined the PowerShell script used, and even added a couple of features, most notably the ability to schedule maintenance mode for a Windows Cluster.  I just submitted that updated version of the MP to the team and also requested the 'buggy' version be removed from the site in the meantime. 

Here is a summary of what the new version offers:

This management pack provides an automated method to schedule maintenance mode for a given set of Windows computers that are in a pre-defined set of groups and the associated rules to target against those groups. In addition, this version supports scheduling maintenance mode for Windows Cluster services.   It serves as an example and foundation to build from in order to develop your own custom schedule to automate within Operations Manager 2007 R2 accordingly.

Hopefully this week that new version will be released to web.  I am now starting to work on another management pack for managing agent failover as an alertnative for those customers who do not wish to implement Active Directory integration.   This will also be PowerShell driven and hopefully be flexible enough to meet your implementation scenarios.  If you would like to send me your ideas or suggestions, please feel free to e-mail me at - mgoedtel@microsoft.com. 

I was recently e-mailed by a colleague regarding the maintenance mode PowerShell script that was originally released by Boris Yanushpolsky (found here) that worked great for RTM/SP1, but was failing when executed on an OpsMgr 2007 R2 agent managed system.  In addition, the script was designed to place an object into maintenance mode for an hourly duration, not in minutes matching the setting in the Operations Console. 

As you know, in Operations Manager RTM/SP1, we did not place the health service or health service watcher instance of the computer object into maintenance mode as one would expect, when you place a computer and its contained objects into maintenance mode.  In Operations Manager R2, this was resolved and no longer requires you to perform this as a second step in the process. 

The attached script has been updated to support automating the placement of computer objects into maintenance mode for Operations Manager R2, and now accepts the argument of minutes instead of hours for duration of maintenance.  I am also in the process of updating the Maintenance Mode management pack that Brian Wren originally developed, and Andrzej Lipka (a former MCS Consultant from Poland) and myself modified with some additional features (see Andrzej's MP here and mine here) so you can leverage it for R2.  I hope to have it completed and tested by this weekend, and submitted for review and release on http://www.opsmanjam.com the following week.

The command-line for executing the script is:

Suggestions and feedback are always welcome.

Attached Media: application/x-zip-compressed ( 1 ko)