Send Intune security task notifications to Microsoft Teams, email, etc. using Microsoft Flow

There’s a feature within Microsoft Defender Advanced Threat Protection (MDATP) and Microsoft Intune where MDATP security recommendations can be sent to Intune as a security task. This is helpful if security admins and MDM admins are separate and need to pass information for endpoint management teams to work on. Even if you work on a small team or are a one-person shop, sending security tasks to Intune provides a work item, so if you’re forgetful or get pulled in many directions, you’ll have a task sitting for you. For more details on this feature please visit: https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Microsoft-Intune-security-tasks-extend-Microsoft-Defender-ATP-s/ba-p/369857

The purpose of this post is to create a method to signal and/or alert that there is a new pending security task in Intune. Currently admins need to access the Intune console and check for tasks which is a manual process. I prefer automation and I created a Flow to post a message in a Teams channel and send an email about new, pending Intune tasks sent from WDATP. If you’re thinking, “I’m not a developer…” well the good news is, neither am I! I love Microsoft Flow because it makes creating workflows and automation easy (and I create a lot of Flows to automate tasks).

Let’s get started

Requirements

  • Microsoft Defender ATP
  • Microsoft Intune
  • Microsoft Flow
  • Microsoft Teams
  • A Windows 10 device enrolled with Intune and managed by Microsoft Defender ATP

Viewing a security recommendation and sending a task to remediate to Intune

Navigate to https://securitycenter.windows.com/tvm_dashboard (note if you don’t have a subscription or haven’t set up MDATP, you’ll need to do this first). Look at the Top security recommendation on the right and select one.

Here I see a list of security recommendations.

When “Update Chrome” is selected we can see the number of devices exposed and CVEs (Common Vulnerabilities and Exposures) the update will address.

Select “Remediation options”

Check the box next to “Open a ticket in Intune (for AAD joined devices)”, select a due date, and add notes if necessary.

When finished, select “Submit request”

Head over the devicemanagement.microsoft.com > Security baselines > Security tasks and there should be a pending task. In this case I have two that have a status = Pending.

Select a task and Assign or Reject it, however, don’t do this yet, because we want to get a notification of pending security task in Intune.

Notifications of new pending tasks

Now we know how to send a task from MDATP to Intune, however what would be better is to be informed a task is waiting for us to address, and to set up notifications I use Microsoft Flow.

Creating a new Flow

Navigate to https://flow.microsoft.com, select My flows from the left hand navigation and select New -> Instant-from blank. Give the Flow a name and select create.

Schedule the Flow to run

Search for the “Recurrence” trigger and add it to the beginning of the Flow. Populate the fields to meet your requirements. I set my schedule to kick off everyday at 8 AM mountain time.

Azure AD Authorization to call Graph

This process requires multiple steps so I’ll refer you to a couple sources that may be utilized to configure the authorization steps:

Query Graph

Search for and add the HTTP Flow action. Method = GET, URI = https://graph.microsoft.com/beta/deviceAppManagement/deviceAppManagementTasks

In the header I utilize the authorization info compiled in previous steps.

The next three Flow actions take the information from the graph call and parse it out based on the JSON schema

  1. Search for and add a Compose action and as the “Input” add the Body from the Http action above.
  2. Search for an add a Initialize variable action, Name = JSONObject, Type = Object, Value is the Value from the Compose 2 output in the previous action.
  1. Next we need to parse the JSON so we can select JSON fields to be added to an email and Teams posts. Search for an add a Parse JSON action, Content = JSONObject from the variable above the Parse action. The Schema is generated easily by going to Graph Explorer and querying Graph as shown below. Copy the JSON returned from the response preview pane and in the Parse JSON action, select “Use sample payload to generate schema” and past the JSON output and select done. This will construct your schema.
Use the JSON output from graph explorer (as shown below) to populate the sample payload to generate the schema.

Send to Teams and/or email

Here I walkthrough sending to Microsoft Teams; however, an email trigger is roughly the same process.

  1. Search for and add a “Apply to each” trigger, Select an output from previous steps = the value from the Parse JSON action above.
  2. I only want task with a status of “Pending” so I added a Condition trigger where search for a status equal to “pending”. The Status object comes from the JSON we parsed above.
    • If status of pending = yes, I send an email and post to Teams, if status is anything other than pending, the Flow terminates.
  3. Search for and add “Post a message” action. Search for the Team site, Channel, and then craft your message. More on this below.

The reason we need to add a schema and parse the JSON returned from the Graph call is so we can select the variables returned individually. Below is an example of the fields I selected for my messages sent to Teams.

Viewing Teams posts

The following is an example of an Intune Task sent to teams with the Flow constructed above. If there is more than one pending task, the Flow will post individual messages for each pending task (same goes for emails). As shown below, I happen to have two tasks that are pending, one to Update Chrome and the other to Update Windows 10, lucky me!

That’s it! If you’re utilizing Microsoft Defender ATP and Intune, integrate the two and start sending tasks to Intune today. Use Flow to schedule notifications and send to Microsoft Teams, email, or whatever method Microsoft Flow supports.

Additional References

Logic apps docs: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-perform-data-operations#join-action

Use data operations with Microsoft Flow: https://docs.microsoft.com/en-us/flow/data-operations

Follow me on Twitter @mscloudinfa

Entire Flow

Android Enterprise Dedicated device – matching a physical device to a device record in Intune

I work with organizations who have 100’s to 1000’s of managed devices in Intune.  When it comes to Android there may be various Android OEMs and OS versions organizations are managing and a variety of use cases for those devices.  With more organizations migrating to Android Enterprise they must choose an enrollment method based on the scenario.  With Android Enterprise there are several methods of enrollment, Dedicated, Work Only, and Personally-Enabled.  For more details on Android enrollment options please visit: https://www.android.com/enterprise/management/

For digital signage, kiosks, barcode scanners, etc. those devices are typically enrolled as a “Dedicated” device where a single or multiple apps are the only apps accessible by the end user. In addition, dedicated devices do not have user affinity, meaning the device isn’t linked in an MDM to a specific user unless there some sort of tagging associated which identifies the user or location of the device.

Because there’s no user affinity assiated with dedicated devices, I’m often asked, “what’s the best method to identify an Android device enrolled as a dedicated device (e.g. kiosk) in the Intune admin portal with a physical device in hand?”

There’s a simple method of doing this and it’s identifying the device by serial number. Here’s how to do it without removing the battery:

1.  With the device turned on tap on the arrow key on the bottom left about 15 times to launch the options (btw, the screen with the app(s) you’re accessing is called the Microsoft Managed Home Screen). Depending on the app configuration for the managed home screen you may see “Logs” and/or “Exit Kiosk”.

2.  Select “Logs” and slide up on the Logs banner to expand

3.  Find the “deviceInfo” and tap the + until it expands

4.  Locate “serialNumber” and match it to the device serial number under “All devices” in the Intune admin portal. If you don’t see the “Serial Number” column select “Columns” at the top of the page and add “Serial Number” to the list.

Here’s a video showing the process in action:

7068B017-43B0-4070-BA94-3F8AD24A918F

In summary whether your organization manages 10 or even 1000’s of devices, having a simple method of identifying a physical device will save a lot of time during the process of troubleshooting.

To learn more about Android device enrollment with Intune please visit: https://docs.microsoft.com/en-us/intune/android-enroll

Intune, Azure AD, and Zscaler Private Access

Securing the perimeter has become increasingly difficult with more and more services moving to the cloud and users needing, no, expecting, access from their personal devices. The days of relying on the walls of a network to “trust” access are fading fast, and some would say they’re long gone. This is why organizations are using Microsoft technologies to build out zero trust networks where they rely on device and user claims to evaluate access to resource both on and off network. As I’ve written about in the past, security comes in layers, and zero trust encompasses many layers of security behind the scenes.

Over the past few years, Microsoft has worked with many security and management vendors to integrate with Microsoft Intune and other solutions in EMS such as Azure Active Directory.

The following list is just an example of the many technology partnerships Microsoft has in place today.

To keep up to date with Microsoft security partners please visit: https://www.microsoft.com/en-us/enterprise-mobility-security/microsoft-intune?rtc=1

For this month’s post I’ll focus on Intune, Azure Active Directory, as well as a Microsoft security partner, Zscaler, particularly Zscaler Private Access and its integration with Azure AD and Intune.

What is Zscaler Private Access?

According to Christopher Hines, Head of Product Marketing at Zscaler:

“The Zscaler Private Access (ZPA) service provides users with seamless and secure access to private applications without placing them on the network and without exposing apps to the internet. Allowing enterprises to embrace a software-defined perimeter that supports all private apps and environments.”

More details about Zscaler may be found by visiting: : https://help.zscaler.com/zpa/getting-started/what-zscaler-private-access

Before we get started, I want to give special thanks to the following individuals I collaborated with for this post:

    • Tyler Castaldo – Microsoft Program Manager – Intune
    • David Creedy – Senior Product Manager – Web Security
    • Christopher Hines – Head of Product Marketing – ZPA and Zscaler App

Let’s get started

Zscaler SSO Setup

First, we need to set up Zscaler with Azure so we can provide SSO as users access the app. Once the user accesses the the Zscaler App on their device, they’ll be passed through to Azure AD for sign-on.

Setting up Zscaler Private Access (ZPA) requires a few steps so I won’t go through them, however the steps are well documented here: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/zscalerprivateaccess-tutorial

In addition, Zscaler has also created their own documentation that may be referenced as well:

Adding Zscaler App to Intune for deployment

For this post I focus on iOS and Android. However, Zscaler is also supported on macOS and Windows 10 (more details at the bottom of this post).

After SSO is set up with Zscaler and Azure AD, we now need to add the Zscaler App to Intune for deployment.

Navigate to portal.azure.com or devicemanagement.microsoft.com and select “Client apps -> Apps”

Select “Add” then App Type and from the dropdown select iOS. Search for Zscaler and select “Zscaler App” as shown below. Add the app and assign it to a group for deployment.

For Android, repeat the steps above, however for the “App type” select “Android“. Use Managed Google Play in the console to search for Zscaler, then add and assign the app to a group for deployment.

Note: if you haven’t set up Managed Google Play with Intune yet, you will find details steps on how to do so by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

When performing a search for “Zscaler” under apps in Intune you should see both assigned apps.

Configuring the Zscaler App using a VPN policy for iOS and app config for Android

Configuring Zscaler Private Access for iOS in Intune is straightforward as Intune has the settings available directly in the Intune adming portal UI as shown below.

Note: the “Organization’s cloud name” is case sensitive and FQDN and key/value pairs are optional, for more details please visit: https://docs.microsoft.com/en-us/intune/vpn-settings-ios#base-vpn-settings.

Select how the VPN will be launched:

Configure additional settings your organization requires to provide access to applications bridged by Zscaler:

For Android, we need to create an app configuration policy and assign it to the Zscaler App we added earlier.

https://docs.microsoft.com/en-us/intune/app-configuration-policies-use-android

Create an app configuration policy by navigating to “Client apps -> App configuration policies”

Select “Add”, provide the policy a name and from the “Device enrollment type” drop-down select “Android”.

Under “Associated app” select the Zscaler App added earlier.

Under “Configuration settings” select “Use configuration designer” from the drop-down and select all the options provided. Select ok to begin configuring the values.

Configure the values based on how your Zscaler environment is configured. In my case, my Zscaler environment is set up in Azure so I utilized the cloud name for the service in Azure as well as the domain my users log into. For username, I selected variable and chose “Partial UPN”.

Once all the settings are configured select “Ok” to complete the setup.

Note: you’ll notice the “deviceToken” value is set to “DummyValue”. This value isn’t needed when Azure AD is used as the identity provider (IdP), however it is needed in the profile, so just add it and type in whatever you like for the value. Also, please note the “Organization’s cloud name” is case sensitive.

After you’re finished with the app config policy, be sure to assign it to the same group you assigned the Zscaler App to.

Client experience

On first launch, the Zscaler App on iOS and/or Android it will redirect to sign-on using Azure AD, however subsequent launches of the Zscaler App will sign-in automatically.

Azure AD Conditional Access

To prevent access to an application Zscaler Private Access is securing access for, we need to create an Azure AD conditional access policy. The Azure AD Conditional Access policy will ensure the device and/or user meets compliance policies (e.g. Intune) before allowing access.

Navigate the Azure Active Directory in the Azure portal and select “Conditional Access”

Provide a name for the policy and under Cloud app add “Zscaler Private Access” and add the Zscaler cloud app used to access resources, i.e. the organization cloud name that points to the app we added earlier. The cloud app I utilize is called Zscaler ZSCloud as shown below.

Select the device platforms to target the Azure AD CA policy, since I’m focusing on iOS and Android in this post, I select iOS and Android from the devices platforms list.

Now grant access if the device is marked as compliant by Intune, enable the policy and save.

Note: additional conditions and access controls may be checked if needed.

If the device is compliant with Intune compliance policies, Zscaler will connect the user to the application. If the device isn’t compliant, Azure AD Conditional Access will block access to the application Zscaler provides access until the compliance issue is remediated.

Note: currently there is an issue with Conditional Access and Android Enterprise where the device is treated as not enrolled.  Zscaler is working through this and we’ll provide an update as soon as the issue is resolved.

Let’s see this in action

I’m testing with my Android device enrolled with Intune under Android Enterprise Device Owner as a fully managed device. The Zscaler Private Access (ZPA) App and ZPA App configuration is automatically deployed.

Intune_Zscaler.gif

Conclusion

In summary we learned how to set up Zscaler with Azure and provide SSO using Azure Active Directory. We also learned how to set up Zscaler Private Access App configuration and app deployment with Microsoft Intune. Finally, we learned how to set up an Azure Active Directory Conditional Access policy to further secure application access with Zscaler based on Intune device compliance.

I hope this post helps you and your organization further secure corporate applications, devices, users, and resources using Microsoft Intune, Azure Active Directory, and Zscaler Private Access. If you’re a Zscaler customer today, go out and give these steps a try.

Appendix

Information on setting up Zscaler for Windows and MacOS

Configuration Manager, Intune, and the Cloud – What’s your plan?

As I meet with organizations, I learn what their business goals are, what their end user goals are, and what their budgetary guidelines are. I also learn a lot about their endpoint management goals. What I’ve discovered is endpoint management has different meanings for each customer with a few common themes, user experience, simplification, and cost reduction.

The pace of change with technology is extremely rapid and organizations often struggle to keep up with all the updates across deployed technologies. When IT teams deploy technologies to help secure and simplify administration, they must provide evidence to the organization about the short- and long-term benefits of shifting to newer technologies, especially if they are duplicative of existing technologies. The evidence to rip and release a working solution is typically prioritized and is provided in the forms of cost reduction, end user benefits, and administrative simplification. Looking back in history, many would argue managing Windows in the enterprise has been a priority for most organizations. Many of these organizations today continue to manage Windows with a variety of technologies with one, (based on my interaction with hundreds of organizations) standing out the most, System Center Configuration Manager (ConfigMgr).

Configuration Manager has been around for a couple decades and for good reason, in my opinion it manages Windows best. For those familiar with ConfigMgr, you’re probably familiar with its history and the changes to the product over time. What I’ve seen is a blend of enhancing the client, infrastructure, and administrative experiences, including enhancements to reporting, management techniques, bandwidth controls, scale, performance, and more recently attaching Configuration Manager to the cloud. These advancements are critical to an ever-changing landscape of Windows computing and resource access.

Why write about this now?

There are a couple reasons:

  • Organizations are going through digital transformation and taking a hard look at existing endpoint management solutions.
  • Configuration Manager remains one of the most widely utilized endpoint management technologies across organizations today and I articulate the ongoing value of ConfigMgr in the content below.

Recently organizations have asked me the question if ConfigMgr is “dead” and my consistent answer is “no” is it not, ConfigMgr as of this post manages over 150 million endpoints, in fact there’s been continued investment in ConfigMgr year-over-year. Take a look at “What’s New in Configuration Manager” over the past several releases and you’ll see a growing list of exciting enhancements over each release.

You’ll also notice ConfigMgr has a release roughly every four months which provides a predicable release schedule for organizations needing to plan updates. Speaking of ConfigMgr updates, in console notifications of new releases provides an easy and informative method to update ConfigMgr to the next release by a click of a button. In addition, ConfigMgr technical previews allow organizations to test new features ahead of upgrading to the next service release of ConfigMgr. The servicing of ConfigMgr and technical previews are a win/win in my opinion.

I also receive questions such as “why stay with Configuration Manager, when I see Microsoft doubling down on efforts to enhance Intune toward feature parity?“. While partially true, there are clear advantages to continue utilizing ConfigMgr and leverage the cloud by cloud attaching ConfigMgr.

For example:

  • Preparing your infrastructure for cloud attach by extending ConfigMgr to Azure enables organizations to manage devices off the corporate network by utilizing Cloud Management Gateway .  By attaching ConfigMgr to the cloud, it allows organizations to simplify management of Windows devices and administrators will have the advantage of leveraging current processes built around endpoint management with ConfigMgr.
  • Organizations needing high availability in ConfigMgr can take advantage of site server high availability and SQL Always On.
  • Cloud attach Windows 10 clients to Intune by enabling co-management in ConfigMgr allows organizations to utilize ConfigMgr and Intune to manage Windows devices.  By enabling co-management, the organization benefits from the currently unparalleled strength of Configuration Manager as well as additional benefits cloud services such as Microsoft Intune and Azure Active Directory provide.
    For example, ConfigMgr client health will be reported directly to the device stats in Intune (shown below), remote actions may be initiated directly from the Intune admin console, as well as utilizing conditional access policies with Azure Active Directory to control access to company resources.

So why not move from ConfigMgr and manage all Windows devices with Intune?

Although managing devices may be viable for many modern management scenarios, there are scenarios where ConfigMgr remains as the preferred solution including:

  • Network controls for locations with low bandwidth
  • Down-level Windows 7/8 client management
  • Windows Server management
  • Devices that are network Air Gapped (isolated) and have no Internet access
  • OS deployment through network boot options
  • Complex application deployment scenarios
  • Third-party software updates
  • Etc.

Co-management provides methods for organizations running ConfigMgr to decide where they manage certain workloads. Currently, there are a number of workloads that may be managed by Intune when devices are co-managed, including:

  • Compliance policies
  • Device configuration
  • Endpoint Protection
  • Resource access policies
  • Client apps
  • Office Click-to-Run apps
  • Windows Update Policies

When utilizing co-management there are several advantages to utilizing Intune, for example in a co-managed scenario when moving “compliance policies” workload over to Intune, organizations can take advantage of Azure Active Directory Conditional Access. There are also immediate benefits of co-management such as executing remote actions directly from Intune including: Factory Reset, Selective Wipe, Device Restart, Fresh Start, etc. Intune compliance policies also play a significate role in controlling device health and access via Azure AD conditional access, for example Windows 10 compliance policies may require one or more of the following before accessing corporate resources:

  • Use a password to access devices
  • Encryption (e.g. BitLocker)
  • Firewall enabled
  • Installed Antivirus
  • Installed AntiSpyWare
  • Windows Defender version and signature is up-to-date
  • Minimum OS version required
  • Maximum OS version allowed
  • Valid operating system builds
  • Require the device to be at or under the Mobile Threat Defense level integrated with Windows Defender Advanced Threat Protection

Traditionally, setting up device health posture for an on-premises requires additional services and hardware such as a Network Access Control (NAC) solution. Whereas selecting workloads by enabling co-management for Intune to manage, organizations can take advantage of access controls delivered from Azure AD and Intune, including for on-premises web applications published through Azure AD Application Proxy. Not only is device health posture evaluated, additional access controls may be enabled including multi-factor authentication.

Below is an example of a device managed with ConfigMgr and Intune where compliance is reported back and shows in the ConfigMgr Software Center.

Intune Portal – shows compliant

Software Center – shows compliant (reported back from Intune)

Windows Deployment

Now let’s talk about Windows deployment options. Traditional deployment techniques for Windows typically involves an image that requires updating and then a system to publish those images so when a bare-metal boot takes place an image can be accessed, downloaded, and installed. OS image management can be a time-consuming process as it requires a human resource to manage and update the OS, drivers, apps, agents, etc. Some organizations offload OS image management to an OEM where the OEM preloads the image on the device, however the images still need to be maintained, and offloading to the OEM comes at a cost.

By leveraging Microsoft Intune and Azure Active Directory, organizations can take advantage of Windows Autopilot. Autopilot is very exciting as it eliminates the OS image management process which in turn can reduce IT costs. By pre-registering devices with Microsoft Intune when a user receives a device from the OEM, upon boot and connecting to the internet, the device will see that it’s registered with Microsoft Intune and go through the Autopilot process.

When organizations continue to utilize ConfigMgr, the CM agent can be pushed from Intune and the device now connects directly to ConfigMgr (when on corporate network) or through the Cloud Management Gateway giving your organization the confidence of maintaining current processes. Additionally, utilizing task sequences in ConfigMgr, Windows 7/8 devices may be upgraded to Windows 10 and automatically enabled for AutoPilot thereafter. The Windows 7/8 to 10 upgrade process may be pushed automatically or manually executed by end users (see screenshot below).

What about running scripts and installing software?

Both ConfigMgr and Intune support running PowerShell scripts and deploying Win32 applications, however for complex scripting scenarios such as running in task sequences and complex application deployments (i.e. deep app dependencies, etc.), ConfigMgr is unparalleled in this space.

My colleague Danny Guillory (who is also a PM on the Intune team) provided the following comments about Win32 applications and Intune:

Win32 App Deployment in Intune is a great way to get those .exe applications deployed and installed on those Windows Devices. The Win32 Wrapping Tool wraps all the files within that folder (think of a zipped folder), then distributes and deploys those files to the endpoints. The addition of detection method and delivery optimization makes Win32 app deployment more robust, simplifies distribution of content, and makes Win32 apps a must to explore with Intune Application Deployment.”

Additionally, MSIX is a new app packaging format that can take existing Win32 applications such as APP-V, MSI, .exe, etc. and package them in the new MSIX format. Many partners already support MSIX as well and for more details on MSIX packaging please visit: https://docs.microsoft.com/en-us/windows/msix/

If you’re looking to simplify application deployment both ConfigMgr and Intune provide the tools needed to deploy applications.

Monitoring and Reporting

Finally let’s talk about monitoring and reporting. ConfigMgr comes with hundreds of built-in reports, in addition there are newer monitoring and reporting capabilities with co-managed devices and a new reporting feature called CMPivot that provides real-time state of devices (see screenshot below). If you’re looking to creating dashboards based on ConfigMgr data, look into the Power BI template for ConfigMgr.

Next Steps

There are many Ignite sessions covering the topics in this post as well, to watch videos and learn more about the services and features discussed in this post please visit: https://www.microsoft.com/en-us/ignite search for “configuration manager”, “MSIX”, “Intune”

In conclusion, as organizations plan for the future of modernizing Windows management processes, my message to those organizations is to continue to leverage your current investments in ConfigMgr and keep current with releases. In parallel, begin to look at the benefits of cloud attaching ConfigMgr and/or managing workloads with Intune.

Windows Autopilot – check those logs…

Windows Autopilot is a Windows 10 feature that enables organizations to pre-register devices either through an OEM or manually.  When users receive a Windows 10 device that is registered with Autopilot and turn it on, they’ll walk through a streamlined and customized out of box experience (OOBE).  In summary, Autopilot helps to reduce the costs (and in some cases, infrastructure) of deploying devices to users.

If Autopilot were to run into an error there are several methods to check what and why issues occurred. Michael Niehaus has several posts about troubleshooting Autopilot including a recent blog post outlining new methods of accessing information to investigate Autopilot. Refer to Michael’s posts for detailed information on how to troubleshoot Autopilot.

In this post I’m sharing a simple script I wrote (based on the info Michael Niehaus outlined in his post) to view aggregated information about Autopilot from the registry and event viewer. In addition to registry and event viewer info, deeper investigation steps may be pursued with ETW.

 

Let’s get started

Requirements

  • Windows 10, 1709 or later
  • PowerShell


PowerShell Script

Feel free to modify the script to suite your needs such as remotely pull information from devices, etc.

The script is straight forward, first it looks for the Windows 10 version, i.e. 1709, and if it’s greater than or equal to “1709” it runs through both steps and pull registry and event logs. If the installed OS is greater than “1709” it will only pull event logs for 1709 as registry entries didn’t show up until 1803. Lastly, the script only pulls the latest 10 events, however that is easily modified.

 

#Get Windows Version
$WinVersion = (Get-ItemProperty -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion” -Name ReleaseId).ReleaseId
Write-Host “”
Write-Host WindowsVersion= $WinVersion

if ($WinVersion -ge ‘1709’)

{
Write-Host “”
Write-Host “AutoPilot Registry Entries”
Get-ItemProperty ‘HKLM:SOFTWAREMicrosoftProvisioningDiagnosticsAutoPilot’
}

if ($WinVersion -gt ‘1709’)

{
#Show AutoPilot events
Write-Host “AutoPilot Event Logs”
Write-Host “”
Get-WinEvent -MaxEvents 10 -LogName ‘Microsoft-Windows-Provisioning-Diagnostics-Provider/AutoPilot’
}

 

Let’s see it in action:

Below are the results of a device not deployed with Autopilot.  As we can see there’s not much to look at or troubleshoot…

clip_image002[6]

Let’s take a look at a device deployed with Autopilot (notice the new setup screen that shows up in 1803)

clip_image003

The results of the script shows more information that may be utilized when troubleshooting Autopilot errors:

clip_image004[6]clip_image005

Microsoft Cloud App Security log collector + OMS = Docker container monitoring

Need a quick method to monitor Docker containers? How about monitoring the Docker container that is utilized for automatic log upload for Microsoft Cloud App Security? If so, try out Microsoft OMS Container Monitoring Solution to monitor your docker containers including continuous log collectors using Docker in Microsoft Cloud App Security! 

Did you know that Microsoft Operations Management Suite (OMS) offers many other management and monitoring solutions including update management for Windows, Surface Hub monitoring, Security and Audit information and many more. For more details please visit: https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-add-solutions

If you’re utilizing Microsoft Cloud App Security in your environment today and would like to learn more about automatic log upload for continuous Cloud App Security reports please visit: https://docs.microsoft.com/en-us/cloud-app-security/discovery-docker

 

The following walks through setting up the Container Monitoring Solution in Azure to monitor a Docker container used for Cloud App Security automatic log upload hosted on an Azure VM.

Requirements

Assumptions for this post

 

Let’s get started…

Here’s a look at the Ubuntu VM with Docker used for Cloud App Security automatic log upload:

clip_image002

If you have an Azure subscription log in, select “new” from the upper left, and search for “container monitoring solution”:

clip_image004

Select Container Monitoring Solution and Create to add it to your OMS workspace:

clip_image006

clip_image008

Once the instance of Container Monitoring Solution is added, sign-on to your host where the containers are deployed and follow the instructions to install the OMS agent used for monitoring the host: https://github.com/Microsoft/OMS-docker#supported-linux-operating-systems-and-docker

 

You’ll run a script that is discussed in the link above to install the OMS agent:

clip_image010

 

Once the installation in complete, navigate back to the OMS admin portal and look for a new tile called “Container Monitoring Solution”:

clip_image012

 

Select the tile and view the status of the containers on the host:

clip_image014

clip_image016

clip_image018

 

From the information provided, I can see I have a failure with my Cloud App Security Log Collector (i.e. I named the container “LogCollector”)

clip_image020

When we drill down into the failure I can see that the which container is failing and other details:

clip_image022

 

Monitoring Docker containers using Microsoft OMS as well as the containers used for log collection for Cloud App Security was really simple and I encourage everyone to deploy OMS today.

Add Windows Defender Browser Protection to Chrome with Intune

I recently read a really great post by Martin Bengtsson about utilizing Configuration Manager (SCCM) to force installation of the Windows Defender Browser Protection extension for Chrome. So I decided to take a different approach and deploy the extension utilizing a PowerShell script deployed through Microsoft Intune.

To learn more about the Windows Defender Browser Protection for Google Chrome please visit: https://chrome.google.com/webstore/detail/windows-defender-browser/bkbeeeffjjeopflfhgeknacdieedcoml

Assumptions

Windows 10 device enrolled in Intune


Let’s get started

I created the following PowerShell script to add the Defender Chrome extension as a registry entry:

New-Item -Path HKLM:SoftwarePoliciesGoogleChrome -Name ExtensionInstallForcelist –Force

$RegKey =”HKLM:SoftwarePoliciesGoogleChromeExtensionInstallForcelist”

Set-ItemProperty -path $RegKey -name 1 -value “bkbeeeffjjeopflfhgeknacdieedcoml;https://clients2.google.com/service/update2/crx”

I saved the script as a .ps1 file and added to Intune utilizing the steps below:

clip_image001

Name the script, upload, and save

clip_image002[4]

Assign the script to a group

clip_image003

Sync your Windows 10 device with Intune

clip_image004[4]

Sync the device with Intune 

clip_image005

Registry Before sync

clip_image006[4]

Chrome without Defender browser protection

clip_image007

Registry after sync

clip_image008[4]

Chrome with Defender browser protection

Once Chrome is launched, the extension is automatically downloaded to the extension directory and added to Chrome.

clip_image009

Chrome extension directory

clip_image010[4]

In addition to configuration, Configuration Manager will also perform remediation if this is something you’re more concerned with, SCCM is the best path to go currently. Again read Martin Bengtsson’s detailed post for insight on deploying and remediating for the Windows Defender Browser Protection for Chrome extension through SCCM.