SCOM 2016 - Setting Up External Email Relay

There will come times when you need to use an external email relay service to send notifications from SCOM. If you are working with a smaller company that uses a third party mail service for example. This is also very helpful if you are building SCOM in a lab and want to use a personal email, like Gmail to test notifications.

There are a few things you will need before we begin:

• SMTP Username (usually your email address)
• SMTP Password
• SMTP server name* 
• SMTP port*

*I have added several common email providers to the end of this post that may help you out. If your provider isn't on the list please feel free to add it in the comments and I will update the list.

Create the Run As Account:
First thing we need to do is setup a Run As account. This will be used later for SMTP authentication. Go to Administration > Run As Configuration > Accounts and Create Run As Account. When the Create Run As Account Wizard starts Click Next

Set Run As account type to Simple Authentication. Display name should be easy to remember and recognize. Click Next

For Credentials you would enter the account name and password you use to log into your mail provider. Click Next

More Secure, Click Create

Click Close

Once it is created Right Click on it and select Properties. Go to the Distribution tab and Click Add

Under Options select Search by resource pool name and Click Search. Select Notification Resource Pool and Click Add. Click OK

You should see Notification Resource Pool in the list. Click Apply

Create Run As Profile:
Next thing we need to do is setup the Run As Profile. In Administration > Run As Configuration > Profiles select Create Run as Profile... Click Next

Give it a nice clear name, select or create a management pack and Click Next

For Run As Accounts Click Add

Choose the Run As account you just created and Click OK

All good, click Create

This isn't a Run As account we will be using internally so you can disregard this. Click Close

Create SMTP Channel:
Next  thing we need is to setup the SMTP Channel. In Administration > Notifications > Channels Select New > E-Mail (SMTP)... Give it a good clear name and Click Next

In Settings Click Add

In SMTP server (FQDN): enter the relay server information. Port number should be what was provided by your email service. Authentication method: External Email Authentication and Run as profile of external email account: should be the Run As account created earlier. Click OK

You should see the SMTP server in the list. Enter a return address and Click Next

Click Finish

From here you can setup the Subscribers and Subscriptions normally.

Next thing to do is to test it. Generate an alert and see if everything processes correctly. If it does that's great!

Now for Gmail (and probably others) there will be an additional step you need to do. After the alert was created and SCOM attempted to send the email Gmail will have blocked it. You probably got an email right after similar to this.

The wonderful people at Gmail are trying to protect your security and in doing so have blocked third party relay that is unrecognized. To allow this click the allowing access to less secure apps link.

Turn Allow less secure apps to On

Close the alerts you have in SCOM and you should start seeing the mail flow.

Common Mail Providers:
Here is a list of a few providers I found information for.

Google (Gmail):
Gmail SMTP Server Name: smtp.gmail.com
Gmail SMTP port: 587

Hotmail:
Hotmail SMTP Server Name: smtp.live.com
Hotmail SMTP port: 25

Yahoo:
Yahoo SMTP Server Name: smtp.mail.yahoo.com
Yahoo SMTP port: 587

Cox:
Cox SMTP Server Name: smtp.cox.net
Cox SMTP port: 587

Comcast:
Comcast SMTP Server Name: smtp.comcast.net
Comcast SMTP port: 587

Microsoft (O365):
O365 SMTP Server Name: smtp.office365.com
O365 SMTP port: 587


More to come!

If you like this blog, give it a g+1

SCORCH 2016 - Protecting Active Directory Security Groups

So last year I did a fun segment for SCOM on How to Monitor Domain Administrators Group to detect unauthorized modifications to the Domain Admins, Schema Admins and Enterprise Admins groups in Active Directory. Now that we have SCORCH setup in our lab its time to take it to the next level. Once SCOM detects the change we can use SCORCH to disable the offending account, remove it from the security group and make a notation as to why the action was taken.

Modifying the Rule:
First thing we need to do is make a change to the rule we created in SCOM so SCORCH knows what to look for. In Authoring > Rules do a search for the rule you created. Right Click and select Properties. When the Properties window opens go to the Configuration Tab. Under Responses select Edit

In the Alert - Properties Click Custom alert fields

In Custom Alert Fields add DAModAdd to Custom field 1 and $Data/Params/Param[1]$ (the distinguished name of the user who was added to the group) to Custom field 2. This will tell SCORCH what and who to look for so it will kick off the Runbook when this alert is generated. Click OK to everything and you are done with SCOM for the moment.

Creating the Runbook:
This is what the Runbook looks like:

 

We are monitoring SCOM for a specific alert. It then pulls the user data from the alert and disables the account. Then we make a notation in the account as to why it was disabled. It is removed from the Domain Admins group and we then update the alert in SCOM. I also used two variables which I will get to in a moment.

Monitor Alert:
We are looking for DAModAdd from SCOM so we want CustomField1 Equals DAModAdd

Disable User:
For Disable User you need the distinguished name which we setup in the parameters of the SCOM Alert earlier.

Update User Properties:
The same custom field used again to identify the user to change. Then added Notes from Optional Properties. In the notes field I put (you can put whatever you like):

Unauthorized Group Access! User disabled by Orchestrator {Date}

Where date is the first variable I added. I invoked the NOW() wildcard in order to date stamp the account so you could tell when the account was disabled.

Remove User from Group:
Now we pull the user out of Domain Admins.

The second variable I created was {Domain Admins} as I plan to use it in later Runbooks.

Note: At the time of this writing there is a bug in the Active Directory Integration Pack. Administrators are reporting an error when trying to add or remove a user from an AD Group. The error "unknown exception caught" shows up in Runbook Tester and fails at this step. The only known fix that I was able to find is to either roll back to a previous version of the ADIP or use the PowerShell IP with the following syntax and variables described earlier:

Remove-ADGroupMember -Identity "{Domain Admins}" -Members "{CustomField2 from "Monitor Alert"}" -Confirm:$False

If someone finds a fix for this please feel free to share it in the comments. 

Update Alert:
Finally we update the SCOM alert. Some people like to just close the alert at this point but I would rather change the Resolution State and close it myself. I created a custom state called User Disabled. You can refer to Creating and Setting Resolution States for help with that.

Go ahead and run it in Runbook Tester. When it executes we should get a disabled user with this in the notes:

And an updated alert

As we did with the monitoring of Domain Admins, Schema Admins and Enterprise Admins you can do the same here. Just change the Custom field 1 to:

SAModAdd - User Added to Schema Admins
EAModAdd - User Added to Enterprise Admins

From there you can create the appropriate Runbooks.


More to come!

If you like this blog, give it a g+1

SCORCH 2016 - Integration Packs

Now that we have SCORCH installed and ready to create some Runbooks lets go ahead and setup the System Center Integration Packs so that we can plug SCORCH into some of the tools in our environment like SCOM and SCCM. You can download the IPs from Microsoft here. Extract them to your hard drive and you should have several .oip files.

Now that we have them downloaded it's time to register them. Double check the .oip files and make sure they are not set to Read-only as this may cause issues later. Open the SCORCH Deployment Manager.

Expand the Orchestrator Management Server and Right Click on Integration Packs. Select Register IP with the Orchestrator Management Server...

The Welcome to the Integration Pack Registration Wizard will start. Click Next

On The Select Integration Packs or Hotfixes screen navigate to where you extracted the .oip files and select the ones you plan to use. I chose SCCM, SCOM, SCSM and AD. Click Next

Confirm your choices and Click Finish

Accept the EULA times however many IPs you selected

Now you should see all of the IPs that you installed.

Right Click on Integration Packs. This time choose Deploy IP to Runbook Server on Runbook Designer.

This time the Welcome to the Integration Pack Deployment Wizard will start. Click Next

Select all of the new IPs you need to deploy. Click Next

Enter the name of the server that has Runbook Designer installed on it and Click Add. Then Click Next

You can schedule a time when the SCORCH server is not busy or in our case we have a new server with no active Runbooks so we are going to install now. Click Next

Review your install choices and Click Finish

The deployment will walk through all the chosen IPs 

When it is finished you should see in the logs

Close Runbook Designer and reopen it. You should now see the new IPs under Activities

Last thing to do is make the connection between SCORCH and the other Components. In Runbook Designer Select the Options drop down and select one of the IPs.

In the Connection Wizard Click Add and populate the connection with your server data and account credentials to be used to make the connection. Be sure to Test the connection to ensure it will work. Click OK

 

Click Finish

Repeat this step for all IPs and you are ready to start making some Runbooks!


More to come!

If you like this blog, give it a g+1