Author: Ravi Yadav

Ravi Yadav is a Senior Technical Consultant @ Infront Consulting Group. Working specifically with Microsoft System Center suite, specializing in Operations Manager, OMS (Operational Management Suite), Management Pack (MP) Dev, Configuration Manager and Virtual Machine Manager. He is based out of Canada, and when he is not at his PC, he enjoys reading, cooking, photography and keeping up with the Toronto Blue Jays.

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

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…)

Advertisements

What is Azure File Sync (AFS) and how to set it up?

Earlier this month, Microsoft introduced Azure File Sync (AFS). So, what is Azure File Sync (AFS)?

Azure File Sync is a cloud based backup solution for backing up and providing disaster recovery options for a single, or multiple file shares within a server, or multiple servers. Some of the benefits are:

  • Eliminates network and storage complexity and capacity planning, as it is done for you in Azure.
  • Changes to on-premises data are synchronized in real time to Azure, and file/folder backup is completely seamless to the end-user(s).
  • At the current time, AFS offers 120 days of data retention.
    • I suspect this will increase over time, and will allow administrators to have options with higher or lesser days of retention.

Setting up and configuring Azure File Sync is pretty quick. Below is how I setup Azure File Sync to sync a folder/files from my local server to Azure. AFS is pretty cool stuff, and I have been wanting to chat about it for some time (NDA). At any rate, getting AFS setup is pretty easy. Microsoft provides pretty good documentation on how to do this as well, but in my opinion, they have elected to omit some steps. Here is my take:

First you will need to create a new Azure File Sync Storage Sync. Within the Azure marketplace, search, “Azure File Sync“. Note, Azure File Sync is currently only available to a limited set of regions:

  • South East Asia
  • Australia East
  • West Europe
  • West US

Once created, under Sync, and getting started, download the Storage Sync Agent.

Note, Azure File Sync currently only works with Windows Server 2016 and Windows Server 2012 R2 (servers must be installed with a GUI — no core).

Download and install the agent on your local server, and configure it to the Storage Sync Service you just created in Azure.

Whoops, since this a brand new server install, there is no AzureRM PowerShell modules installed. Go ahead and launch PowerShell as an Administrator, and execute the cmdlet, “Install-Module AzureRM -force

Okay, back to the install. Remember to select the Storage Sync Service you just created in Azure

Once the install is complete, go back to Azure, and under Sync, Registered Servers, your local server should now be present.

Great, now we need to create a Storage account. We can either chose an existing storage account, or create a new one – I chose the ladder.

Regardless with route you take with the Storage account, go into the Storage account properties, and scroll down to File Service, and select Files.

Create a File Share, give it some name, and some quota. I gave it 1GB, as this is simply for testing and PoC. The file path is the same file path you want to backup to AFS. This file path should already exist on your local server(s).

Now go back to your Azure File Sync, and under Sync, and Sync Groups, create a new Sync Group. Within the Azure File Share, select the File Share we just created within our Storage account.

Finally, now we can create an server endpoint. Go back to your Sync Groups, and create a new server endpoint. Here you will need to specify the file/folder you will want to share/copy/backup to your Azure File Sync (AFS).

And that is it! Next I will show you how you can actually restore from your Azure File Sync.

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

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

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.

Differences Between Active Directory and Azure Active Directory

Lately, a lot of people keep asking, “What’s the difference between Active Directory, and Azure Active Directory?” Well, in short, a lot! Here is my take on it, and my typical response to customers.


One thing to note is, Azure Active Directory (AAD) and traditional/on-premises Active Directory (AD) are similar yet two very different things. One thing to note is, Azure Active Directory (AAD) and traditional/on-premises Active Directory (AD) are similar yet two very different things.

When you’re focusing on traditional On-Premises AD, you have the ability:

  • Create Organizational Units (OUs),
  • Create Group Policy Objects (GPOs),
  • Authenticate with Kerberos,
  • Working with a single domain (machine joins),
  • Query and interact with Lightweight Directory Access Protocol (LDAP),
  • Domain trusts between multiple domains,
  • And so on…

With Azure AD (AAD), functions mentioned above do not exist. AAD is simply an identify solution, and essentially a federation hub for online services, ie. Office 365, Facebook, and other various 3rd party applications/websites, etc.

  • Users and groups can be created but in a flat structure, things like OUs and GPOs do not exist in AAD.
  • Since there is no domain trust with AAD, federated services are used to create a relationship. This can be achieved with ADFS, which allows On-Prem AD to communicate and authenticate with SSO (Single Sign On).
  • Also, you cannot query against AAD with LDAP, however you can use REST API’s that work HTTP and HTTPS.

Here is a great article, along with many others on the web, that help explain. https://blogs.technet.microsoft.com/chrisavis/2013/04/24/active-directory-differences-between-on-premise-and-in-the-cloud/

 

Enabling SCOM 2016 Agent Proxy

Not too much has changed when it comes to SCOM 2012R2 and SCOM 2016. This post is a similar post to SCOM 2012R2, but applicable to SCOM 2016. (See that post here).

You could go to the computer that SCOM is complaining about and manually enable the agent proxy via Administration > Managed Computers, and modifying its properties, see below:

2

Or…… you could make your life easier, and do this…

The fix is easy, and the explanation are both below:

To resolve the “Agent proxy not enabled” alert for all machines in your current environment, run the following PowerShell code in the SCOM PowerShell Console:

get-SCOMagent | where {$_.ProxyingEnabled -match "False"} | Enable-SCOMAgentProxy

To prevent this alert in the future, run the following below:

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"; new-managementGroupConnection -ConnectionString:<strong>yourSCOMMGMTserverFQDNhere</strong>; set-location "OperationsManagerMonitoring::"; Set-DefaultSetting -Name HealthService\ProxyingEnabled -Value True

 

Monitoring Domain Controllers in SCOM 2016 – Script Automation

Not too long ago, I wrote about how SCOM 2016 has some workarounds for monitoring domain controllers, find that post here. We learned the HSLockdown tool needs to be configured to allow the Local System account to be run under.

I was in an environment were 100+ domain controllers needed this done.. No way was I going to do this manually 100+ times… So, I wrote the following script. Unfortunately, do some PowerShell switch limitations, I had to resort to using a batch command line script.

How it works. Save the list of servers affected to a text file. Using this file/script, and PSExec, we can execute the script against the servers affected. To get that script, please visit the Microsoft TechNet Gallery.

Cheers!