OM 2012 Agent: report to SCOM 2007 (not R2) & SCOM 2012

October 15, 2012

Can an Operations Manager 2012 Agent report to an Operations Manager 2007(not R2) Management Group?
Yes it can.
Just install the Operations Manager 2012 Agent onto the server. Go to control panel and open the “Operations Manager Agent Properties”, add the 2007 Management Group. The server will show up in the “Agent Pending” group of your 2007 Management console. Go and Approve it.

In Operations Manager 2007 (not R2)


In Operations Manager 2012


So now your server is reporting to both Management Groups. Usefull to know if you’re planning a side by side installation of SCOM 2012 next to SCOM 2007.

Grtz,
Samuel.

Advertisements

Quick Win: SCOM Alert Rule to Detect Server Reboot / Shutdown

October 9, 2012

This is a Quick Win. It only takes a few minutes to create and it gives you an interesting result.

If you have a lot of servers it’s hard to keep track of who’s rebooting which server. With this SCOM rule, you will get a message in Operations Manager telling you who initiated the reboot/shutdown and for which reason. The only thing you have to do, is make people aware to put a nice comment in the shutdown / restart comment field.
This can also be used to detect unexpected reboots or you could start reporting on all reboots on a periodic bases.

Ingrediënts

  • System center operations manager
  • The event id for shutdown / restart (1074 for Win 2008 servers)
  • A logparser (i did this one for you, if you want more info read it here)

Let’s start

Open your Operations Manager console and go to the Authoring pane. Start by making a new “NT Event Log” rule.



Name it and target it to the “Windows Computers”



The reboot event appears in the “System” log.



The Next step is to create some sort of filtering. You can figure out the parameter stuff by using a logparser.

http://blogs.technet.com/b/stefan_stranger/archive/2008/05/13/opsmgr-2007-parameters-explained.aspx



To have a nice output in your alert, you can use this example.


Now if someone restarts a server and correctly fills the comment field you’ll et an output like this


AD FS Management Pack undocumented required configuration

October 5, 2012

When implementing the AD FS management pack in System Center Operations Manager and looking at the guide, the only required configuration you get, is:

  • Install SCOM 2007 R2 or 2007 SP1 agents on AD FS servers
  • Enable Agent Proxy on all AD FS servers.
  • Using the Add Role Services Wizard in Windows Server 2008, verify that the IIS 6 Management Compatibility and IIS 6 Metabase Compatibility role services are installed. (Some AD FS 2.0 scripts depend on Internet Information Services (IIS) Windows Management Instrumentation (WMI) objects being installed.)

We did just that: we installed SCOM 2012 (hey, MS told us the SCOM 2007 R2 management packs work in SCOM 2012!) and enabled agent proxy.

Next, on the AD FS servers, we added the IIS services IIS 6 Management Compatibility and IIS 6 Metabase Compatibility role service.

The discovery scripts kicked in, and our AD FS servers were discovered. Next, we noticed some alerts on AD FS:

AD FS 2.0 application pool Is Not Running On The Federation Server


But the alert is false. The application pool is running!



When looking at the monitor, you see that a powershell script is executed, trying to connect to root/MicrosoftIISv2. Using wbemtest, you will notice that root/MicrosoftIISv2 is not available.

To ensure this script works, add the following IIS services:

  • IIS Management Scripts and Tools
    • To enable managing IIS using WMI
  • IIS 6 WMI compatibility

    • To enable the provider root/MicrosoftIISv2

    No restart required. Just wait a few moments and the alerts will magically disappear!


Authenticate SCOM console on a proxy

September 27, 2012

When going to client environments I often face this issue: internet access is only possible when authenticating against a proxy. Now, this is especially a problem when you want to be able to download management packs using the SCOM console, or at least check whether you are up-to-date.

Following a hint of my collegue Thomas Vuylsteke (see his excellent blog at http://setspn.blogspot.com/), I quickly found the “proxy configuration” page on MSDN, stating that it is possible to configure proxy utilization in the .exe.config file: http://msdn.microsoft.com/en-us/library/dkwyc043.aspx

This is actually a quick fix:

On SCOM 2012, open C:\Program Files\System Center 2012\Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe.config

Add the following code:

<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy usesystemdefault="True" />
</defaultProxy>
</system.net>

The bottom of your config-file should look like this:


En now it is possible to use the online catalog!



A quick fix for a nasty issue! I didn’t test it yet for the SCOM 2007 R2 console, but I’m pretty sure it will also work for that version.

UPDATE: apparently, the quotes didn’t pass very well in this blog post. I updated it so now you should be able to copy-paste the code.

UPDATE2: I confirmed that this works with non-MS proxy servers.


Error when uninstalling a SCOM agent

September 14, 2012

Several customers of mine have come across SCOM agents that cannot be uninstalled. This can be triggered by uninstalling an agent manually or when you want to upgrade the agent to 2012. This can occur with SCOM 2007 RTM, SP1 or R2 agents. I haven’t come across this issue on SCOM 2012 yet, but you never know!

In this case, I wanted to uninstall an agent using add/remove programs:


When trying to uninstall the agent, I stumbled across the following issue:


The patch package could not be opened. Verify that the patch package exists and that you can access it, or contact the application vendor to verify this is a valid Windows Installer patch package.

 What does this mean? You probably installed some agent patch on this server, may this be a seperate KB or a cumulative update. The problem is, when uninstalling the agent, the uninstaller looks where the install files for this cumulative update are located. To find out which patch was installed, open the registry editor regedit.exe.

If it is a SCOM 2007 pre-R2 agent, go to HKEY_CLASSES_ROOT\Installer\Products\C9A0067E2876122489E4BA987C08CDD2\Patches

If it is a SCOM 2007 R2 agent, go to: HKEY_CLASSES_ROOT\Installer\Products\7779052F1B26F94BAD9C107B86962A2\Patches

If it is a SCOM 2012 agent, go to: HKEY_CLASSES_ROOT\Installer\Products\9D603783EC87E0E49B25825AC08C3BEE\Patches

(thanks binaryoverflow.wordpress.com for pointing out the location for SCOM 2012!)

Open the Multi-String Patches. In my case, I saw the following 3 lines:


By removing the contents of this REG_MULTI_SZ:


I was able to uninstall the agent. Problem solved!

[EDIT 11-October-2012]I just discovered that Microsoft released a KB for this issue! http://support.microsoft.com/kb/971187%5B/edit%5D


Data Warehouse Object Health State Data Dedicated Maintenance Recovery State

August 1, 2012

A customer of mine had his SCOM 2007 R2 CU6 Root Management Server that was in a critical health state. When looking at the health explorer, we saw this:


 

SCOM performance its own database maintenance. Kevin Holman wrote a nice article about what maintenance is done automatically by SCOM and what maintenance you could configure additionally: http://blogs.technet.com/b/kevinholman/archive/2008/04/12/what-sql-maintenance-should-i-perform-on-my-opsmgr-databases.aspx .

When looking at the state change events, we saw the following description:

Failed to store data in the Data Warehouse. Exception ‘SqlException’: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. One or more workflows were affected by this. Workflow name: Microsoft.SystemCenter.DataWarehouse.StandardDataSetMaintenance Instance name: State data set Instance ID: {GUID} Management group: MG

 What does this mean? SCOM is trying to perform its maintenance on state data, but unfortunately, there is too much maintenance work to do, so the rule times out. Best would be to now check why this is timing out. Maybe you have corrupt tables? Or you had a sudden flow of a lot of data that was inserted in the datawarehouse? For this customer, we had issues with config churn which we just fixed. So this time-out could be easily explained.

How to fix this? First, disable the rule performing the maintenance so it will not interfere with our manual procedure. Open the SCOM console

  1. Go to the authoring pane
  2. Select Authoring => Management Pack Objects => Rules
  3. Change the scope to ‘Standard Data Set’
  4. Right-click The only rule there is: Standard Data Warehouse Data Set maintenance rule
  5. Select Override the rule for all objects of class: Standard Data Set
  6. Disable the rule by ticking the row with the parameter name Enabled and by changing the Override Value to false


  7. Select an appropriate override management pack (not the default management pack!) and click on apply.

Now we will be triggering the stored procedure used by this rule manually, and this with no timeout!

  1. Open SQL Management Studio
  2. Select the instance where your OperationsManagerDW database is residing
  3. Once opened click on new query and select you OperationsManagerDW database.
  4. Remember that our state change event description mentioned issues with state data, so we first need to get the ID of the state data set. To do this, click on new query, select your datawarehouse database and enter the following command:

    SELECT DatasetID FROM vDataset WHERE DatasetDefaultName = ‘State data set’


    Click on execute and Copy the resulting ID.

  5. Click on new query, select your datawarehouse database and enter the following command:

    EXEC StandardDataSetMaintenance “GUID”, with GUID the ID that resulted from the previous query.


  6. Wait until the command finishes successfully.

Go back to the authoring pane of the SCOM console to remove our previously defined override.

  1. Go to the authoring pane
  2. Select Authoring => Management Pack Objects => Rules
  3. Change the scope to ‘Standard Data Set’
  4. Right-click The only rule there is: Standard Data Warehouse Data Set maintenance rule
  5. Select Overrides summary
  6. Delete the previously defined override:

And the error disappeared! If this error comes back frequently, you should check for corrupt tables, config churn, database performance or other issues why the maintenance is timing out.


Microsoft ASP.NET 2.0 AJAX Extensions 1.0 Setup failed

July 5, 2012

One of the requirements for the installation of the SCOM web console is the installation of Microsoft ASP.NET 2.0 AJAX Extensions 1.0. Recently, I the installation failed with the error:

Microsoft ASP.NET 2.0 AJAX Extensions 1.0 Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run the Setup Wizard again.

To know what went wrong, I executed the following command to try to install it again, but from a command prompt with administrative privileges:

    ASPAJAXExtSetup.msi INSTALLDIR=c:\AJAX ALLUSERS=2 /l c:\ajax\log.txt

After trying to install again, I searched through the installation log and found the following information:

ExecNetFx: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)
ExecNetFx: Error 0x8007006d: failed to allocate output string
ExecNetFx: Error 0xffffffff: Command line returned an error.
ExecNetFx: Error 0xffffffff: failed to execute Ngen command: C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe update /queue
CustomAction NetFxExecuteNativeImageCommitInstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

So what is the issue? The Microsoft .NET Framework NGEN v2.0.50727 services are needed by the installer but are disabled by default. They need to be started by .NET installers. To solve this, change the startup type of both services Microsoft .NET Framework NGEN v2.0.50727_X86 and Microsoft .NET Framework NGEN v2.0.50727_X64 to manual and re-install the application, which now runs fine!