Another Defender for Endpoint integration

image

If you visit Microsoft Endpoint Manager | Endpoint Security | Microsoft Defender for Endpoint and scroll down the page on the right you see the new section App Policy Protection Settings as shown above. Turning this ON will basically allow the state of Microsoft Defender on both Android and iOS to feed into your compliance policies.

image

Once you have enabled these settings visit Apps | App Protection policies and edit or create an policy. During this process you will find a Conditional launch section. If you then scroll down to the bottom of tat page you will the screen shown above where  you can add the setting for Max allowed device threat option. This basically is the threat level you would allow on your device. If the threat level on a device goes above this then the selected action will take place. That action can either be Wipe or Block. Wipe is rather drastic, especially to start with, so Block is probably the best starting point.

You can read more about this new capability here:

Microsoft Defender for Endpoint risk signals available for your App protection policies (preview)

It is a nice integration we are beginning to see more of between device management and Defender for Endpoints.

Frustrations of using the Microsoft Graph with PowerShell

I’ve spent the past few day wrestling with the using Microsoft Graph with PowerShell, and it hasn’t been fun. Let me explain.

image

The first issue is that you can’t use the connect-graph command in the PowerShell ISE in Windows 10. if you do, you just get a flashing cursor as shown above that eventually times out.

image

If you repeat the same process in wither Windows terminal (above) or the PowerShell command you are taken through the standard device login browser process as expected.

image

After that, if you return to the ISE (above) and repeat the command connect-graph, you receive a message telling you that you are connected by virtue of the token from the previous Windows Terminal session.

SNAGHTML3e54e286

If you run the preferred Graph command get-mguser (above) you see that the AssignedLicenses and AssignedPlans attributes are blank.

image

If you now run my script:

https://github.com/directorcia/Office365/blob/master/Intune-connect.ps1

You also get connected to the Microsoft Graph as I highlighted here, but specifically to the Intune portion of the Graph:

New Intune connection PowerShell script

Typically, this type of connection is also designed for device management with PowerShell and work very well. However, because device management also requires access to users, we can also get access to user data via the Graph.

SNAGHTML3e5a0c9b

You achieve this by running the following script after connecting to Intune Graph:

$uri = “https://graph.microsoft.com/beta/users”
$users = (Invoke-MSGraphRequest -Url $uri -HttpMethod GET).Value
$users

which you see above gives you similar to the user options before but with far more detail as demonstrated by the assignedLicenses and assignedPlans highlighted previously highlight above.

SNAGHTML3e5cd9e4

Just to prove there is no smoke and mirrors here, above the output of the command get-mguser used after the connect-graph command (i.e. the non-Intune connection method).

Clearly, the data is in the Graph, but the command get-mguser does not yet seem to support pulling all this down from what I see. I hope someone can point out the error of my ways here but to create the reporting and automation I REALLY want looks like I’m to either have to use the PowerShell Intune module or revert to using the full web based invoke-request to get what I’m after.

image

What kind of worries me a little is that Intune PowerShell project seen above and at:

https://github.com/microsoft/Intune-PowerShell-SDK

that works REALLY well, hasn’t seen any updates in 2 years! There are 57 outstanding issues at the time of writing this blog, including two from me because not all the native wrapper commands work as expected. Are they being attended to at all I wonder?

In summary then, I’m in somewhat of quandary about using PowerShell with the Microsoft Graph. Specific stuff like the Intune SDK works well using the invoke-msgraphrequest command. It is easy to setup and manage the permissions for. On the other hand, the more general Graph commands like get-mguser don’t as yet seem to return as much information as they could. As well as the Intune SDK works I’m kind of afraid that it will not see future development.

So where should I invest my time to continue automating Microsoft 365 administration? Suggestion anyone?

Get Intune and Endpoint policies using PowerShell

Recently, I wrote an article about how to use PowerShell to connect to Intune and Microsoft Endpoint Manager. You’ll find it here:

Intune connection PowerShell script

Having a script that just connects to Intune doesn’t achieve a whole lot now does it? It’s now time to put that connection script to good use.

image

I’ve created another script, that once connected to Intune will allow you to display all the policy names you have configure in both Intune and Endpoint Manager as shown above. You can find that script here:

https://github.com/directorcia/Office365/blob/master/intune-policy-get.ps1

You’ll need to use my script to connect to Intune first. Once you have you can run the second script.

Although these scripts don’t do a huge amount, they will help you hopefully more easily connect to Intune with PowerShell and understand how you can also use PowerShell to work with information in both Intune and Endpoint Manager.

I’ll work on more advanced scripts for Intune and Endpoint that I’ll share in the future. However, this should hopefully get you up and running with automating device management in Microsoft 365.

New Intune connection PowerShell script

image

I’ve uploaded a new connection to Intune script that is freely available on my Github repository. You’ll find it here:

https://github.com/directorcia/Office365/blob/master/Intune-connect.ps1

image

Once it has been run you can run commands like:

get-autopilotprofile

as shown above.

To allow this script to operate correctly you’ll need the following two modules installed:

WindowsAutoPilotIntune

and

Microsoft.Graph.Intune

Both of these will be installed as part of my o365-setup.ps1 and o365-update.ps1 scripts, which are also freely available.

image

I’ve also added this Intune connection script to the connection selector script (c.ps1) in the same repository.

image

When intune-connect.ps1 runs you’ll be prompted for your credentials as normal.

image

Then you password and MFA if required.

image

Because connection to Intune via PowerShell now uses the Microsoft Graph, you’ll need to allow the above permissions as shown once.

SNAGHTML95fe247f

You’ll find those permissions, when you accepted them, in Azure AD, User, Applications as shown above inside the Azure portal. In there will be an application called Microsoft Intune PowerShell as shown above.

image

If you select that Microsoft Intune PowerShell and scroll down to the bottom of the screen that is displayed, you can select a link View granted permissions as shown above.

image

You will then see all the permission granted to that user for accessing the Graph. You can also remove these if you ever want to as well here.

Having access to Intune and Autopilot via PowerShell will make automating device management much easier.

Need to Know podcast–Episode 261

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-261-mark-oshea/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

I speak with a returning guest Mark O’Shea around the changes we’ve seen recently in Microsoft 365, especially around device management and Microsoft Endpoint Manager. The whole device deployment and management landscape is changing fast. It all used to be about Intune but now the focus is really Endpoint Manager and Mark helps us understand the why’s and what fors.

I’ve also got a swag of Microsoft Cloud news to share with you to bring up to date with the latest happenings.

As always, thanks for being a subscriber and don’t hesitate to share what I do with others.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Resources

@intunedin

Intunedin.net

@directorcia

What’s New with Microsoft 365 | November 2020 [VIDEO]

What’s New in Microsoft Teams | November 2020

Teams Breakout rooms go GA

Microsoft Edge v.88: Deprecate support for FTP protocol

Microsoft Edge v.88: Adobe Flash support will be removed

Microsoft Edge v.88: Alerts if your passwords are found in an online leak

Add to OneDrive is generally available

Introducing the SharePoint Success Site – Drive adoption and get the most out of SharePoint

Threat actor leverages coin miner techniques to stay under the radar – here’s how to spot them

New datacenters for Sweden, Denmark, and Chile

CIAOPS Patron community

Need to Know podcast–Episode 260

We welcome back Brenton Johnson to speak about his success with Intune and how he’s using it to manage devices for his customers. Brenton shares his journey as well as some handy best practices during our chat.

Of course, there is also all the Microsoft Cloud news to get through, so sit back and enjoy this bumper episode.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-260-brenton-johnson/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

@contactbrenton

@directorcia

Uptake Digital

Power Apps Community plan

Meet the Microsoft Pluton processor – The security chip designed for the future of Windows PCs

The Microsoft Cloud App Security (MCAS) Ninja Training is Here!

Extend data loss prevention to your devices with Microsoft Endpoint Data Loss Prevention, now generally available

It’s Time to Hang Up on Phone Transports for Authentication

See how to easily keep tabs on your Azure Sentinel ingestion costs

What’s new: Microsoft 365 Defender connector now in Public Preview for Azure Sentinel

Microsoft’s Cloud PC: Leak reveals new details on upcoming Azure-powered remote desktop

What’s New in Microsoft Teams | October 2020

The definitive guide to Productivity Score

Need to Know podcast–Episode 259

FAQ podcasts are shorter and more focused on a particular topic. In this episode I speak about some automation options that are available in the Microsoft Cloud.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-259-baselines/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

FAQ 20

@directorcia

Use security baselines to configure Windows 10 devices in Intune

Preset security policies in EOP and Microsoft Defender for Office 365

CIAOPS Patron Community

Intune Data Collection Policy Error 0x87d1fde8

State = error

State Details = -2016281112 (Remediation failed)

image

It all started when I was checking my Intune Configuration policies and I found that all of a sudden I have a new policy called Intune data collection policy as shown above, that I didn’t created. Worse, it had errors!

image

When I looked at a specific device that was affected, as shown above, I could see two errors on the device. One was from a user designated as System account, which was also somewhat puzzling.

image

Digging further I found that the State was Error and the State details were -2016281112 (Remediation failed) as you can see above.

image

At the most granular level, I found the Error code was 0x87d1fde8 as shown above.

image

It turns out that the Intune data collection policy gets created when you use Endpoint Analytics as shown above.

image

This gives you some really nice reports as shown above on your Windows devices. You can read more about it here:

What is Endpoint Analytics?

I had now solved where the mystery Intune data collection policy came from and after much research it turns out that the device errors are because of licensing as you can read here:

Licensing Prerequisites

which says:

Endpoint analytics is included in the following plans:

Proactive remediations also require one of the following licenses for the managed devices:

  • Windows 10 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5)

  • Windows 10 Education A3 or A5 (included in Microsoft 365 A3 or A5)

  • Windows Virtual Desktop Access E3 or E5

The error I was seeing was due to those machines only being Windows 10 Pro, NOT Win 10 Enterprise! Endpoint Analytics currently only works with Windows 10 Enterprise licensed devices.

Once I had changed the Intune data collection policy to exclude the Windows 10 Pro machines the errors went away, as did the duplicate System account as well.

Hopefully, Microsoft will consider extending Endpoint Analytics to Windows 10 Pro machines as well, but for now you’ll need to exclude them from any Intune data collection policy if you don’t want errors in Endpoint Manager.