• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)


Date: Thursday, 27 Mar 2014 15:24

A couple of fellow colleagues in MCS (Paul Bishop & Jason Rydstrand) a while back had identified a significant bug in the latest version of the Exchange 2010 management pack, which will cause severe growth of two tables in the data warehouse DB in an enterprise deployment of Exchange 2010 and Operations Manager.  This affects both OM 2007 R2 and OM 2012.  Here are the specifics: 

The following tables never get groomed out of the data warehouse even though they are set to groom data older than 45 and 3 days respectively:  

  • Exchange2010.ActiveUserStatisticsDailyV14_

  • Exchange2010.ActiveUserStatisticsHourlyV14_

Two Exchange tables share the same Dataset ID and Table GUID. The grooming stored procedure, Exchange2010.Transport_ActiveUserGroom, queries the StandardDataSetAggregationStorage table to get the table name for grooming, but two results get returned and only the last result actually gets groomed.  This issue occurs because we end up grooming the wrong table. This query in the stored procedure returns two records when only one is expected:

SELECT @TableName = BaseTableName FROM StandardDatasetAggregationStorage WHERE (DatasetId = @DatasetId) AND (AggregationTypeId = @AggregationTypeId)

The first result is the correct table (ActiveUserStatisticsHourlyV14 or ActiveUserStatisticsDailyV14) but the second result is what actually gets set as the table name, which happens to be TenantStatisticsHourlyV14 or TenantStatisticsDailyV14. Because of this we end up grooming the Tenant tables instead of the ActiveUser tables on the following statement:  

DELETE TOP (1000000) FROM [Exchange2010].[TenantStatisticsDailyV14_] WHERE ([DateTime] < CONVERT(datetime, '2012-10-01 00:00:00', 120))

When we should be running the following instead (for daily and hourly):

DELETE TOP (1000000) FROM [Exchange2010].[ActiveUserStatisticsDailyV14_] WHERE ([DateTime] < CONVERT(datetime, '2012-10-01 00:00:00', 120)) DELETE TOP (1000000) FROM [Exchange2010].[ActiveUserStatisticsHourlyV14_

As a workaround until the bug is addressed by the product group, the two delete statements above must be run to groom the tables, moving the date at the end closer and closer to your preferred grooming interval until all the old data is cleared out.  One solution is to change the stored procedure to loop based on the results returned from the select query, but the real issue is likely that two different tables are using the same GUID and the ActiveUser & Tenant tables aren't the only ones have this issue so there is a chance this would need to be done against other tables as well.  Additionally, the logic was expanded and fully tested to incorporate loop logic so that the execution statement within the SP executes against the hourly and daily tables having a base table of both ActiveUserStatisticsV14 and TenantStatisticsV14.

The SQL Scripts attached are available for you to run against your SQL Server hosting the Operations Manager Data Warehouse database to update the stored procedures with the improved logic.

Attached Media: application/zip ( 4 ko)
Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2007, Operations Mana..."
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 02 Jun 2013 02:12

 

Several years ago, a colleague of mine Steve Rachui blogged about a custom management pack template supporting the scenario of allow discovery of AD Security Group membership for agent-managed Windows systems.  Recently I was working with this management pack for a customer and identified an opportunity to make minor optimizations to the logic of the discovery script.  Instead of relying on Operations Manager to discover the distinguished name for the computer object in Active Directory and pass this as an argument to the script, I determined it was best to handle this in the script.  Secondly in an enterprise deployment of Active Directory with thousands of objects defined, the discovery script may not complete successfully because it is missing the command object property – Page Size with a value of 1,000.  This is because by default when you query Active Directory using ADO, it only returns the first 1,000 objects, regardless of how many are defined.  So this object property is included and ensures the discovery is able to search all group objects and return the expected results – AD groups the agent-managed system is a member of.

 

The updated MP is included here for you to utilize.  Please refer to Steve’s blog posting on how to configure and use this MP.

Attached Media: text/xml ( 7 ko)
Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2007 R2, Operations M..."
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 02 Jun 2013 02:12

 

Several years ago, a colleague of mine Steve Rachui blogged about a custom management pack template supporting the scenario of allow discovery of AD Security Group membership for agent-managed Windows systems.  Recently I was working with this management pack for a customer and identified an opportunity to make minor optimizations to the logic of the discovery script.  Instead of relying on Operations Manager to discover the distinguished name for the computer object in Active Directory and pass this as an argument to the script, I determined it was best to handle this in the script.  Secondly in an enterprise deployment of Active Directory with thousands of objects defined, the discovery script may not complete successfully because it is missing the command object property – Page Size with a value of 1,000.  This is because by default when you query Active Directory using ADO, it only returns the first 1,000 objects, regardless of how many are defined.  So this object property is included and ensures the discovery is able to search all group objects and return the expected results – AD groups the agent-managed system is a member of.

 

The updated MP is included here for you to utilize.  Please refer to Steve’s blog posting on how to configure and use this MP.

Attached Media: text/xml ( 7 ko)
Author: "Matt Goedtel (MSFT)" Tags: "Management Packs, Operations Manager 200..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 28 Jan 2013 03:25

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)
Author: "Matt Goedtel (MSFT)" Tags: "Disaster Recovery, Operations Manager 20..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 28 Jan 2013 03:25

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 ( 5 ko)
Author: "Matt Goedtel (MSFT)" Tags: "Disaster Recovery, Operations Manager 20..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 07 Jan 2013 02:58

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

 

OM2012_SLAReport_ReportBeforeChange

 

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:

OM2012_SLAReport_XMLBefore

  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:

OM2012_SLAAvailReport-Updated

 

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.

Author: "Matt Goedtel (MSFT)" Tags: "Reporting, Reports, Operations Manager 2..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 07 Jan 2013 02:58

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

 

OM2012_SLAReport_ReportBeforeChange

 

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:

OM2012_SLAReport_XMLBefore

  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:

OM2012_SLAAvailReport-Updated

 

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.

Author: "Matt Goedtel (MSFT)" Tags: "Reports, Operations Manager 2012, Report..."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 14 Dec 2012 20:03

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 -

ServiceManagerMSIRegistryKey_UnModified

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.

Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2012"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 14 Dec 2012 20:03

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 -

ServiceManagerMSIRegistryKey_UnModified

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.

Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2012"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 12 Oct 2012 13:36

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:

OMReport_TextBoxControl

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:

AlertbyAlertName_Report

 

And there you have it folks. 

Author: "Matt Goedtel (MSFT)" Tags: "Reports, Operations Manager 2007 R2, Ope..."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 12 Oct 2012 13:36

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:

OMReport_TextBoxControl

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:

AlertbyAlertName_Report

 

And there you have it folks. 

Author: "Matt Goedtel (MSFT)" Tags: "Learn, Reporting, Reports, Operations Ma..."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 21 Sep 2012 15:52

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

Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2007 R2, Operations M..."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 21 Sep 2012 15:52

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

Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2007, Management Pack..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 19 Sep 2012 18:20

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. 

Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2007 R2, Operations M..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 19 Sep 2012 18:20

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. 

Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2007 R2, Operations M..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 19 Jan 2012 14:04

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/zip ( 148 ko)
Author: "Matt Goedtel (MSFT)" Tags: "Operations Manager 2007 R2, Operations M..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 19 Jan 2012 14:04

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)
Author: "Matt Goedtel - MSFT" Tags: "Operations Manager 2007, SCOM 2007, Repo..."
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 08 Jan 2012 01:42

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.

Author: "Matt Goedtel - MSFT" Tags: "Operations Manager 2007, MP, SCOM 2007, ..."
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 08 Jan 2012 01:42

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.

Author: "Matt Goedtel (MSFT)" Tags: "MP, Operations Manager 2007, SCOM 2007, ..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 29 Aug 2011 14:01

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:

WebConfig_SLDSessionDB_Reference

The entry for the Data Warehouse database is here:

WebConfig_OperationsManagerDW_Reference

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.

Author: "Gumshoe"
Comments Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader