Sometimes for a variety of reasons it becomes necessary to try and figure out which gateways are paired to which management servers and unfortunately this is a configuration that can often slip under the radar when documenting a management group.
Luckily there is a simply way to figure this out without having to log on to each server and trawl through the registry.
Powershell to the recue!
Get-SCOMGatewayManagementServer | where {$_.Name –eq “< GATEWAY SERVER >”} | Get-SCOMParentManagementServer
Note: this command has changed slightly from past versions of SCOM
With Event Log collection in Azure Monitor Logs (Log Analytics), if the log name is too long you can’t see the full name in the UI and it can be tricky to check what the log is.
Especially if you don’t have data yet.
Here’s a quick script using Get-AzOperationalInsightsDataSource that will display the event logs you are collecting.
A post I came across from Ian Blyth with a short powershell script to show which Resource Pools your management servers are part of. It’s quite useful to see all of the resource pool members in one place without having to open each one in the console, particularly in larger environments.
This situation will occur when you try and remove a management pack that utilities a Run As account. You’ll get an error that the management pack is dependent on Microsoft.SystemCenter.SecureReferenceOverride and removing that can be a little bit painful.
Anyone one who has ever removed a management pack with a dependency knows the old method of exporting the management pack, removing the offending refference and importing it back again. The steps for Microsoft.SystemCenter.SecureReferenceOverride are slightly different but the principle is the same.
1. First you need to remove the Run AS account from the Run As Profile
2. Export the Microsoft.SystemCenter.SecureReferenceOverride management pack
3. Edit the management pack and remove the references as you would with any other dependency
4. Increment the management pack version
5. Re import the management pack
Here is a nice method from Matthew Long which uses powershell and doesn’t require any XML editing.
The below is copied for my records, original posting here
Open a powershell session with the Operations Manager module/snappin loaded.
Now we can view the referenced management packs by typing $MP.References
From the list of items in the Key column, note down the alias of your MP you wish to delete. If you are having trouble finding it, the Value column will list the full ID of the MP.
Now that we know the MP alias, we can remove it from the Secure Reference MP by typing $MP.References.Remove(“yourMPAliasGoesHere“)
Now we can verify the MP is valid by entering $MP.Verify() to ensure there are no orphaned overrides, etc.
Finally, we can save our changes by typing: $MP.AcceptChanges()
An odd issue I encountered today at one of my customers that has recently completed a migration to SCOM 2012 R2, when trying to open the overrides node with no scope selected I got the following error “An object of class ManagementPackClass with ID <GUID Removed> was not found” and then the view shows 0 overrides until the console is reopened with a /clearcache.
Turns out this error is caused by having an override that references a class that no longer exists, in order to track it down you first have to access the overrides which you can no longer see unless you do the following:
1. Export your overrides to text file using poweshell by running get-scomoverride | out-file c:\SCOMOverrides.txt 2. Search the output text file for the GUID which was in the original error “An object of class ManagementPackClass with ID <GUID Removed> was not found”
3. The GUID will appear on a line labeled Context, below that one look for a line labeled Identifier, In my case it looked as follows “Identifier: 1|Windows.Operating.System.Custom.Monitors”
4. Generally this is enough information to identify which management pack needs to be deleted if it is not then continue to step 5
5. In SQL run the following query, remebering to edit it for your Identifier, against your operationsmanager database select * from ManagementPack where ManagementPackSystemName like ‘Windows.Operating.System.Custom.Monitors’ 6. Once you have identified which management pack is causing your issue it needs to be deleted, once the new configuration is processed you will be able to see your overrides again.
Kevin Holman has posted a couple of powershell scripts to simplify enabling proxy for SCOM 2012 agents, proxy always on is a particularly handy find:
Turn on agent proxy for all agents where it is disabled: get-SCOMagent | where {$_.ProxyingEnabled -match “False”} | Enable-SCOMAgentProxy
Turn on agent proxy as a default setting for all new agents to be deployed, never to have to mess with this again: add-pssnapin “Microsoft.EnterpriseManagement.OperationsManager.Client”; new-managementGroupConnection -ConnectionString:scomserver.domain.com; set-location “OperationsManagerMonitoring::”; Set-DefaultSetting -Name HealthService\ProxyingEnabled -Value True
Well the old “Manually installed agent that doesn’t appear under pending management” situation still exists in SCOM 2012. What is different is that the powershell cmdlet get-agentpendingaction no longer works.
Instead we have the following cmdlet Get-SCOMPendingManagement which provides you all agents
that are in pending management and with Approve-SCOMPendingManagement you can approve the agent you need to.
For a specific agent open the Operations Manager Shell and enter: Get-SCOMPendingManagement | where {$_.AgentName -eq “ServernameFQDN“} | Approve-SCOMPendingManagement
