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:


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.


Migrating Notifications from SCOM 2012 R2 to 2016

When upgrading a SCOM environment from 2012R2 (or 2012) to 2016, one of the most time demanding tasks can be replicating the notifications settings. In my case, I had to do a brand new install, and needed some way to migrate the notifications configuration from the old SCOM environment to the new. Luckily there is a pretty quick way to achieve this. Let’s begin!

Log in to the 2012R2 environment, go to the Administrations pane, and locate and export the Notifications Internal Library (Microsoft.SystemCenter.Notifications.Internal). Export this MP somewhere locally.

Open the MP/XML file with some editing tool, Notepad, Notepad++, Visual Studio, etc….

As you can see, this MP version is version 7.1.10226.0.

If you quickly hop over to the SCOM 2016 environment, and locate the same MP (same name, Microsoft.SystemCenter.Notifications.Internal), you will notice it is a different version. What we will need to do here is, update the OLD MP to a version number just slightly higher than the one in the 2016 environment.

So, in my case, I will change 7.1.10226.0 to 7.2.11719.1. Save the XML file, and copy it over to the SCOM 2016 environment.

Next we have two options:

  1. we can either import the updated MP, or,
  2. alternatively we can delete the MP from SCOM 2016 (v7.2.11719.0)

Before doing that, it is recommended to export the MP, and save it for “just in case“. In my case, I deleted the MP.

Now if you go into Notifications settings, you will see an exact copy of the configurations from your SCOM 2012R2 environment. To enable all the notifications, or disable, execute the following cmdlet in the OperationsManager console.

Get-SCOMNotificationSubscription | Enable-SCOMNotificationSubscription
Get-SCOMNotificationSubscription | Disable-SCOMNotificationSubscription

As an FYI, I forgot to disable the subscriptions beforehand. This would have been ideal to do before saving the XML file before importing into SCOM 2016. You can edit this by replacing the following text. Run a Control+H (Replace), and Replace All, Enabled=”true” to Enabled=”false”.


There you go! Notifications have been replaced from SCOM 2012R2 to SCOM 2016.

Monitoring Domain Controllers in SCOM 2016 – Event ID 1102

So  you deploy a SCOM 2016 agent to a Windows 2016 Domain Controller, only problem is, after the agent push, discovery doesn’t work. Well, the agent isn’t corrupted… Ports are open… SCOM agent is being deployed using the System Local account…  etc. etc. So, now what?

Taking a look at the Windows 2016 domain controller and its event log, the domain controller OpsMgr log is getting bombarded with Event IDs 1102….

After some investigation, seems to be this has been an issue in SCOM 2012 (and 2012R2) as well. Well, here’s the fix…

Taking a look at the HSLockdown, the Local System account is being denied access..  Browse to the following folder “%windir%\Program Files\Microsoft Monitoring Agent\Agent “and run the following command (elevated access…), “HSLockdown.exe /L

Now that we can see the Local System account is being denied access, let’s give it access… Running the following command, “HSLockdown /A “NT AUTHORITY\SYSTEM“. Restart the SCOM Agent (net stop HealthService.exe & net start HealthService.exe) and you should be good to go now!


How To Disable Azure AD Connect via PowerShell

Recently I came across an environment where Exchange was being migrated to Office 365. As you may know, DirSync is no longer supported for Exchange/O365 migrations and Microsoft recommends you now use Azure AD Connect.

With that said, recently in a PoC environment, using Azure AD Connect, the domain controller that was running the Azure AD Connect utility was never uninstalled, and the VM was shortly deleted. Well, as a result, the O365 admins are now getting reminded daily that their AD Sync has failed to connect.

As of today, there is no way to disable Azure AD Connect via the Azure Resource Manager (ARM) portal, but this can be done with some PowerShell. If you take a look at the ARM portal, there is no option to currently disable the directory synchronization.

First, you will need to install the Azure Active Directory Connection utility, the download for that can be found HERE. This will provide you the PowerShell cmdlet’s needed to run the code below. No, AzureADPreview V2 will not work (yet…).

Once installed, launch the PowerShell console and we will need to connect to Azure AD and trigger the Directory Sync to false. Below are the commands you will need to get this done. Note, you will need an Azure global admin account with the *@*.onmicrosoft.com domain to successfully sign into Azure AD via PowerShell.

#specify credentials for azure ad connect
$Msolcred = Get-credential
#connect to azure ad
Connect-MsolService -Credential $MsolCred
#disable AD Connect / Dir Sync
Set-MsolDirSyncEnabled –EnableDirSync $false 
#confirm AD Connect / Dir Sync disabled

If you choose to re-enable the AD Connect, just change the flag to TRUE.

Set-MsolDirSyncEnabled –EnableDirSync $true 

Once complete, we can now verify the Directory Sync has now been disabled in ARM.

For more on Azure AD PowerShell cmdlets, visit the following page, HERE.