Here are the steps to resolve it.

1.  Check to User Permissions.

-  Verify the user you are running the installer as is a member of the Operations Manager Administrators.
-  Verify the user has sysadmin access to the database in SQL.

2.  Check the SPN of the SDK Service.

- http://wchomak.spaces.live.com/blog/cns!F56EFE25599555EC!824.entry?sa=646856610
- http://blogs.technet.com/jonathanalmquist/archive/2008/08/14/operations-manager-2007-spn-s.aspx
- http://blogs.technet.com/kevinholman/archive/2007/12/13/system-center-operations-manager-sdk-service-failed-to-register-an-spn.aspx

3.  Check the Operations Manager database.

- Go into SQL Enterprise Management Studio 
- Expand Databases, OperationsManager, and Tables
- Right click on MT_ManagementGroup
- Click Open Table if you are using SQL Server 2005 or click Edit Top 200 Rows if you are using SQL Server 2008.
- Look at the Value in column SQLServerName_6B1D1BE8_EBB4_B425_08DC_2385C5930B04
- This should be the name of your operations manager database server.  (If you ever moved your operations manager database to a new SQL server there is a chance that this step got missed.)

Event: 21016

OpsMgr was unable to set up a communications channel to scomrms1.scom.com and there are no failover hosts.  Communication will resume when scomrms1.scom.com is available and communication from this computer is allowed.

and

Event: 21007

 The OpsMgr Connector cannot create a mutually authenticated connection to scomrms.scom.com because it is not in a trusted domain.

I ran MOMCertImport and everything seemed to be fine.  After taking a look into HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings\ I realized that there was no reg key for ChannelCertificateSerialNumber.

This told me there was a problem with running the MOMCertImport tool as nothing was being written to the registry.

It turns out that running MOMCertImport doesn’t call the UAC dialog box the application runs and lets you select you cert and exits normally.  So what you must do is right click on MOMCertImport.exe and click on Run as administrator.

Then click Continue in the UAC dialog box.

The Health Service on computer SCOMMS.mydomain.com failed to resolve Secure Reference override. This issue may affect multiple instances. Additional details: Account for RunAs profile in workflow “Microsoft.Linux.RHEL.5.Process.Klog.Restart”, running for instance “Red Hat Enterprise Linux Server release 5.3 (Tikanga)” with id:”{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}” is not defined. Workflow will not be loaded. Please associate an account with the profile. Management group “MG”

So how do we fix these problems?  After searching for a solution I came across Marius Sutara’s Secure Reference Helper tool.   http://blogs.msdn.com/mariussutara/archive/2009/04/09/tool-opsmgr-2007-r2-what-to-do-with-secure-reference-override-alert.aspx

I downloaded the 64-bit version of the program but when I tried to install it, the installation failed.

I tried it on another RMS server and it failed there too.  So we can’t even use the tool because the installer doesn’t work.  Not so fast.

Lets extract the files from the MSI and see what it does.

msiexec /a “c:\temp\SecureReferenceSetup.x64.msi” /qb TARGETDIR=”c:\securefiles”

Here are the files from the MSI.

Microsoft.SystemCenter.Community.SecureReferenceHelper.xml - This file just creates the task in the actions pane.  (Not all that useful to me)
SecureReference.exe – This is the meat of the application.  You can run this program standalone as long as you have the .net 3.5 framework installed.
SecureReference.SetupAction.exe -  This is the installer that was failing.
So lets see what this puppy does.

I launch the SecureReference.exe app and get a login screen.  If you have admin access to the RMS you can just type in the RMS server name in the box.

I uncheck perform removal of duplicate alerts automatically.

Using the tool and I can plainly see that the problem is with the Unix Privileged Account.  I set the Unix Privileged Account to my Unix Action Account and my problem is solved.

**Update** some people were still having problems extracting the files so I posted the executable for the application on my blog.

http://www.scom2k7.com/downloads/SecureReference.zip

Application: System Center Operations Manager 2007 R2
Application Version: 6.1.7221.0
Severity: Error
Message:

: Verification failed with [1] errors:
——————————————————-
Error 1:
: Failed to verify View with ID: View_1f1998325fe94ccb97855d7154bfa30c
Target property :ManagementPackElement=Service_ceecc43c88ee428197f7eafbf91236e2 in ManagementPack:[Name=my.managementpack, KeyToken=, Version=1.0.0.0] for this View is incorrect.Cannot find ManagementPackElement [Type=ManagementPackClass, ID=Service_ceecc43c88ee428197f7eafbf91236e2] in ManagementPack [ManagementPack:[Name=my.managmentpack, KeyToken=, Version=1.0.0.0]]
——————————————————-

The reason for this error is that there is a view that you created in the Monitoring Console to display the distributed application.  You have to delete this view first.  Then you can delete the distributed Application.

Turns out there is a nice override to disable discovery of these in the “SQL 200x Database Engines (Windows Server)” discovery.

All you need to do is find the SQL 200x Database Engines (Windows Server) discovery.  Create an override “For all objects of type: Windows Server”

Then choose the Parameter Name “Exclude List” and type in “SQLEXPRESS”.

First I tried a basic vb script, like this.

This works fine in a directory with only a few files but my directory has 10,000 other files in it.  I ran this script waited 10 minutes and then canceled it.  Obviously this was not going to work as the script has to touch every file in the directory.  Operations Manager would time out way before the script finishes.

So after many Google and Bing searches looking for a different vb scripts to count only the xml files, I decided to see how easy it would be in C#.

In C# it was a piece of cake.  You can download the C# project file with source here.
http://www.scom2k7.com/downloads/filecount.zip 

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.IO;

namespace filecount

{

    class Program

    {

        static void Main(string[] args)

        {

            string directoryPath = args[0];

            string eXtension = “*.” + args[1];

            int fileCount = System.IO.Directory.GetFiles(directoryPath,

            eXtension).Length;

            Console.WriteLine(fileCount);

        }

    }

}

I ran the executable that visual studio created with two parameters “directory” and “extension” and it took one second to count the number of xml files in the directory.  This is what I was looking for, way faster and more efficient. 

So now I have a working executable the takes two parameters.  How do I get it to work with SCOM? 

The easiest way was to remove the Console.WriteLine(fileCount) and set the count to the exit code. 

Environment.Exit(fileCount);

Now all I need to do is wrap this executable with a vbscipt and have SCOM call it. You can download the vb script here. http://www.scom2k7.com/downloads/advanced.zip

Dim oAPI, oBag, objShell, objFSO, objFile, myCMD, bWaitOnReturn, returnCmd, oArgs

Set oAPI = CreateObject(“MOM.ScriptAPI”)

Set oBag = oAPI.CreateTypedPropertyBag(StateDataType)

Set oArgs = WScript.Arguments

If oArgs.Count < 3 Then

Call oAPI.LogScriptEvent(“FileCountCSharp.vbs”, 500, 0, “Script aborted. Not enough parameters provided.”)

WScript.Quit -1

End If

folder = oArgs(0)

extension = oArgs(1)

userCount = cint(oArgs(2))

bWaitOnReturn= True

Set objShell=CreateObject(“WScript.Shell”)

Set objFSO=CreateObject(“Scripting.FileSystemObject”)

strPath=“C:\ScomTools\filecount.exe”

If objFSO.FileExists(strPath) Then

set objFile=objFSO.GetFile(strPath)

myCMD = strPath & ” “ & folder & ” “ & extension

returnCmd = objShell.Run (myCMD,0,bWaitOnReturn)

Else

Call oAPI.LogScriptEvent(“filecount.exe”, 510, 0, “Can’t find EXE to run Script”)

WScript.Quit

End If

If returnCmd > userCount Then

            strReturn = userCount

            Call oBag.AddValue(“State”,“BAD”)

            Call oBag.AddValue(“ret”,strReturn)

      Else

            Call oBag.AddValue(“State”,“GOOD”)

End If

Call oAPI.Return(oBag)

To test it I ran this command cscript c:\temp\newtest.vbs “c:\temp” “xml” 4 saying if there are more than 4 files in the directory and should return BAD state and how many files actual files are in the directory.  This is what I got back.

<DataItem type=”System.PropertyBagData” time=”2009-06-17T10:58:59.3066298-04:00″
sourceHealthServiceId=”B3B5A38D-0DBE-5CA9-592D-B76333A989D8″>
<Property Name=”State”VariantType=”8″>BAD</Property>
<Property Name=”ret” VariantType=”3″>5</Property></DataItem>

Looks good now to test a good condition.  cscript c:\temp\newtest.vbs “c:\temp” “xml” 25 saying if there is more than 25 xml files create an alert.  There is not  more than 25 files so the scom script should return good.

<DataItem type=”System.PropertyBagData” time=”2009-06-17T10:59:34.5256052-04:00″
sourceHealthServiceId=”B3B5A38D-0DBE-5CA9-592D-B76333A989D8″>
<Property Name=”State” VariantType=”8″>GOOD</Property></DataItem>

Ok now we have a good working script and c# executable.  Now we just need to put the script into a monitor and copy the file to the server we want to monitor and we are done.  You can follow these directions if you don’t know how to put the script into a monitor.  http://www.scom2k7.com/create-a-script-based-unit-monitor-in-opsmgr2007-via-the-gui/

So now think of the possibilities.  Anything that can be called from C# can now be monitored in SCOM.  SDKs, APIs, Web Services, are all easily leveraged in C#.    The only downside is you need the executable on the server the monitor is running on, but that could be fixed by having the script to check for the executable and if it wasn’t there you could copy it from a centralized network location.

You may have known that Windows Server 2008 RTM shipped as Service Pack 1. This is because the Windows Server 2008 code base is shared by Windows Vista, and Windows Vista was at SP1 when 2008 shipped. Windows Server 2008 SP2 was released on May 26, 2009 and was the first service pack you can actually apply to Windows Server 2008.

Unlike Windows Server 2003 R2, which was based on the same code base as Windows Server 2003 SP1, Windows Server 2008 R2 is based on an entirely different code base (Windows 7). The Windows 7 code base is derived from Vista, but is actually a seperate kernel. This change in strategy was required to address challenges that 2008 R2 faced, such as hardware platforms with many processor cores and new power saving features that couldn’t be addressed by keeping the same kernel as Server 2008.

For this reason, Windows Server 2008 R2 RTM will ship as service pack level SP0, not SP1.

Good to know as I plan on upgrading all of my SCOM R2 Servers to Windows 2008 R2.

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032409727&CountryCode=US

Agenda

- Deployment and Performance Best Practices

- High Availability and Disaster recovery Best Practices

- Virtualization Best Practices

- OpsMgr R2 Deployment and Upgrade

- Deployment Case Studies