I've been getting some questions about this lately, so I thought it would be a good post.
One of the big questions is, "why doesn't this work". Well, it does work! The confusion usually comes from not knowing that the disable override needs to be targeted at the same class as the Object Discovery.
A couple of quick notes before I dive into the mechanics of removing discovered object.
A couple reasons why this cmdlet is useful.
1. It enables us to quickly remove discovered objects, in order to remove these instances from being included in workflows from a MP, instead of going through a mountain of rules and monitors and creating disable overrides.
2. It enables us to cleanup discovered objects. For example - we create a group of agents to include in AD Client Monitoring after the ADMP is imported. Down the road, it is decided that we don't want some of those agents to participate in AD Client Monitoring. So we remove a few agents from the group, but the discovered objects remain...hence, the AD Client Monitoring workflow is still delivered to that agent. We need to run the cmdlet to finish the job. A little more about this at the end.
For this example, I will be removing AD Client Monitoring objects. This example assumes you have ADMP imported with some agents enabled for AD Client Monitoring. However, the steps are the same for any kind of inventory you wish to remove.
First, open up the console and take a look at the Monitoring pane > Discovered Inventory. In the Action pane, click Change target type. Select Active Directory Client Perspective.
As you can see, I have 8 agents enabled for Client Perspective. In this example, I'd like to remove 3 of these objects.
What I need to do here, is go into the Authoring pane > Object Discoveries. Scope to Active Directory Client Perspective. As you see, the discovery is targeting Windows Computer. This is what we need to target to remove the discovered objects.
Now, we could go ahead and disable override for specific agents. But, if you have more than a handful, you might consider creating a group. Either way, we're going to need to target Windows Computer in order for this to work.
I'm creating a group, targeting Windows Computer, and adding my 3 explicit members.
After our group is created, let's go back to Authoring > Object Discoveries. Override the discovery for a group. In the override, select the Enable parameter and change to False. Remember to save to your MP (not default MP).
Now, open Operations Manager Command Shell and run
Remove-DisabledMonitoringObject
There is no indication in the cmdlet that anything really happened. But, if you go back to the Monitoring pane > Discovered Inventory, you'll notice that the inventory has disappeared. This is fairly instantaneous. If your inventory is still there, go to step one :)
A little tip on removing discovered objects for, let's say...AD Client Monitoring! As we know, this discovery is not enabled by default. We create a group and apply an enable override to it, in order to get AD Client Monitoring to the agent. One might think that in order remove AD Client Monitoring from a couple agents down the road, we may just remove those couple of agents from the group and run the Remove-DisabledMonitoringObject cmdlet. Because the discovery is not enabled by default...right?
Unfortunately, that's not the case. It's not enabled...but, it's not disabled either.
We could create a group, populate it with only those agents, disable override the discovery for that group, and run the cmdlet. Furthermore, to keep things tight, we'd need to take those agents out of the enable group. Then, we could delete our group we just created to remove those agents. But that's a lot of work!
Another way is to, go into your current override for enabling the group, change the enable parameter to false, run the cmdlet, then change the enable back to true.
Follow me?
Sealing a Management Pack is easy. Although, it can be frustrating the first time through. It's a process that requires a few different pieces to interact, so preparation is key. Going through some simple steps now will save time in the future.
- Create a directory somewhere on a workstation where you'll be sealing MP's. For this example, I created the directory c:\MPS
- I also created four directories within c:\MPS
- \Input - this directory will contain the MP to be sealed
- \Output - this directory will contain the sealed MP
- \MP - this directory will contain all the referenced MP
- \Key - this directory will contain the pair key file
- Copy MPSeal.exe from the source installation files "SupportTools" directory to the c:\MPS directory
- Copy sn.exe to the c:\MPS directory
- Copy your unsealed MP into the \Input directory
- Copy all the *.mp files from the RMS installation directory into the \MP directory
- Usually "%Program Files%\System Center Operations Manager 2007\"
- Also, copy all *.mp files that you'll be referencing to the \MP directory
- TIP: I'd just keep this directory updated with all available current MP's (ie; Active Directory, Exchange, etc)
So, the c:\MPS directory will look like this.
Now, we're ready to seal our Management Pack.
Open a command prompt and navigate to your work directory (c:\MPS). Run these commands in sequence.
- sn -k c:\mps\key\PairKey.snk
- sn -p c:\mps\key\PairKey.snk c:\mps\key\PubKey
- sn -tp c:\mps\key\PubKey
- mpseal c:\mps\input\<unsealed_mp>.xml /I "c:\mps\mp" /Keyfi
e "c:\mps\key\PairKey.snk" /Company "Your Company" /Outdir "c:\mps\output"
You should now have your sealed MP in the Output directory. And, you'll have a working directory for later use. Just remember to keep the MP versions in the c:\MPS\MP directory current with your Management Groups. Otherwise, you'll get version errors while attempting to run the MPSeal tool.
Hint: Once you've created the key the first time around, it's not necessary to create a new key each time you seal a MP. The current key may be reused. So, the only step you'll need to actually do after the first run is the last step. How's that for easy!
Let's say you have an agent Health Service that has been restarting for some reason. One thing you can do to help identify Health Service restart trends is to collect and examine some relevant local agent performance counters. In particular, this will not pinpoint root cause. But it's a good place to start, and I thought I would blog about something fun and easy!
On the agent computer, open Performance Monitor. Right-click Counter Logs, click New Log Settings.
Type in a name for the new log.
Click Add Counters. Under Performance object, select Process from the drop-down list. In Select counters from list, select Private Bytes. In Select instances from list, select HealthService. Click Add.
Also select any MonitoringHost instance in the list. You can make multiple selections by holding control key. Click Add, then close.
Under the General tab, you should see your added counters. Just keep the defaults here, and note the location of the Current log file name.
Click on Schedule tab. One setting here that may need to be adjusted, is the Stop log setting. Depending on how often the HealthService is restarting, you should adjust this accordingly so that you'll have enough data to trend the Private Bytes counters.
That's it. Click OK, and your new counter log should appear with a green icon (indicating that it's running).
Let it run for the allotted time, then open it to view the data. Here's how.
In Performance Monitor, select System Monitor in left pane. Right-click in the graph pane, and click Properties.
On the Source tab, click Log files. Click Add button and locate your counter log.
Notice the Time Range area. If these counters were collecting for days, you might want to zoom in on a specific day/hour to view a more detailed graph of the counters. You can move the viewable timeframe by clicking on either side of the bar (highlighted yellow) and moving to desired range.
Click the Data tab and add the counters you collected to the list. Remove other counters.
On the Graph tab, you may need to adjust the minimum/maximum values. If a counter is off the chart, come back to the graph tab and adjust the maximum value up until you can see all data.
Results of my collection. This looks healthy. An unhealthy agent, or one that continues to reach restart thresholds, may show high/low spikes.
There's a lot of confusion about SPN's (service principal name) when it comes to OpsMgr. How are SPN's registered? When are SPN's registered? Why aren't SPN's registering?
For brevity, I will direct your attention to the following links for more information on what, when and how.
http://wchomak.spaces.live.com/blog/cns!F56EFE25599555EC!824.entry
Thanks Walter!
The reason I'm blogging on this is to give a snapshot of all the SPN's that should be in your environment so you know you've get them all right. Here's a birds-eye view.
Root Management Server:
servicePrincipalName: MSOMSdkSvc/
rms.domain.com servicePrincipalName: MSOMSdkSvc/
rms servicePrincipalName: MSOMHSvc/
rms.domain.com
servicePrincipalName: MSOMHSvc/
rms servicePrincipalName: HOST/
rms.domain.com servicePrincipalName: HOST/
rms Management Server(s):
servicePrincipalName: MSOMHSvc/
ms.domain.com servicePrincipalName: MSOMHSvc/
ms servicePrincipalName: HOST/
ms.domain.com servicePrincipalName: HOST/
ms Management Server with ACS:
servicePrincipalName: AdtServer/ms.domain.com
servicePrincipalName: AdtServer/ms
servicePrincipalName: MSOMHSvc/ms.domain.com
servicePrincipalName: MSOMHSvc/ms
servicePrincipalName: HOST/ms.domain.com
servicePrincipalName: HOST/ms
Database Servers (including ACS DB):
servicePrincipalName: MSSQLSvc/db_server:1433
servicePrincipalName: MSSQLSvc/db_server.domain.com:1433
You can use SETSPN -L <server_name> to view these. Another quick way to view these is with the ldifde tool.
Ldifde -f c:\ldifde.txt -t 3268 -d DC=domain,DC=COM -r "(serviceprincipalname=MSOM*)" -l serviceprincipalname -p subtree
Thanks to Kevin for the ldifde query.
To query the SQL Service SPN, the queries will look like:
SETSPN -L <domain\sql_service_account>
Ldifde -f c:\ldifde.txt -t 3268 -d DC=domain,DC=COM -r "(serviceprincipalname=MSSQLSvc*)" -l serviceprincipalname -p subtree
You'll most likely find multiple SPN's for SQL Service. Just be sure there's one for each of your OpsMgr DB role servers. If SQL runs under Local System, it will automatically register its SPN's each time the service starts.
I can see this as being a common setting to overlook, so thought I would write a quick blog on it.
If you want to schedule a report for delivery to an email recipient, first you'll need to configure SSRS with a valid email server. Otherwise, you will not have the email option available while configuring your scheduled report delivery.
Subscribe to a Report: No email option
Logon to the Report Server, and launch Reporting Services Configuration.
Click Email Setting in left pane, and fill in Sender Address and SMTP Server fields. Then click apply.
You should now have a green check next to Email Settings in left pane.
Go back to schedule a report, and E-Mail option is now available.
If you open the properties of this alert rule, you'll see that the configuration data source scans the Operations Manager log on the Management Server for event ID 11852. Filtering on this event and comparing to the Application or System log on your Operations DB server, you might notice that these events coincide with the MSSQLService being stopped. Of maybe you'll see 6009 System events, indicating the server had rebooted.
This would obviously cause logon failures to the operations DB for the SDK or MSAA accounts. Take a look at the Application log on your DB server, and you'll likely see a bunch of 18456 failure audit events at the same time this alert is generated. It appears as though the Management Server attempts a connection approximately every 15 seconds. So, the longer the DB is down, the greater the repeat count on this alert.
As this is targeted at Management Servers, and it seems this event is only generated when the Operations DB is unavailable for abovementioned reasons, I'm not quite sure what value this rule provides. If the Operations DB is unavailable, the management server will generate this event locally. When the Operations DB is available and Operations Manager can connect to it, only then will this event be collected and an alert generated.
Also, we cannot plan a Maintenance Mode scenario to circumvent the alert (http://blogs.technet.com/cliveeastwood/archive/2007/09/18/agentmm-a-command-line-tool-to-place-opsmgr-agents-into-maintenance-mode.aspx). I haven't seen any other cases where this event generates an alert for this rule. My solution to this pesky problem - override the rule > For all objects of type: Management Server.
UPDATE:
This has been fixed in a recent hotfix (951979). This also fixes a number of other issues.
http://support.microsoft.com/kb/951979
If you cannot apply this hotfix now for whatever reason...read on...
You have probably seen this alert in your Operations Manager console, after upgrading to SP1. This monitor has been identified as a bug, and the workaround is posted all over the blogs. If you're like me, I generally take the advice of anything posted on Operations Manager Product Team Blog.
Here is the product team's posting for this workaround.
http://blogs.technet.com/momteam/archive/2008/03/01/performance-module-could-not-find-a-performance-counter.aspx
There is only one thing I would add to this. It's a good practice to save overrides to your own management packs. As you probably know, if you override a rule/monitor by right-clicking and traversing > Overrides > Disable the Rule, this action will always save the override in the Default Management Pack. This is why I advise customers to disable a rule by traversing > Overrides > Override the Rule, set the "enabled" parameter to false, and place the override into a MP other than the Default MP. I always advise a customer to create a MP, and never use the Default Management Pack. And this case is no exception.
In fact, in my environment I have a MP called "Override - Product workaround and bug". As you might suspect, I use this MP specifically for overrides pertaining to workarounds or bugs in the Operations Manager product or Management Packs themselves. This helps to keep these types of overrides organized in one container, so as not to mix them up with overrides that were decided upon by [your] organization.
Copy this script into a .vbs file. Edit line 15 (objAlert.TimeRaised = "xxxxxxxx245959"). Replace xxxxxxxx with YearMonthDay (ex: 20080401). TimeRaised is a Date/Time stamp. The 245959 simply means 12:59:59pm. So, any alert raised on or before this date will be updated to a "Resolved" state. Run this on a MOM 2005 Management Server.
Set objWMI = GetObject("winmgmts://./root/MOM")
strQuery = "select * from MSFT_Alert where ResolutionState <> 255"
Set colAlerts = objWMI.ExecQuery(strQuery)
For Each objAlert In colAlerts
If Len(Trim(objAlert.AlertHistoryComment)) = 0 Then objAlert.AlertHistoryComment = Null
If Len(Trim(objAlert.CustomField1)) = 0 Then objAlert.CustomField1 = Null
If Len(Trim(objAlert.CustomField2)) = 0 Then objAlert.CustomField2 = Null
If Len(Trim(objAlert.CustomField3)) = 0 Then objAlert.CustomField3 = Null
If Len(Trim(objAlert.CustomField4)) = 0 Then objAlert.CustomField4 = Null
If Len(Trim(objAlert.CustomField5)) = 0 Then objAlert.CustomField5 = Null
If Len(Trim(objAlert.Description)) = 0 Then objAlert.Description = Null
If Len(Trim(objAlert.OwnerName)) = 0 Then objAlert.OwnerName = Null
If Len(Trim(objAlert.ResolvedBy)) = 0 Then objAlert.ResolvedBy = Null
If Len(Trim(objAlert.TimeResolved)) = 0 Then objAlert.TimeResolved = Null
If ObjAlert.TimeRaised <= "xxxxxxxx245959" then
objAlert.ResolutionState = 255
objAlert.Put_
End If
Next
Additional notes:
If we execute an Update query to the OnePoint DB directly, we are essentially circumventing MOM from performing it's normal Alert update process and some interesting fields (like TimeResolved, ResolvedBy, etc) will not be updated properly. This is why it's recommended to use this method if the console will not suffice.
Also, a note about updating particular blank fields in the script to NULL. If these blank fields are not updated to NULL, the script will fail. This is not a SQL or MOM issue. It's a problem with SWBemObjectEx. Blank fields cannot be handled. Specifically, you'll receive the following error:
If you have created a scheduled report to send to an email recipient outside of your organization, you may run across the issue of the email address not being valid. Specifically, the status of the report will be:
The e-mail address of one or more recipients is not valid.
Example 1
This may be due to the fact that the Reporting server does not have access to relay SMTP messages through your Exchange server. Follow these steps to configure your Exchange server to relay SMTP messages to recipients outside your organization for your Reporting server.
1. Logon to the Exchange server, and open Exchange System Manager.
2. Navigate to Default SMTP Virtual Server
Example 2
3. Right-click > Properties. Click on Access tab. Then, click on Relay button.
Example 3
4. In Relay restrictions, click Add button. Add the IP Address for the Reporting server. Or, click on DNS Lookup and type in the name of the Reporting server. This option will populate the IP Address for you.
Example 4
5. Restart Default SMTP Virtual Server. Right-click > Stop. Right-click > Start.
Example 5
There are some roadblocks if you choose to install Reporting after your Management Group has already been running the SP1 upgrade. Without going into great detail, it seems the conflict is directly related to Management Pack versions already imported into the SP1 deployment and versions in the RTM installation of Reporting. I've tested this with only a minimal set of MP's currently running in my SP1 environment. If you have a number of MP's imported into your MG, there may be other MP dependencies. Either way, the installation log file should output that information for you.
So, my process was to simply install the Data Warehouse RTM and Reporting RTM. Then, to upgrade both these components to SP1. The Data Warehouse components installed fine. The Reporting part did not. I opened the installation log (choose to view the installation log file on the last dialog box of a failed installation, or by navigating to "C:\Documents and Settings\%username%\Local Settings\Temp\MOMReporting*.log").
Following are some failures I noted from the installation log while attempting the Reporting installation.
Failed to load MP C:\Program Files\System Center Operations Manager 2007\Reporting\Microsoft.SystemCenter.DataWarehouse.Internal.mp
Failed to load MP C:\Program Files\System Center Operations Manager 2007\Reporting\ODR.mp
I decided to delete these MP's, first by exporting and deleting the Default MP (as there were dependencies). I then re-imported the Default MP and proceeded with the Reporting installation. This was a success. As well, the installation imported the MP's I had deleted in previous steps.
I then proceeded with the SP1 upgrade of the Data Warehouse and Reporting components without issue. After a period of time (20-30 minutes), I saw reports populated in the console Reporting pane.
By the way, I have seen others with issues installing Reporting in a MG that is already at SP1 level and there solutions were different. This workaround may or may not work, depending on your design and configuration. This is just one example and how I went about solving this problem in my environment.
You can follow these steps to change/update the credentials used for a single agent or group of agents in a MOM 2005 Management Group.
1. Change the password for the account used as the Agent Action account in Active Directory.
2. To find the agents that are using a particular Action Account, run the following query against your OnePoint database:
use OnePoint
Select Name, Value
from Attribute INNER JOIN Computer ON DISCOVERYCOMPUTERID = IDCOMPUTER
WHERE ClassAttributeID IN (Select ClassAttributeID from ClassAttribute where
ClassAttributeName = 'Action Account Identity')
AND IDComputer IN (Select DiscoveryComputerID from Attribute WHERE
ClassAttributeID IN (Select ClassAttributeID from ClassAttribute where
ClassAttributeName = 'Action Account Identity'))
order by value, name
3. In the MOM 2005 Administrator console, navigate to Administration > Computers > Agent-Managed Computers.
4. Select all the agent-managed computers that are using the Action Account for which you are changing the password. Refer to the results of the query in step 3.
5. Right-click on the selection(s), and choose All Tasks > Update Agent Settings.
6. Enter the new Action Account credentials.
PowerShell script to import User Roles. Copy and save code to file with .ps1 extension. Execute PS script from within SCOM Command Shell or PowerShell. User input prompts will not work if copying and pasting code directly into shell.
This script works in conjunction with the ExportUserRoles script. Otherwise, the input file must be in the following format:
Profile: <monitoringProfile>
Name: <userRoleName>
DisplayName: <userRoleDisplayName>
Description: <userRoleDescriptioin>
Users: <account1 account2 account3>
There is no validation of accounts worked into this script. If an account cannot be queried in AD, the script will throw errors but continue to process. Use netbios name for accounts/groups (domain\account).
##--------------------------------------------------##
# Use this script to import User Roles.
# This script requires the User Roles to have
# already been exported using the ExportUserRoles
# script, or a text file in the same format as the
# output of the ExportUserRoles script.
# Author: Jonathan Almquist
# Name: ImportUserRoles.ps1
# Ver: 6.0.6278.0-1
# Date: 03/23/2008
# Revisions:
##--------------------------------------------------##
## Get user input
$rms = read-Host "Enter the RMS server name"
$filename = read-Host "Enter path and filename for output file (ex: c:\user_roles.txt)"
## Check for Operations Manager Snap-in
$snapin = pssnapin | select-Object name
$added = 0
## Loop through each instance of Snap-in
foreach ($pssnapin in $snapin)
{
if ($pssnapin -like "*Microsoft.EnterpriseManagement.OperationsManager.Client*")
{
$added = 1
}
}
if ($added -eq 0)
{
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"
write-Host "Operations Manager Snap-in added."
}
else
{
write-Host "Operations Manager Snap-in already added."
}
set-location "OperationsManagerMonitoring::"
## Check for Monitoring Drive
$drive = psdrive | select-Object name
$added = 0
## Loop through each instance of Drive
foreach ($psdrive in $drive)
{
if ($psdrive -like "*Monitoring*")
{
$added = 1
}
}
if ($added -eq 0)
{
New-PSDrive -Name: Monitoring -PSProvider: OperationsManagerMonitoring -Root: \
write-Host "Monitoring Drive added."
}
else
{
write-Host "Monitoring Drive alreaded added."
}
## Connect to Management Group
New-ManagementGroupConnection -ConnectionString: $rms
cd Monitoring:\$rms
$mg = (get-item .).ManagementGroup
$lines = get-content $filename
foreach ($line in $lines)
{
if ($line.StartsWith("Profile:"))
{
$profile = $line -replace "Profile: ", ""
}
elseif ($line.startswith("Name: "))
{
$name = $line -replace "Name: ", ""
}
elseif ($line.startswith("DisplayName: "))
{
$displayName = $line -replace "DisplayName: ", ""
}
elseif ($line.startswith("Description: "))
{
$description = $line -replace "Description: ", ""
}
elseif ($line.startswith("Users: "))
{
$users = $line -replace "Users: ", ""
if ($users -like "* *")
{
$users = $users.Split(" ")
}
## When the script reaches the Users line, this Role block is complete.
## Begin Role check and creation
$rolelist = get-userrole | select-object name
$added = 0
foreach ($role in $rolelist)
{
if ($role -like "*$name*")
{
$added = 1
}
}
if ($added -eq 0)
{
$getProfile = $mg.GetMonitoringProfiles() | where {$_.Name -eq $profile}
$obj = new-object Microsoft.EnterpriseManagement.Monitoring.Security.MonitoringUserRole
$obj.Name = $name
$obj.DisplayName = $displayName
$obj.Description = $description
$obj.MonitoringProfile = $getProfile
$mg.InsertMonitoringUserRole($obj)
write-Host "$name User Role added."
}
else
{
write-Host "$name Role alreaded added."
}
## Compare user list and add users
if ($users -notlike "")
{
foreach ($user in $users)
{
write-host "Adding $user to $displayName"
$addUser = get-userrole | where {$_.name -eq $name}
$addUser.users.add($user)
$addUser.update()
}
}
else
{write-Host "No users in $displayName"}
## Move on to the next Role block.
write-Host "`r`n"
}
}
write-Host "Process complete."
##
##
PowerShell script to write all User Roles to a text file. Copy and save code to file with .ps1 extension. Execute the *.ps1 script from within SCOM Command Shell or PowerShell. User input prompts will not work if copying and pasting code directly into shell.
The output file can be used in conjunction with the ImportUserRoles script. Format of the output file is as follows:
Profile: <monitoringProfile>
Name: <userRoleName>
DisplayName: <userRoleDisplayName>
Description: <userRoleDescriptioin>
Users: <account1 account2 account3>
##--------------------------------------------------##
# Use this script to export User Roles to a text
# file. The output file from this script can be
# used in conjunction with the ImportUserRoles
# script.
# Author: Jonathan Almquist
# Name: ExportUserRoles.ps1
# Ver: 6.0.6278.0-2
# Date: 03/20/2008
# Revisions:
# -Added user input prompt for RMS server name
# -Added user input prompt for file path & name
# --quotes not required for path with spaces
# -Added pssnapin checking
# -Added psdrive checking
# -Management Group connectivity from PS
##--------------------------------------------------##
## Get user input
$rms = read-Host "Enter the RMS server name"
$filename = read-Host "Enter path and filename for output file (ex: c:\user_roles.txt)"
## Check for Operations Manager Snap-in
$snapin = pssnapin | select-Object name
$added = 0
## Loop through each instance of Snap-in
foreach ($pssnapin in $snapin)
{
if ($pssnapin -like "*Microsoft.EnterpriseManagement.OperationsManager.Client*")
{
$added = 1
}
}
if ($added -eq 0)
{
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"
write-Host "Operations Manager Snap-in added."
}
else
{
write-Host "Operations Manager Snap-in already added."
}
set-location "OperationsManagerMonitoring::"
## Check for Monitoring Drive
$drive = psdrive | select-Object name
$added = 0
## Loop through each instance of Drive
foreach ($psdrive in $drive)
{
if ($psdrive -like "*Monitoring*")
{
$added = 1
}
}
if ($added -eq 0)
{
New-PSDrive -Name: Monitoring -PSProvider: OperationsManagerMonitoring -Root: \
write-Host "Monitoring Drive added."
}
else
{
write-Host "Monitoring Drive alreaded added."
}
## Connect to Management Group
New-ManagementGroupConnection -ConnectionString: $rms
cd Monitoring:\$rms
## Gather information
$mgName = (get-item .).ManagementGroup.name
$date = get-date -uformat "%Y-%m-%d"
$userroles = get-userrole | select-object name,displayname,description,monitoringprofile,users
## Write output file
foreach ($role in $userroles)
{
"Profile: " + $role.monitoringprofile.name + "`r`n" + "Name: " + $role.name + "`r`n" + "DisplayName: " + $role.displayname + "`r`n" + "Description: " + $role.description + "`r`n" + "Users: " + $role.users + "`r`n" | out-file $filename -append
}
write-Host "Process complete"
##
##
So, you installed Audit Collection Services (ACS) and the collector isn't able to connect to the OperationsManagerAC database. You get a bunch of errors in your Operations Manager and Application event logs on your ACS Collector:
Event Type: Error
Event Source: AdtServer
Event Category: None
Event ID: 4618
Date: 3/13/2008
Time: 12:23:30 AM
User: N/A
Computer: OMMS
Description:
Error occured on database connection:
Status: 0x02200000
ODBC Error: 18456
ODBC State: 28000
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Database: Register
Connection: ComplianceTest
Event Type: Error
Event Source: AdtServer
Event Category: None
Event ID: 4618
Date: 3/12/2008
Time: 11:22:10 PM
User: N/A
Computer: OMMS
Description:
The description for Event ID ( 4618 ) in Source ( AdtServer ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: 0x02200000, 18456, 28000, [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'., Register, ComplianceTest, -.
If the SQL Server which hosts your ACS database is set to logon using a domain account, there may be a couple extra steps you may need to take beyond installation to get things flowing properly.
Before I go any further, first be sure you have these tools:
KERBTRAY is part of the Resource Kit Tools. Download here.
SETSPN can be downloaded here.
Logon to the SQL Server housing the ACS database. Open a CMD prompt and type the following command:
setspn -L <domain>\<account>
This is the account in which SQL Server logs in as:
Example 1
Example 2
We are looking for results like in the example. If no registered SPN's are returned, we need to register them. Do so by running the following commands:
setspn -A MSSQLSvc/<fqdn> <domain>\<account>
and
setspn -A MSSQLSvc/<fqdn>:<port> <domain>\<account>
Example 3
If you run setspn -L <domain>\<account> again, you should see the result return register SPN's like in example 2.
Now, open up Active Directory Users and Computers and navigate to the user account that SQL Server log in as. Right-click > Properties > click Account tab. Check "Account is trusted for delegation" in the Account options list.
Example 4
Now logon to a Domain Controller and startup KerbTray. You should see a green icon appear in the system tray.
Example 5
Right-click the KerbTray and click Purge Tickets. Wait for the icon to turn yellow. Then, in CMD prompt, run the command:
net session* /d
Restart the MSSQLSERVER service on the ACS SQL Server and the Audit Collection Collector Service on the ACS Collector. Soon after, new tables and views should be created in your ACS database.
Example 6
I started seeing these alerts after upgrading my Management Group to SP1. This warning alert (Operations Manager SDK service failed to register an SPN) occurred each time the SDK Service on my RMS restarted.
This is the actual event in the Operations Manager event log on the RMS.
Event Type: Warning
Event Source: OpsMgr SDK Service
Event Category: None
Event ID: 26371
Date: 3/12/2008
Time: 11:25:22 AM
User: N/A
Computer: OMRMS
Description:
The System Center Operations Manager SDK service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/OMRMS and MSOMSdkSvc/OMRMS.opsmgrlab.com to the servicePrincipalName of OPSMGRLAB\SCOM-SDK
I verified the SPN was registered for the SDK Service by running SETSPN -L. Even still, I verified there were no duplicate entries using the DHCheck.exe tool.
The summary in the alert states "...the SDK service needs to register SPN's for itself". So, the suggested resolution is slightly misleading, and I'll tell you why. Each time the SDK Service is started on the RMS, it attempts to register its SPN. The account that the service logs on with is your SDK account (in my case SCOM-SDK, which is an Active Directory account). When you create a user account in Active Directory, the account does not inherently receive Allow Read servicePrincipalName and Write servicePrincipalName permissions for the object. Given that the SDK Service needs to register SPN's for itself, we need to give our SDK account Allow permission on these properties.
Before going into this workaround, I want to express that the product group does not recommend changing permission in Active Directory in order to work around this issue with this particular monitor. If you have verified the SDK SPN is in fact registered, and workflows are functioning properly...I would just disable the monitor that is generating the alert. It has been identified that, in some cases, this monitor will detect an issue with the SDK SPN...but this is, with all intents and purposes, a false alart!
Open ADSIEdit.msc on your DC. Navigate to the account you created for your SDK Service. Right-click > Properties. Click Security tab. Click Advanced > Click add > type in SELF > Click OK. Click Properties tab. Open the Apply Onto drop-down list > select This object only. Scroll the properties list down until you find Read servicePrincipalName and Write servicePrincipalName. Select Allow for both. Click OK until all dialogue boxes are closed. Restart the SDK Service on the RMS.
