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

Modern Device Management with Microsoft 365 Business Premium–Part 7

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

So far the discussions in this series has focused largely around security and configuration. However, modern device management also brings with it a new way to deploy devices and applications. It provides the ability to do this in a completely hands off approach. That means, that it is now possible to purchase the device, deploy the device, manage and maintain the devices and retire that device without every having to physically touch the device.

A great example of this is Windows Autopilot. This is a services, surfaced through the Endpoint Manager console, that allows you to set deployment policies for device initial set up, automatically from the cloud. The end user is largely shielded from the initial Windows OEM on boarding experience and are typically only required to provide their credentials to configure the device.

Initially, Windows Autopilot was designed as a service largely available with the purchase of a new device. However, importantly, it is now something that can be, and should be, applied to all Windows 10 devices in your environment going forward.

The first requirement to take advantage of Windows Autopilot is that the user requires a license that supports it. The good news is that Microsoft 365 Business Premium includes a license for Windows Autopilot.

Next, unique information about the devices needs to be obtained and uploaded into the Endpoint Manager console. If the devices is a new purchase, this will be available from the distributor. However, if the device already exists then it will need to be ‘harvested’ using a simply PowerShell script. You can read more about this here:

Adding devices to Windows Autopilot

The script that you use is here:

get-windowsautpilotinfo

and the commands are:

Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv

just make sure you run PowerShell as an administrator so the Autopilot module can be installed.

When you run this script it will create a CSV output file that looks like:

image

Basically the file contains the device serial number, Windows product id and a hardware hash. In essence, file allows that machine to be uniquely identified.

SNAGHTML15108d68

The next step in the process is to upload the machine CSV file into the Endpoint Manager console. To do this, navigate to Devices, then Enroll devices as shown above.

SNAGHTML1511efe6

You’ll then need to select Windows enrollment  and Devices as shown above.

image

You’ll then need to select the Import button from the menu at the top. You’ll then see a dialog for where you can upload the machine CSV file as shown above.

When you upload the file will be checked for integrity.

image

You will the result as shown above. You can also have multiple devices in this CSV file and that number will also be reflected here.

When ready, select the Import button.

image

The import process will take a few minutes per device to digest but after that you should see the machine you imported as shown above.

What will also happen now is that Endpoint Manager will look for a match between the devices you imported and any machine that may already be enrolled in the environment. This is why it is important to all any existing Windows 10 machine here, even if they didn’t have Autopilot applied to them initially.

image

You’ll also note that you can assign a user to the device, as shown above. Doing so will mean that upon completing Autopilot it will be ready for that user, without the need for them having to log in during the Autopilot process. This allows device enrolment WITHOUT the need for a user on the device!

SNAGHTML155f6752

Now that Endpoint Manager can recognise the devices as they boot up, the next step is to set the process through which these devices will run during that initial boot phase. This is set via Deployment Policies as shown above, in the Windows Autopilot Deployment Program area of Enroll devices in Endpoint Manager..

image

Here, select the option to Create profile, as shown above

image

Give the new policy a name and generally set the Convert all targeted devices to Autopilot as Yes.

image

The next stage is where you set the the Out Of the Box Experience (OOBE) for the user. For example, you can hide the Microsoft Software License Terms, Privacy settings, etc. Generally here, you want to minimise what the user is presented with as the machine boots.

image

You then assign the policy as you would any other in Endpoint Manager and complete  the process.

The policy should now be displayed in the list of deployment profiles. You can edit the existing profile or create new ones if you wish.

image

Now that Endpoint Manager can identify devices as they boot and apply a deployment profile to them as well, you can target these devices for an Autopilot Reset as shown above.

To do this, simply navigate to the device in Endpoint Manager, select the ellipse (three dots) in the top right, and from the menu that appears select Autopilot reset.

image

The device will receive a warning as shown above, indicating the process will start in 45 minutes. If however, the machine is rebooted prior to this, the Autopilot process will commence.

When the Autopilot process does commence, the device will re-initialise Windows to being ‘Out Of the Box’. If a user has been assigned to that device, it will used to join to Azure AD and enrol in Endpoint manager automatically, without user interaction. When complete, the device will be ready for the user to access the new clean environment.

In summary then, Windows Autopilot is part of Endpoint Manager and allows you to provide an ‘Out Of the Box Experience’ (OOBE) for users and automatically enrol the device in your environment. You can do this with new devices shipped to the user directly from a distributor and you can also incorporate any existing Windows 10 device in your environment by harvesting the unique device information and then uploading that into the Endpoint Manager console.

Once a machine appears under Autopilot in the Endpoint Manager console, it means you can fully manage and redeploy that device if you need to, without ever having to touch that machine. That is what modern device management is all about!

Modern Device Management with Microsoft 365 Business Premium – Part 8

Need to Know podcast–Episode 214

I chat with MVP Microsoft Mark O’Shea about the Microsoft 365 technical information from the recent Microsoft Inspire in Las Vegas. The focus is not on the partner information but the technical announcements from the conference, and yes there were plenty. Brenton and I are also back together to bring you up to date with everything that is happening in the Microsoft Cloud. Enjoy the episode.

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

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-214-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

@intunedin

@contactbrenton

@directorcia

Intunedin

Microsoft 365 Dark Mode

What’s new in Microsoft 365 [VIDEO]

New to Microsoft 365 in August

Outlook Flow connector changes

Higher tech for higher ed

Soft Delete for Azure Backup Virtual Machines

Microsoft Azure available from new cloud region in Switzerland

Requested features for list groups

Enhanced QuickEdit for SharePoint Online

Meet the new Outlook on the web

Azure Sentintel

Windows 7 end of support

Office 2010 end of support

Microsoft 365 Security and Compliance

Conditional Access

Windows Virtual Desktop

Edge Insider Enterprise preview

Microsoft 365 Training Day: Security and Compliance day

MyAnalytics

CIAOPS Techwerks 8 – Adelaide October 2019

CIAOPS Techwerks 9 – Melbourne November 2019

Need to Know podcast–Episode 190

Brenton and I take an opportunity to get you up to date ahead of Microsoft Ignite on all the latest news in the Microsoft Cloud. We have some news about SharePoint and Outlook as well as some changes to Windows 7 support. Brenton also suggests that maybe we need a dedicated episode on PowerShell. What do you think? Let us know.

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-190-cloud-updates/

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

New Outlook on the web

Helping customers shift to a modern desktop

Microsoft Ignite

Microsoft Teams data residency

Windows 7 monthly update charge

PowerShell basics

Initial set up of an Office 365 PowerShell environment

CIAOPS Learn

CIAOPS Patron

Auditing Office 365 logins

Using Azure Automation to schedule mailbox checks

Introduction to Windows Autopilot

Microsoft has introduced a new technology called Windows Autopilot that allows you to easily deploy Windows 10 Professional and Enterprise machines with nothing more than just an Internet connection.

A good way to get a feel of how all this works in practice is to use a Virtual Machine (VM) as a test bed which is what I’ll show you here.

The first thing is that you are going to need to get some information about the machine so that it can be recognised by Windows Autopilot when it is provisioned. Normally, this information will be provided directly by the manufacturer of the PC, but here’s how it actually works behind the scenes.

For this test process we start by running up a new clean virtual machine with Windows Professional installed.

Once the machine is running (we don’t need to worry about connecting to Azure or a domain just yet), we need to run PowerShell as an administrator so we can extract the required information.

image

The first PowerShell command that needs to be run is:

wmic bios get serialnumber

record the number that it produces.

image

Next, run the PowerShell command:

Get-ItemPropertyValue “hklm:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DefaultProductKey\” “ProductId”

once again, record the number that is output.

image

Finally, run these two commands:

$wmi = Get-WMIObject -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter “InstanceID=’Ext’ AND ParentID=’./DevDetail’”

$wmi.DeviceHardwareData | Out-File “$($env:COMPUTERNAME).txt”

This will create a file containing machine identification information, basically a hash.

image

This file will be written to the location from which the PowerShell command was run. By default this will be c:\windows\system32.

image

If you open the text file created (which has the name of the machine) it should appear like that shown above.

image

With all the information safely recorded, you can now run SYSPREP to generalise the machine and reboot or blow away the version of Windows (but not the actual VM. That needs to be retained so it is correctly identified during the coming provisioning process).

image

You need to now create a .CSV file to upload so that the machine can be identified at boot and provisioned. You can see the format of the file above.

Basically, the machine configuration file has at least 2 lines. The first is a heading line:

Device, Serial Number, Windows Product ID, Hardware Hash

The second line are the results from your PowerShell commands above separated by commas.

Ensure that you save the file as .CSV not .TXT!

You’ll now need to upload this file to the web. Navigate to:

https://businessstore.microsoft.com/

and login there with the Office 365 global administrator account for your tenant. This will typically be a tenant with Microsoft 365 licenses installed.

image

Once logged in the screen should appear like that shown above. Select the Manage option from the menu across the top of the page.

image

This should then take you to a screen like shown above. From the menu on the left hand side select Devices.

image

If this is the first device you’ve added to Windows Autopilot, you won’t see any existing devices.

Select the + Add devices menu option just under the Search devices box.

image

Navigate to the location of the .CSV file you created earlier that contains the information about your test VM. Select the file to upload it to the portal.

image

Since there are currently no deployment groups you’ll be asked to add a new one as shown above. Simply enter a group name and select Add.

image

The file should successfully upload to the portal and you’ll see a message telling you that it is being currently processed and you should refresh your screen to see the progress.

image

When the process is complete, you’ll get a happy green bar across the top and you’ll also see you machine listed below as shown above.

image

You’ll now need to create a profile for the deployment of Windows. Select the menu option AutoPilot deployment from the menu just above the list of devices as shown. From the menu that appears select Create new profile.

image

Give the new profile a name (here Test-Policy) and select any other desired settings.

Select the Create button when complete.

image

That will take you back to the list of devices. You’ll now need to apply the new profile you just created to the machine you have just added.

To do this, select the machine from the list.

image

Then select the option to Apply the appropriate policy.

Most of what we have just done will actually be done by the PC supplier down the track. They will basically get the details of each PC prior to shipment and upload that into the portal where you can then create and apply policies. We have stepped through the whole process here because we are using a virtual machine and to show you what actually happens.

The idea at this point is the new Windows 10 machine is shipped out to the end user. The only requirement the user needs to have is their Office 365 login details plus an Internet connection.

image

If we now re-provision the original machine it will boot to a point and ask the user to confirm their regional preference.

Make a select and press Yes.

image

They will then be prompted for a keyboard layout.

Make a selection and press Yes.

image

The use will also be prompted for any additional keyboard configuration. In most cases the user will select Skip here.

At this point the new machine will check to see whether it is connected to the Internet. If it detects a wifi network it will prompt the user to login. This means the machine can be provisioned ANYWHERE there is an internet connect (i.e.at home, at a coffee shop, etc). It doesn’t need to be connected to the corporate LAN.

image

The next prompt will ask the user to login with their Office 365 account. This is their Azure AD account which is the same as they use to login to the Office 365 portal.

image

The user will now be prompted for their password.

image

The machine will now add itself to the Office 365 Azure AD and apply any policies that have been configured. I’ll cover the deployment of custom policies and application deployment in another article.

image

After a few moments the user will be logged into the Windows 10 machine and will display the information from their Office 365 account as shown above.

image

You will also find that the machine has been joined to Azure AD as shown above.

image

If you dig into the user accounts on the machine you will find that there are no local accounts enabled as we elected back when we set up the initial AutoPilot profile in the portal.

image

Now, thanks to Windows Autopilot, we have quickly and easily deployed a new Windows 10 machine without the need for administrative intervention (such as joining to a domain). This machine is now directly connected to Azure AD and any Office 365 user can now login.

Although this process has been done using a virtual machine it can be done with any Windows 10 Pro or Enterprise machine. The main requirement is to get the machine information into the web portal so that it can be identified and provisioned at boot. Obtaining that information is as simple as a few PowerShell commands so you can try it for yourself to get a feel of how well it works.

For more information on Windows Autopilot visit – https://docs.microsoft.com/en-us/windows/deployment/windows-10-auto-pilot

Look Ma, SBS running on Azure

image

One of the challenges I set myself when I first started using Azure was to get Windows Small Business Server (SBS) working in Azure IaaS. Happily, I can announce that today I have achieved that goal as the above image shows hopefully demonstrates.

Why did I do this? Apart from the technical challenge I wanted to have a typical on premises SMB ‘legacy’ environment in Azure for testing, labs, training and migration scenarios. I am not planning to use it in production and STRONGLY recommend that SBS should no longer be run in production for many reasons anywhere, including on premises. I appreciate this is bordering on heresy for some, but I stand by the fact that you need to be off SBS. 

That said, I do appreciate that there are people out there running it and some may even be considering moving SBS onto the cloud. Although I would never recommend you do that in production I can tell you that it is 100% possible with Azure. This, to me, demonstrates the flexibility and power Azure provides as well as it’s ability to solve just about any IT challenge you throw at it.

So, if you wanna know how I did, just ask me.

Azure Nested Virtualization

One of the things that Azure VMs currently don’t seem to allow is the ability to login to machines using just Azure AD credentials. So, how to overcome this issue but remain totally cloud based?

The solution is to use nested virtualisation in Azure which Microsoft recently announced here:

Nested Virtualization in Azure

Nested virtualization is only available on specific machines (See above link for details). One of these is the E_V3 series, which are currently not available in every region.

image image

Just for comparison, I looked at my usual ‘go to’ machine (a DS2_v2) and the supported E2S_V3. As you can see from the above the E2S_V3 is far better value, being cheaper and having more RAM.

This made me think that perhaps I should convert some of my stand alone test VMs into guest VMs in a nested arrangement. As long as I only use these machines together the compute cost would only be for the single host VM on which the multiple guests are running rather than multiple individual Azure VMs. Hmm…something to consider down the track.

image

So I ran up a E2S_V3 out of the West US 2 datacenter with Windows Server 2016 datacenter in the standard manner.

Once the server I up I simply went in and added the Hyper V role as you would with any Windows Server.

image

The feature installed and when complete I rebooted the server as required.

image

After the reboot I had access to the Hyper V Manager as you can see above, as with any Windows Server.

image

I now needed to create a new Hyper V Virtual Switch that would support NAT that my guests could connect to and then get access to the Internet.

To do this I needed to run 3 lines of PowerShell:

New-VMSwitch -SwitchName “NATSwitch” -SwitchType Internal

New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceAlias “vEthernet (NATSwitch)”

New-NetNAT -Name “NATNetwork” -InternalIPInterfaceAddressPrefix 192.168.0.0/24

You can alter the IP addresses to suit.

image

Once this is complete if I now look in my Hyper V Manager I see a new virtual switch as shown above. I’ll use this to connect the network card of my VMs to.

At this point I’ll need to assign the IP addresses to my virtual machines manually. I can configure an appropriate DHCP server if I want but I’ll leave that for a future article.

image

So now I just create a VM on this server as I would normally. In this case I chose a Windows 10 Preview edition.

image

When complete I need to set a static IP until I get the DHCP server operating.

image

Voila, a nested VM in Azure connected to the Internet and ready for further testing.

I can’t tell you how much flexibility this is going to provide me. Not only can I now login to machines using Azure AD account but I can run up things like Windows 10S and (shock, horror) maybe even get SBS working as a guest. Now that would be really cool to achieve and I have added that to my ‘to do’ list. Watch for and article real soon!

Till then, all I can say is that Azure Nested Virtualization is super cool and really super cheap! Love the cloud!

In private browsing

I work across many different Office 365 (and Azure) tenants every day. Many times I need to be inside multiple tenants at the same time. How can I do that effectively? I use ‘private’ browsing modes inside each browser to keep login details isolated.

You can think of ‘private’ browsing as an isolated instance of surfing the web. When you start ‘private’ browsing you start with a ‘clean’ environment (no credentials, logins, etc) are remembered. When you close down the sessions everything is forgotten.

Here’s how you start ‘private’ browsing sessions across the major browsers.

Microsoft Edge

image

Right mouse click on the Microsoft Edge browser icon and select New InPrivate window from the menu that appears.

image

If you are already using Microsoft Edge, select the three dots in the upper right to display the above menu. Select the New InPrivate window option.

Google Chrome

image

Right mouse click on the Google Chrome browser icon and select New incognito window from the menu that appears.

image

If you are already using Google Chrome, select the three dots in the top right to display the menu shown above. From this menu select New incognito window.

Internet Explorer

image

Right mouse click on the Internet Explorer browser icon and select Start InPrivate browsing from the menu that appears.

image

if you are already using Internet Explorer, select the Cog icon in the top right, then from the menu that appears select Safety. From the fly out menu that then appears, select InPrivate Browsing.

Firefox

image

Right mouse click on the Firefox browser icon and select New private window from the menu that appears.

image

If you are already using Firefox, select the three lines in the top right to display the menu shown. From the menu that appears, select New Private Window.

Thus, between these four major browsers and their ‘private’ browsing modes, I can work with eight different tenants all at once. Barely enough, I’m telling you. Barely enough.