___________________________________________________________________________________________________________________________
IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
__________________________________________________________________________________________________________________________
Brad Watts with another blog on System Center Operations Manager. One of the common scenarios I run into with customers is monitoring service accounts with Operations Manager. Specifically, three common scenarios dealing with service accounts:
· Account Locked Out: typically there are a group of service accounts that you need to know immediately if they get locked out.
· Password Expired: same situation as with the account being locked out but here we will receive an alert if the password has expired.
· Password Age: this can be used in two different scenarios
o Many organizations set their service accounts to never expire but are required to change the password every x number of days. In this scenario this monitoring would alert you when it’s time to change the password.
o This monitoring can also be used as a warning that the password is about to expire. For instance, if the policy is for the passwords to expire after 60 days you could set this to alert when the password is 50 days old.
Each of these scenarios is easy enough for me to set up but if you don’t have experience with Management Pack Authoring then reusability becomes difficult. So my goal is to provide a Visual Studio Solution that will allow a typical Operations Manager Administrator the ability to monitor service accounts. This means that it must be simple to add and remove service accounts from being monitored.
Overview
Disclaimer: This is an example solution and should be handled as such. You should test this in your lab environments before implementing. Once you download the content you are responsible for the solution. This is a community management pack and is in no way a solution from Microsoft.
I decided to break this blog article into four sections:
Section 1: Before You Get Started: This will outline the pre-requisites needed to use this solution.
Section 2: PowerShell Script: This Management Pack uses one simple PowerShell script that we’ll cover in this section.
Section 3: Loading the Solution: Covers loading the Visual Studio Solution that is provided at the end of this blog.
Section 4: Using the Solution: Covers how to add and remove service account using the Visual Studio Solution.
Section 5: Using the Management Pack: Covers importing the management pack and exploring the new monitors.
Before You Get Started
Before you can implement this solution you’ll need to make sure the following items are in place in your environment.
1) Operations Manager 2012 R2
2) Load the Active Directory PowerShell Module on your Management Servers. If you are running Server 2012 R2 this will be available as a Feature that you can add. The workflow in this Management Pack targets the “All Management Server Resource Pool” and loads this module.
3) Visual Studio 2012/2013/2015 (any addition)
4) Visual Studio Authoring Extension (https://www.microsoft.com/en-us/download/details.aspx?id=30169)
I know for some people Visual Studio is something they try to stay away from. Stick with me in this case because in this solution we use what are called Management Pack Snippets in order to make your life easier.
PowerShell Script
At the core of this solution is a very simple PowerShell script that pulls the information we need for the service accounts.
param($account,$debug)
#Constants used for event logging
$SCRIPT_NAME = ‘MonitorADAccount.ps1’
$EVENT_LEVEL_ERROR = 1
$VENT_LEVEL_WARNING = 2
$EVENT_LEVEL_INFO = 4
$SCRIPT_STARTED = 841
$PROPERTYBAG_CREATED = 842
$SCRIPT_ENDED = 845
#==================================================================================
# Sub: LogDebugEvent
# Purpose: Logs an informational event to the Operations Manager event log
# only if Debug argument is true
#==================================================================================
function Log-DebugEvent
{
param($eventNo,$message)
$message = “`n” + $message
if ($debug -eq $true) {
$api.LogScriptEvent($SCRIPT_NAME,$eventNo,$EVENT_LEVEL_INFO,$message)
}
}
#Start by setting up API object.
$api = New-Object -comObject ‘MOM.ScriptAPI’
$message = ‘Account: ‘ + $account
Log-DebugEvent $SCRIPT_STARTED $message
import-module ActiveDirectory
$bag = $api.CreatePropertyBag()
$user = get-aduser $account -Properties *
$bag.AddValue(‘LockedOut’,$user.lockedout)
$pwd = [DateTime] $user.PasswordLastSet
$now = get-date
$passwordlastset = ($now – $pwd).days
$bag.AddValue(‘LastSet’,$passwordlastset)
$bag.AddValue(‘Expired’,$user.PasswordExpired)
$bag
$message = ‘Account: ‘ + $account + ‘ – Accounts Retured: ‘ + $user.count + ‘ – Account Locked Out: ‘ + $user.lockedout + ‘ Password Age: ‘ + $passwordlastset + ‘ Password Expired: ‘ + $user.PasswordExpired
Log-DebugEvent $PROPERTYBAG_CREATED $message
There is one item that I won’t cover in the script. This monitor has an overridable parameter [CR1] called Debug. If this is set to true you will log a couple of events in the Operations Manager event log each time the script is run. You’ll get event number 841 when the script is kicked off and this will show you the account it is attempting to get information on. You’ll also get event number 842 when the script is finished that should show you the details on the account that you targeted.
Now let take a look at the important lines of the script.
import-module ActiveDirectory
This will add the Active Directory PowerShell commands that we need and connect to the domain that the Management Server is a member of.
$bag = $api.CreatePropertyBag()
Operations Manager uses Property Bags to pass information out of scripts. Here we are just initializing the Property Bag.
$user = get-aduser $account -Properties *
$bag.AddValue(‘LockedOut’,$user.lockedout)
$pwd = [DateTime] $user.PasswordLastSet
$now = get-date
$passwordlastset = ($now – $pwd).days
$bag.AddValue(‘LastSet’,$passwordlastset)
$bag.AddValue(‘Expired’,$user.PasswordExpired)
$bag
First we get the user using “get-aduser” along with the account name that is passed in. Once we have the user account we can start to add values to our Property Bag. We have three values that are passed out in the Property Bag, LockedOut, LastSet, and Expired. Each one of these will be used for a different monitor. Note that we get the age of the password by subtracting the current date to the PasswordLasSet property of the use account. Once we’ve filled out the Property Bag we return the values with the line containing just $bag.
Loading the Solution
Once you’ve downloaded the zip file provided below you can extract the content to a folder of your choosing. The only caveat here is that wherever your running Visual Studio from will need to have access to the extracted folder.
Now that you’ve got the extracted solution you can launch Visual Studio with the VSAE already installed. When Visual Studio loads it should bring you to a splash screen. On this splash screen choose to “Open Project”
Navigate to the location where you extracted the content. In the base folder you should find a sln file named “Example.ADAccount.Monitoring.”
Opening this file should load the solution. Once loaded your “Solution Explorer” should look like the following.
Using the Solution
Now that you’ve loaded the solution the next step is using the solution. The nice part about this setup is typically they only folder you need to be concerned about in the “Solution Explorer” is the one labeled “Action.”
You can see under the “Action” folder are three different “Snippet Data” items. There is one that you need to fill out for each scenario on monitoring a service account. The easiest way to demonstrate using this solution is to walk through a scenario. Let say we have two service accounts we want to monitor.
· Svc-lockout
o Account Locked
o Password Age: older than 45 days
o Password Expired
· Svc-sql
o Account Locked
o Password Age: older than 45 days
Start by double clicking on “Account Locked.mpsd” in your “Solution Explorer.” This should bring up a screen that looks like this.
Click on the “Click here to add a new item” and we’ll add the two service accounts. Note that I have the “ID” as a column due to the fact that many account have “-“ in them that aren’t accepted in the ID field. Typically I just use the service account name minus the “-“. Here is what the filled out data should look like:
Walk through the same procedure for “Password Age.mpsd.” Once you finished here the data should look like:
Walk through the same procedure for “Password Expired.mpsd.” Note here that we are only monitoring the svc-lockout account here. Once you finished here the data should look like:
Once you’ve filled out the information you can build your solution by selecting “Build | Build Solution”
This will place the Management Pack under the following path:
<Path you extracted content>\Example.ADAccount.Monitoring\Example.ADAccount.Monitoring\bin\Debug
Recommendations
Note on Cook Down.
· This Management Pack does not cook down between Accounts. What I mean by that is if you are monitoring 20 accounts then it will run the script at least 20 times. The script is not resource intensive but it is something you should keep in mind.
· Cook down does occur between the scenarios as long as the same interval is passed in to each. So when monitoring svc-sql for instance I would want to make sure I use the same interval. You’re initial thoughts may be that I need to check lockout every 10 minutes but password age just once a day. In actuality you get no benefit from setting them differently. If I set both to run every 10 minutes, I’ll run the script one less time each day than if I set one to 10 minutes and the other to every 24 hours. (With cook down you run the script once every 10 minutes and without cook down you run it once every 10 minutes plus the once a day for the password age)
Removing a Service Account
It should be pretty straight forward on how to add more service accounts to be monitored but what about removing a service account. If you go back to where you added in the accounts highlight one of the rows my first thought is to right click and choose a delete option. Well when you right click nothing at all happens. The solution is extremely simple, after clicking on one of the rows you can simply press your ”delete” key to remove that row.
Adding Service Accounts Through CSV Files
Instead of adding each account individually you can use a csv file to add in the accounts. The only caveat here is that you shouldn’t have any headers in the file. For example for the Password Age template you’re csv file should look similar to the following:
svclockout,300,svc-lockout,45
svcsql,300,svc-sql,45
Using the Management Pack
Now that we’ve gone through and created the management pack using the Visual Studio Solution we need to see what this looks like in Operations Manager. Take the Management Pack that was created in the Debug directory mentioned above and import it into Operations Manager. Once imported you can create a state view in the console. Below I went into My Workspace | Right Clicked | New | State View. When creating the State View I selected the “All Management Server Resource Pool.”
In the new view you can open up the Health Explorer for the Resource Pool. Under “Configuration” you should have a new aggregate monitor named “Account Status.” If you open this up you will see all of the accounts that you are monitoring.
In the above you can see that the svc-lockout has expired and it was set longer than 45 days ago but the account isn’t locked out. Also the svc-sql account’s password age is older than 45 days but it isn’t locked out. Also notice that we aren’t monitoring for the “Password Expired” on the svc-sql account.
You can also check your “Active Alerts”
Summary
Being able to monitor service accounts is a common request that I see for Operations Manager. In the above solution hopefully can be used by two different camps. First, would be people that have no Authoring Experience but would like to be able to monitor for these three scenarios. With this solution they should be able to use this just to add in this monitoring. This can also be useful for people with authoring experience. In that case this would be a starting point that they can add in additional scenarios or extend what the PowerShell script is currently doing. For example, the current script is assuming a single domain environment and would need to be modified for multiple domains. Here is a link to the solution:
http://tinyurl.com/zgmlb23[CR2]
[CR1]Suggest changing this to ‘parameter than can be overridden’.
[CR2]Suggest using sxp to make an aka.ms vanity alias for this: https://sxp.cloudapp.net
Good
Great write up, but the question is, if this is common requirement, why not build it into SCOM. I know it’s a complicated beast as it is, but it’s things like that are definitely missing. Of course one can come up with a solution such as this, but it really shouldn’t be as complicated.
I can only assume that they haven’t gotten enough request or they don’t believe this is a common enough scenario to build it into the product. I personally think it would be a nice addition as a MP Template just like we have services and processes. The product group pays a lot of attention to https://connect.microsoft.com/WindowsServer/SC_Public. You can post it up to that site as a suggestion and then people can vote on it.
hey,
I’m having an issue with my server, I’m suppose to have 3 user access on my server but every time there are two people logged in and a third person is trying to log in, the serve ask’s for one of the other two users to disconnect in order to open the third user. Where would I have to go to correct this issue? Or how can I correct this so that 3 people can be logged in at the same time?
Hi Prashant, this might be something better posted in the forums. But off hand, it sounds like you are in remote admin mode, which limits connections to 2 users. You would need to purchase RDS CALs and put on full blown RDS…
Wanted to know if you might be able to edit the MP so it can do multiple domains, it would be greatly appreciated? I have multiple domains and I am limited when it comes to programing. I am in the process of making multiple management packs, one for each domain. Thank you in advance.
I updated the solution so that you pass in a domain along with the account name. I made a couple of assumptions:
1) There are trust between the domains
2) You can query the additional domains using a single account and from the Management Servers
Also, I don’t have but a single domain in my lab. I did test and make sure I didn’t break anything for the single domain by passing in the additional parameter and I’m confident this will work across multiple domains but I couldn’t test it.
You can use the same link that is in the article to get the updated visual studio solution.
Hi Brad,
This sounds like just the ticket for monitoring our service accounts, but there is kind of a hitch in the get along, the link to the Visual Studio Authoring Extension no longer works, also my dev is using VS 2017 instead of VS 2015. Do you have any suggestions?
Jeff,
That link should still work. Here is the direct link not using tinyurl: https://1drv.ms/f/s!Am5WunbinyvqsIo5SDBKCTUW2oP5ng
The VSAE for 2017 is coming but it’s still in private preview right now. I’d expect a public preview soon but not sure of a date. Until then the only choice is to use VS 2015.
Can’t get this working for multiple domains.
Each domain its own SCOM gateway, and the AD PowerShell modules have been imported on each server.
Any ideas?