Few things in this world are black and white and that includes software you download. 

There is a lot of "gray-ish" stuff residing on computers today.  A good example is software that comes bundled with the computer or was installed by another software application of a different vendor. 

Most of the time these applications aren’t something you want in the first place.  Other examples include advertising software or evasion software that actively tries to dodge the detection of your cybersecurity tools.   While these software files may not pose a direct threat to your computer in the same way that malware, Trojans and other types of malicious software do, these unwanted applications can impede the performance of your endpoints.  These unwanted software servings are referred to as Potentially Unwanted Applications (PUA).  A PUA is an application that has a poor reputation.  These applications can serve as a time consuming distraction of cleaning up these files.  Over time, these applications can increase the risk to your network. 

Windows 10 Defends Against PUAs

Windows 10 (Professional and Enterprise editions) can detect and block possibly harmful third party and unwanted applications using Windows Defender and does so without requiring Defender ATP or Enterprise licenses.  When activated, the PUA security feature looks for certain file structures and conditions that include the following:

• The file is being scanned from the browser
• The file is in a folder with "downloads" in the path
• The file is in a folder with "temp" in the path
• The file is on the user's desktop
• The file does not meet one of these conditions and is not under %programfiles%, %appdata% or %windows%

Should these conditions be met, the file in question is then quarantined and not allowed to be installed until approved. 

Using PowerShell to Enable PUA

You can use PowerShell to enable PUA within Windows Defender. 

The command options are as follows:

Set-MpPreference -PUAProtection Enabled

Set-MpPreference -PUAProtection AudiMode

The PS command will add and modify the DWORD value in the protected registry key as is shown below.

HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows Defender\MpEngine\MpEnablePus.

And assigns one of the following values.

• Disabled: 0 (Does not block PUAs)
• Enabled: 1 (Blocks PUAs)
• Audit Mode: 2 (PUA events are reported in Windows Event Viewer.  PUAs will not be blocked however)

Of course, you can make the changes directly in the registry itself.

The end result is as follows:

Enabling PUA with Group Policy

For domain-joined machines, you can enable PUA protection through Group Policy.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Windows Defender Antivirus and enable “Configure protection for potentially unwanted applications.”

Then choose which your desired option:

You can also use Configuration Manager to deploy the setting as well.

05:07

Enabling PUA with Microsoft Endpoint Manager (Intune)

You can configure the Defender/PUA Protection CSP for your Intune enrolled devices.  You can either create a configuration profile or use the preferred method of enabling and configuring a security baseline.  To create a configuration profile choose Windows 10 as the platform and Device restrictions as the profile type. 

To deploy PUA using a security baseline, go to Endpoint Security > Security Baselines > Microsoft Defender ATP baseline > Profile configure the “Defender potentially unwanted app action” setting as is shown below.

Enable PUA in Chromium-based Microsoft Edge

The new Edge browser (version 80 and greater) contains its own PUA protection ability.  Go to your browser settings and select Privacy and services.  Then enable the “Block potentially unwarned apps” as is shown in the screenshot below.

You can also deploy this Edge setting using Group Policy as well.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Microsoft Edge > SmartScreen settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps.”

To enable the same setting using Microsoft Endpoint Manager, create a configuration profile and choose Windows 10 as the platform and Administrative Templates as the profile type.  Then go to Microsoft Edge > SmartScreen Settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps."

You should enable these PUA tools as a part of your multilayer security strategy.  Hardening your desktop devices and reducing their attack surface exposure is critically important.  Another way to stop PUA (or, really any unwanted file download) is application control via PolicyPak Least Privilege Manager.  You can check it out here.

The last thing that standard users need on Windows 10 machines is access to REGEDIT.  It is one of the first things we block access to with Group Policy.  Surprising though, there is no native way in Intune to block it however.  The good news is that you can do it by creating a custom profile in Intune or any MDM.  I have included the information you need to create it below.  Now you can be rest assured that users won't be causing issues and circumventing policies by messing with the registry.

OMA-URI:  ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/IntuneEdu/EXE/Policy

Data Type:  String (XML file)

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

        <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

        FilePathRule>

        <FilePathRule Id="ce9d9fd5-d765-48df-b87b-e1bafd5653ed" Name="All files" Description="Allows members of the Everyone group to run applications that are located in any folder." UserOrGroupSid="S-1-1-0" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

                        <Exceptions>

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT® WINDOWS® OPERATING SYSTEM" BinaryName="REG.EXE">

          <BinaryVersionRange LowSection="*" HighSection="*" />

        FilePublisherCondition>

                Exceptions>

        FilePathRule>

     RuleCollection>

Group Policy admins have been blocking access to command prompt for standard users since the beginning.  That is why it is frustrating for MDM admins having no native way in Intune to block it in the same fashion of Group Policy.  Well in actuality, you can block the cmd prompt, it just takes a custom profile, which is something that not everyone likes to do much.  Below is how you set it up so feel free to use the settings.  

OMA-URI:  ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/IntuneEdu/EXE/Policy

Data Type:  String (XML file)

Here is the XML code to paste in:

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

        <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

        FilePathRule>

        <FilePathRule Id="ce9d9fd5-d765-48df-b87b-e1bafd5653ed" Name="All files" Description="Allows members of the Everyone group to run applications that are located in any folder." UserOrGroupSid="S-1-1-0" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

                        <Exceptions>

                    <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT® WINDOWS® OPERATING SYSTEM" BinaryName="CMD.EXE">

          <BinaryVersionRange LowSection="*" HighSection="*" />

        FilePublisherCondition>

                Exceptions>

        FilePathRule>

     RuleCollection>

In Part 1, of our blog series outlining the details of Azure security defaults, we left off on the topic of MFA registration, which utilizes the Microsoft Authenticator app.  While all users MUST register for MFA, MFA is not required for all users every time.  Security defaults does enforce MFA for privileged accounts every time they log on as these accounts have increased access to your environment.  Security defaults requires added authentication for the following nine Azure administrator roles.

• Global administrator
• SharePoint administrator
• Exchange administrator
• Conditional Access administrator
• Security administrator
• Helpdesk administrator or password administrator
• Billing administrator
• User administrator
• Authentication administrator

MFA should be standard policy for all Azure admin account as account takeover attacks are one of the leading types of threats today.  Cybercriminals specifically target privileged accounts so special attention is needed.

Protecting all users

Security defaults is about improving the protection for all users, not just admin accounts.  While MFA is not required of every logon attempt, non-admin users are prompted for additional authentication when connecting from a new device or app.  There may be other instances that trigger MFA for standard users as well.

Limitations of MFA using security defaults

As mentioned, security defaults gives you free access to Azure AD MFA.  Free however, has its limitations.  Some of these shortcomings are listed below.

• Admins have no control over verification methods
• SMS and phone calls are not available as second factors
• You cannot configure trusted IPs for MFA exclusion
• An exclusion account for emergency access
• No MFA reports or fraud alerts

Again, keep in mind that Azure security defaults gives you the bare security minimum.  To obtain more features and control over MFA, you will need to ante up some additional money.  If you have a license for Conditional Access but have not yet enabled it, you can use security defaults as a temporary security band-aid until you are ready to enable Conditional Access policies.

Blocking legacy authentication

The majority of compromising sign-in attempts come from legacy authentication.  These credential stuffing or account takeover attacks tend to be automated and performed by bot nets.  Legacy authentication utilizes protocols that only use basic authentication.  These outdated protocols only require single factor authentication and cannot enforce a second factor as part of the natural authentication flow.  This is in contrast to modern authentication, which does support second factor authentication.  Using legacy authentication, an imposter can simply bypass your active MFA policy.

Client applications or services that use legacy authentication also have a blaring vulnerability in that credentials are collected and then stored until validated against an authority.   Apps or services that utilize modern authentication never store credentials.  Instead, they only present them.  In other words, modern authentication never trusts the app or service that is requesting your credentials. 

For these reasons, it is highly recommended that legacy authentication protocols such as IMAP, SMTP and POP3 be blocked.  This means that clients cannot use an older version of Office 2010 but can use a more current version such as Office 2016.  Some email/faxing software and other types of applications require the use of these older protocols.  Make sure that none of your applications are using legacy authentication protocols before enabling security defaults.   

Protecting privileged actions

We mentioned how security defaults uses MFA to protect privileged user accounts.  It also protects privileged actions as well.  This is important because non-admin users can be delegated to Azure Resources.  Azure services can be managed through the Azure Resource Manager API.  These services include:

• Azure portal
• Azure PowerShell
• Azure CLI

These services give users tenant wide powers such as the ability to modify configurations, service settings and billing subscriptions.  This is why it is imperative to verify the identity of users that utilize them.  When enabled, security defaults will require added authentication before allowing delegated access. 

Conclusion

Azure AD security defaults certainly has its shortcomings and should not be considered a long-term solution for any sizable organization.  It also does not provide the rich security protections that many organizations need to satisfy security policies or compliances.  It does provide a “one-click” easy button that new tenants can use to protect themselves right out of the gate while they begin to learn their solution options.  While it may provide ample protection for small organizations, tenant owners should view it as a transitory measure only.  Security defaults is a great first step and one that hopefully, will better secure the entire O365 community as well. 

The old adage, “You can lead a horse to water but you can’t make them drink,” certainly applies to cybersecurity today.   You can provide users and organizations with all types of cybersecurity tools and policies, but as long as they are optional, you cannot make them utilize them.  A case in point is the enforcement of multifactor authentication (MFA) for Azure.  Despite the fact that Microsoft attests that MFA will prevent 99.9 percent of account compromises, only around 8 percent of administrative accounts in Azure AD use it.  In a world in which credential stuffing attacks initiate billions of malicious login attempts on a monthly basis, MFA should be an enforced policy for every organization.  The hard truth is that we live in a digital world in which security is no longer optional. 

Depreciation of Baseline Security Policies

Microsoft has already been providing a set of predefined policies to help organizations protect themselves against common attacks.  There were four baseline policies.

• Require MFA for admins (preview)
• End user protection (preview)
• Block legacy authentication (preview)
• Require MFA for service management (preview

Azure admins could enable or disable them for their Azure userbase.  Unfortunately, too many organizations have not taken advantage of these policies or the rich set of security capabilities such as Conditional Access.  This not only makes them more vulnerable, but adds to the collective threat environment for everyone else as well.  Every computer that is compromised serves as one more potential attack vehicle that perpetrators can use for malicious deeds towards others.  The IT industry is starting to recognize that organizations not only have a responsibility to protect their own users, but share in the universal collective effort to make the world a less vulnerable place.  By hardening up our own attack surfaces, we harden the world as well.  As a result, Microsoft is depreciating these predefined policies on February 29, 2020, replacing them with the new “Security Defaults.”

What are Azure Security Defaults?

The intention of Security Defaults is simple; provide an enforced default security state for all Azure organizations that do not implement security policy initiatives on their own.  Security Defaults are available to all tenants and like Baseline Security policies, are offered at no additional cost.  New tenants will automatically have security defaults enabled by default.  If your tenant was created on or after October 22, 2019, chances are that security defaults is already enabled.  In the coming phase, Microsoft will begin retroactively enabling it for existing domains who have failed to enact any security measures on their own.  These security defaults enforce the following:

• Unified Multi-Factor Authentication registration
• Multi-Factor Authentication enforcement
• Blocking legacy authentication
• Protecting privileged actions

If you are an existing tenant prior to the October date and currently and currently do not utilize security policies of any kind, you will need to enable Security Defaults for now.  You can do this by going to Azure Active Directory > Properties > “Manage Security defaults” and set the Enable security defaults toggle to Yes as is shown below.

If you currently utilize Conditional Access, Classic or Identity Protection policies that consist of settings that may conflict with any of the security default offerings, you will receive an error message when trying to enable default security policies as is shown below.

Note that you will have to disable Security defaults before creating conditional access or other security policies that involve conflicting settings.  Keep in mind too that Security defaults is a bare minimum.  While they may be appropriate for small organizations, medium or large enterprises should expand into policies that are more comprehensive. 

MFA Registration

Let’s start with multifactor authentication.  Security defaults require all users within the tenant to register for MFA.  MFA requires a user to use a second method of authentication to prove their identity in addition to their logon credentials.  The most popular method currently is SMS MFA in which the user must type in a unique one-time code sent to their cell phone after logging on with their assigned credentials.  While this and other methods are available in Azure Conditional Access policies, it is not an available option under Security defaults.  Azure Security defaults only utilizes the Microsoft Authenticator app

Once you enable Security defaults, users are required to register for MFA within 14 days.  The 14-day clock starts from the time the user logs on for the first time once the security defaults are enabled.  Should a user fail to register within this required time frame, the user will not be able to logon until the FMA registration is completed.  The screenshot below shows what users will see during the 14-day registration period.

In addition to completing the MFA registration process, users must also install the Microsoft Authenticator app on their cell phone.  We will cover Multi-Factor Authentication enforcement in Part 2 of this blog series. 

MSIX … What it means for you… and managing those Applications

Do not be alarmed if you see a file with an .msix extension to it.  MSIX is the latest application installer for Windows applications.  Now that you know what it is, the next question is probably, why does the world need another application installer?

Good question.  After all, we already have three installer formats.

The current set of Installer Choices

The former trilogy of application installers include EXE, MSI and AppX packages.  EXE installers are the most recognized and best suited for manual installs.  They incorporate GUI driven wizards that guide users through the installation process.  This allows for customized options such as multiple languages, add-ons and selected file paths.  EXE installers can also detect previous installations.  Because they are so accommodative to customization, they are also complex.   This makes unattended installs challenging.  EXE files also make admins very nervous in a malware world. 

MSI installers are simple, which is why they are best-suited silent unattended installations.  They too use graphical interfaces but do not offer extras or customized options, nor can MSI installers detect prior installations.  Finally, there are AppX installers.  These are used for Universal Windows apps and have similar characteristics to MSI installers in that they are simple and straightforward.  One thing that sets them apart from the other two is that they rely on container technology.  This isolates them from the rest of the operating system.  This makes them much more secure.  Unfortunately, AppX packages can only be used for Windows 10 so legacy machines cannot utilize them.

The new alternative called MSIX

MSIX is the new kid in town.  It is not very popular as of yet as it was just released in 2018.  It is the alternative to the current three and Microsoft intends that the MSIX packaging solution to be the centerpiece of its deployment toolset eventually.  Like many great ideas from Microsoft, new tools and ways of doing things take time for organizations to digest them.  The MSIX installer platform does not have a great market presence as of yet.   That does not take away from its many benefits however.  MSIX has definite improvements over its predecessors as it combines the best features of MSI and APX into a single format.  Basically, it installs like an MSI file, but behind the scenes, installs like an AppX.  You can create MSIX packages with either an interactive user interface or command line sequence.  Let’s look at the advantages associated with this new installer format.

Advantages of the MSIX Installer

One thing common to traditional applications is that tend to leave a footprint.  This footprint consist of AppData files and registry entries that never seem to get deleted after the application is uninstalled.  This clutter then lives on for the lifetime of the hosted machine.  MSIX has alleviated this.  Like AppX, MSIX is based on a containerized model.  This simplifies both the install and uninstall processes.  Uninstalling an MSIX package will remove any files and registry entries created by the app within the AppData folder, reducing machined clutter.

Unlike AppX installers, MSIX installers work on more than just Windows 10 machines and they support 32-bit applications.  Microsoft has released an SDK, which provides all API’s necessary to unpack an app package on multiple platforms.  Its cross-platform compatibility includes iOS, MacOS, Android, Linux and Windows 7.  In addition, the process of converting older applications to the MSIX format is far easier than to AppX.  You can also convert AppX applications to MSIX as well.  MSIX package bundling allows a single package to contain multiple language or device specific items, except unlike EXE installs, they options can be automatically selected by Windows. 

MSIX can also hand over the updating process to the operating system.  This streamlines the updating process by making it more secure and reliable.

Security is at the epicenter of MSIX.  MSIX applications are tamper proof because they must be digitally signed regardless of how the packages are installed.  For software vendors creating MSIX packages to publish in the Microsoft Store, Microsoft will sign the package once the approval process has been is complete.  Organizations intending to publish MSIX for direct download or internal network distribution must sign it with a valid code-signing certificate purchased from a certificate authority.

The MSIX Packaging Tool

You can download the MSIX packaging tool from the Microsoft Store.  The package tool requires Windows 1809 and later.  Microsoft recommends that you create a clean VM for the conversion host.  Keep in mind that the MSIX Packaging Tool will assume the processor architecture of the Windows 10 OS version in which the conversion process is taking place. You must convert your installers in the same environment where you expect to deploy them.  Once installed, simply open the tool to begin the packaging wizard.  You will be first be asked to choose the selected task.  In this example, we are creating a new application package.

You will then choose the desired packaging method.

The packaging tool will perform an assessment of the machine that will handle the conversion process.

You will then set out to create the package.  You need to select the installer you want to package.  Then you must select a signing preference.  Your choices are as follows:

In the example below, we have selected an MSI installer with no arguments.  We are signing using a certificate from a certificate authority with the assigned password.

Next, fill out required packaging information.

Click “Next” and the installation process will begin. During this process, the packager will capture the registry or any files needed to install or configure the app.

At this point, the conversion process will listen for any executables that are triggered at the initial launch of the application.  This is why it is essential use a quiet machine for the conversion process.  Captured executables will be displayed on the screen.  It is here that you will manage any first launch tasks.  You should launch the application at least one time in order to capture any first launch tasks. 

Upon clicking “Next” you will asked to confirm that you wish to culminate the listening process.

Now choose a destination folder for the final package and click Create.

That completes the MSIX packaging process.  Be prepared to see MSIX packages a lot more down the road.  

It is a wonderful thing when new initiatives benefit both the company behind the implementation and the customers they serve.  Such is the case with the announcement at Ignite 2019 that ConfigMgr and Intune are melding together to become one.  Together, the idea is that they will form a single management conglomerate tool called Microsoft Endpoint Manager. 

The MEM console will show a single view of all devices managed by either product through a single interface.  Here's an example.

So the idea is that you can now manage ConfigMgr devices through the MEM interface.  Of course, you can still manage through one or the other if you wish and there are some features that cannot be replicated amongst the two.  Separately, the two tools will be known as:

• Microsoft Endpoint Manager Microsoft Intune (MEMMI)
• Microsoft Endpoint Manager Configuration Manager (MEMCM)

The merging of these two management systems now forms a new modern device management system that is exactly what internal IT needs to manage the modern workplace of today.  Modern management for the modern workspace.  That was a common theme at Ignite.

Branding and Licensing Simplification

Some may say that the merging is a recognition by Microsoft that vast majority of companies continue to stick to ConfigMgr and Group Policy to manage enterprise desktop devices.  While Intune is capable of managing your entire Windows 10 environment, many companies continue to limit its management scope to mobile devices. 

For Microsoft, bringing the two management systems together under one roof allows them to simplify their branding under one incorporated name.  By integrating ConfigMgr into the Intune Portal itself, Microsoft is undoubtedly hoping that enterprises can better amalgamate themselves with the capabilities and functionality of MEMMI. 

Users will enjoy the simplification of both licensing and experience.  Those enterprises that currently have ConfigMgr licenses will automatically have Intune licenses too, allowing them to co-manage their desktop devices with both tools.  From a product perspective, admins will be able to view their mobile devices and ConfigMgr controlled PC’s from a single interface.  No more having to bounce repeatedly back and forth between interfaces throughout the course of the day.  Says Brad Anderson, Corporate Vice President at Microsoft, “It’s all about simplifying — and we’re taking that simplifying deep and broad from a branding, licensing and product perspective,”

By implementing the new co-existing licensing model, Microsoft is encouraging those companies that need to need leave existing systems in place to provision new machines as cloud-managed devices.  Regardless of how the device managed however, MEM provides a single view of all devices managed by either product.

Examining the Licensing Structure

So when you think of the new licensing model, think of the management scope of ConfigMgr.  ConfigMgr specializes in PC desktop management, so your PC devices are now automatically licensed for Intune as well so you can go ahead and enable co-management if you want. Note: Phones and non-Microsoft devices are still the exclusive domain of Intune (MEMMI) so those devices are not applicable to receive dual licensing.   Note you will still need Azure Active Directory P1 licensing for your users.  Mobile devices, iOS and Linux machines will remain exclusively licensed under MEMMI.

Intelligence Driven

Modern management systems must be intelligence based in order to maximize the user experience.  There are currently 190 million devices managed by either ConfigMgr or Intune.  The convergence of ConfigMgr and Intune greatly scales the potential use of telemetry power that Internal IT can utilize in its PC deployments and problem solving.  MEM will be introducing an array of intelligent actions that will give admins granular analysis as well as new comparative insights to their environments versus others. 

One example of this is Productivity Score.  Productivity Score will allow organizations to evaluate their employee and technology experiences into measurable metrics that Internal IT can use to justify the value that it brings to the organization.  From the perspective of the user experience, it will quantify how people are collaborating on content, developing a meeting culture and communicating with one another.  Real measured results concerning these types of user experiences can offer insights into how to enhance the user experience and increase productivity.    The technology experience will provide insights into assessing policies, device settings, device boot times, application performance and adherence to security compliances

MEM is an Endpoint

Many of us predicted this would happen one day.  As companies strive towards digitally transforming their organizations from the ground up, it was only a matter of time until something was done to streamline the management of on-premise and mobile desktops in scale.   One point that Anderson emphasized his Intune presentation MEM is that the merging of these two management system giants is not a temporary arrangement.  Says Anderson,

"Let me be very clear -- this vision includes both ConfigMgr and Intune.  Co-management isn't a bridge; it's a destination."

MEM allows you to start utilizing cloud intelligence without making a single change to your ConfigMgr policies.  Working collaboratively together, yet visible and accessible through a single interface, MEM provides the modern management system that Windows enterprises need. End-to-end management and automation is now available in a converged license package.  Look for the MEM transformation to emerge within your Intune environment. 

I have a few Azure + Intune tenants for testing. So I decided to take a laptop and move it from one tenant to another.

As you’ll recall from my book in Chapter 8, every device has a serial number and hardware ID. You manufacture this into a CSV file from a Powershell script. When I uploaded the CSV into my other tenant, I got this.

Okay. No problem. I’ll just… go to the original tenant where I know this device lives and find it and be on my merry way.

No. No. And no.

Let’s talk about what you should do, then I’ll explain what I had to do.

What you should do

The first thing to do is to look at the serial number in the CSV file from the machine you want to transfer over. In my case, the serial number was PC012345 (or something like that.) You can see that here.

What you’re supposed to do next is merely go to Intune | Device enrollment | Windows enrollment and see the list of Autopilot devices. There, you can search for the serial number.

Remember: My serial number was PC012345. But if you look below, there is no computer with that serial number. There’s PBW-something-something. But no PC0-something-something.

Note also that there is no other search possible; it’s serial number or nothing.

Ohhhkay. So maybe this is at least hanging out in Azure AD. Let’s check. Nope. No luck.

But I knew it was, in fact using Autopilot to get connected to my Fabrikam1000.com tenant. How do I know? Because I set up branding (also explained in Chapter 8 of my MDM book)! This is critical, so you know you’re not going crazy. Branding really helps you identify that your machine really is under your Autopilot control.

Then now in Azure AD, you can see the computer show up here.

But the darn computer still wasn’t in Windows Autopilot devices.

I was stumped.

I got some help from some fellow MVPs, the final “winner” being Sandy Zang, another Enterprise Mobility MVP.

Sandy suggested I click on every computer I have in Autopilot to see if something popped out. Because I didn’t have too, too many… I did just that, and found this.

Holy crap. What’s happening here?

What I needed to do...

Well somehow in Autopilot’s brain, my computer’s hardware ID is swapped with some other computer. I don’t claim to know how or why this happened. But at least I had a clue now!

So, okay.. Next would be to nuke that machine.. Which I attempted to, and this happened.

Then I remembered there’s another whole portal to check for Autopilot. In the Microsoft Store for Business. Those two records PBXXXX (not my computer) were indeed there. And, clicking on them and pressing delete made them vaporize !

I then went back to Intune and Autopilot and clicked Sync then Refresh.. and Bingo !! Phantom machines obliterated !

Kudos to Sandy for the thought. I wouldn’t have gotten there without the idea.

So Ignite 2019 is behind me (and us).  And I wanted to give you some of my insights into what I took away (and how I participated.)

First, Microsoft is such a huge company that this year, with all the new stuff coming out (or changes to existing products) Microsoft put out a “book of news” which is a giant PDF of all the what’s new. It’s only 85 pages. Ow ow ow ow ow.

https://news.microsoft.com/wp-content/uploads/prod/sites/563/2019/11/Ignite-2019-Book-of-News-2.pdf

That being said, I’m going to cut to the chase for what I specialize in and think most about: Windows desktop management with Group Policy and MDM.

It starts off with this announcement: Microsoft SCCM and Microsoft Intune are now under a unified product umbrella called “MEM”: Microsoft Endpoint Manager. With this, naturally, there are going to be some questions:

• What does this mean for you?
• What does this mean for on-prem (SCCM and Group Policy) worlds?
• And what does this mean for existing SCCM and existing Intune customers?

Let me try to answer that in this blog. To do that, I want to quote Microsoft leadership (VP Brad Anderson) in his kickoff address:

"Modern management does not mean cloud-only.  It does not mean a migration away from ConfigMgr, or a migration to Intune.  Modern management puts the cloud intelligence that comes from organizations like Microsoft to work to automate  tasks,  prioritize your efforts, connect the IT and Security teams, and continually improve the user experience.  We do believe the destination many organizations will arrive at over time will be a cloud-only management solution with Intune and Microsoft 365 at the center, but we want to enable you to take advantage of our cloud capabilities incrementally at your own pace – without replacing infrastructure as some of you may not be ready for a full cloud migration.  This enables you to  get cloud value along with your on-prem deployments, on the road to full cloud/modern transformation."

Let’s break this down (my words interpreting Brad; this is not Brad himself):

• “Hey Microsoft Customer”: what you’re doing now is okay. (SCCM & Group Policy still has a place, works as expected and continues to work for desktops, onprem servers, VDI etc.)
• “Hey Microsoft Customer”: Cloud is great. If you’re ready for it, great. When you start to use it you’ll get added cloud benefits.
• “Hey Microsoft Customer”: You don’t have to DUMP AND JUMP what you’ve built to cloudland. We think you’ll get there eventually.
• "Hey Microsoft Customer": The tools you use today, like Group Policy and SCCM, aren’t going away.  In fact, they can't go away.

This is ALL good news. For all scenarios and customers: What you’re doing isn’t going away, but there’s options for you if you want to take advantage of the cloud. Indeed, the newest philosophy and guidance (which I took away from multiple sessions) appears to be:

• Keep your PCs / servers / Citrix/ VDI / everything in Group Policy / SCCM land for now.
• Cloud attach / Hybrid Azure AD join to gain some cloud attached features, increased security, reporting, and insights.
• From a policy (and workload) management perspective: pick one. Group Policy or MDM or SCCM for the particular job.

On stage, at least two Microsoft-led sessions referenced my new MDM book (whoa! Thanks Microsoft friends!) and expressed (my sentiment) that trying to untangle a machine with both Group Policy **AND** MDM settings on the same box is a difficult problem. And one that should be avoided.

In Ghostbuster’s parlance:

“Don’t cross the streams…it would be bad. Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.”

(Full scene here: https://www.youtube.com/watch?v=wyKQe_i9yyo )

Maybe not that bad, but.. in that ballpark.

So what does this mean for you? The “take away” advice I felt I got was: once you’re settled and have the cloud / Azure/ MDM  (Intune or other) reasonably handled, then NEW deployments of Windows 10 can be cloud only … from a management and policy perspective.

So how can Group Policy, Azure, MDM and SCCM be used at the same time… but take on different (non-conflicting) roles? Here’s an example:

• Roll out a machine using Azure and Autopilot and perform a hybrid Azure AD join.
• Machine gets on-prem Group Policy setting for Windows-y and security things.
• Machine gets software deployment settings from MDM.
• Machine gets patching and updates from SCCM.

Again: That’s just one way to slice it. There are surely others.

So… the message to customers from Microsoft would now be (again, my interpretation; not one person directly.):

1. Get ready for, understand, and use the cloud when you can.
2. Attach your on-prem universe to the cloud for cloud-attached benefits.
3. Yes, we realize utilizing the cloud could actually be a long, long time before you get there and are comfortable. Perhaps many years.
4. Once you’re there in cloudland, we recommend new PC deployments can be in the cloud.
5. Even then, we realize Group Policy will always be used for some circumstances, and we’re cool with that. (So, once again, Group Policy isn’t somehow ‘going away.’). Indeed, even today Windows Virtual Desktop requires on-prem Active Directory and Group Policy even though the WVD machines are in Azure / the cloud. (You can see my walkthrough and gettings started with WVD here if you want to give it a try!)

That being said, Microsoft is trying to make it easier for you to take your existing Group Policy settings and see if it’s possible to use them in MDM-land if you choose to do it. Already, they have the MMAT tool which can analyze your existing Group Policy Objects (or an endpoint) and give you a report on what will, and what won’t transition to MDM-land. .. and I talk about it in my MDM book, chapter 5. Get your signed copy now.?)

What was announced this week with regards to Group Policy and Intune are two items:

1. Microsoft is going to ship a “CSE TOOL” which customers can add-into Windows 10, when a machine is born, or after the fact. This CSE Tool will then be able accept some directives from your MDM service (like Intune or others) and poke at SOME Microsoft Group Policy  CSEs to instantiate some Group Policy functions. The first items that Microsoft is tackling are:

1. Drive maps.
2. NON “Microsoft policies keys” in Registry (think unusual ADM / ADMX files).
3. Auditing.

These items are interesting if the idea is to stop using Group Policy for these items and then use MDM instead. (Again, don’t cross the streams.) What is interesting though is that (again) the MDM provider will have to call this CSE tool, which then actually performs the work in the Group Policy CSE. Which, once again, friends … means that Group Policy cannot die. This essentially guarantees it.

2. Microsoft also demonstrated a future feature in Intune, which is SIMILAR in practice to MMAT I mentioned above. The gist is that you can show Intune a GPO backup which Intune can now analyze. Then if the settings in the GPO exist, an Intune profile will be made (with    the equivalent settings in Intune land.)

That being said, as was repeated several times across multiple sessions: If you’re going to attempt a transition from Group Policy to MDM, don’t “lift and shift” over your settings without making proper decisions to keep or kill a setting.

Then, additionally, if you’ve now lifted and shifted Group Policy to MDM… here we go again… don’t cross the streams.

With any tool which makes things easier, use it wisely with a heap of planning to know what your destination should look like. Don’t just use the tool (any tool) because it’s there.

My little inner fear here is that many companies won’t heed this advice, and very quickly be in the same place like “I’ve got too many MDM profiles where I don’t know what they’re doing !!” as they already do in the “I’ve got too many GPOs where I don’t know what they’re doing!!” place they are right now.

So in summary, here’s what I learned at Ignite 2019:

• Intune and SCCM are now under one umbrella: Microsoft Endpoint Manager. Indeed, if you’re an existing SCCM customer, you now automatically get Windows Intune licenses for managing Windows devices via Intune. Note that this doesn’t mean you magically get, say, iOS or Mac or other non-Windows PC licenses. Also note this requires an Azure Active Directory P1 (at least) subscription  for your organization.
• It’s okay to be on-prem, and it’s okay to be cloud. Cloud is a destination, but destinations take a long time to manifest.
• Microsoft is increasing their tooling for Group Policy understanding and to take on some better Group Policy to MDM migration scenarios for those who feel they are ready to go there.
• (once again) Group Policy isn’t dead.

So, take a deep breath. You’re doing fine. If you’ve got no toes in, or one toe in, or nine toes into the cloud… you’re doing fine. And, yes, I realize, you cannot put toes into cloud, but just  go with me here.

I hope this blog entry helps you out and you’ll share it with your friends, your boss, and anyone else who wants to learn what’s new in management this year from Ignite 2019.

PS: Here’s some pictures of me at Ignite:

• First in the Microsoft Endpoint manager booth (https://twitter.com/jeremymoskowitz/status/1192204319745024005
• Second at the bookstore with my Group Policy and MDM books https://twitter.com/jeremymoskowitz/status/1191776777452032002
• Third, petting a therapy animal who is there for some down time with the geeks https://twitter.com/jeremymoskowitz/status/1191782442354532353

Ignite 2019 was really bananas, and it was awesome seeing many of you in person !

Windows Update for Business is the method where you can use Group Policy, SCCM or Intune to describe "rings" for your business. In these rings, you express "who is going to go first" to get updates.

Then, who will go next, and so on.

I explain these rings in details in my new MDM book.

But I wanted to share two Microsoft blog entries on this important topic, since it comes up from time to time. These are good extra sources of information.

https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Deployment-rings-The-hidden-strategic-gem-of-Windows-as-a/bc-p/664595

-https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Tactical-considerations-for-creating-Windows-deployment-rings/ba-p/746979

Hope these help you out!