Get Smarter

Interesting Rando-News 

First, I know in my last email I said writing my book took "none" months. I meant nine. Nine months.
These newsletters don't have an editor, or even a good spellchecker. So they're a bit off the cuff.
My book has eyeballs and eyeballs of real pros looking at it. Even THEN there will be errors, but, hey.. they're nicely shellacked !

Next, here's a bunch of items I've been sitting on for a bit. 

Item 1: Windows 1903
---
I know you already know that Windows 1903 is out. Buuut.. it seems a little mysterious how to GET it and what's IN IT. Well, here's a blog which explains both. Be sure to click on "What's new for IT Pros in Windows 10, 1903" for all the best stuff.

https://blogs.windows.com/windowsexperience/2019/05/21/how-to-get-the-windows-10-may-2019-update/#Sot6SPqZhUjM7lSa.97 

Item 2: 1903 Baselines are out
---
So Baselines are preconfigured advice which can be delivered via Group Policy or an MDM service like  Intune. (And, YES, of course with ALL CAPS I cover this in my "Group Policy (with a side of MDM)" training class, AND also in Chapter 10 of my new MDM/Intune/Autopilot/Azure book !)

Those baselines are here:  https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-configuration-framework/windows-security-baselines

And, here's the official blog entry on it:
https://blogs.technet.microsoft.com/secguide/2019/05/23/security-baseline-final-for-windows-10-v1903-and-windows-server-v1903/

But, it's Item #3, that's related to Item #2 that's the big interesting thing.

Item #3: Microsoft no longer recommends password rotation for regular users. 
--
Yep, so inside the Baselines, Microsoft has taken a step back from requiring that users rotate their passwords. At first glance you might think "Wow, that really sounds like it LOWERS my security posture." But then, the real reason why this can be a good idea is found when you dig into Aaron Margosis' blog: "If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration?"

There you go. So, if you're already implementing password rotation.. I guess "keep doing it" if you haven’t implemented the other mentioned security functions; but STOP if you HAVE implemented these other security measures. I found a few other's takes on this advice:

https://www.forbes.com/sites/daveywinder/2019/04/27/microsoft-confirms-change-to-windows-10-passwords-that-nobody-saw-coming/#4c0a682d7bf2

https://www.scmagazine.com/home/security-news/privacy-compliance/some-cybersecurity-experts-argue-this-may-be-one-of-the-last-global-password-days/?utm_source=newsletter&utm_medium=email&utm_campaign=SCUS_Newswire_20190502&hmSubId=c_Ol5WdI-AA1&email_hash=1640a0a38d3b4b638fd2beadfc5e9dc7&mpweb=1325-7621-514959

Item #4: Windows 1903 and Blurred Backgrounds
---
What do you think of those Blurred Backgrounds in Windows 1903 at login time? Don't like them?
Computer | Admin Templates | System | Logon | Show Clear logon background and set it to ENABLED.

Ah.. but what if you don't have the Windows 1903 ADMX files? 

Item #5: No Windows 1903 ADMX files yet.
---
They're not available yet for download. So you can always take a Windows 10 1903 machine and use the ADMX and ADML items from there if you're in a hurry. But I advise to wait for the download. I’ll let you know when that occurs.

Item #6: Super cool Windows 10 thing to broadcast your screen "over there." 
---
This is one of those things I'm wondering if everyone on the planet knew, except maybe.. Me. 
Basically, you can "project your whole screen" to an app .. "over there" on another Windows 10 machine. I tested this and it's so freeking cool. Just. So. Cool. My. Head. Exploded.  
Tip: Both computers have to be on the same Wifi or Bluetooth network. 
https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/How-to-Use-an-Additional-Computer-as-a-Secondary-Display/ba-p/681152

And now.. time for the plugs... :-)

- My CLASS (next Group Policy+ MDM class Chicago Sep 16 - 18th [three days].. Sign up today at www.MDMandGPanswers.com/class ) 
- Nor did I plug my new MDM: Intune, Autopilot and Azure book which is coming out in July (www.MDMandGPanswers.com/book)

No time like the present. Sign up for class and/or get your book. :-)

Happy Friday everyone !

While we used to actively block devices from registering with Intune and SCCM or Group Policy at the same time, we more than welcome this duality of management capabilities today.  Outside of cloud-only enterprises, Microsoft not only allows, but encourages the practice of allowing settings management from multiple sources. Microsoft refers to this current practice as co-management. 

The advantage of Hybrid MDM was that it allowed you to manage SCCM exclusive and MDM exclusive devices from a single console.  Essentially it was a a product of convenience more than anything.  With co-management, the two work in cohesion.  Clients can now have the Configuration Manager client installed and be enrolled in Intune.  For those organizations that have a considerable investment in time and resources in SCCM, Co-management adds greater functionality to your SCCM structure by incorporating cloud functionality.

Co-management requires version 1710 or later and requires all involved Windows 10 devices to be Azure AD-joined or joined to on-premise AD and registered with Azure AD.  For new Windows 10 devices, you can simply join them to Azure AD, enroll them in Intune and install the Configuration Manager client for co-management ability.  When it comes to Windows 10 devices that already have the Configuration Manager client installed the path is more complex, but basically requires you to setup hybrid Azure AD and enrolling them into Intune. Whichever way you get there; the end result is that you get the best of both worlds. 

Co-management is about more than just increased functionality however.  It gives IT administrators the flexibility to choose which management solution works best for their organization, devices and workloads they have to manage.  This facility of choice is exemplified in the screenshot below that shows the workloads tab of the SCCM admin screen.  As you can see, with co-ecomanagement you can switch the authority from Configuration Manager to Intune for select workloads.  This puts the SCCM admin in charge of which tool will manage what policies by simply moving the slider to the selected choice.

Note the presence of the “Pilot Intune” option.  As MDM is relatively new to most admins, Pilot Intune gives you the ability to pilot things first in order to ensure everything operates as expected.  Once results are confirmed, you can throw the switch all the way.  Eventually, Microsoft hopes that all the siders will be moved to the right, with everything hosted and managed in the cloud.  Those who are intimidated by SCCM might say that’s not a bad thing. 

Surprises are great when you are engrossed in a captivating movie.  A good novel always has multiple twists that you don’t see coming.  For the most part though, the world prefers predictability, especially when it comes to managing corporate enterprises.  The whole purpose of deploying settings is to ensure conformity to your enterprise client devices.  Group Policy and MDM were made to deliver a level of certainty to the enterprise.  

So what happens when Group Policy Settings and MDM settings collide with one another?  Because Windows 10 can potentially be a member of an on-prem active directory domain and be MDM enrolled as well, that is a distinct possibility.  Starting with the 1709 release, Microsoft unveiled a GPO setting that allows hybrid joined devices to be automatically MDM enrolled.  So let’s say we have a hybrid environment of Windows 10 laptops and just for grins we disabled Cortana using an MDM policy setting and enabled it using a Group Policy Setting.  Which policy do you would win out?  

If you had to guess, you would probably say Group Policy since it is the elder of the two.  If you did, you would be sort of wrong.  You would also be sort of wrong if you said MDM. 

How can you be sort of wrong you ask? 

Because when MDM and GP settings conflict, we honestly have no idea which one is going to win out. 

In fact, that is the default, expected behavior.  Yes, the default behavior is uncertainty.  Just like the stock market doesn’t like uncertainty, neither do network admins.

So in order to add some stability to these conflicting scenarios, Microsoft introduced a Policy CSP called ControlPolicyConflict/MDMWinsOverGP.  It uses an integer based data type for which there are two supported values:

• 0 (default state of uncertainty)
• 1 - The MDM policy is used and the GP policy is blocked.

To enable this policy, we have to create a custom OMA-URI setting as shown in the screenshot below.

So if MDM and the same Group Policy setting are contending to assign the SAME value to the SAME setting .. then you can use MDMWinsOverGP to force the MDM to always regardless of what GP is trying to do.  

If you are managing a hybrid environment with MDM and GPO, it may in fact be good practice to enable this CSP for good measure just to ensure that certainty will always prevail.  In the IT world, certainty is a good thing.

Long, long ago, well, actually not so long ago, there were two worlds.  There was the on-prem world and the mobile world, and the two would never become one, until of course they did one day.  Up until Windows 10 version 1607, a device could either be on premise AD or Azure AD.  This made sense at the time.  Back then, MDM enrolled machines was pretty much restricted to mobile devices as administrators wanted the extensive management control that Group Policy or SCCM provided them for enterprise desktops. Mobile devices were better served in the cloud and outside of device resets and remote wipe capabilities, there wasn’t much you could do with MDM early on.

It wasn’t thought a good idea at the time to have settings delivered from multiple sources.  In order to prevent that from happening, devices were blocked from the ability to simultaneously register with SCCM and Intune at the same time.  In fact, the activation of the SCCM client on a Windows device automatically disabled any built-in MDM capabilities.  Devices were segregated to one or the other.

If your company’s IT staff had separated SCCM administrators and mobile device administrators, then everything was fine.  But if you had to manage both desktops and tablets, you had to switch back and forth between the Configuration Manager console and the MDM console.  So Microsoft set about to integrate Configuration Manager with Intune with what was called “hybrid configuration” so that both on-prem and mobile devices could be managed from the same console.  Co-management between the two was born.  Note that Intune was the only MDM supported in this scenario.  The merging of these two platforms is illustrated below.

But as in everything, things change.  Microsoft put more focus into MDM as time went on, and as a result, more setting capabilities and features were built into Intune.  Organizations also started recognizing the value of migrating more computers to the cloud than just mobile devices.  Microsoft also began figuring out that it was in their interest to encourage customers to move to the cloud.  Because of these and other factors, the usefulness of allowing devices to co-exist in both on-prem AD and Azure AD was realized.  Starting with 1607, computers could be a part of both at the same time.  Then came 1709 in which the SCCM client could now run on a device without its MDM capabilities being disabled.  This made it possible for a computer to receive setting input from both sources.  This signaled the end of Hybrid MDM.  In August of 2018, Hybrid MDM became a deprecated feature and Microsoft began blocking the registering of new Hybrid MDM customers in November of the same year.