Thought I'd put together some samples of PowerShell commands for Operations Manager 2007.  It is assumed you are running these from the Operations Manager 2007 Command Shell (or all OpsMgr shap-ins are loaded).  Watch out for word wrap.  Any text in red needs to be modified to your criteria.  Check back now and then, as I will be adding to this list periodically.

FYI:  I don't claim to be a PowerShell guru.  Some of these could be reworked to run more efficiently, particularly when using in large-scale deployments.

 

Overrides

 

Get all overrides in Management Group:

Get-ManagementPack | where {$_.sealed -match "False"} | get-override | select-object name,parameter,module,rule,enforced,value,timeadded,lastmodified

 

Get all overrides in specific Management Pack:

Get-ManagementPack | where {$_.DisplayName -match "MP_Name"} | get-override | select-object Name,Rule,Monitor

 

Get all overrides that were created in a specific date/time range:

Get-ManagementPack | where {$_.sealed -match "False"} | get-override | where {$_.TimeAdded -ge "01/01/2008 00:00:00" -and $_.TimeAdded -lt "09/01/2008 23:59:59"} | select-object name,TimeAdded

 

Get all overrides that have been modified:

Get-ManagementPack | where {$_.sealed -match "False"} | get-override | where {$_.LastModified -gt $_.TimeAdded} | select-object name,TimeAdded,LastModified

 

Get all overrides that have been modified in a specific date/time range:

Get-ManagementPack | where {$_.sealed -match "False"} | get-override | where {$_.LastModified -gt $_.TimeAdded -and $_.LastModified -ge "01/01/2008 00:00:00" -and $_.LastModified -lt "09/01/2008 23:59:59"}  | select-object name,TimeAdded,LastModified

 

Get all rules overridden from specific Management Pack:

$overrides = Get-ManagementPack | where {$_.DisplayName -match "Override_MP_Name"} | get-override

$rules = $overrides | where {$_.rule}

foreach ($rule in $rules) {get-rule | where {$_.Id -eq $rule.rule.id} | select-object DisplayName}

 

Get all monitors overridden from specific Management Pack:

$overrides = Get-ManagementPack | where {$_.DisplayName -match "Override_MP_Name"} | get-override

$Monitors = $overrides | where {$_.monitor}

foreach ($monitor in $monitors) {get-monitor | where {$_.Id -eq $monitor.monitor.id} | select-object DisplayName}

 

Agent

 

Get all agents currently reporting to specific Management Server
(this needs to be run on target management sever, as it queries local IP properties)

$ip = [Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties()

$active = $ip.GetActiveTcpConnections()

$connectedAgents = $active | where {$_.LocalEndPoint -match "5723"}

$agents = get-agent

foreach ($RemoteEndPoint in $connectedAgents)
{$agents | where {$_.ipaddress -eq $RemoteEndPoint.RemoteEndPoint.Address.IPAddressToString} | select-object DisplayName}
write-host "`n`nAgents connected to this Management Server:" $connectedAgents.count

 

Approve or Reject specific agent for manual install:

$action = Get-AgentPendingAction | where {$_.AgentName –match “netbios_name” -and $_.AgentPendingActionType –match "ManualApproval”}

$action | [approve or reject]-AgentPendingAction

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.
  • You can get the sn.exe tool with the .NET Framework SDK
• 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\"

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.

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.