Friday, March 9, 2012

[OpsMgr 2007] Powershell Script to list Number of active SDK connections per user

I've already post a short word on this :  >>>>>>>>>> HERE <<<<<<<<<<

And here is a smal improvment that count the number of connection by connected users :)

Replace My.Server.FullName by your RMS fullname.
  1. # Connect your environment
  2. add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";
  3. set-location "OperationsManagerMonitoring::";
  4. new-managementGroupConnection -ConnectionString:My.Server.FullName;
  5. set-location My.Server.FullName;
  6. # Get the connected users
  7. $SDKUsers = Get-ManagementGroupConnection | foreach-object {$_.ManagementGroup.getConnectedUserNames()} | sort
  8. $SDKNumberConnections = $SDKUsers | measure-object
  9. # number of active connections
  10. $SDKNumberConnections.count
  11. # count active connections per users
  12. $hash =@{}
  13. $SDKUsers | % {$hash[$_] = $hash[$_] + 1 }
  14. $Result = $hash.getenumerator() | ? { $_.value -gt 0 }
  15. $Result | sort value -DESC

 The result will be a table with the user account and the number of actives connections :


This can be a very usefull information to be able to investigate who is connecting the SCOM environment and why why have too much active connection.
Having too much SDK connection make the environment very slow.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] Find out which users have a console connection with OpsMgr 2007

Find out which users have a console connection with OpsMgr | Info Support

Usefull link to have the Powershell command line to know the number of actual SDK connection and the list of user that have a connection.

List users that have a SDK connection
  • Get-ManagementGroupConnection | foreach-object {$_.ManagementGroup.getConnectedUserNames()}
 Give number of current SDK connections
  • Get-ManagementGroupConnection | foreach-object {$_.ManagementGroup.getConnectedUserNames()} | measure-object

This posting is provided "AS IS" with no warranties.

Wednesday, March 7, 2012

[SQL & SCOM] List all Manual Reset Monitors

Here is a short SQL script to use to retrieve the Name of each Manual Reset Monitor. The aim was to identify these monitors in the connector.

  1. Select Monitor.MonitorName, MNTSName
  2. From [OperationsManager].[dbo].[MonitorTypeState] MTS
  3. Inner join OperationsManager.dbo.MonitorType MT With (NOLOCK) on MT.MonitorTypeId = MTS. MonitorTypeId
  4. Inner join Monitor with (NOLOCK) on Monitor. MonitorTypeId = MT. MonitorTypeId
  5. Where MNTSName like '%ManualReset%'
Result should be like :


MonitorNameMNTSName
Microsoft.Windows.Server.2000.OperatingSystem.ServerServiceConfigurationManualResetEventRaised
Microsoft.Windows.Server.2003.OperatingSystem.ServerServiceConfigurationManualResetEventRaised
Microsoft.Windows.Server.2008.OperatingSystem.ServerServiceConfigurationManualResetEventRaised

This posting is provided "AS IS" with no warranties.

Monday, March 5, 2012

I Love System Center Wallpaper new version in High Resolution

I Love System Center Wallpaper

New version, System Center Wallpaper. High Resolution (3840 x 2160), and in 11 Colors.







This posting is provided "AS IS" with no warranties.

Friday, March 2, 2012

[OpsMgr 2007 & 2012] System Center Monitoring Pack for System Center 2012 Configuration Manager - Release Candidate

Version:5.0.7705.0                    Date Published:2/29/2012
Language:English



File Name



Size     
ConfigMgr_MPGuide.docx127 KB       Download
ConfigMgr_MPGuide_Appendix.docx142 KB       Download
System Center Monitoring Pack for Configuration Manager.msi993 KB       Download




Overview
This is the release of the Monitoring Pack for Microsoft System Center 2012 Configuration Manager RC2. This monitoring pack helps administrators manage and administer Configuration Manager servers, computers, databases, services, disks, applications, or any other kind of object that requires monitoring.

Feature Summary
This release of monitoring pack delivers improved capabilities for Configuration Manager monitoring, including the following:
  • Monitoring the availability status of all server roles
  • Monitoring the health status of key services
  • Monitoring SQL replication health status
  • Collecting and monitoring performance counters from Configuration Manager servers
  • A topology diagram of the Configuration Manager site hierarchy
  • Reports showing the availability status and performance of Configuration Manager servers

Release History
  • 2/29/2012 - RC2 Release, version 5.0.7705.0

System requirements

Supported Operating Systems: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2

  • Other Software:
    • System Center Operations Manager 2007 R2 or later
    • System Center 2012 Configuration Manager RC

Instructions


  1. Click the Download button on this page to start the download
  2. Do one of the following:
    • To start the installation immediately, click Run.
    • To save the download to your computer for installation at a later time, click Save.
    • To cancel the installation, click Cancel.

This posting is provided "AS IS" with no warranties.

Thursday, March 1, 2012

[OpsMgr 2007] How to create a Two-State PowerShell Script Monitor using the Authoring Console

Here is a blog that has been very very usefull for me to develop some MPs. Thanks to Stefan Koell


As always be careful with the samples provided in the different links.
Always use a test environment first to try those examples!
Will only work with OpsMgr 2007 R2 !



This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] Choosing what to backup in System Center Operations Manager 2007

A typical installation of System Center Operations Manager include the OpsMgr DB and the reporting DB. By the way, some installation include too the ACS DB for some organisation.

All these DB have to be secure and also you have to keep backups.

Operations Manager Database :
Main database use by SCOM used to store all configuration for all your management groups. All changes in SCOM (Management group changes, add/modification/remove of Management Packs) are reflected in this DB.
If it's corrupted or lost and you don't have any backup, you'll have to rebuilt all your Mangement Groups.

Reporting Databases :
Reporting Datawarehouse is used to store collected data for a longer periode that the OpsMgr DB to be able to retrieve old data in the different report we can use.
If it's corrupted or lost and you don't have any backup, you will lost all the old data used for reporting purpose.

Audit Collection Database :
Mainly used for security auditing and governmental compliance reporting, a lost of data will result in sanctions against the compagny. It's a real priority to make sure backups are well working on this DB.

RMS Server encryption key :
Data in the OpsMgr DB are encrypted with the RMS encryption Key. Having issues with the key will result in the lost of all the configuration information of the management groups .
An other point is that the key is asked to promote a MS as RMS in case of crash of the RMS.

IIS Configuration and metabase :
If metabase is corrupted, Configuration will be lost. Rebuilt or reconfiguration will be easier with backups.

Management packs :
I would say, it's better to keep the MP sources you have imported (Provided, customs, and override MPs) in a kind of library outside SCOM. If you have to reinstall a management group for example with the same version of each MPs that are not up-to-date, it will be easier to reimport from you library.




Hope I don't forgot anything.. will update the post in this case... let me know if you detect that I missed something !

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] List of all cumulative update releases for System Center Operations Manager 2007 R2

Cumulative update build numbers with a larger numeric value include the fixes from all previously released cumulative updates. Any version of SCOM 2007 R2 can be updated to a later-version cumulative update.

Note : You cannot uninstall a later-version cumulative update to downgrade to an earlier-version cumulative update.

Updated in May 2012

Build 6.1.7221.99: System Center Operations Manager 2007 R2 Cumulative Update 6

This cumulative update was released on May 15, 2012. Cumulative Update 6 for Operations Manager 2007 R2 (2626076) includes all previous cumulative updates for Operations Manager 2007 R2 and includes all cross-platform updates.
To download Cumulative Update 6 for Operations Manager 2007 R2, go to the following Microsoft Download Center website:


Build 6.1.7221.81: System Center Operations Manager 2007 R2 Cumulative Update 5

This cumulative update was released on July 29, 2011. Cumulative Update 5 includes fixes for SCOM 2007 R2 and for cross-platform components (2495674 (http://support.microsoft.com/kb/2495674) ). For more information about the SCOM 2007 R2 Cumulative Update 5 fixes that are included in this build, click the following article number to view the article in the Microsoft Knowledge Base:
2495674 (http://support.microsoft.com/kb/2495674) Cumulative Update 5 for System Center Operations Manager 2007 R2 is available

Build 6.1.7221.61: System Center Operations Manager 2007 R2 Cumulative Update 4

This cumulative update was released on January 31, 2011. Cumulative Update 4 includes fixes for SCOM 2007 R2 (2449679 (http://support.microsoft.com/kb/2449679) ) and fixes for cross-platform components (see Microsoft Knowledge Base article 2222955 (http://support.microsoft.com/kb/2222955) ) in one update package. For more information about the SCOM 2007 R2 Cumulative Update 4 fixes that are included in this build, click the following article number to view the article in the Microsoft Knowledge Base:

2449679 (http://support.microsoft.com/kb/2449679) System Center Operations Manager 2007 R2 Cumulative Update 4

Build 6.1.7221.49: System Center Operations Manager 2007 R2 Cumulative Update 3

This cumulative update was released on October 1, 2010. Cumulative Update 3 includes fixes for SCOM 2007 R2 (2251525  (http://support.microsoft.com/kb/2251525/ ) ) and fixes for cross-platform components (see Microsoft Knowledge Base article 2222955  (http://support.microsoft.com/kb/2222955/ ) ) in one update package. For more information about the SCOM 2007 R2 Cumulative Update 3 fixes that are included in this build, click the following article number to view the article in the Microsoft Knowledge Base:
2251525  (http://support.microsoft.com/kb/2251525/ ) System Center Operations Manager 2007 R2 Cumulative Update 3


Build 6.1.7221.15: System Center Operations Manager 2007 R2 Cumulative Update 2

This cumulative update was released on June 29, 2010. For more information about the SCOM 2007 R2 Cumulative Update 2 fixes that are included in this build, click the following article number to view the article in the Microsoft Knowledge Base:
979257  (http://support.microsoft.com/kb/979257/ ) System Center Operations Manager 2007 R2 Cumulative Update 2 Release Notes


Build 6.1.7221.13: System Center Operations Manager 2007 R2 Cumulative Update 1

This cumulative update was released on January 30, 2010. For more information about the SCOM 2007 R2 Cumulative Update 1 fixes that are included in this build, click the following article number to view the article in the Microsoft Knowledge Base:
974144  (http://support.microsoft.com/kb/974144/ ) System Center Operations Manager 2007 R2 Cumulative Update 1

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] Best practices to use for creating and configuring overrides

Here are some best practices given by Microsoft to configure overrides in Operation Manager 2007.

Store overrides in a separate management pack

For each management pack that you use in System Center Operations Manager 2007, create an additional management pack in which to store overrides. For example, after you import the Active Directory management pack, create an Active Directory Override management pack. Then, store any overrides that you configure for the Active Directory management pack objects in the Active Directory Override management pack.

Do not use the Disable command in the Overrides menu to create an override to disable monitors, rules, or object discoveries

When you want to disable a management pack object, do not use the Disable the ObjectName command on the Overrides menu. Instead, click the Override option to override the object. Then, follow these steps:
  1. In the Override Properties dialog box, click to select the Override check box that corresponds to the Enabled parameter.
  2. In the Override Setting column, click False.
  3. In the Select destination management pack list, click the appropriate management pack in which to store the override.
Note This method lets you specify a management pack in which to create the override. However, if you click the Disable the ObjectName command, System Center Operations Manager 2007 creates the override in the Default management pack.

Make sure that an overridden parameter is set for every rule and for every monitor that uses the parameter

When you override a parameter, make sure that the parameter is configured for each rule that uses the parameter and for each monitor that uses the parameter. There may be more than one rule or monitor that uses the particular parameter.

For example, the following rules and monitors use the Intersite Expected Max Latency parameter:

Monitors
  • AD Replication Monitoring
Rules
  • AD Replication Performance Collection - Metric Replication Latency
  • AD Replication Performance Collection - Metric Replication Latency: Maximum
  • AD Replication Performance Collection - Metric Replication Latency: Minimum
  • AD Replication Performance Collection - Metric Replication Latency: Average
For more information about the rules and monitors that use the same parameters, see the "AD and Exchange Script Mappings" document. To obtain this document, download the ADExchMP_script_map.zip package on the following Web site: http://systemcenterforum.org/wp-content/uploads/

Configure overrides for groups instead of for specific instances

We recommend that you configure an override for a group instead of using an override to target a specific instance. Configuring overrides for groups allows for better manageability than what is available if you target a specific instance. To configure an override for a group, follow these steps:
  1. Create a group that has the following characteristics:
    • Create the group in the appropriate overrides management pack.
    • Configure the group to contain the particular instances or formulas that target the instances that you want to override.
    For example, create a group that is named AD DC 2003 Role. Then, manually put instances of the AD Domain Controller 2003 Role objects into the AD DC 2003 Role group.
  2. Click the For a group command on the submenu of the Overrides menu.
  3. In the Select Object dialog box that appears, click the new group that you created.

Test overrides by using an override management pack and groups in a test environment

You can test overrides in one environment and then apply the overrides to another environment. For example, you can test an override in a test environment and then implement the override in a production environment. To do this, follow these steps:
  1. Create the test groups in the appropriate override management pack.
  2. Add the appropriate instances from the test environment to the test groups. You can explicitly specify the instances. Or, you can use a formula to specify the instances.
  3. Perform sufficient testing to validate the override.
  4. Export the particular management pack from the test environment.
  5. Import the override management pack into the production environment.
  6. Populate the groups that are contained in the override management pack by using the appropriate instances from the production environment.



See http://support.microsoft.com/kb/943239 published on December 2007.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] Monitoring Pack for SQL Azure is released - CTP version

App Details :

          Version: CTP
          Release Date: 2/16/2012


Application Description :

The SQL Azure Monitoring Management Pack enables you to monitor the availability and performance of applications that are running on SQL Azure.
Feature Summary:After configuration, the SQL Azure Monitoring Management Pack offers the following functionalities:
  • Wizard to discover SQL Azure servers and databases
  • Provides connectivity status of SQL azure server.
  • Collects and monitor health of SQL azure databases
  • Collects and monitors performance information.
  • Highly optimized PowerShell based infrastructure to efficiently monitors SQL Azure.
  • Ability to define Custom thresholds for each monitor to configure the warning and critical alerts.
  • Run-as profile to securely connect to SQL azure
  • Detailed knowledge to guide the IT operator with troubleshooting the problem
  • Custom tasks to redirect the user to the SQL azure online portal



This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] System Center Operations Manager 2007 is unable to monitor SQL Server replication status - KB Microsoft

When using Microsoft System Center Operations Manager Server 2007 R2 with the Microsoft SQL Server Management Pack, items within SQL Server Replication report a Not Monitored state under Publication State, Publisher State and Subscription State.

This behavior is by design
There are no replication monitors in the Microsoft SQL Server Management Pack for Operations Manager 2007 SP1 and R2. http://www.microsoft.com/download/en/details.aspx?id=10631 .
If you check in Authoring Console Monitors for SQL replication you will see that when the SQL 2008 Publication\Entity Health\Availability entry is expanded there is no monitor to update information to rollup monitors.

There is also no way to monitor the SQL Server replication status at the moment : Replication monitors are introduced in the SQL Server 2012 Management Pack that will be released following the release of System Center 2012 Operations Manager. 


This article only applies to the Microsoft SQL Server Management Pack for Operations Manager 2007 SP1 and R2 . This Management Pack provides discovery and monitoring of SQL Server 2005, 2008, and 2008 R2.


Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use (http://go.microsoft.com/fwlink/?LinkId=151500) for other considerations.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] Configuration may not update in System Center Operations Manager 2007 - New KB Microsoft

Microsoft has published an updated KB article 2635742.  If an agented client is significant faster (more than few minutes) than the clock on the RMS, the configuration may not update in System Center Operations Manager 2007 !

That make me think at the Active directory that have the same behavior...

Microsoft provides a resolution and code to determine if the problem exists in your organization.



You may experience one or more of the following symptoms in a System Center Operations Manager 2007 Management Group:
Newly installed agents display as "Not Monitored" in the Operations Console, yet existing agents are monitored.
One or more monitors on one or more agents may not change state when healthy or unhealthy conditions are met.
Agents show as being in maintenance mode in the Operations Console, yet the workflows are not actually unloaded by the System Center Management service on the monitored computer.

Configuration changes, new rules or monitors, or overrides are not applied to some agents.
The Operations Manager event log on one or more agents will display event 21026, indicating that the current configuration is still valid, even though the configuration for these agents should have been updated.
The file "OpsMgrConnector.Config.xml" in the management group folder under "Health Service State"\"Connector Configuration Cache" does not update for long periods of time relative to the rest of the management group on one or more agents.

In addition, the Operations Manager event log may display one or more event with an ID 29106 when the System Center Configuration Management service restarts.  For example
          Log Name:      Operations Manager
          Source:          OpsMgr Config Service
          Event ID:        29106
          Level:            Warning
          Description:
The request to synchronize state for OpsMgr Health Service identified by "da4d36df-ce22-8930-e6d4-45b783e9fdb1" failed due to the following exception "System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
          Log Name:      Operations Manager
          Source:          OpsMgr Config Service
          Event ID:        29106
          Level:            Warning
          Description:
The request to synchronize state for OpsMgr Health Service identified by "fc1c815b-c0c4-242d-ae27-30db4ef99b54" failed due to the following exception "Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistException: TypedManagedEntityId = 'ac8f3d08-ee2a-ae21-0e46-19c3da794183' is deleted.

Collecting ETL logs against the Configuration Service at INF level might reveal lines similar to that below:
3326  [ConfigurationChangeSetProvider.UpdateQueryTimestampFromResults]    [configurationchangesetprovider_cs595]( 000000000343A92F )Timestamp = 04/11/2074 08:57:09.
3327  [DatabaseAccessor.NotifyOnChanges]    [databasenotification_cs329]( 0000000002E4BD4E )Firing change notification.
3328  [ConfigurationEngine.DatabaseHelper.OnConfigurationChange]    [configurationengine_cs499]( 00000000023546E1 )IsIncremental=True, NumberOfChanges=0
3329  [StateManager.CollectDirty]    [statemanager_cs39]( 00000000035D75A8 )State=274cda45-6031-c0e2-3659-0072251f5655 is dirty
    < large number of additional GUIDS >
3432  [StateManager.CollectDirty]    [statemanager_cs39]( 00000000035D75A8 )State=6ec4fb2d-d1c1-72a8-32e6-fe26df42aba8 is dirty
3433  [StateManager.CollectDirty]    [statemanager_cs45]( 00000000035D75A8 )NumberOfDirtyStates=104
3434  [ConfigurationEngine.CommunicationHelper.NotifyDirtyStatesTask.Run]    [configurationengine_cs869]Completed successfully
3435  [DatabaseAccessor.GetPollingIntervalMillisecondsTimeSpan]    [databaseaccessor_cs126]Database polling interval 0 milliseconds

Note the timestamp in line 3326 is set to 04/11/2074.  If this appears in ETL logging, use the SQL queries in the "More Information" section to confirm the condition listed in the "cause" section exists.

The System Center Management Configuration service uses a timestamp to determine when new configuration data needs to be calculated for agents and management servers.  If the system clock on an agent is faster than the system clock on the RMS, discovery data from this agent will set the timestamp for one or more managed instances hosted by that agent to the current agent system clock time.  The System Center Configuration Management service will delay calculating configuration updates for the instances on that agent until the system clock on the RMS is current with the timestamp for that discovery data.  If the agent system clock was significantly faster than RMS system time when discovery data was sent, or the agent continues to send data with a future timestamp, then it is possible that the management group would experience the symptoms listed above. 

Setting the agent system clock time to match the RMS system clock time will not reset the timestamp for the existing discovery data and the issue will remain until the RMS system clock time exceeds the discovery data by the grooming interval, when the obsolete discovery data will be groomed normally.

Resolution :

The system clocks for all agents and management servers in the management group must not significantly exceed the system clock on the RMS when submitting ANY data.  If any agents or management servers have system clocks more than a few minutes faster than the RMS, they should be corrected first to avoid any additional data with future timestamps being added to the database.
The future timestamps for the discovery data that has already been submitted must be modified in the OperationsManager database to reflect the current time.
The System Center Configuration Management service and System Center Management service on the RMS must be restarted after both the above conditions are met.

More information :

  • Use the following three queries to determine if this condition exists.  The queries must be run against the OperationsManager database.  If the timestamp with the greatest value in the table is greater than the current time (in UTC format), then the condition exists.

Select GetUTCDate()as 'Current Time',
MAX(TimeGeneratedOfLastSnapshot) as 'DiscoverySource Timestamp' from DiscoverySource

Select GetUTCDate()as 'Current Time',
MAX(timegenerated) as 'DiscoverySourceToTypedManagedEntity Timestamp' from DiscoverySourceToTypedManagedEntity

Select GetUTCDate()as 'Current Time',
MAX(timegenerated) as 'DiscoverySourceToRelationship Timestamp' from DiscoverySourceToRelationship

  • The following three queries can be used to determine which computers may have submitted discovery data with a future timestamp.  If the system clocks on these agents are not current, set them to current time before taking any additional action.

-- Find all computers with DiscoverySource Timestamp more than one day in future --
Select DisplayName, * from BaseManagedEntity where BaseManagedEntityID in
 (select BaseManagedEntityId from BaseManagedEntity BME
  join DiscoverySource DS on DS.BoundManagedEntityId = BME.BaseManagedEntityId
  where DS.TimeGeneratedOfLastSnapshot > DATEADD (d, 1, GETUTCDATE())
  and FullName like 'Microsoft.Windows.Computer%')
-- Find all computers with DiscoverySourceToTypedManagedEntity Timestamp more than one day in future --
Select DisplayName, *
from BaseManagedEntity
where BaseManagedEntityID in
 (select BaseManagedEntityId from BaseManagedEntity BME
  join DiscoverySourceToTypedManagedEntity DSTME on DSTME.TypedManagedEntityId = BME.BaseManagedEntityId
  where DSTME.TimeGenerated > DATEADD (d, 1, GETUTCDATE())
  and FullName like 'Microsoft.Windows.Computer%')
-- Find all computers with DiscoverySourceToRelationship Timestamp more than one day in future --
Select DisplayName, *
from BaseManagedEntity
where BaseManagedEntityID in
  (select BaseManagedEntityId from BaseManagedEntity BME
   join DiscoverySource DS on DS.BoundManagedEntityId = BME.BaseManagedEntityId
   join DiscoverySourceToRelationship DSR on DSR.DiscoverySourceId = DS.DiscoverySourceId
   where DSR.TimeGenerated > DATEADD (d, 1, GETUTCDATE())
   and FullName like 'Microsoft.Windows.Computer%')

  • To correct the existing data, run the following commands against the affected tables.
Update DiscoverySource
Set TimeGeneratedOfLastSnapshot = GETUTCDATE()
where TimeGeneratedOfLastSnapshot > GETUTCDATE()
Update DiscoverySourceToTypedManagedEntity
Set TimeGenerated = GETUTCDATE()
where TimeGenerated > GETUTCDATE()
Update DiscoverySourceToRelationship
Set TimeGenerated = GETUTCDATE()
where TimeGenerated > GETUTCDATE()

  • The following query can be used to see what additional data has been submitted to the database with a timestamp in the future.  The tables related to maintenance mode should have several rows, assuming there are agents currently in maintenance mode which is scheduled to end at some time.  All other tables should have timestamps with the current time, or in the past.
/*                                                            */
/* The following query will search all tables in the database */
/* for columns with datetime datatypes.  It will then return  */
/* the total number of rows in each table that have values    */
/* greater than the configured number of days from present.   */
/* Times are all in UTC format.  The default increment is     */
/* 3 days, but can be adjusted as needed.                     */
/*                                                            */
DECLARE @tabname AS sysname;
DECLARE @colname AS sysname;
DECLARE @fcontin AS tinyint;
DECLARE @query AS nvarchar(max);
CREATE TABLE #work
(
  TableName sysname,
  ColumnName sysname,
  NumRows int,
);
DECLARE cur_meta CURSOR FOR
  SELECT t.Name 'Table',
         c.Name 'Column'
  FROM sys.columns c
  INNER JOIN sys.tables t ON c.object_id = t.object_id
  INNER JOIN sys.types y ON c.system_type_id = y.system_type_id
  WHERE y.Name = 'datetime';
/* Change the increment in the DATEADD(dd,3,GETUTCDATE()) function  */
/*  as needed from the default of +3 days from current time         */
OPEN cur_meta;
SET @fcontin = 1;
WHILE (@fcontin > 0)
BEGIN
  FETCH cur_meta INTO @tabname, @colname;
  IF (@@FETCH_STATUS < 0)
     BREAK;
  PRINT 'Table = '+ @tabname + ', Column = ' + @colname;
  SET @query = 'SELECT ''' + @tabname
                + ''', ''' + @colname
                + ''', COUNT(*) FROM ' + QUOTENAME(@tabname)
                + ' WHERE ' + QUOTENAME(@colname) + ' > DATEADD(dd,3,GETUTCDATE())';
  INSERT INTO #work
  EXECUTE ( @query );
END
CLOSE cur_meta;
DEALLOCATE cur_meta;
SELECT *
  FROM #work
  ORDER BY 3 DESC;
     
DROP TABLE #work;

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use (http://go.microsoft.com/fwlink/?LinkId=151500) for other considerations.

This posting is provided "AS IS" with no warranties.

[OpsMgr 2007] Removing orphaned Operations Management agents using PowerShell - New KB Microsoft

I've never heard about this before but if there is a KB, the issue is real ! :)


In a System Center Operations Manager 2007 R2 Command shell, you may see agents that are still in a pending management state even though they do not appear under pending management in the Operations Manager console.   

This can occur if there are agent records left behind in the Operations Manager database. At some point these agents were deployed to a management server manually but later that management server was decommissioned and the agents were never properly removed.
Follow the steps below to resolve this issue.
In this example we assume we have two agent systems named Agent1.contoso.msft and Agent2.contoso.msft. Both agents were assigned to a management server named ManagementServer.Contoso.msft that no longer exists. In your environment you would substitute the names for your specific agents and management server. 

          AgentName : Agent1.contoso.msft
          ManagementServerName : ManagementServer.Contoso.msft
          AgentPendingActionType : PushInstallFailed
          LastModified : <date/time>
          ManagementGroup : Opsmgr-Group
          ManagementGroupId : 888a2cd4-0db6-f669-32f8-5b08aa25d2e2

          AgentName : Agent2.contoso.msft
          ManagementServerName : ManagementServer.Contoso.msft
          AgentPendingActionType : PushInstallFailed
          LastModified : <date/time>
          ManagementGroup : Opsmgr-Group
          ManagementGroupId : 888a2cd4-0db6-f669-32f8-5b08aa25d2e2

NOTE Before executing any query against the Operations Manager database be sure that a complete and current backup exists. 
  • Run the following queries : 
SELECT AgentPendingActionId
FROM AgentPendingAction WHERE AgentName like 'Agent1.contoso.msft'  

Result:
2A5C2E8F-2AD4-1703-D3BE-4755DF1A8E2E

SELECT AgentPendingActionId
FROM AgentPendingAction WHERE AgentName like 'Agent2.contoso.msft'  

Result:
360DB30E-3C2C-50A9-B047-A123A87280C0

  • Execute QUERY :
DECLARE @ActionId uniqueidentifier
SET @ActionId = (SELECT AgentPendingActionId
FROM AgentPendingAction WHERE AgentName like 'Agent1.contoso.msft')  
EXEC p_AgentPendingActionDeleteByIdList @AgentPendingActionIdList = @ActionId

Record is deleted successfully.

Do the same for the second agent as well.

Now via powershell we can confirm no records exist for these two systems. 
Following command will show us each agent and its assigned primary and failover management server via powershell.

get-agent|ft -a ComputerName,primarymanagementservername,@{l="secondary";e={$_.getfailovermanagementservers()|foreach{$_.name}}}

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use (http://go.microsoft.com/fwlink/?LinkId=151500) for other considerations.

This posting is provided "AS IS" with no warranties.