Category: OMS

Log Analytics (OMS) AD Assessment – “No Data Found”

July 10, 2018July 10, 2018 · Leave a comment ·

So, you deployed the OMS/Log Analytics AD (Active Directory) Assessment solution, and let it sit for a few hours, or maybe even a few days now.. Yet, the AD Assessment tile is still shows, “No Data Found“….

Well that is frustrating! Below is the series of steps I took to get this working, and ultimately what the actual solution was to get this OMS/Log Analytics solution pack working.

First things first, did the basics… Check to ensure the Microsoft Monitoring Agent is deployed, and installed correctly. Also checked to see the service was running.

Confirmed the AD Assessment prerequisites were all satisfied:

The Active Directory Health Check solution requires a supported version of .NET Framework 4.5.2 or above installed on each computer that has the Microsoft Monitoring Agent (MMA) installed. The MMA agent is used by System Center 2016 – Operations Manager and Operations Manager 2012 R2, and the Log Analytics service.
The solution supports domain controllers running Windows Server 2008 and 2008 R2, Windows Server 2012 and 2012 R2, and Windows Server 2016.
A Log Analytics workspace to add the Active Directory Health Check solution from the Azure marketplace in the Azure portal. There is no further configuration required.

After all that, I decided to execute the following query within Log Analytics, I got the following results:

Operation | where Solution == "ADAssessment" | sort by OperationStatus asc

Okay, so I ensured .NET 4.0 was installed, fully. For safe measures, I enabled all of the .NET 4.6 sub-features, and for kicks, installed .NET 3.5 as well. Yet.. still nothing!

Next, I decided to take a look at the registry…

If we navigate to the following Registry Key, “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management Groups\<YOUR Management Group Name>\Solutions\ADAssessment”

I decided to delete the “LastExecuted” key, and then decided to reboot the server….

After a few minutes, I went back to the OMS/Log Analytics portal, and there it is!!!!

I ran the same query again, and verified the AD Assessment solution was working as expected:

Operation | where Solution == "ADAssessment" | sort by OperationStatus asc

Great! Now, if I click within the tile, I get the following AD Health Checks.

I hope this helped! Cheers! For more information on the OMS Active Directory Assessment Solution, please visit: https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-ad-assessment

Azure Update Management – Part II

March 8, 2018 · 5 Comments ·

A little while ago, I blogged on OMS’ (Operations Management Suite) Update Management Solution. As great as this solution was, there were some limitations at the time, such having the ability to exclude specific patches, co-management with SCCM (Configuration Manager), and few others.

Since that post, there have been some great improvements to Update Management, so let’s go over some of the key updates, and do a quick setup walk-through:

Both Windows (2008R2+) and (most) Linux Operating Systems are supported
Can patch any machine in any cloud, Azure, AWS, Google, etc.
Can patch any machine on-premises
Ability to Exclude patches

One of the biggest improvements I want to highlight is, the ability to EXCLUDE patches, perhaps in time there will also be INCLUDE only patches. 😉

First, we need to get into our Azure VM properties.. Scroll down to the Update Management.

If the machine belongs to a Log Analytics workspace, and/or does not have an Automation Account, then link it now, and/or link/create the Automation Account
If you do not have an Log Analytics workspace and/or an Automation Account, then you have the ability to create it at run-time now.

In this scenario, I kept it clean as possible, so both the Log Analytics workspace needs to be created, and likewise for the Automation Account, and Update Management needs to be linked to the workspace.

Once enabled, it a few minutes to complete the solution deployment….

After Update Management has been enabled, and it has run its discovery on the VM, insights will be populated, like its compliance state.

Now we know this machine is not compliant, as it missing a security update(s), in addition, missing 3 other updates too. Next, we will schedule a patching deployment for the future. So let’s do that now.

Now we can create a deployment schedule with some base settings, name, time, etc. But one thing to note, we can now EXCLUDE specific patches! This is a great feature, as let’s say, we are patching an application server, and a specific version of .NET will break our application, as the application Dev team has not tested the application against the latest .NET framework.

In this demo, I am going to EXCLUDE patch, KB890830.

Next, we need to create a schedule. This can be an ad-hoc schedule, or a recurring schedule.

Once you hit create, we can now see the Deployment Schedule, under Scheduled Update Deployments.

You can also click on the deployment to see it’s properties, and which patches have been excluded.

After the deployment has initiated, you can take a look at its progress.

If we go into the Update Deployment (yes, I got impatient, and deleted the first one, and re-created it…), and click on the Deployment we created, we can see the details.

As you can see, patch, KB890830 was not applied! Awesome.

If we not go back to the Update Management module, we can now see the VM is compliant.

Connect Batch of Azure VMs to Log Analytics (OMS) via PowerShell

October 16, 2017October 16, 2017 · 1 Comment ·

So, you have a bunch of Virtual Machines (VMs) in Azure, and didn’t used an ARM template, and now need to connect the VMs to Log Analytics (OMS). Earlier this month, I demonstrated on this can be done with the ARM portal, here’s that blog post. Of course, this has to be done individually and can be very tedious if you have 10’s or 100’s of machines to do this to… All I can think of is PowerShell!

Here is a script I tweaked that Microsoft has already provided but for a single VM. I have just tweaked it to automate and traverse through your entire resource group, and add ALL VMs within the RG to Log Analytics.

Here is the link to Microsoft TechNet for that script. Please test it out and let me know. And if it helped you out, please give it a 5 start rating.

Microsoft TechNet PowerShell Gallery

If all went well, your before and after should look similar to this. I had two test VMs in my Resource Group.

Before:

After:

(more…)

Connect Azure VMs to Log Analytics (OMS) via ARM Portal

October 2, 2017October 2, 2017 · 2 Comments ·

Let’s say you have a bunch of machines in Azure, and want them communicating with Azure Log Analytics (aka OMS). Well, I am pretty sure that last thing you want to do is deploy the Microsoft Monitoring Agent to each machine, manually…

Well, now you can connect a VM to Log Analytics (OMS) with just a few clicks.

Go into the ARM (Azure Resource Manager) portal, and navigate to your “Log Analytics” blade, select your OMS workspace name, and within the Workspace Data Sources, select Virtual Machines.

Here you should have your machines that currently live within Azure. As you can see, there is one machine that is not connected to the OMS workspace. Let’s connect it now.

Select the VM in question, and you will now be presented with the following:

Make sure the VM is online/running, and select Connect. The VM must be online in order for the extensions to be passed through.

Give it a few moments, and there we go! No manual agent deployment.

We can also verify now in OMS, to see our new machine chatting with Log Analytics. (Go into the Agent Health solution/title)

ADFS Monitoring with Azure, OMS, SCOM 2016

September 21, 2017December 5, 2017 · 3 Comments ·

ADFS (Active Directory Federation Services) has really taken flight since the inception of Office 365 and Azure Active Directory. Getting your on-premises environment configured with online identity services such as Azure, and having the SSO (Single Sign-On) abilities makes ADFS fundamental. Implementing ADFS is one thing, but what about monitoring your ADFS environment?

The following post is intended to illustrate the differences between ADFS monitoring by comparing the following monitoring tools: Azure AD Connect Health, OMS (Operations Management Suite) and SCOM 2016 (System Center Operations Manager).

SCOM (Operations Manager) 2016

First step is to deploy SCOM agents to your ADFS environment/servers along with the ADFS Management Pack install. Once that is complete, and discovery has run, we should start seeing data within the ADFS view(s).

Within the ADFS view, we can see some useful information such as Token requests. This data is represented in an hour fashion, and we can see the number of tokens being requested per hour over the given date range.

And good view is the Password Failed attempts. We can see how many bad password attempts were made over the various date range, but information such as which user, and when, could be useful.

This information is all good, however without doing some custom management pack work, it is impossible to get any additional data, ie. which users are requesting the token, which users are inputting bad passwords, and which users are connecting to which site/service offered by ADFS.

OMS (Operations Management Suite)

OMS does a nice job with dashboards, but unlike SCOM, we need to not only know which Event IDs we need to capture, we also need to build our dashboards out. This is not ideal, as it does require some custom work, and some investigation with regards to ADFS related Event IDs.

The query below, “EventID=4648 OR EventID4624 | measure count() by TargetAccount” shows us which target account/active directory user has requested the most ADFS tokens over the last 1 hour. Please note, this query is based on the OMS Log Analytics language version 1.

Since OMS does require a lot of ADFS knowledge, ie Event IDs, I decided not to proceed any further and build additional queries and dashboards.

Azure AD Connect Health

Lastly, Azure AD Connect is probably the most simple, and least technical configuration.

As a prerequisite, I enabled the all event types on the ADFS logs.

After running the AD Connect agent on the ADFS server(s). And launching the Azure Resource Manager portal, we get some dashboards. Right off the bat, we can see some excellent information. Let’s take a deeper look.

If we click on the total request widget, this shows us similar data as we see in SCOM 2016, with some exceptions. Not only can we see the number of tokens being requested. We also can see which ADFS server within the farm is distributing the tokens. Since this is a highly-available and load-balanced configuration, it is comforting to know ADFS is distributing tokens as it is designed.

Secondly, we can also see which services within ADFS are generating the most hits. This is great to see which sites are the most busy. This something that lacks in SCOM and OMS, and I was unable to generate even after some custom MP work.

If we go into the Bad Password Attempts widget, we can see not only the number of bad password attempts, but also see which user and at what time and their source IP the attempt was generated from — very cool!

Overall, AD Connect Health does an excellent job and provides rich data and expands on what SCOM already does.

Verdict

After comparing SCOM 2016, OMS and Azure AD Connect Health, the clear winner is Azure AD Connect Health. Not only is the configuration straight forward, but provides more than enough information to monitor the ADFS environment. Azure AD Connect Health provides rich and very clear dashboards with almost no effect other than some log configuration on the ADFS server(s). The data is comparable to what SCOM presents, however much more richer and detailed. OMS and SCOM are still good tools, however does require some more technical knowledge and building the dashboards can be laboursome.

Using OMS for Patch Deployment (Update Management)

February 2, 2017February 2, 2017 · 12 Comments ·

Not too long ago, the OMS team introduced the Update Management solution. This solution has definitely made the patch management process a lot easier, however at the same time, has raised some questions, such as:

What’s the future of SCCM (Configuration Manager) with OMS now deploying patches?
Can this be used concurrently/dual-homed with SCCM for on-premises environments?
Is OMS essentially System Center in the cloud?
Is OMS the future?

For the most part, SCCM will still be required for on-premises environments. When it comes to application deployments, computer/server images, granularity with patch/hotfix selection, etc. Microsoft has explicitly stated SCCM configured machines cannot be tagged to OMS with respect to patching, so at the current time, OMS and SCCM cannot/will not work together, whereas OMS and SCOM work hand-in-hand (for now?).

It also seems OMS is slowly becoming System Center in the cloud. It has absorbed the monitoring capabilities from SCOM, and now the patch management process from WSUS and SCCM.

So, is OMS the future, in my opinion, no, it is not the future, it is very much the present! I think OMS/Azure will soon welcome the demise of System Center.

Getting started with OMS Update Management is very easy. For starters, you will need the following:

OMS Workspace
Update Management Solution added to OMS
Automation account (create in Azure first)
Machines to manage

Once we have taken care of these steps, the rest is pretty easy.

Clicking on the Update Management title, here is an overview.

Update Management Overview

As we can see, I have a few machines that need some updates. I haven’t introduce a Linux machine to OMS yet (had to create a new workspace recently… Maybe I will get to that in another blog post, until then..)

If we move over to the right, and click on Manage Update Deployments, we can then see our current configuration and schedules, and create new ones.

Create an Update Deployment

Creating a deployment schedule is very, very easy!

Name your deployment, and select some computers to manage in this group.

Notice the big red box, we cannot couple machines with OMS Update and System Center Configuration Manager!

Next, create a schedule, for example deploy patches on the Last Sunday of the month, and run the schedule for 5 hours (300 minutes). If a machine is unable to complete the patching cycle within the 300 minutes, it will resume with patches at the next scheduled deployment.

We can also choose to run this schedule 1-time, or reoccur weekly. Once happy with the schedule and computers, hit Save.

Once saved, we can now see our Scheduled Update Deployment.

Post Update Deployment

Once the Update Deployment has executed, let’s take a quick look at the updates that were applied.

If go back to OMS and select the results, we can see what patches were applied, what failed, etc.

We can also expand further, by seeing the KB for the patch, and the exact patch that was applied, or failed, or missed, etc.

If we go back to the Update Deployments, we can see our deployment ran as planned, and patched the 4 servers in the group (one of the five machines was offline).

Now we should have a better/happier Update Management Overview:

Here’s the title from OMS (All Solutions) view:

So how exactly did this all happen?

How the Update Management Solution Work?

The short answer is, “I don’t know.” 🙂

I say this because the solution clearly adds two Runbooks to the solution, and both of these Runbooks are not accessible and not even visible. If you dig a bit into the Job details, then we can see some information. But overall, the guts of this solution is pretty well hidden.

Go into your Azure portal (ARM — Azure Resource Manager) and find Automation Account you created for this solution to work. I called mine, “OMSUpdateMgmt“.

As you can see, there are 0 (Zero) Runbooks… and we now have 7 Hybrid Worker Groups.

If we click on the Jobs title, we can see 4 jobs completed (I had 5 schedules/deployments. I cancelled 1).

If we click on this title, we can get some more information:

Ah ha!! There are the Runbooks, “Patch-MicrosoftOMSComputer” and “Patch-MicrosoftOMSComputers“. If we select one of the jobs, we can get some more detail.

We can now see the Runbook executed against my SQL server.

If we click on Input, we can see the Runbook, “Patch-MicrosoftOMSComputer” has 6 Input parameters:

WORKSPACEID
DURATION
SCHEDULENAME
MACHINEID
STARTTIMEUTC
MASTERJOBID

If we go back to the OMSUpdateMgmt Automation Account overview, and select Hybrid Worker Groups, we can get some more insight. 😉

Nice, the Automation Account found all the machines in my workspace, and made them each a worker.

FINAL THOUGHTS

Pros:

Very easy to create collections/groups (similar approach to SCCM/WSUS)
Simple setup for multiple patch cycles
Able to patch Nano machines as well
Can leverage OMS Alerting for missed patches
Complexity of the implementation could not be easier
Works for both Windows Server and Client OS

Cons:

Cannot approve/decline specific patches/fixes like in SCCM/WSUS
Cannot use SCCM in parallel
Computers must be Windows Server 2012 or higher
No roll-back of patches
No inventory of patches/hotfixes/drivers to be deployed

The Update Management solution for OMS is great! It makes the entire process a lot easier and cleaner (IMO), especially since I am not a SCCM expert. You can setup collections just like we could in WSUS and SCCM. However there are some negative takeaways (see above). Of course like most OMS solutions, updates are pushed out regularly, so I am sure the Update Management solution will get some tweaks here and there as time goes on.

For more information on the OMS Update Management Solution, please visit the following: https://docs.microsoft.com/en-us/azure/operations-management-suite/oms-solution-update-management

Dual-Homing OMS/Microsoft Monitoring Agent (MMA) — Questions

December 14, 2016December 14, 2016 · 8 Comments ·

Earlier this week, I posted on how the OMS/Microsoft Monitoring Agent (MMA) can be dual-homed for multiple OMS Workspaces.

A good question from the community came up (thank you @ Manoj Mathew), “Have you noticed any performance impacts on the Agents when they are multi homed to OMS?“

In the OMS Query below — making use of OMS’ Log Analytics, I checked the performance data in the last 48 hours. Unfortunately I cannot go any further, since the MMA was deployed earlier in that day, and the second OMS workspace was added later that afternoon.

There are a few spikes in the Memory and CPU, but this is also a result of a few factors:

Initially there is a high level of CPU/Memory usage as OMS did its stuff when the MMA/OMS made friends and synced up their data/solutions
There is a small spike when the second OMS workspace was added but this is minimal at best
This server was being patched with 90+ Windows Server OS patches around 8PM.

The query I used to collect the data is here,

Computer="COMPUTERNAME.FQDN" Type=Perf (CounterName="Available MBytes" OR CounterName="% Processor Time") (ObjectName=Memory OR ObjectName=Processor)

A second question being asked here is, “how many OMS Workspace IDs can be added to “dual-home” the MMA agent?“

Unfortunately I only have 3 OMS Workspace’s to work with at the moment in this environment, but with that said, I can surely say a minimum of 3. If you have the ability to test more than 3, I would love to find out!

Dual-Homing OMS/Microsoft Monitoring Agent (MMA)

December 12, 2016December 14, 2016 · 2 Comments ·

Today I learned that the MMA (Microsoft Monitoring Agent) has the ability to be “dual-homed“. Similar to what we have seen in the past with the System Center Operations Manager (SCOM) agent and dual-homing it to multiple SCOM environments/Management Groups, the same can be said for the Operations Management Suite (OMS)/MMA agent. By going into the MMA properties, you can add multiple OMS Workspace IDs. This is great if you want the Computer reporting to multiple OMS Workspaces and/or Azure Subscriptions, as was the case for me today.

Simply launch the MMA agent, and within the Azure Log Analytics (OMS), add your OMS Workspace ID here.

Note, this works for the MMA version, 8.0.11030.0 — Windows. Has not been tested against the Linux Agent.

SCOM 2016 + OMS Toronto Meetup! – Reminder

November 7, 2016November 7, 2016 · Leave a comment ·

Hi All,

Just a quick reminder, next week, November 16th, I will be hosting a SCOM 2016 and OMS meetup. It will be hosted at the University of Toronto, Nov 16, 2016. Please see the link below for more details!

Seating is free (but limited!), so RSVP your spot soon!! For more details on the Meetup, please see HERE.

See you all there!

Step-by-Step: Setup and Configure Azure Site Recovery (ASR) for On-Premises Virtual Machine with Azure Resource Manager (ARM)

November 7, 2016November 1, 2016 · 3 Comments ·

This post is a series of blog posts for Azure Site Recovery (ASR).

ASR for VMs being hosted within Azure
ASR for a Hyper-V hosted On-Premises, coming soon…
ASR for an ESXi hosted On-Premises, coming soon…

Here is a step by step walk-through on how to go about setting up and configuring ASR (Azure Site Recovery) and backing up your On-Premises Virtual Machines (VMs) with Azure Resource Manager (ARM).

First things, first, Azure’s Recovery Service Vault is a unified vault/resource that allows you to manage your backup and data disaster recovery needs within Azure. For example, if you are hosting your VMs on-premises you can create a link between your on-prem site and Azure to allow your VMs to be backed-up into Azure. This is regardless of your hypervisor, it can be either ESX or Hyper-V, either will work. However for the interest of this blog post, I will be setting up ASR for VMs being hosted on your On-Premises environment on a Hyper-V 2012R2 environment.

Configuring Azure

Step 1: Create a Recovery Services Vault

Within Azure Resource Manager (ARM), if we select New, within the Marketplace, select Monitoring + management, then select Backup and Site Recovery (OMS) within the featured apps. Of course if this is no longer present, just search for it within the marketplace.

Next we will now need to create our vault.

Give it a meaningful name, and you can either create a new Resource Group, or use an existing. I opted with existing, as I will (another post) next setup a Site-to-Site ASR.

Give this a few seconds, maybe minutes to do its thing…

Great, now our Vault is up and ready to go!

Step 2: Choose your Protection Goal(s)

Click Settings > Site Recovery (Under Getting Stated) > Step 1: Prepare Infrastructure > Protection Goal > And specify the following > Click OK:

Replicating to: Azure
Machines Virtualized: Yes, with Hyper-V
Using SCVMM (Virtual Machine Manager): No

Step 3: Setup the Source Environment

Next, we will now need to give our Hyper-V site a name, “Ravi-OnPrem” makes sense here, but give it something meaningful.

Once validated, we can now go ahead with the Azure Backup Agent. Download the Azure Backup Agent, and also, download the Backup Credentials.

Download the Agent and Credentials to the server you will be backing up. In my example, I will be backing up a Windows Server 2016 (RTM).

Step 4: Microsoft Azure Recovery Site (MARS) Agent Install

The Microsoft Azure Recovery Site (MARS) Agent is a pretty simple install, but here is what I experienced when installing:

Since my environment is pretty open, ie. No Proxy, no changes required here.

Your call here..

All good with the MARS prerequisites… Hit Install!

All good, time to register our server to our Recovery Services Vault.

Step 5: Register Server to Azure Recovery Services Vault

Here is where we will need that VaultCrentials file.. I hope you downloaded it as mentioned earlier… As you can see, back in the first few steps, when we created our Vault, the settings are now automatically inputted.

Here, I decided to let the wizard generate the Passphrase. I then saved the key locally to the server.

Perfect! Now we can go ahead and with the Azure Back: Site Recovery/Backup Schedule, etc.

Step 6: Configuring Microsoft Azure Backup

Going back to our On-Prem server, which by the way is a Windows 2016 OS, let’s launch Microsoft Azure Backup…

Click on Schedule Backup within the (Right) Actions Pane:

Since this is a basic server, I only allocated 1 drive for this example, once we hit Backup, I am presented with the available drives.

Now we can begin defining our Backup Schedule

Step 7: Specify Backup Schedule

For this example, I want to back up the following server with the following properties:

Backup once a week @ 4AM, every Monday

Retention Policy will be as follows, see below:

Once you are satisfied with the policy, go ahead and hit next. Since we want to back up to Azure, and not an offline backup, we will backup over the network.

Have a look over before we do the initial backup.

Step 7: Initiate Backup Now

Going back to the main console, within the right pane, within Actions, let’s initiate our Back Up Now.

If we now double click within the job, we can see the Backup has begun….

Step 8: Validate Backup

If we go back to Azure, and take a look at our Vault properties, we can see there is a Backup in progress.

If we drill down within the Backup, we can see our server being backed-up.

After a few minutes, we can go back to the server, and track its progress:

And likewise, if we go within to the Azure Resource Manager, and within the Vault Backup jobs, and take a look at the details, we can see data is being updated to Azure.

Perfect!

SCOM & Other Geeky Stuff

A series of blog posts around Microsoft Cloud and Datacenter technologies, specifically Azure Cloud, System Center and other various Microsoft technologies.