Azure Cloud Shell now available in Microsoft 365

image

If you take a close look at your Microsoft 365 admin center, as shown above, you might see a new icon in the top right. The Azure Cloud shell is now available right from here.

image

If you select that, you’ll then see a PowerShell style window appear at the bottom of page as shown above. Here you can run all your favourite scripts directly in a browser!

I’ve covered the Azure Cloud Shell in previous articles:

Azure Cloud Shell

Connecting to Exchange Online with Azure Cloud Shell

and you can read the Microsoft documentation here:

Overview of Azure Cloud Shell

The only limitation seems to me is that you need an active Azure subscription tied to your Microsoft 365 environment because Azure Cloud Shell does need some storage to operate. But who doesn’t have an Azure subscription in their tenant these days right?

Deploy Office 365 and Azure together

(Hint, this is another reason to ALWAYS sell an Azure subscription when you sell Microsoft 365 if you are a reseller).

Hopefully, Microsoft might allow some included storage in the future for those without an Azure subscription.

Having the ability to run PowerShell directly from the browser with Microsoft 365 is a super handy addition and hopefully the functionality will keep extending with this.

PowerShell with Azure Conditional Access

Recently, I did a video demonstrating how PowerShell can be used to automate Endpoint Management:

PowerShell with Endpoint Manager

I’ve now also created a video demonstrating how to automate Azure Conditional Access using PowerShell. As before, I am only making these scripts available via the CIAOPS Paton program.

In this video you’ll see me automatically backup up both Conditional Access locations and policies, then apply best practices locations and policies, finally restore the original policies, all using scripting.

Again, these scripts are not free and part of the CIAOPS Paton program. You’ll find my free stuff at https://www.github.com/directorcia.

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.

Modern Device Management with Microsoft 365 Business Premium–Part 8

Office 365 Mobile MDM – Modern Device Management with Microsoft 365 Business Premium–Part 1

Intune MDM – Modern Device Management with Microsoft 365 Business Premium – Part 2

Intune MAM – Modern Device Management with Microsoft 365 Business premium – Part 3

Endpoint Manager – Modern Device Management with Microsoft 365 Business Premium – Part 4

Baselines – Modern Device Management with Microsoft 365 Business Premium – Part 5

Deployment – Modern Device Management with Microsoft 365 Business Premium – Part 6

Autopilot admin – Modern Dev Management with Microsoft 365 Business Premium – Part 7

In the previous post I detailed Windows Autopilot from the administrator’s point of view. What does it look on the device side?

image

Just before the Autopilot Reset is selected in the EndPoint Manager portal as shown above, let me show you one quick configuration I’ve also done in Windows Hello for Business to make life that little bit easier.

image

In Devices | Enroll Devices | Windows enrollment select Windows Hello for Business as shown above.

SNAGHTMLf86d2ee

I have set the Configure Windows Hello for Business to be Disabled. Because I’m using a machine WITHOUT a TPM chip here (i.e. a Virtual Machine), it means that if Windows Hello for Business is enabled I’m going to need to go through the process of registering a device PIN. For now, to keep it as simple as possible, I want that Disabled.

Of course, I have also completed the Autopilot enrolment process and created an Autopilot device policy as detailed in the previous part in the series. Note, that a user has also already been assigned to this device. This means that the machine will be joined to Azure AD using this assigned user. That means they will not need to input their credentials during the process.

image

After selecting Autopilot Reset in Endpoint Manager I am asked to confirm the process as shown above. Take careful note here of what Autopilot does to that machine.

Select Yes to continue.

image

Once I select Autopilot Reset in Endpoint Manager, any active user will receive the above message that they have 45 minutes before the targeted machine is forcibly rebooted. I will fast track that process by manually rebooting the workstation to commence the Autopilot reset process.

image

If the devices is at the lock screen you will see the above message when the Autopilot process commences.

image

The workstation will then reboot and commence a Windows ‘refresh’ of the device, effectively doing a clean installation of Windows 10.

image

image

image

image

image

image

image

image

It will then complete the Autopilot configuration as seen above. You will note here that no user input is required. The reason for this is in Endpoint Manager a user has already been assigned to the device.

image

Not long after, you’ll will then end up with the ability to login to the workstation, as shown above.

image

image

When you do, you’ll be taken through the normal first run Windows experience as shown above.

image

The standard desktop should appears and all the device policies, Intune, Endpoint Security, etc will commence application to the device. Thus, it is just like you did a manual device join to Azure AD but you DIDN’T! Autopilot did all the hard work for you!

This is an example of how easy modern device management cam make your life once you set it up. If there is a problem with a machine, don’t waste long hours troubleshooting! Do an Autopilot reset to get a fresh version with everything deployed and accessible from the cloud. Easy! Need to reprovision an existing machine for a new user? Autopilot Reset again. Easy! the list goes on and on for the benefits of Windows Autopilot.

Although not yet available, what would you say if the same Autopilot concept was coming to both iOS and Android? Roll on modern device management is what I would say.

Modern Device Management with Microsoft 365 Business Premium – Part 9

Need to Know podcast–Episode 254

In this episode we go a bit Dev and talk with MVP David Gardiner about software and using things like GitHub to make life easier for all those scripts you have developed. Having a handle on using software is a very important skill for IT Professionals to have in the cloud and David gives us some insight and experience as a developer that I think will help.

Of course I bring you up to date with all the news on the even of Microsoft Ignite and the fire hose we expect afterwards. Listen in an enjoy this 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-254-david-gardiner/

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

@davidrgardiner

@directorcia

https://david.gardiner.net.au/

https://github.com/flcdrg

https://www.adnug.net/

Microsoft Ignite 2020

Guidance for delivering Virtual Events

In development for Microsoft Intune

Move flows across environments

End of support for Office 2010

New conversations button in Teams

The changing security environment with Microsoft 365

A couple of new additions to Azure Sentinel

Need to Know podcast–Episode 253

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-253-automation-optiona/

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 16

CIAOPS Patron Community

@directorcia