With Jeremy Moskowitz
To consult about an on-site (Private) Group Policy class or the Group Policy Health Check, please call Laura Rubinstein at 215-391-0096 or email laura[[att]]policypak.com
To purchase seats in a LIVE or ONLINE training class, contact Laura Rubinstein at 215-391-0096 or email laura[[att]]policypak.com
Get serious, and perform “Best Practices” around Group Policy management. Take back control and get your IT life back!
|No Public Classes Scheduled|
Call if you have 3 or more people to help us get started! In the meantime, click here to checkout our Online Class
Welcome to Part 2 of this article series in which we take a look at the primary policy types that you can create and utilize in Microsoft Endpoint Microsoft (Intune). In Part 1 we looked at Configuration Profiles and how they are the rough equivalent of GPOs in a traditional AD on premise domain in which some things were hidden, others revealed. Here we will examine some of the other major components of MEM, all pertaining to security.
Also referred to Security Profiles, Security Baselines are sets of Windows settings that are preconfigured by Microsoft Security engineers. There are currently 3 Security Baselines as is shown below. They are
- Windows 10 Security Baseline
- Microsoft Defender ATP Baseline
- Microsoft Edge Baseline
The baselines by themselves don’t really do anything until you use one of them to create a security policy. To create a profile you simply click on the appropriate baseline and then create your desired policy. Baselines should be looked at as minimum security standards, although for most enterprises, they would work admirably. You can change any of the settings, but keep in mind that when you unconfigure a setting, you are making it less secure. In most cases, you should simply accept the settings as is and deploy the policies to their targeted users and devices. The screenshot below shows the preconfigured BitLocker settings within the Windows 10 Security Baseline.
Compliance Policies are used to determine whether a device is compliant with a pre-defined baseline. Compliance Policies vary on the platform of the device. Some examples of Windows 10 compliant baselines can include the following:
- BitLocker enabled
- Minimum OS version
- Password qualities
- Firewall enabled and configured
- Location of the device
You can then select a noncompliance action such as an email notification sent to the user informing them of their device’s noncompliance state. You can even lock or retire a device that has been noncompliant for a specified duration. An example of a Compliance Policy requiring a minimum Windows 10 OS version is shown below:
Conditional Access Policies
Conditional Access Policies work hand-in-hand with Compliance Policies. They prevent access to noncompliant devices. For instance, you can prevent devices connecting from anywhere outside of the U.S. for instance. You can also list other conditional access requirements such as the installation of approved applications or MFA as shown in the screenshot below. You should always test your Conditional Access Policies first as you could deny everyone access including yourself.
Although not a “policy” per se, Enrollment Restrictions play an important role in MEM security. By default, authorized users can enroll 2 devices into the MEM portal. If don’t want the default, you can create enrollment restrictions that will allow users to enroll anywhere from 1 to 15 devices. You can also assign Device Type Restrictions that will prevent users from enrolling either personal devices, or designated device version platforms as is shown in the screenshot below.
Creating a MEM Strategy
As you can see, there are a lot of moving parts in MEM. The key is to ensure that all of your policies and restrictive settings work in conjunction of one another in order to safeguard your organization as well as ensure that your users can perform their required digital workloads. While MEM alone falls short of the granular setting coverability of Group Policy, it can play an important role for new startups and established companies that have significant numbers of mobile and remote devices.
Microsoft Endpoint Manager (the Intune part), is a powerful device management and endpoint security system that is constantly evolving. What began as a portal to manage and secure mobile devices can now manage desktop computers, virtual machines and even servers. It can now deliver a broad spectrum of configuration and security settings as well as intelligent cloud actions. Because of this, it’s hard to keep abreast of all of the changes and informational resources are perpetually outdated.
Microsoft Endpoint offers multiple policy types. With so much confusion out there concerning which policies do what, I thought it might be a good time to take a snapshot of the state of Microsoft Endpoint as it is today. This two-part series will cover a quick review, (or for some an introduction), on the various parts of this rapidly expanding management ecosphere.
This has long been the bread and butter of Intune. Configuration policies are the equivalent of Group Policy Objects. A configuration profile is created to deploy managed settings to targeted devices or users. Like other MDM solutions, Microsoft Endpoint supports more than just Windows. When you go about creating a configuration profile, you can choose between multiple platforms including Android, iOS, iPadOS, macOS and Windows as is shown in the screenshot below.
For the sake of this article, we will focus on Windows 10. You then select which profile type you want to configure settings for. The list of profiles has greatly expanded over the years. Some of the profiles available at this time include:
- Device Restrictions (Think Group Policy restrictions)
- Edition upgrade and mode switch
- Endpoint Protection
Below is an example of the available Control Panel Settings than you can block within the Device Restrictions policy.
A wizard then guides you through the process of configuring your desired settings and deploying them to the applicable targets. While the number of available settings offered within Microsoft Endpoint has exponentially grown over the years, it still doesn’t come close to the more than 10,000 settings offered by the culmination of Group Policy and Group Policy Preferences combined. While its capabilities and offerings may fall short for on-prem AD enterprises, it does provide ample coverage for many mobile and non domain-joined devices.
Administrative Templates is one of the available Configuration profiles but I want to focus on it separately. These are ADMX settings, some of the same ones you are accustomed to configuring in Group Policy Administrative Templates that includes both Computer and User side settings. Here you can configure settings for things such as Microsoft Edge, One Drive, Word, Excel, etc. In the screenshot below you will notice the same hierarchical structure you are familiar with in Group Policy Administrative Templates. Again, while the list of available ADMX settings has grown substantially, it still falls far short of what is currently available in native Group Policy. (Hint: Use PolicyPak MDM to take 100% of real on-prem GPO settings and use them with Intune.)
One more Configuration Profile type I want to focus on is Custom Profiles because a lot of people find them confusing. Windows 10 devices contain Configuration Service Provider (CSP) settings and it is these settings that MDM solutions actually manage. MDM has the ability to manage any CSP setting, but not all of these settings are currently built into the Microsoft Endpoint interface. That is where custom profiles come into play. If you want to deliver settings to an available CSP that isn’t accessible within the Microsoft Endpoint, you can create a custom profile which does require some input the following settings:
- Name: The name is for your own reference to help you identify it. Use any name you wish.
- Description: Enter a short summary of what the profile does and any other pertinent details
- OMA-URI: The OMA-URI settings are unique for each platform be it Android, iOS, Windows, etc. It is also case sensitive so be careful to type in the setting path correctly. To configure settings for a Windows 10 device you would type the path: Vendor/MSFT/Policy/Config/AreaName/PolicyName
- Data type: The data type will vary based on the OMA-URI setting. The options are String, String (XML file), Date and time, Integer, Floating point, Boolean and Base 64 (file)
- Value: Here is where you associate the OMA-URI value you wish to enforce.
Below is what the Custom Profile creation process looks like in Microsoft Endpoint.
So that sums up our look at Configuration Profiles.
In case you want a more in-depth view of these, I suggest you check out my MDM book.... www.MDMandGPanswers.com/book where I give more details and examples.
In Part 2 of this series, we will look at the other policy types such as security and conditional access.
I came upon this cool little app the other day and wanted to share it. It is a Windows 10 privacy tool called Spydish. It’s a very small app that you can download from the developer’s GitHub site. It runs as an EXE file so there’s not installation necessary. The premise of the app is straightforward as it simply checks if privacy related policies are enabled on your Windows 10 machine. It also gives you the option to enable any of the included settings or return them to their default state. The application can only be run locally so you cannot use it to access privacy settings of remote machines. It doesn’t require Group Policy so you can run it on a Windows 10 Home version. While you wouldn’t use it to manage the privacy settings of your enterprise fleet of laptops, it’s a quick way to see which privacy settings are set on a designated Windows 10 system and modify them.
Once opened, Spydish lists a series of privacy related policies in a sidebar on the left. Settings are grouped in different categories such as Privacy, Cortana, Bloatware, App Permissions, etc. You can choose the entire allotment of Local Computer Policies, a selected group or groups or pick individual settings. Then click the Analyze button as is shown in the screenshot below. A readout appears almost instantly, showing the current settings for each policy.
As easy as it is to obtain the current state of your privacy settings, it is just as easy to apply or revert them. In the screenshot below I have selected the Microsoft Edge group of settings. As you can see, none of the settings are currently configured. Now simply click the “Apply selected” button as is shown below.
Spydish will then apply all of the settings as shown here.
Clicking “Revert selected will revert any settings back to their default state. While users can modify Windows 10 privacy settings manually, Spydish is a way to get the job done quick and effortless. Check it out.
It’s a Cloud, Cloud, Cloud, Cloud, Cloud, Cloud world. Except actually most of your stuff is still likely mostly on-prem, or acts that way. Take Windows 10 for instance. Windows 10 has events in the event logs, and maybe you already know about on-prem Event Forwarding.
But how do we take on-prem events from Windows 10 (or Windows Server) and get the up to the cloud for later analysis? If you have 24, 250, or 25,000 domain joined (or even NON-domain joined) machines, say with Windows Intune or PolicyPak Cloud… how can you do the equivalent of event forwarding to some central place?
That is the job of Azure Log Analytics. I’m going to call it “LA” for short.
LA had an original name, OMS which stood for Operations Management Suite, but as near as I can tell, that’s over. But its good to know LA’s original name, because you’ll see OMS pop up from time to time in the walkthrough, docs, and software. Additionally, it’s also good to know that what you’ll see here is build upon the original System Center Microsoft Operations Manager (SCOM); but I won’t be using that function.
The official documentation for LA can be found here; but I had a few stumbles. Some tips o’ the hat to Travis Roberts’ video and blog which also helped give me a leg up. The blog is here and the helpful video series on Azure Log Analytics (though a little old now because of the name and UI changes) can be found at: https://www.youtube.com/watch?v=6hgvjgPBNzE&list=PLnWpsLZNgHzVXXyN9a0jm9xNNDrikHf8I
My goal in researching this project was to give some PolicyPak MDM Customers a quick guide to research interesting events that PolicyPak automatically logs to its own event log. But in this guide, I’m also going to show you how to collect some standard and also some extra event logs.
To get started you need a Log Workspace. This is basically a security block between this collection of logs, and say another collection of logs. Each Log Workspace has a GUID based Workspace ID and two keys (Primary and Secondary.) You’ll use these to send, say, YOUR Windows 10 machines’ event logs to your workspace. And the other Azure admins … you know, those SQL server people or Exchange or whatever … they’ll send their event logs to their workspaces.
To get started use the big search thingie to find “Log Analytics workspaces” like what’s seen here.
Then, there’s a little Wizard (not shown) to help you get started. Basically it’s asking you for names and which Azure region you want to keep the data in. Then after it gets going you’ll see “Your deployment is underway” like what’s seen here.
Then you should be thrown into the Advanced settings like what’s seen here. If not, find the Workspace you just created and click Advanced in the left-side menu. It should get you to this place. Note then the “WORKSPACE ID” and “PRIMARY KEY” like what’s seen here. Hang on to those, you’ll need these in a bit. Then also download the Windows Agent 64-bit or 32-bit to get started for your example machines.
In this example, we’ll be installing the LA Agent by hand on a test machine. In real life you could use, say Windows Intune to deploy it with command line options to just chuck in your Workspace ID and Primary Keys and do the whole thing silently and automatically.
Once you have the download, get it over to your test machine. Machine can be real or virtual. Note that you shouldn’t do this (nor do you need to) for WVD virtual machines. Those have a magical connector to accept event logs to LA; and you shouldn’t need to use this method. (Docs: https://docs.microsoft.com/en-us/azure/virtual-desktop/diagnostics-log-analytics and a blog https://www.mdmandgpanswers.com/blogs/view-blog/windows-10-and-server-event-logs-to-azure-log-analytics-walkthru)
Then, Up, Up and away. Launch the agent.. which requires admin rights. (Or, pro tip: Use PolicyPak Scripts to install it automatically where the script is elevated. https://kb.policypak.com/kb/article/901-policypak-scripts-deploy-software-via-vpn-or-with-policypak-cloud/ )
You’ll need to select “Connect the agent to Azure Log Analytics (OMS)” like what’s seen here.
Then, it’s time to chuck in your Workspace ID and Workspace Key. And you’ll likely keep the default of Azure Cloud: Azure Commercial. Pull the pulldown if you have something unusual to select here.
Yes, you want to check for updates when MS Update kicks in….
And.. you’re basically done.
Now let’s make sure we’re talking in both directions. The Microsoft Monitoring Agent is found in Control Panel… which is a weird place, but, hey… that’s okay.
Then click the Azure Log Analytics (OMS) tab and … see you’re talking outbound.
Back in Azure, in the Advanced Settings page, the zero should be one !
Now it’s time to add in the actual event logs you want to capture. Note that the more you capture, the more you pay. Strictly speaking for the PolicyPak customer I made this blog entry for, he only needed to capture the PolicyPak log (which I do last.) But just for completeness and testing, I’ll capture some more too, since you might not have the PolicyPak Log. (And, why don’t you!? Come on over and check out PolicyPak for Pete’s sake. Really, your sake to be honest.)
So just type Application then +. Then System and + and bingo. Those are “well known” logs which LA knows about and pre-populates this list. But PolicyPak? Not as common.. (Yet !) Therefore you could take a guess that our event logs are named PolicyPak (they are…). But how would you know?
The trick is to find the log you want to capture in Windows, and go to its properties and get its Full Name like what’s seen here. Yeah, this one was easy.
But some are harder. I also wanted to capture the MDM event log which has a goofy and weird name. To get it, I went into an Event inside that log and captured its name microsoft-windows-devicemanagement-enterprise-diagnostics-provider/Operational and its brother microsoft-windows-devicemanagement-enterprise-diagnostics-provider/admin.
You can see that second log here…
Once I pasted in all the logs and added them, I clicked Save and got this !
Data.. data? Do we have data ? Click on Logs and close the sample queries. Let’s just see what have. All of it (which shouldn’t be much.)
In the top box, type
Then click Run. Bingo.. out should pop all the events that have been captured. You can change the Display Time to make sure that you’re getting the right events, right now.
It took a little while for the non-well-known logs to show up. But maybe it will work faster for you than for me. If you want to give it a shot and try your non-well-known logs, like this, give it a go.
Event | where Eventlog == "PolicyPak"
Then click Run again.
Pow! Here come your logs.
Then I can also dig into an event, and … hey look ! EastSalesUser1 ran Procmon, and PolicyPak did the elevation ! Amazeballs !
That’s it. Well, that’s basics anyway.
Remember this blog is a simple walkthrough / getting started. This isn’t “Magic Tricks with Windows Analytics.” But if I had this guide, I would have been up and running about 10x faster. So I hope this helps you out and shows how you can take on-prem or “Always on the go” Windows 10 machines and record their logs, then sort thru them for actionable items and trends.
After taking Jeremy’s Group Policy Class, my staff and I were able to reduce the number of help desk calls dramatically! Thank you Jeremy!
MCSE Systems Administrator, Royal Canin USA, Inc
If you want to learn everything about Group Policy, then you need to attend Jeremy’s training class, I came in as a novice and left an expert. Jeremy speaks to you, not above you.
Desktop Computing Specialist, Princeton University
Jeremy is absolutely the best presenter and instructor I have seen. I really would like to get the same type of instruction for other IT courses. He has a wonderful way of sharing his knowledge in a simple, effective way that leaves you thinking “Wow! That makes so much sense. ” After taking his “Group Policy Online University” courses and reading his books I feel like a pro — truly understanding Group Policy. And whenever I have a question, Jeremy is always there to help. I really liked the fact you can review the online course TWICE. It’s almost like getting TWO courses in one. Add in his weekly tips and simply you can’t go wrong. Thanks Jeremy — and your staff for creating a great learning experience that I benefit from every day.
Network Administrator, Mondial Assistance
I used the tools he demonstrated and those tools saved me a lot of time and money.
Senior Network Engineer, County of Orange, CA
After hearing Jeremy speak, I was immediately able to confidently use GPMC, and successfully deploy many GPO’s which have saved my sanity and added years to my life. Having a copy of Jeremy’s Group Policy, Profiles, and IntelliMirror book on hand has given me instant access to many of those “How does this work in the real world?” questions. Thanks Jeremy, You are awesome!
Lead Systems Administrator
After taking Jeremy’s class, I was able to create and troubleshoot Group Policy in our environment. Others tried to convince me that the “Microsoft Standard” is to have one huge policy, but troubleshooting that policy for them was a nightmare. After they saw how easy it was to create smaller, less complicated policies, troubleshooting became a piece of cake.
Server Administrator, University of Toledo
I was able to apply some of the Group Policy best practices that I had not already implemented. I am also looking forward to implementing the many new Vista/W2K8 GPOs.
Sr. Systems Administrator, Adventist Health Systems
I sincerely enjoyed the class in Boston and I learned a lot. Within two work days of coming back I had a major update to a core product piece of software that, because of your class, I knew to ask for an MSI file for the update and how to properly create a GPO to distribute to the appropriate users and make it do an install without interaction or granting them administrator rights. When they logged in this morning the update applied beautifully. This one process alone has made the whole class worth it to me. With the many other things I learned and will also put to use in the near future and I am extremely happy. Thanks again for coming to Boston.
Tech Support Specialist, Fidelity Bank
After listening to Jeremy, I felt much more confident in working with Group Policy and using it for many benefits in our Organization. The book was a great supplement, too.
Manager, IT Operations, Miller-Valentine Group
Jeremy has a way of explaining things that are down to earth. He takes a potentially dry subject and makes it more fun. These Group Policy courses are invaluable to help me in my job. As we transition to new machines and new operating systems, I can use the information and tools learned in class immediately. The pre-built virtual lab machines made it so I could focus on the labs right away. The hands-on labs are awesome! I am really glad I signed up for Jeremy’s online courses–even though I ended up taking them on my own after work. It was a really good investment.
ATK Launch Systems