Search Results

Keyword: ‘$PROFILE’

Setting agent failover servers & Switching SNMP device proxies

July 7th, 2008 jpavleck 3 comments

By default, you can’t really specify a failover management server in OpsMgr. Why? Not really sure, though I think it’s a ploy to ensure you setup the OpsMgr Active Directory Integration, which will handle this for you.

No fret though, we can still do it – it’ll just take a little bit of actual effort.

First, we need to define our Primary and Failover management servers. This isn’t something you can just progmatically grab, so you’ll need to know the name yourself.

In my $PROFILE, I’ve set them to be defined to 2 variables with the following:

# Set Primary Management Server
$Primary_MS = Get-ManagementServer | ? {$_.Name -like "SERVERNAME*"}
# Set Failover Management Server
$Failover_MS = Get-ManagementServer | ? {$_.Name -like "BACKUPSERVER*"}

Now that we have that set, it’s simple to do the rest. First, lets grab all of the servers that don’t have a failover management server set.

$noFailoverSpecified = Get-Agent | ? {(!$_.GetFailoverManagementServers())}

What the above does is call the GetFailoverManagementServers() method on each agent. If they have a failover, it will return data and thus $True. If there aren’t any failovers, it will return nothing – which is the same as $False. So we look for all the ones that don’t return anything.

If you’re curious, you can see just how many servers are missing failovers with

$noFailoverSpecified.Count

- in my case it was 63.

Now, we just run a quick snippet that adds the failover server to the agent:

ForEach ($agent in $noFailoverSpecified) {
Set-ManagementServer -PrimaryManagementServer $Primary_MS -AgentManagedComputer $agent -FailoverServer $Failover_MS | Out-Null
}

That will crunch away as it’s doing it’s thing, we’re redirecting output to $null so we don’t have to see agents scrolling over and over. When it returns you to a prompt, you’re done. If you’d like to verify that you did indeed set all of the agents to have a failover, we can check real quick:

If ((Get-Agent |? {(!$_.GetFailoverManagementServers())}).Count -eq $null)
{
Write-Host "Every agent has a failover server, great job!" -ForeGroundColor Green
} else {
Write-Host "Looks like we missed some, try again!" -ForeGroundColor Magenta
}

And that’s that. All of your agents have a primary and failover server.

Screen shot of SCOM Command Shell showing steps to setup failover agents

But wait, you have a lot of remotely managed devices too? Monitoring SNMP on a bunch of different servers – what happens for that?

Well, we can’t setup a failover (From what I’ve seen, if I’m wrong please let me know) agent. But we can proactively write a script that will change the proxy agent on the devices, and run it as needed.

This was written in a response to this query on the newsgroups, and is only a cursory look into it. There may be other ways of doing this – and I’d love to hear it. As it stands, I’m not sure how to set them back to a management server as the monitor.

Firstly, we’ll have to pick an agent managed computer to use as the new proxy agent. You can’t use a management server for this, because they aren’t “Agent Managed” and you can’t use Set-ManagementServer because the devices aren’t “Remote Managed Computers”.  I have a seperate agent-managed server on my network I call “Timex” because it acts like a watcher node. So I’ll go ahead and use him.

$proxyAgent = Get-Agent |? {$_.Name -eq "timex.pavleck.net"}

Then gather a list of our current remotely managed devices

$remDevices = Get-RemotelyManagedDevice

Now just loop through it, setting the device to use the proxy agent we just instantiated:

ForEach($device in $remDevices) {
Set-ProxyAgent -ProxyAgent $proxyAgent -Device $device | Out-Null
}

That will loop through things changing the proxy server that it uses. When it’s done, we can verify it by running:

Get-RemotelyManagedDevice |? {$_.ProxyAgentPrincipalName -ne $proxyAgent.Name}

If it outputs nothing, then they’ve all been changed. Simple as that!

SCOM: Setting the proxy agent for a device via command shell

SCOM PowerShell Snippets

June 15th, 2008 jpavleck No comments

There are a lot of things you can do with System Center Operations Manager in PowerShell, that you can’t do (Or would be a pain in the butt to do) via the GUI or other methods.

I’ll place all of the snippets that I’ve picked up while in the course of my SCOM time here on this page. You can place these either in your $PROFILE, or do as I have and create a section in your $PROFILE to store certain SCOM variables, and then dot-source your SCOM-specific code. I use “. $ProfileDir\Scom_Snippets.ps1″ to load my snips.

Speaking of SCOM variables in your main $PROFILE, when I write these snippets, I assume you have them set up similar to mine. Eventually I’ll have a tutorial on how to set it all up, but for now this is what I recommend – some I use now, some I have for ‘future expansion’.

Open your PowerShell profile in your editor of choice, and add a section to it. We’ll be dot-sourcing your SCOM snippet file, as well as setting variables for SCOM

### System Center Operations Manager 2007 Variables ###
# This block holds environment specific information relating
# to the OpsMgr environment, allowing the SCOM Snippets file
# to be dot sourced and made more ‘generic’.

. $ProfileDir\SCOM_Snippets.ps1 # Load snippets script
$omserver = "SCOMServer.mydomain.com" # FQDN of SCOM RMS
$omserverip = "10.10.9.26" # IP Address of the SCOM RMS
$omdbserver = "SCOMSQLDB.mydomain.com" # FQDN of the OpsMgr SQL Server
$omdbinstance = "Default" # Name of SCOM SQL Instance
$omdb = "OperationsManager" # Name of the OpsMgr database, OperationsManager is the default
### End Operations Manager 2007 Variables ###

Once that is done, you can open or edit your SCOM_Snippets.ps1 file and begin entering the functions I show you, as well as ones you come up with on your own.

Begin the Snippets!

Function Get-AgentNameByHSID – This function will take the Health Service ID, most often referenced in the error about agent proxying “Health service ( <Health Service GUID> ) should not generate data about this managed object ( <Object GUID> ).” and return the agent name responsible for it.

Function Get-AgentNameByHSID([guid]$hsid) {
(Get-MonitoringObject -id $hsid).DisplayName
}

Function Get-ActiveRules – This function accepts 2 arguments, server name and file name/location. Server name is required, if no file name/location is given, it will by default save it to C:\$server-rules.xml. This function retrieves the currently running workflows on a given server – workflows are rules, monitors, discovery objects, and anything else that is deployed to the remote agent.

function Get-ActiveRules ([string]$server, [string]$location) {
If (!$location) { $location = "C:\$server-Rules.xml" }
# Create the Task object
$taskobj = Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.GetAllRunningWorkflows"}
# Make sure we have it, if not, the MP isn’t installed.
If (!$taskobj) {
Write-Host "Unable to find required monitoring tasks – MS System Center Internal Tasks MP needs to be installed." -ForeGroundColor Magenta;
break;
}
# Grab HealthService class object
$hsobj = Get-MonitoringClass -name "Microsoft.SystemCenter.HealthService"
# Find HealthService object defined for named server
$monobj = Get-MonitoringObject -MonitoringClass $hsobj | Where-Object {$_.DisplayName -match $server}
# Now actually proceed with the task. I have mine formatted like this version, but I’ve added some light
# error checking for the ‘public’ version.
#(Start-Task -task $taskobj -TargetMonitoringObject $monobj).Output | Out-File C:\$server-Rules.xml
$taskOut = Start-Task -Task $taskobj -TargetMonitoringObject $monobj
# See if it worked, if it did, export out the OutPut part and save as an XML file, then display some items.
If ($taskOut.ErrorCode -eq 0) {
[xml]$taskXML = $taskOut.OutPut
$ruleCount = $taskXML.DataItem.Count
Write-Host "Succeeded in gathering rules for $server" -ForeGroundColor Green
Write-Host "Currently $ruleCount rules active." -ForeGroundColor Green
Write-Host "Exporting to $location" -ForeGroundColor Green
$taskOut.OutPut | Out-File $location
} else {
Write-Host "Error gathering rules for $server" -ForeGroundColor Magenta
Write-Host "Error Code: " + $taskOut.ErrorCode -ForeGroundColor Magenta
Write-Host "Error Message: " + $taskOut.ErrorMessage -ForeGroundColor Magenta
}
}

Function Set-Failover looks for agents that do not have anything set for their failover server, and proceeds to set it. Set the primary and failover servers yourself, then it’s good to go.

Function Set-Failover() {
# Set Primary Management Server
$Primary_MS = Get-ManagementServer | ? {$_.Name -like "SERVERNAME*"}
# Set Failover Management Server
$Failover_MS = Get-ManagementServer | ? {$_.Name -like "BACKUPSERVER*"}

$noFailoverSpecified = Get-Agent | ? {(!$_.GetFailoverManagementServers())}

ForEach ($agent in $noFailoverSpecified) {
Set-ManagementServer -PrimaryManagementServer $Primary_MS -AgentManagedComputer $agent -FailoverServer $Failover_MS | Out-Null
}
}
 

Function Get-MissingFailovers queries for all agents without a failover server assigned, then prints out a list of what needs fixed.

Function Get-MissingFailovers()
$noFailover = Get-Agent |? {!$_.GetFailoverManagementServers()}
If ($noFailover.Count -eq $null) {
Write-Host "All agents have a failover server assigned." -ForeGroundColor Green
} else {
Write-Host "Warning! Missing failover agents for the following servers: " -ForeGroundColor Magenta;
foreach ($agent in $noFailover) {
Write-Host $agent.Name -ForeGroundColor Magenta
}
}
 
Categories: Uncategorized Tags: