A while back I got a question from a customer who wanted to update some of their alerts with the name of the server generating the alert. This can somewhat be found already by looking at the Path of the alert but this wasn´t good enough and they wanted to see just the server name, not the FQDN. My idea was to solve this using a PowerShell script which updated the alert with the server name and injecting it into Custom Field 1 of the alert.
To do this I am using the mentioned script along with the notification functions in SCOM. It´s really easy and fast to set up, see how it´s done below.
The first thing you need to do is to download the script from my TechNet Gallery here and place it in the same folder on all your servers that are part of the Notifications Resource Pool. To find out which servers are members of this resource pool, navigate to Administration and then Resource Pools.
One of the things I work with in my role as a product manager for Operations Management Suite (OMS) is the automation part of the suite. In this case, it means Azure Automation that can do a lot for us in terms of automating our recurring tasks. This post will be the first post about what you can do with Desired State Configuration (DSC) as a part of Azure Automation.
Before we get started there are some things worth knowing. As a part of OMS, the licensing for DSC is based on per-node and the listing price is at $10 per node/month. This means that each server you want to configure using DSC is assigned this license.
Before we get started there is one prerequisite you need to take care of; the latest version of WMF 5 (Windows Management Framework) needs to be installed on the server about to be configured as a DSC node. This makes is possible for the node to communicate with Azure Automation. You can find WMF 5 here. This isn´t necessary if you’re running Windows Server 2016 as I will be doing for this post.
The first thing we need to do is to create a file stating what to communicate with and what to do. This is called a MOF file and is what makes is possible to retrieve configuration, but also to register the server as a node to Azure Automation DSC.
In my earlier posts about what you can do with Azure Automation and OMS I have been using the Hybrid Worker Role for some, and for others I have run them directly in Azure. Now, what´s new since I wrote these posts is that you no longer need to delegate rights in your AD to the computer account running the agent connected to OMS. This has been changed as the team behind the Hybrid Worker Role have added the ability to run your scripts with a given run as account. In this post you will see how you can use Run as accounts with hybrid worker groups in Azure Automation.
If you want to read the historic posts, you´ll find them below:
So the time has come, holidays are over and we have stepped into another year. This time it says 2016 and I think we are looking into a great year with tons of possibilities, such as System Center 2016, Windows Server 2016 along with continuous updates to Operations Management Suite and a lot more. I ended last year with writing a series of five blog posts about how you can use Azure Automation and OMS to finish some of your repetitive tasks for you. Find them all below and take a look. Who knowns? This might be just what you´ve been looking for?
Now that my blog has been up and running for a complete year, the time has come for a summary of the year 2015. Of course this statistic should be shared with my readers as well to let you know what we have accomplished together.
During 2015 I wrote 41 different posts, starting with Using your onprem AD account with Azure Operational Insights and ending the year with a post about NiCE as a new sponsor and A first look at SCOM 2016 Technical Preview 4.
The last weeks I have blogged more about what you can do with Microsoft Operations Management Suite (OMS) and Azure Automation. This have ended up in three posts on how to create both on-prem AD users but also Azure AD users. To make life even easier for you, I have now created a runbook which lets you create new on-prem service accounts. The best part of it? It´s completely automatic and the only thing you need to provide is the system name (SM for Service Manager for example) and the function (Workflows, to use for SCSM workflows etc.), the rest is handled for you.
You can find the three previous posts below.
If you have been following my blog for a while, you might remember two of my later posts which concerns the creation of AD users, both on-prem and in Azure AD. Those posts show the real strength with using Azure Automation and you will see how easy you can make life for yourself but also for your personnel. The first post about creating AD users in your on-prem AD can be found here and the other one about creating Azure AD users can be found here.
So what have I done this time to make this post interesting? As I mentioned, the above posts are great in automating the user creation. But do you want to be the one as an admin or the author to sit all day and create users? Wouldn’t it be better if you could leave that to HR or someone else who can create the users as soon as they want it? Since I´m guessing that you would want to delegate this task, I´ve written this post so that you know how to do it. I will be using Role Based Access Control (RBAC) for Azure Automation to make all of this work.
A few weeks back I wrote this post about how you can use OMS and Azure Automation to create new users in your on-prem AD. That solution uses the Hybrid Worker Role of Azure Automation and works perfect as long as you want the user on-prem. But what about those of you that doesn’t have an on-prem AD anymore, or never had one? There´s no need to cry over that repetitive task anymore, cause I´ve got the solution for you. Do you want a way to automatically create new users in your Azure AD where all you have to do is to type in the name, city, office etc.? Then keep on reading, cause this is what you´re looking for.
When you start working with Azure Automation, you will most likely run into the fact that not all of the PowerShell modules you are used to is available in there from the beginning. A while back I wrote a post on how you can create an AD user in your on-prem AD using Hybrid Workers which you can find here. Since we´re moving more and more towards different cloud services, such as Operations Management Suite, Office 365 and so on, we have the need for our identities to also exist in the cloud. In this case as a follow-up on my previous post, I want to show you how you can create an Azure AD user as well using Azure Automation. For this to work, a couple of things needs to be configured first. In this post I will show how to get ready to automate this kind of tasks.
Every time a new employee starts its employment in a company, a new user should be created, a new mailbox should be created etc. Does this seem familiar? Have you been there? Is this one of the recurring tasks you wish someone else could do instead of you? Would you like it to be automated where you just put in some values and then someone else takes care of it?
If you have answered yes to one or more of the above questions, then you should definitely keep on reading, because this is exactly what I will help you out with in this post.