This time, we are meeting Leon, who is a very passionate about sharing his knowledge with the community and help others! He is definitely one of those guys that you go to to get your stuff done! Let’s get to know him better:
Q: Please tell us a little about yourself and your background.
A: My name is Leon Laude, I work as a full time consultant in mid-size company in Stockholm, Sweden. My focus is mainly on Microsoft products, such as Windows Server, System Center, Hyper-V, Azure, Active Directory and a few others. I started working with these roughly 7 years ago, I started my IT career as a help desk agent, then I moved on to 2nd line support for workstations and printers, and eventually I ended up working with everything within the data center such as servers, firewalls, networks and storage within the Windows environment.
Q: I see you are very active on Technet Forums and also run your personal blog. What attracted you to get involved into community contributions?
A: I like to help people, I have always liked helping others, it brings me joy in life and I can also learn many new things by helping others.
I’ve known the Microsoft TechNet community for quite some time now, and I’ve noticed how many questions get asked there, but there are also many questions that are struggling to get some answers. There is clearly a big need of more help there, so I thought that I can share my knowledge with others, and maybe it could be useful or help them out, so I ended up contributing to the community by answering and troubleshooting people’s questions and also writing Wiki articles.
Q: What technologies do you think are on the rise dominantly in near future?
A: This is always an interesting question, but I think we can all agree on that the cloud is growing bigger and becoming more popular.
From what I hear and experience from current customers and colleagues, many companies want to go with the hybrid model, meaning having both on-premises and cloud services.
Another technology that is rising is containers, I believe this will also play a bigger role in the future.
Q: What advice would you give to the new IT professionals to be successful in their journey?
A: What you need to know about IT is that it’s constantly changing, find something you feel comfortable to work with and something you enjoy doing.
Don’t get stuck with some tool, because it won’t last forever, try to be open to new things and keep yourself up-to date with where the IT industry is heading.
It is also very important to keep a good balance between your work and your personal life.
Q: What do you enjoy to do when you’re not working?
A: I spend a lot of time contributing to the Microsoft TechNet community, because I enjoy doing it, which doesn’t actually leave me that much time to do other things.
My other passions are travelling around the world, doing sports to keep myself fit, being with my girlfriend, family and friends. I do love the nature and I’ve always liked exploring and trying out new things!
This is one widely known “inconvenience” with working with Powershell to manage your subscriptions in a big SCOM environment. Consider the following widely common scenario:
You have a SCOM environment with a fairly large number of subscriptions. You have a planned maintenance scheduled, and so you plan to disable all your subscriptions so that the support teams aren’t bothered with unnecessary alerts. There is a simple quick way of doing this:
This will disable all your subscriptions and stop sending notifications out. This is simple enough. The issue lies with enabling them back. The catch here is when you enable the subscription using Powershell, you start getting all the notifications that were “cached” during the time of the maintenance mode, and your support teams are bombarded with tens or even hundreds of such spam notifications. This is because when you enable the subscriptions with Powershell, it enabled it using the default option of “More messages”. Moreover, there is no apparent parameter/switch to change it to “Fewer messages”.
If you are not familiar with these two options, here’s what they mean:
More Messages: This option means all the notifications that were cached since the subscription was disabled are forwarded to subscribers.
Fewer Messages: This option means only the notifications that are generated after the subscription was re-enabled are forwarded to the subscribers.
This discussion was actually happening a few days ago on the SCOM Community Gitter Lobby (make sure to join!), and Dimitry K. suggested an excellent workaround on this issue (Kudos, Dimitry!). There’s no parameter in the cmdlet to switch options but you can actually do this using a method. Here’s the code:
$sub = Get-SCOMNotificationSubscription | where {$_.displayname -like "SUBSCRIPTION_NAME"}$sub.Enabled = $true$sub.Update($true)
Note the last line – $sub.Update($true)
The value you pass to this method actually determines the option to choose more or fewer messages. If you choose Update($true), it is equivalent to fewer messages, and if you choose Update($false), it is equivalent to more messages in the GUI.
Hope this helps, and save you and your support teams from a bunch of spam emails!
This is a question that I often get asked by the customers I work with and apparently a lot of others as evident by the related questions on the forums.
One way of doing it is to author your own service monitor, but that involves considerable amount of knowledge and experience of management packs and the underlying coding. It usually takes a lot of time as well. Not everyone has the right knowledge or the time to spend on it so I thought I’d share a quick trick I do to measure uptime of a service and also be able to present it to the concerned parties in the form of a report.
It often happens that you have a service running on your servers and many organizations use it as a “proof” to show that the application was running, or maybe as analysis for troubleshooting, hence it becomes necessary to be able to measure the uptime of the service accurately and to be able to show it to the management and/or to pass it around.
The thing is, when you’re creating a monitor to measure availability of a service in SCOM, you usually choose a “Basic Service Monitor”. This monitor is not very “intelligent” and simply places an instance of itself on every server belonging to the class that you choose. However, you do have another option to monitor your service with, and it is the “Windows Service Template”. This type provides you much more features and finer control on your service monitoring. I wrote a blog earlier comparing these two options of service monitoring and when to use what.
So the way the Windows Service template works is that it creates a discovery of it’s own and hence creates an actual class. This class can further be used to target other workflows that you may have to monitor this class of servers. Another advantage of that is you can now use this class to fetch a “Service Availability” report. For example:
Let’s say I’m monitoring the Spooler service on a bunch of servers, and I need to be able to see the uptime of this service on each of these servers. So I create a Windows Service Template monitor, call it “Test Spooler”.
Now once it’s done, go to “Discovered Inventory” tab under Monitoring. Click on “Change the target type” and you can see that now the “Test Spooler” is a class available for targeting.
This means you can also target your availability report to this target as well and measure the uptime of the service it is monitoring.
You can also fetch a report for a group of service monitors created this way. There’s a good discussion we had a while back regarding this exact requirement:
Ruben is back with another awesome blog post, and I have no doubt this one is going to help a lot of people!
We all know the hassles of migrating your SCOM from one version to another, and it involves a lot of manual efforts. And especially so when you choose the side-by-side upgrade path. Making sure you have all the Management Packs re-imported, all overrides are intact, making sure all permissions to various users you’ve assigned over the years are still in place, etc just to mention a few examples. We’ve all wished how great it would be if you could run some kind of script and it’ll do it all for us. Well, this is exactly what Ruben has made available for us! Here, take a look:
Preface
Migrating from SCOM 2012 R2 to SCOM 1801 isn’t a stressful job as both environments can live in parallel.
This blog gives examples how to migrate the configuration from A to B by trying to leverage PowerShell whenever possible / reasonable.
Please apply the PowerShell code only if you feel comfortable with it. If there are questions, please don’t hesitate to drop me a line.
Introduction
Although it is possible letting the agent do duplicate work in the sense of executing code in management packs, sending data to different management groups can cause excessive resource consumption on the monitored computer.
I suggest:
Migrate configuration to 1801 from 2012 R2 (blog topic)
Test with a very small amount of machine of different types (Application Servers, Web Servers, MSSQL, Exchange, Domain Controllers)
Move the remaining, majority to 1801
Change connectors to ticket systems, alert devices other peripheral systems
Remove the agent connections from 2012 R2 (see below for details)
Monitor the new environment for a while, if all fine decommission 2012 R2
Requirements
1801 is setup fully functional and first agents have been deployed successfully.
Windows PowerShell 5.1 is required on the 2012 R2 and on the 1801 server
Service Accounts used in 2012 R2 will be re-used. – If they are different in 1801 it is no big obstacle to change them if they are overwritten by one of the import steps.
Usually SCOM will alert if there is misconfiguration such a lack of permission somewhere.
Migration
Below now the steps separated in the different parts. – No guarantee for complete- or correctness.
Management Packs
Migrating to a new environment is always a great chance to perform cleanup and apply the lessons you’ve learned in the old one.
Review
Export all Management Packs from the current SCOM environment and review.
For your convenience use Excel to open the CSV file. Import only those Management Packs which bring measurable benefit.
Overrides
Standard Approach
If you have followed best practices you have created Override Management Packs for each Management Pack to store your customizations. Export those and import them into your new environment.
Note: Verify that the overrides work as expected.
Green field approach
In case you have stored the all overrides only in one Management Pack or want to be more selective follow these steps
Create a new Override Management Pack for that specific MP and name it properly.
Export the Microsoft.SystemCenter.Notifications.Internal mp in the old and new management groups – do not modify these, they are our backup copies
Make a copy of both files and rename them to something meaningful like Microsoft.SystemCenter.Notifications.Internal.ManagementGroupName_backup.xml
Make a note of the MP version number of the Microsoft.SystemCenter.Notifications.Internal MP from the new management group. In my case it was 7.2.11719.0
Open up the Microsoft.SystemCenter.Notifications.Internal.xml file for the old management group and change the version number to that of the new management group MP version + 1. In my case I changed it from 7.0.9538.0 to 7.2.11719.1. This is so the MP imports properly in the new management group
Exporting Configuration with PowerShell
Open a PowerShell console on the 2012 R2 Management Server and use the following cmdlets to store the information to C:\Temp\ResolutionStates.json
<# The cmdlet 'Get-SCOMRunAsAccount' can't extract credential information. A free cmdlet, written by Stefan Roth is required for that. – Import it to your 2012 R2 environment before proceeding with the following lines.
https://www.powershellgallery.com/packages/RunAsAccount/1.0 #>
Run As Profiles usually come with Management Packs and therefore not handled here.
Note:
Run As Profiles are the binding component between Run As Account and the Object (e.g. a Computer / Health State) they are used. Please check the configuration in the 2012 R2 environment to setup the mapping and distribution manually.
Datawarehouse Retention Settings
Datawarehouse retention settings are configured with a cmdline tool named dwdatarp.exe. It was released in 2008 and works since then.
We discussed about the common misconceptions regarding failover for Windows agents in SCOM in the previous post (part 1). In this part, as promised, Stoyan Chalakov is going to be discussing about the failover for Linux machines monitored by SCOM. Here goes:
Linux/UNIX agent failover and Resource Pools – debunking the myth – Part 2
While answering questions on the Microsoft Technet Forums, I noticed that are lots of questions on topics, which are repeating, or which often are not that well understood. So I had a discussion with Sam (Sameer Mhaisekar) and we decided that it would be very beneficial if we write short blog posts on those topics.
One such topic is agent failover in SCOM and the difference between a Windows and Linux/UNIX agent. In order to understand how the Linux/UNIX agent failover works, one need to first become acquainted with the concept of Resource Pools in Operations Manager.
Sam already wrote the first part on this subject, where he explains the basic of Resource Pools and gives also example of how the failover of the Windows agent work in SCOM. He also referenced 3 very important articles about Resource Pools in SCOM, which are you need to read before getting to Linux/UNIX agent failover.
Before jumping to failover, it is important to mention some important facts about the architecture of Linux/UNIX agent.
The Linux/UNIX agent is very different from the Windows one and hasn’t been changed since Operations Manager 2012. One of the most important functional difference, compared to a Windows agent is the absence of a Health Service implementation. So, all the monitored data is passed to the Health Service on a management server, where all the management pack workflows are being run. This makes it a passive agent, which is being queried (using the WSMan protocol, Port 1270) for availability and performance data by the management servers in the Resource Pool.
The first important thing that needs mentioning is that you cannot discover and monitor UNIX/Linux systems without configuring a Resource Pool first. When you start the SCOM discovery wizard you will notice that you cannot continue unless you have selected a Resource Pool from the drop-down menu.
Here a few important considerations regarding the Resource Pool that will manage the UNIX/Linux agents:
It is recommended and, in my opinion, very important to dedicate the management servers in the cross platform Resource Pool only to UNIX/Linux monitoring. The reason for this are the capacity limits, which Operations Manager has when it comes to monitoring UNIX\Linux and Windows and which needs to be calculated very accurately. I will try to explain this in detail. A dedicated management server can handle up to 3000 Windows agents, but only 1000 Linux or UNIX computers. We already revealed the reason for that – cross platform workflows are being run on the management server and this costs performance.
So, if you have also Windows agents, reporting to the dedicated management server, capacity and scalability calculations cannot be made precise and the performance of the management server can be jeopardized.
This fully applies and is a must for larger organizations where there are many Linux or UNIX computers (hundreds of systems) and their number grows. In smaller monitored environments, where you have a small (tens of systems), (almost) static number of cross platform agents, very often, dedicating management servers only for those systems can be an overkill. So, in such cases, I often use management servers, which are not dedicated and are members of the Default Resource Pools or are managing Windows agents. This of course, is only possible if the number of Windows agents is way below the capacity limits of the management group, which would leave enough system Resources on the management server for running the Linux/UNIX workflows.
It is very important to dedicate the management server in the cross platform Resource Pool only to UNIX/Linux monitoring. This means not only that you should not assign Windows agents to report to it, but also the server should be excluded also from the other Resource Pools in the management group (SCOM Default Resource Pools, network monitoring Resource Pools, etc.). The reason is the same – performance. If the management server participates in other Resource Pools, it will execute also other types of workflows.
To exclude the management server from the Default Resource Pools, you will need to modify their membership from automatic to manual. By default, each management server, added to the management group is automatically added to the Resource Pools that have an automatic membership type. For some of the Resource Pools this can be accomplished over the console, for others like the “All Management Servers Resource Pool” this can be done only with PowerShell:
When you do the capacity planning for your management group, make sure you don’t forget to calculate the number of UNIX or Linux computers a management server can handle in the case another member of the Resource Pool fails. Let me explain this with an example:
According to the official documentation (see the link above), a dedicated management server can handle up to 1000 Linux or UNIX computers. But, if you have two dedicated management servers in your cross platform Resource Pool and you aim for high availability, you cannot assign 2000 (2x 1000) agents to the Pool. Why? Just imagine what will happen with a management server if its “buddy” from the same Resource Pool fails and all its agents get reassigned to the one, which is still operational. You guessed right – it will be quickly overwhelmed by all the agents and become non-operational. So, the right thing to do if you would like your cross platform monitoring to be highly available, is to have 2 management for not more than 1000 agents, so that in case of failure the remaining server can still handle the performance load.
Last, but not least, make sure the management servers, which will be used for Linux/UNIX monitoring are sized (RAM, CPUs, Disk space) according to the Microsoft recommendations.
Now back to the agent failover topic…I think it got already pretty clear how the Linux/UNIX agent failover happens behind the scenes, but short summary won’t do any harm:
After the discovery wizard is started, a Resource Pool must be selected for managing the systems.
When the Resource Pool is selected, it assigns one of the participating management server to complete the actual discovery of the systems and take over the monitoring.
When the management server fails, the Resource Pool selects one of its other members to take over the monitoring.
Here a reference to what we said in the beginning that the UNIX/Linux agent is passive and is being queried by the management server. Because of this, it is not actually aware of what happens in the background and continues to communicate with the server, which has been now assigned to it.
Now is also the right time to make a couple of very import notes:
XPlat (cross platform) certificates
Part of the preparation of the environment for the monitoring of cross platform systems is the creation of self-signed certificate and its deployment to every management server, member of the Resource Pool. This will ensure that in case of failover each management server will be able to communicate with agent, using the same certificate.
High availability with Operations Manager Gateways as members of the Resource Pool (thanks to Graham Davies for the reminder)
What I forgot to mention in the first version of this post, but is of high importance for maintaining high availability of your Gateway Resource Pools (Resource Pool, consisting of Operations Manager Gateway servers) is the fact that two Gateways are not sufficient for achieving high availability. Why? You will find the answer in the article Kevin Holman wrote about Resource Pools in SCOM and how exactly they provide high availability This is also the same article Sam posted in the first part and it is must read if you have to plan for and manage Resource Pools and cross platform agent failover in Operations Manager:
Understanding UNIX/Linux agent high availability and failover is not a hard thing to do. Still, in order to properly plan for Operations Manager cross platform monitoring, there are some additional things like sizing and scalability that need to be considered.
Awesome, thanks a lot Stoyan! It was very informative and interesting read, as usual! 🙂
You can get in touch with Stoyan on LinkedIn or Twitter, or visit his Technet profile.
Should you enable autogrowth on SCOM Operational Database?
I did some some research online and consulted some of the best SCOM experts I know and put together an article that explains why you would NOT want to autogrow your SCOM DB.
The short version is:
DO NOT autogrow your SCOM Operational DB, unless you absolutely need to. Autogrowing DB comes with its own set of disadvantages and might affect the performance of the DB.
So, choose the size of your DB very carefully while you are designing your Management Group!
The myth:“If the primary Management Server is down, the windows agents will automatically failover to any Management Server in the Resource Pool.”
It’s been 6 years since the release of SCOM 2012, and yet, the understanding around the failover process in SCOM is still widely confused. SCOM 2012 came out with the concept of the “Resource Pools”, essentially replacing and enhancing the previous “Root Management Server” concept. Having said that, the Resource Pools are still very widely misunderstood and confused.
Why was the concept of Resource Pools introduced? For failover? Sure, but probably not in the way you are thinking. I talk very frequently to other SCOMers in person and online and I often find that their understanding about the Resource Pools is not very accurate. So, I thought about writing a two-part blog explaining the failover process in SCOM – one for the Windows Agents and other for Unix/Linux and network agents.
I will talk about the Windows Agents failover part here, and my friend Stoyan Chalakov was generous enough to agree to write on the U/L and networking part. So, let’s get started!
Before we jump into the actual failover process, let’s recap briefly what Resource Pools are and what do they do.
Basically, the concept of resource pools was introduced to eliminate the Root Management Server as the single point of failure. Till SCOM 2007, RMS was the boss and other MS were under it in the management group hierarchy. Many critical workflows were specifically targeted at the RMS and so there was a risk of your SCOM being paralyzed if the RMS goes down. On top of that, you couldn’t cluster it either.
So starting from SCOM 2012 Microsoft came up with the concept of Resource Pools, and the idea that all the Management Servers are peers, and not in hierarchy. That simplified so many things and the workflows that were running on the RMS were now running on the members of the Resource Pools.
When you install SCOM, out-of-the-box you get 3 default Resource Pools – The “All Management Servers Resource Pool”, which deals with most of the legacy RMS workflows, the “Notifications Resource Pool”, which deals with notifications (alerts subscription service), and “AD Integration Assignment Pool”, which deals with the AD Integrations.
Now the scope of this blog is not to get into much detail of Resource Pools, but there are actually a couple of very good blogs out there that discuss Resource Pools in great details. The one we’ll discuss about here is in particular the “All Management Servers Resource Pool”, and specifically what it DOES NOT do.
Now coming back to the failover thing – I’m sure most of you have read or known that the Resource Pools provide failover and high availability in SCOM. Which is true. But again you may also be thinking that the Resource Pools (notably the All Management Servers Resource Pool) provides failover to your Windows Agents. This is simply not true. In almost all of the blogs and even in the Microsoft official documents, when you’re reading about Resource Pools, there is a line mentioned somewhere, “Windows agents do not report to resource pools” – and that’s it. Nothing else. No further explanation, no further discussions at all. That is why it is often just skimmed over or simply forgotten.
So, what does “Windows agents do not report to resource pools” actually mean?
Let’s have a case:
3 Management Servers: MS1, MS2, MS3
2 Gateway Servers: GW1 (reports to MS1) and GW2 (reports to MS2)
As the name suggests, we have all the MS in the “All Management Servers Resource Pool”.
Now let’s understand how the failover takes place should the MS or GW go down.
Case 1: Management Server goes down –
Let’s say it’s the MS3 that failed. All the agents reporting to MS3 are RANDOMLY failed over to either MS1 or MS2 (for successful failover, of course you need the required port 5723 open to all MS). This is the out-of-the-box feature of SCOM and does not require you to set up AD Integration. This process is random by default, but you CAN configure which Management Server you want it to failover to, using Powershell:
Now, once you run this the agents will failover to the Management Server YOU want, instead of failing over randomly. This is NOT affected by what Management Servers you have in whatever Resource Pool. Let’s say I removed one (or all) Management Server(s) from the All Management Servers Resource Pool, this behavior is NOT affected (Don’t do that though, it’ll cause other problems!). The servers will still failover to any Management Servers in the Management Group.
When you install a Windows agent, you configure it to report to a particular Management Server (or GW) only. The Resource Pool simply doesn’t play a role here.
In conclusion, Windows agents will failover to any available Management Server RANDOMLY (unless explicitly configured) and this behavior is NOT affected by any Resource Pools (default or custom).
Case 2: Management Server with a GW reporting goes down –
Let’s say MS1 goes down. GW failovers are not automatic and unlike agents, they DO NOT failover randomly to any other available MS. You need to configure the GW explicitly for failover to MS2 or MS3, using Powershell.
Let’s say GW1 goes down. Again, the agents will NOT automatically failover to another GW server. You will need to configure the agents to use another server (GW2), using a Powershell script.
#Agents reporting to "GW1" – Failover to "GW2"
$primaryMS = Get-SCOMManagementServer | where {$_.Name –eq "GW1"}
$failoverMS = Get-SCOMManagementServer | where {$_.Name –eq "GW2"}
$agent = Get-SCOMAgent | where {$_.PrimaryManagementServerName -eq "GW1"}
Set-SCOMParentManagementServer -Agent: $agent -PrimaryServer: $primaryMS
Set-SCOMParentManagementServer -Agent: $agent -FailoverServer: $failoverMS
Note: Scripts are for example only. You may need to modify them according to your requirements.
Now you’re probably thinking, how come people say that the Resource Pools are used for Failover and high availability then? Fair question! The answer is, they do provide automatic failover to the workflows that are running on the health services of the members of the resource pools. Windows agents run their workloads on their respective health services local to them; hence they have no relationship with the Resource Pools.
In other words you can also say that the failover and high availability resource pools provide is actually for Management Servers, and not for the Windows agents reporting to them.
However, this is not the case with Unix/Linux agents. I will not go into details of it here though, because Stoyan will have an entire blog dedicated to this in part 2, so I’ll let him dive into the details. 😉
Hope this clarifies some misunderstandings and helps someone out there plan their deployment correctly!
I am a regular visitor/contributor to the SCOM Technet Forums and regularly meet many experts from around the globe there. Fortunately for me I eventually became friends/acquaintances with many of them. One of them is Cyril! If you have posted a question in the forums, you may very well have received the solution from a “CyrAz”, that’s him! 😉
I was able to convince Cyril to feature in one of our community experts interview series, and from his answers you can easily guess the knowledge and experience Cyril possesses! Enough chatter from me, I will let Cyril do the talking now:
Q: Hi Cyril! Thanks for agreeing to this. I see you very often on the SCOM Technet forums, and from what I can tell, you really know what you’re talking about! Can you please tell us a little about yourself and your professional journey so far?
A:Thanks for having me 🙂 I’m a system consultant and I almost exclusively work on Microsoft technologies. I work on quite a lot of them (Active Directory, PKI, Exchange, Direct Access, HyperV/Storage Space direct and even Azure Stack these days) but my current field of expertise is System Center, and more specifically SCOM and Orchestrator.
I started working on these two technologies around 6 years ago when my boss wanted me to specialize on something and asked me if I was interested in System Center. I said yes, because I was interested in the whole “everything is integrated together” aspect of the suite, being able to manage every aspect of the datacenter etc. I quickly realized this ideal world only existed in Microsoft’s presentations and that most of these products were actually not designed to run together and were even pretty clunky by themselves, but I still really liked what they allowed to do!
So I went from customer to customer, doing things that were more and more complicated, from daily operator tasks to architecture design and complex MP development; until now where I believe I can call myself an “expert”, even though I’m still learning things every day. I’ve only started using Visual Studio for MP developments a little bit over a year ago!
And I can say that blogs and Technet forums helped me a lot during this journey, it’s really nice to have such a knowledgeable and sharing community!
Q: What is your opinion about Microsoft’s strategy of 2 different models for System Center products? What do you prefer, the LTSC or SAC model?
A:I’m glad Microsoft is still developing SCOM, and I can’t wait to get the most recent improvements so I definitely prefer SAC. But to be honest, I’m a bit disappointed by what was added in 1801 and 1807… I’m convinced SCOM has great foundations, the Management Pack system is incredibly powerful and flexible, but there is so much that could be done to improve the final product!
Now from my customers point of view, it really depends on how much they can afford in maintaining their environments… if they have a dedicated team that has enough knowledge, they can go for SAC. If they rely exclusively on me coming from time to time to check that everything is running properly, that may not be the best idea.
Q: How do you feel about the whole SCOM vs. OMS argument? Will OMS be a viable “replacement” for SCOM?
A:I must say I really like Log Analytics and what it is becoming, especially since Kusto query language was released. I was already a huge fan of competing products such as Splunk, and that pretty much sums up what I think about the SCOM vs Log Analytics argument : it has no reason to exist since they are not competitors!
Log Analytics is becoming a great tool for… well, ingesting, archiving and analyzing logs of all kind.
But for now it is a terrible replacement for SCOM, regardless of what Microsoft is trying to make us believe! It doesn’t provide any solution to replace the huge list of existing management packs and everything they include, it doesn’t provide an easy solution to develop your own monitoring, it has terrible SLA regarding data ingestion latency…
However, I can very well see how they can work together to provide more information on your environment, and how Log Analytics can become a good monitoring tool someday. But definitely not today, and probably not tomorrow neither.
Q: Given a chance, what would you like to ask or advise to Microsoft?
A: Don’t abandon great tools that can still provide tremendous service to many people just because you believe they are not the future! And maybe try to make them a little bit more usable by non experts…
Q: Lastly, the traditional question! Star Wars or Star Trek?
A:A 4-cheese pizza and a cold beer, thanks 🙂
Awesome! Thanks again for sharing your expertise with us Cyril, and I hope you will continue to help the folks on the forums! 😀
This post describes how to create PowerShell SCOM Console Tasks in XML along three examples.
Introduction:
Console Tasks are executed on the SCOM Management Server. Three examples show how to create them using Visual Studio.
Task 1: Displaying a Management Server’s Last-Boot-Time [DisplayLastBootTime]
Executes a PowerShell script which displays the result in a MessageBox
Task 2: Show all new alerts related to selected Computer [ShowNewAlerts]
Passes the Computer principal name property (aka FQDN) to the script which then uses a GridView to display the alerts
Task 3: Listing the top N processes running on a Management Server [ListTopNProcesses]
An InputBox let the user specify the number (N) of top process on the Management server which is retrieved by script and shown via GridView
Requirements:
This blog assumes that you have created already a management pack before. If not, or if you feel difficulties please visit the section ‘Reading’ and go through the links.
The used software is Visual Studio 2017 (2013 and 2015 should work as well) plus the Visual Studio Authoring Extension. Additionally, the ‘PowerShell Tools for Visual Studio 2017’ are installed.
The Community Edition of Visual Studio technically works. – Please check the license terms in advance. – If you are working for a ‘normal company’ you will most likely require Visual Studio Professional.
Realization:
Initial steps in Visual Studio
à Create a new project based on Management Pack / Operations Manager 2012 R2 Management Pack template.
à Name it SCOM.Custom.ConsoleTasks
à Create a folder named Health Model and a sub folder of it named Tasks
à Add an Empty Management Pack Fragment to the root and name it Project.mpx.
Category Value specifies that this element is a console task
Presentation
ConsoleTask Target defines against what this task is launched. In this case it’s the Management Server. You can only see the task if you click on a View that is targeting the corresponding class. E.g.:
Console-ManagementServer-Tasks.gif
Parameters, Argument Name “Application” sets PowerShell.exe to be called for execution
Parameters, Argument <![CDATA … defines the file within this Visual Studio project that contains the PowerShell code to be processed when the task is launched ( not handled yet ).
LanguagePack
DisplayString maps the Console Task ID to a text that is more user friendly. This will be shown in the SCOM console
Within the Tasks folder create a PowerShell file named DisplayManagementServerLastBootTime.ps1
Content of DisplayManagementServerLastBootTime.ps1 :
$regPat = '[0-9]{8}'
$bootInfo = wmic os get lastbootuptime
$bootDateNumber = Select-String -InputObject $bootInfo -Pattern $regPat | Select-Object -ExpandProperty Matches | Select-Object -ExpandProperty Value
$bootDate = ([DateTime]::ParseExact($bootDateNumber,'yyyyMMdd',[Globalization.CultureInfo]::InvariantCulture))
$lastBootTime = $bootDate | Get-Date -Format 'yyyy-MM-dd'
$null = [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic')
$null = [Microsoft.VisualBasic.Interaction]::MsgBox($lastBootTime,0,"""Last Boot time of $($env:COMPUTERNAME)""")
Deploy this Management Pack to the SCOM Server and test it. The following screenshot shows the expected result:
Console-DisplayLastBootTime.gif
Creating ShowNewAlerts task
Keep the content of ConsoleTasks.mpx unchanged. Add the new code into the proper places.
Additional Content for ConsoleTasks.mpx for ShowNewAlerts:
Key points explanation for ConsoleTasks.mpx for ShowNewAlerts
Categories
Category Value specifies that this element is a console task
Presentation
ConsoleTask Target defines against what this task is launched. In this case it’s the Windows Computer. – This task is visible when in a View that shows Computer objects.
Parameters, Argument Name “Application” sets PowerShell.exe to be called for execution
Parameters, Argument <![CDATA … defines the file within this Visual Studio project that contains the PowerShell code to be processed when the task is launched ( not handled yet ).
Parameters, Argument “$Target/Property […]/PrincipalName$” gets the FQDN (principal name attribute) of the selected computer and makes it available for retrieving it in the script.
Content of ShowNewAlertsForThisComputer.ps1 :
param($ComputerName)
$allNewAlerts = Get-SCOMAlert | Select-Object -Property Name, Description, MonitoringObjectDisplayName, IsMonitorAlert, ResolutionState, Severity, PrincipalName, TimeRaised | Where-Object {$_.PrincipalName -eq $ComputerName -and $_.ResolutionState -eq '0'}
if ($allNewAlerts) {
$allNewAlerts | Out-GridView
} else {
Write-Host 'No new alerts available for the computer: ' + $ComputerName
}
Deploy this Management Pack to the SCOM Server and test it. The following screenshot shows the expected result:
Console-ShowNewAlerts
Creating ListTopNProcesses task
Keep the content of ConsoleTasks.mpx unchanged. Add the new code into the proper places.
Additional Content for ConsoleTasks.mpx for ListTopNProcesses:
Key points explanation for ConsoleTasks.mpx for ListTopNProcesses
Categories
Category Value specifies that this element is a console task
Presentation
ConsoleTask Target defines against what this task is launched. In this case it’s the Windows Computer. – This task is visible when in a View that shows Computer objects.
Parameters, Argument Name “Application” sets PowerShell.exe to be called for execution
Parameters, Argument <![CDATA … defines the file within this Visual Studio project that contains the PowerShell code to be processed when the task is launched ( not handled yet ).
Content of ListTopNProcesses.ps1 :
$null = [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic')
$receivedValue = [Microsoft.VisualBasic.Interaction]::InputBox("""Enter the number of top processes to be shown""", """List top processes:""", "10")
Get-Process | Sort-Object -Property CPU -Descending | Select-Object -First $receivedValue | Out-GridView
Deploy this Management Pack to the SCOM Server and test it. The following screenshot shows the expected result:
Console-ListTopNProcesses.gif
Reading:
If you are new to management pack authoring I suggest the free training material from Brian Wren. – It was made for SCOM 2012 R2 but is still valid until today (current SCOM 1807 in year 2018).
A few days ago, I needed to find out how many users are connecting to SCOM daily/weekly and how long was each user connected. Out-of-the-box SCOM does not provide you a way of doing this. So I started looking around for some hints. I came across this article, which looked pretty convincing.
This looked all good, except I wanted to do it with Powershell.
Whenever any “client” connects/disconnects to/from the console an event is written in the Operations Manager event log. In each event there is event data which gives you information on the following points:
EventID
ManagementServer Name
Username
SessionID
UUID – extracted from SessionID
ID – extracted from SessionID
TimeCreated
SessionDuration -calculated Time between log on and log off Event
SessionCount – calculated cumulated counter of all current sessions
So, I started working on a script that’d meet my requirements. To be honest, I am still a Powershell student, so I got stuck halfway. So I decided to “get-help” (Powershell pun, get it? ;)) from my friend and guide Stoyan Chalakov. I explained to him my idea and asked whether he would help me script it. Sure enough, I wasn’t disappointed. He liked the idea as well, and came up with a nice script that outputs the data the way we imagined. I’ve linked the link to his script on Technet at the end.
Some important remarks which apply to both methods (the one described in the blog and the script):
“Yes, there are design flaws in this approach:
If you create daily files, you will have an unknown amount of already open sessions at the beginning of the day and a certain amount of not yet closed sessions at the end. So your SessionCount will be lower than the cumulated values from the “Client Connections” performance counters of all Management Servers.
But when you analyse e.g. weekly data instead of daily, you should get very good results.
The tricky part is , the exact same event is written when a Powershell SDK connection is made. You cannot distinguish between PowerShell SDK connections and Operations console connections. Unfortunately this is by design and I am not aware of a way to mitigate this problem.”
The script parses all the events, which are being logged in regards to the particular user and gathers information in regards to:
Open session, where the session has not been closed (presence of the Login event, absence of Logout event)
Closed session and their duration (presence of the Login event and Logout event)
Closed session without and Login session event, indicating that the Login session event has been overridden and cannot be found.
The script should be run directly on a management server. If you need you can enable PSremoting and run this on a multiple management server.
The script is in its first version, where you need to enter a domain and username. The second version (currently being worked on) will include a full report on all user session and their duration, without the need of specifying a particular user name.
Sample output of the script:
You can download the script here:
Stoyan has commented thoroughly throughout the script, so there would no issues to understand the way it works.
