Agents on Windows 2012 R2 Domain Controllers can stop responding or heart-beating

This is an issue I have been tracking for some time. When you deploy SCOM 2012 Agents on Windows Server 2012 R2 Domain Controllers, it is possible for the agents to stop responding and or sending heartbeats. The agent services will still be running. You will see the events in the OpsMgr event log stop processing, and you might see heartbeat failures as well. I have personally seen this on both of my Windows 2012 R2 domain controllers, which also run DNS and DHCP, and have the AD, DNS, and DHCP management packs imported.

WMI, SCOM and Windows 2003 server

On many W2K03 servers WMI can get hosed when the SCOM Agent is installed. This is not due to the SCOM Agent but due to the fact that WMI on W2K03 servers is a bit instable.

Since the SCOM Agent utilizes WMI to its fullest extend, the less stronger parts of WMI will be giving problems. There are ways to 'reset' WMI but there is also a hotfix for it. Look here for this hotfix.

Always read the KB article completely so one knows whether this hotfix applies to their situation as well.

However, when one wants to reregister the WMI repository on a W2K03 server this script will do the trick:

Windows Azure Symbol/Icon Set

Microsoft has published a free symbol/icon set for Windows Azure. This set can be used with Visio and PowerPoint.
For example:

The same zip file contains all symbols and icons as PNG files as well, so you can use them for other applications as well. Download the zip file from here.

Hope that this post was helpful.

System Center 2012: PowerShell Cmdlets

Microsoft has released documents containing ALL the Cmdlets available for ALL the System Center 2012 components.

Since System Center 2012 is PowerShell driven, there is a HUGE collection of cmdlets:

Changing the OperationsManagerACS Database Retention Period

Operations Manager grooms, or removes, data from its various databases at regular configurable intervals. For the Operations database, this is done in the Operations console. For the ACS database, these settings are configured during setup with a default value of 14 days. This means that every day, all database partitions (and their data) that are older than 14 days are dropped or deleted. Because of the volume of data that ACS can accumulate, 14 days is not an unreasonable setting. However, some companies might need to retain data for longer periods and they must have already planned for that when making the sizing and performance calculations for their environment. You can change the retention period for the ACS data by following this procedure.