Last time (Fixing OMS Workspaces) we looked a way to repair or distribute OMS Workspace settings using Powershell. Wouldn't it be nice if we could leverage SCOM's access to individual machines to be able to keep them attached to the workspaces? If we could pull this off, we could minimize the amount of time we're blind to each server in our environment. Why use SCOM to push OMS settings?
Beyond Impact is a managed hosting company. We have customer servers both in Azure, and in our own privately hosted cloud environment. SCOM allows us access to both worlds. A couple of our customers use OMS to drive their own visibility into their environment using custom PowerBI dashboarding allowing them to analyze the performance impact of new code deployments in their Dynamics AX environment and allows them to tightly monitor their hosting costs.
The problem was that their servers were disappearing from their dashboards nearly weekly. Tasked with keeping this visibility stable, I wrote the script we presented in the last blog. The issue is that that fix requires either a manual or scheduled run. We have standardized on SCOM as our launch platform for our environmental automation as it's already in place and highly customizable making it very manageable from an operations perspective. It's also a great time to dig into a newer offering from SquaredUp for SCOM that has me personally very excited.
They recently released a free Management Pack for SCOM that puts Powershell options everywhere SCOM currently has scripting options for VBScript. Go download it here and install it. I'll wait.... Once that's in place, in SCOM, you can open Authoring > Tasks and "Create New Task" from the right hand task pane. There are also discoveries, rules, and monitors you can create that allow you to use Powershell everywere you would hope it would be in SCOM. In our case, we've built a group that houses all of the servers we monitor in our customer's domain. I'll be building a rule that checks each server on a timer to run this script against. For this demonstration, we'll be making a task so that we can manually run it against servers in an ad hoc, as needed fashion.
Select "Create New Task" from the right hand task pane. Select "Run a PowerShell Script (Community)" for the type of task.Name your task, attach it to a management pack (I keep one for just our custom solutions to make it easier to find them and tie them together). Scope it to Windows Server. Paste in the code below, enter your workspace ID and Keys, Adjust the $prod portions to suit your needs for your local naming conventions.
Now you can visit your Monitoring > Windows Server state view and this task should show up in the right hand task pane as an option. Running it will check the healthservice agent for the existence of the workspaces you've indicated. If it doesn't find it/them, it will add them in and restart the agent.
The trickiest part of this script was getting the Agent to restart without killing the task we're calling the restart from. We're basically invoking and abandoning a child task. If the agent doesn't come back, you'll have to restart it either manually or with a Powershell remote command:
start-service -name healthservice -computername "your_server_FQDN_Here"
If the server needs different credentials to run, you'll be able to provide those by entering into a PSSession with those credentials onto the server in question and just doing a:
Did you find this article useful? Let me know at email@example.com
If you want to be kept informed, follow our RSS feed: http://blog.beyondimpactllc.com/blog/rss.xml
Learn more about PowerShell in Azure
Beyond Impact is a Cloud Hosting and Managed Services provider based in Minneapolis, Minnesota.
You can learn more about our Cloud Services at beyondimpactllc.com/azure-services/.