Blocking Registry edits on Windows with an Intune Device Configuration profile

This article shows you how to use Intune to block Registry editing on Windows devices using a Configuration profile.

Navigate to https://endpoint.microsoft.com and select Device from the menu on the left as shown above.

Then, select Windows on the right.

Select Configuration profiles from the menu on the left as shown.

Select Create profile.

Then select the Platform as Windows 10 and later.

Select the Profile type as Templates.

From the list of templates select Custom.

Select Create in the bottom right.

Give the policy a name and select Next to continue.

Select Add.

In the OMA-URI settings enter the following as shown above:

Name = Block Registry

Description = Block Registry

OMA-URI = ./user/vendor/MSFT/Policy/Config/ADMX_ShellCommandpromptRegeditTools/DisableRegedit

Data type = String

Value =
<enabled/>
<data id=”DisableRegeditMode” value=”2″/>

Ensure you enter these exactly as shown, anything else will prevent the policy working as expected.

Press Save.

You should now see the item you just entered displayed as shown above.

Select Next to continue.

Assign the policy to a group. Here it is being assigned to all Windows devices.

Select Next to continue.

You will now see a summary. Ensure the Configuration settings has the above set before selecting the Create button to complete the policy.

You should now see that the policy has been created and listed with all other Configuration profile policies as shown above.

You can edit this policy at any stage simply by selecting it.

You now need to wait until the policy is deployed successfully to devices. You can check the status of this by viewing the Device status for the policy as shown above.

If you now try and make a change to the registry on a device where the policy is deployed you will see the following message.

Intune Remote Help introduction

Video link = https://www.youtube.com/watch?v=8CSy-Q383Dw

This video provides an introduction to the Intune Remote Help capabilities and compares it to the free Quick Assist service that is provided with Windows.

Use remote help with Intune and Microsoft Endpoint Manager

Remote help software download – https://aka.ms/downloadremotehelp

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?

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.

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

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.

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.

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.

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

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

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.

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

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

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:

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.

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.

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

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.

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.

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.

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!

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

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

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

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.

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.

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.

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

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.

The first PowerShell command that needs to be run is:

wmic bios get serialnumber

record the number that it produces.

Next, run the PowerShell command:

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

once again, record the number that is output.

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.

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

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

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).

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.

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

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

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.

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.

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.

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.

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.

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.

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

Select the Create button when complete.

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.

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.

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.

They will then be prompted for a keyboard layout.

Make a selection and press Yes.

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.

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.

The user will now be prompted for their password.

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.

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.

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

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.

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

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.