Here’s a cool article that I found over in our TechNet Wiki. This one was started by a Microsoft employee but since it’s on the TechNet Wiki anyone can add to it. It’s one is a one-stop shop for all the best OpsMgr 2012 information on the web so if you’re looking to get a head start on your upcoming SCOM 2012 deployment then you'll definitely want to add this one to your Favorites:
=====
What is a survival guide? It is a page we created as a pointer to the best information on the web. You can use the information below to learn the fundamentals; increase your current knowledge; or stay current on Operations Manager and events. And, if you think we missed some great article out there, please add it below…
You can find the rest of the System Center 2012 Operations Manager Survival Guide here.
J.C. Hornbeck | System Center & Security Knowledge Engineer
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/ ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ Operations Manager Team blog: http://blogs.technet.com/momteam/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/ The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
Here’s a new Knowledge Base article we published today. This one talks about troubleshooting an issue where configuration doesn’t update in System Center Operations Manager 2007:
You may experience one or more of the following symptoms in a System Center Operations Manager 2007 Management Group:
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.
1) 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.
2) The future timestamps for the discovery data that has already been submitted must be modified in the OperationsManager database to reflect the current time.
3) The System Center Configuration Management service and System Center Management service on the RMS must be restarted after both the above conditions are met.
1) 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
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
2) 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%')
-- 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%')
3) 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()
Update DiscoverySource Set TimeGeneratedOfLastSnapshot = GETUTCDATE() where TimeGeneratedOfLastSnapshot > GETUTCDATE()
Update DiscoverySourceToTypedManagedEntity Set TimeGenerated = GETUTCDATE() where TimeGenerated > GETUTCDATE()
Update DiscoverySourceToRelationship Set TimeGenerated = GETUTCDATE() where TimeGenerated > GETUTCDATE()
4) 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;
/* */ /* 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;
For the most current version of this article please see the following:
2635742 : Configuration may not update in System Center Operations Manager 2007
Here’s one more Knowledge Base article we published today. This one talks about how to remove orphaned SCOM 2007 agents using PowerShell:
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}}}
2626752 : Removing orphaned Operations Management agents using PowerShell
Here’s a new Knowledge Base article we published today. This one explains why you can’t see a SQL Server replication status even though you have the SQL Server MP loaded in SCOM 2007:
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.
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.
2673200 : System Center Operations Manager 2007 is unable to monitor SQL Server replication status
In case you have missed those, Kristopher Bash, who works in the cross-platform team, has published a set of blog posts about the new cross-platforms templates and functionality in System Center 2012 – Operations Manager:
Also, a second “heads up” about another blog: Christopher Crammond, developer who works on OpsMgr support of Java applications, has posted an article on how to extend what we support out of the box and provide additional capabilities when monitoring Tomcat 7.x. The article has two parts:
Even if I am presently not working with the Unix stuff as much anymore these days, those who know me are aware that it was a passion of mine – and it is very cool to see the amount of functionality and ease of use that is coming out from that area!
Did you miss System Center Universe? No problem. The sessions were all recorded and are now available for viewing on demand here:
http://www.systemcenteruniverse.com/Agenda?sf3213864=1
In case you missed it, this is the site for the System Center Universe:
http://systemcenteruniverse.com/
Thanks again to the sponsors of System Center Universe and to the speakers!! It was a great community event.
Twitter hashtag: #SCU2012
Looking forward to the next one!
Here’s a new Knowledge Base article we published today. This one talks about an issue where OpsMgr integration with System Center 2012 Virtual Machine Manager fails with error 10218:
When creating the integration from System Center 2012 Virtual Machine Manager (SCVMM 2012) to Operations Manager, the integration fails with the following error:
Error (10218) Setup could not import the System Center Virtual Machine Manager Management Pack into Operations Manager server because one or more required management packs are missing. The SCVMM Management Packs cannot be deployed unless the following component management packs are present in Operations Manager 2007: Windows Server Internet Information Services 2003, Windows Server 2008 Internet Information Services 7, Windows Server Internet Information Services Library, SQL Server Core Library.
NOTE All required Management Packs have been imported in Operations Manager.
In this scenario, the Virtual Server 2005 R2 Management Pack was imported which imports the Microsoft Virtualization Core Library. The cause of the problem is that SCVMM 2012 will import a newer version of the Microsoft Virtualization Core Library Management Pack and the old version cannot be present in order for integration to complete successfully.
There are two potential solutions:
1. Remove the old version of the Microsoft Virtualization Core Library and the Microsoft Virtual Server 2005 R2 Management Pack.
or
2. Configure a second Operations Management group for the SCVMM 2012 integration and configure the SCVMM 2012 server as well as the Hyper-V servers to report to this new management group.
The Microsoft Virtualization Core Library is a Hyper-V Management Pack developed by the Hyper-V team. It has been updated to support the latest version of Hyper-v and improve monitoring of the hosts.
2674625 : Operations Manager integration with System Center 2012 Virtual Machine Manager fails with error 10218
Here’s a new Knowledge Base article we published today on the AVIcode 5.7 SE-Viewer. This one talks about an issue where the time displayed in the SE-Viewer does not reflect the current time after Daylight Saving Time (DST) has been applied:
Times displayed in the SE-Viewer from AVIcode 5.7 do not reflect the current time after Daylight Saving Time (DST) has been applied.
The SE-Viewer will obtain the time zone offset and DST setting from the local client when launched. These settings are in effect for the duration of the browser session. If the local time changes due to DST, the new time will not be reflected in SE-Viewer for the duration of the browser session.
Any browser sessions with SE-Viewer open when the new DST time takes effect should be closed and reopened to reflect the actual current time at the client location.
2673546 : Timestamps in AVIcode 5.7 SE-Viewer do not reflect DST change
We will add a new product family to your WSUS server today – System Center. The System Center product family will contain updates for versions 2012 and higher of System Center products, which include System Center 2012, a product that combines components such as:
The System Center product family will allow a variety of update types, e.g. service packs, optional updates, critical updates, and security updates. System Center updates will also be available in the Microsoft Update Catalog at http://catalog.update.microsoft.com.
You will see new product categories appear under the System Center product family as new updates are available for each product or product component. The first product category to be added will be System Center Advisor. For additional information about System Center Advisor, see http://www.SystemCenterAdvisor.com/.
We encourage you to synchronize the System Center product family if you are planning to deploy System Center 2012, either through upgrades or new licenses, or if you already have System Center 2012 products in your managed environment. For additional information about System Center 2012, see http://www.microsoft.com/en-us/server-cloud/system-center/default.aspx.
We have created a new forum under the Operations Manager forum category on TechNet for Application Performance Monitoring (APM). Please feel free to fire away questions to Microsoft, the MVPs, and the broader community, answer questions, and have some good discussions.
Here’s the link:
http://social.technet.microsoft.com/Forums/en-US/scomapm/threads