Microsoft Endpoint Manager – Converting your Windows 10 Pro devices to Enterprise

Microsoft Endpoint Manager – Converting your Windows 10 Pro devices to Enterprise

Hello Readers,

Recently during a rollout of Microsoft Endpoint Manager, I noticed that my configured Lockscreen and Desktop background where not being applied to my newly enrolled Windows 10 devices. 🙁 After a bit of investigation I noticed that the device was running as Windows 10 Pro, even though the image used to build the machine was Windows 10 Enterprise.

Launch https://devicemanagement.microsoft.com and browse to Device –> Configuration Profiles –> New
– Name = Provide a name
– Description = (Optional)
– Platform = Windows 10 and later
– Profile Type = Edition upgrade and mode switch
– Settings = Select Windows 10 Enterprise and provide your key

Now assign the policy to the affected devices and you will now have Windows 10 Enteprise devices.

Regards
The Author – Blogabout.Cloud

Obtaining your ImmutabeID the easy way because hard matching is a nightmare

Imagine, your company has just been brought by another organization. The acquiring company what you using Office 365 services as quick as possible so they create you a Cloud Only Account to leverage their existing tenant. Now imagine, you are 12 months into the acquisition and you want to have a single sign-on experience for your end-users.

Now you have a dilemma on your hands, as your primary user principle name on-premises is different from your UPN in the Azure Tenant.

WHAT DO YOU DO!!!

Image result for captain picard head in hand
What did I do??

You engage your Windows PowerShell Console in Administrator Mode and teleport in the Get-ImmutableID.ps1 PowerShell script

Image result for captain picard
Engage!!!
New Features coming soon!!

With this script, you are able to download all the ImmutableIDs from your local Active Directory into a single CSV file to your desktop.

Please Note:

If there are additional fields you would like to see in this script, please submit an update via Github or email alerts@blogabout.cloud

You will need some manual intervention matching your on-premises AD Users and AAD Users but once this is complete you will be able to run the following script to set the ImmutableID in your Azure Active Directory.

PowerShell Script

region File Path
$Filepath1 = Get-Filename -initialdirectory “$env:USERNAME\desktop”
$csv1 = Import-Csv -Path $filepath1
endregion

Start-Transcript “env:userprofile\desktop\SetAllUserAADtest.txt”

ForEach($user in $csv1){
1
Try

1
{ Get-AzureADUSer -ObjectId $user.primarysmtpaddress -ErrorAction Ignore Write-Host "Success:",$user.PrimarySMTPAddress,"was found and set with",$user.ImmutableID -BackgroundColor DarkGreen

1
Set-AzureADUser -ObjectID $user.PrimarySMTPAddress -ImmutableID $user.ImmutableID }

1
catch

1
{ Write-Host "ERROR:",$user.PrimarySMTPAddress,"could not be found" -BackgroundColor DarkRed }


Stop-Transcript

While this is a tried and tested in my own deployments, I am unable to take responsibility for any potential issues you may encounter. Keep safe with responsible scripting, always test in a lab environment first.

Regards
The Author – Blogabout.Cloud

Configuring your time zone with Microsoft Endpoint Manager

Configuring your time zone with Microsoft Endpoint Manager

Isn’t it annoying when your time zone on your Azure AD Join, Hybrid Azure AD Joined or Autopilot enrolled device has the incorrect time?

Is there a simple way of resolving this issue for all devices?

Of course, there is… Now let’s look at how it is done.

First of all log into your Microsoft Endpoint Manager Admin center via https://devicemanagement.microsoft.com/ or the Azure Intune Portal. You will now need to create a new Device Configuration Policy with the following information

– Name = Something you can identify the profile easily
– Platform = Windows 10 and later
– Profile Type = Custom

Custom Profile – Device Configuration

Press Add
– Name = Set time zone
– Description: (Optional)
– Platform = ./Device/Vendor/MSFT/Policy/Config/TimeLanguageSettings/ConfigureTimeZone
– Data type = String
– Value = What ever time zone you require (This information can be found here https://support.microsoft.com/en-gb/help/973627/microsoft-time-zone-index-values

Save your newly created policy and assign to the relevant group

Regards
The Author – Blogabout.Cloud

Encrypting your Windows 10 devices using Microsoft Intune and non-admin users

Encrypting your Windows 10 devices using Microsoft Intune and non-admin users

Microsoft Endpoint Manager is great however, if you want to encrypt Windows 10 device silently with a normal standard user logged in then you might find it difficult to do so via the MEM Portal settings. So this is where this blog post will come in handy 🙂

In order to encrypt the device silent you need to create a Custom Configuration Policy. Browse to your Microsoft Endpoint Manager Portal or Intune Portal –> Go to Device Configurations Profile –> Create New Profile

  • Enter a Name for the Profile
  • Select Windows 10 and later from Platform
  • Select Custom from Profile type
  • Select Configure from Settings
  • Press Add

We will now need to enter the following information to configure encryption.

NameOMA-URIData TypeValue
AllowStandardUserEncryption ./Vendor/MSFT/BitLocker/AllowStandardUserEncryption Integer 1

Once you have created the policy, assign it to your required devices and BitLocker will now encrypt the devices.

Oh but wait!!!

In my experience in performing this procedure have ran into an issue where Intune recognises the device has compliant against “Require BitLocker” but non-compliant against “Encryption of data storage on the device”.

This is due to the device not being able to backup the BitLocker Encryption Key to Azure Active Directory. The workaround for this was to deploy a PowerShell script using Intune that forces the key to be backup up.

So lets add a script to Intune which will execute the required steps; First go to Device Configuration –> Scripts –> Add

Provide a Name which will easily identify the script in the Intune Portal.

Browse to the script location on your local machine or network drive
Tick Yes to Run script in 64 bit PowerShell host.

And save then assign to the required AAD Group to execute on the client macine.

I cannot take any credit for the script but it resolves the issue I encountered and my compliant policy was once again “Compliant” for all devices. I have made this script available via my GitHub account.

https://github.com/TheWatcherNode/blogaboutcloud

Regards,
The Author – Blogabout.Cloud

Require BitLocker -2016345708 (Syncml(404): The requested target was not found)

Hello Reader,
During a Windows 10 pilot roll-out, I have run into the following issue where the Device Compliance Policy is shown an error for Require BitLocker but however, Encryption of the data storage on the device was compliant?

Weird!!

This issue was being caused PCR7 Configuration stating “Binding Not Possible”. The resolution of this message is to UPDATE YOUR BIOS!! The devices were newly purchased but required an urgent patch to their BIOs.

Required Steps

  • Decrypt/suspend BitLocker in order to install the latest firmware.
  • Install the BIOs
  • Reboot device
  • Turn on BitLocker

Once the device has again checked in for its Device Compliance Policy, both Encryption of data storage on the device and Require BitLocker should be compliant.

Regards,
The Author – Blogabout.Cloud

Removing the need for Windows Group Policies using the capability of the Microsoft Cloud.

Removing the need for Windows Group Policies using the capability of the Microsoft Cloud.

Back in July Microsoft announced that it is now possible to configure enrolled Windows 10 devices with Administrator templates that are very similar to Windows Group Policies. Since this announcement Microsoft has made further progress introducing administrative templates for Windows, Office and most recently Edge.

Microsoft Endpoint Manager is becoming more common as businesses around the globe adapt, adopt and migrate more of their workloads to the Microsoft Cloud.

Let’s dive into the reasoning for removing Windows 10 Group Policies and adopting Administrative Templates from Microsoft Intune. One of the most valuable things that any business can do is enrol their Windows 10 devices in Microsoft Endpoint Manager as it provides a lot of additional functionality which cannot be deployed using the conventional on-premises infrastructure.

This modern management of Windows 10 allows businesses to apply policies to devices that may not be connected to the corporate LAN but have an internet connection. This provides the protection, configuration and compliance to the end-user device whether they are in or out of network.

I have been working with several customers recently who have seen huge value from moving their group policy objects (GPO) to Administrative Templates. Many of the organisations deployed legacy or out of date group polices to their end-users which are not needed and in some cases cause a security hole within their Windows 10 build.

Adopting Microsoft Endpoint Manager allows businesses to evaluate their GPO structure and condense their requirements. Condensing your GPO’s with administrative templates is just the start of the journey to modern management.

  • Do you deploy applications via GPOs?
  • Do you deploy registry keys via GPOs?

If you do, these can also be delivered using the power of the Microsoft Cloud and specifically Microsoft Endpoint Manager. I have recently been deploying a large number of core applications to Windows 10 including reg key modifications using a PowerShell script from within the MEM portal. So as soon as the Windows 10 device is enrolled and has an internet connection, all applications and policies are configured with the devices regularly poling for any updates/changes made within the Intune portal.

So isnt time you investigated what Microsoft Endpoint Manager can do for you today?

Regards,
The Author – Blogabout.Cloud

Do you have Device Writeback enabled on Azure Active Directory Connect? Do you know how to check if a device has been written back?

Do you have Device Writeback enabled on Azure Active Directory Connect? Do you know how to check if a device has been written back?

I have been recently working with a customer and errors within AAD look which pointed to an issue with Device Writeback not being enabled on Azure Active Directory Connect.

But how do you check if the device is writing back? Well, I’m glad you asked. First of all, we need the Device ID which is obtain running a cmd via command prompt.

dsregcmd /status

Once you have this information you will need to run the following command using PowerShell on one of your domain controllers.

$deviceid = “Enter ID here”
Get-ADObject -LDAPFilter “(cn=$deviceid)” -SearchBase = “CN=RegisteredDevices,DC=OfficeC2R,DC=com,”

If you are returned an error i.e Directory Object Not Found. It is safe to say the device hasnt been registered yet.

And its as simple as that

Regards
The Author – Blogabout.Cloud

Isn’t it time you switch gears into Windows Autopilot

Isn’t it time you switch gears into Windows Autopilot

Windows Autopilot has increased popularity over the past 3 years since its release in 2017. As a consultant within the Microsoft Cloud space, I had more conversations with customers about how Autopilot can change who they deploy Windows 10 devices to their end-users.

Being able to deliver a brand new Windows 10 device from the OEM Factory to the end-users desk that is already configured with all the required security policies and applications has to be the biggest selling point.

This post is how we can move to Windows Autopilot in 3 easy steps;

Step 1 – Register Devices

Option 1 – (Recommended) Have devices registered automatically;

– Request clean images, choice of Windows 10 version at the same time (if available) not all OEM vendors are able to provide clean images. A useful workaround for this is getting a Windows 10 script I have seen available to remove bloatware. If you haven’t seen it I have dropped a copy on GitHub.
– Specify group tag to help segment device by purpose (depending on the size of your organisation this may not be a requirement)
-Device are automatically tagged with purchase order ID

Option 2 – (Recommended for Piloting) Register devices yourself via Intune for testing and evaluation using Get-WindowsAutopilotInfo PowerShell script created by Microsoft.

Once you have the required CSV file from executing the script you can manually register the device.

Option 3 – Register (harvest) existing Intune-managed devices automatically. If you are an organisation that has already enrolled your Windows 10 devices into Microsoft Intune you can register all devices for Windows Autopilot.

Step 2 – Assign a profile

Use Intune;
– Select profile scenario (user-driven or self-deploying)
– Configure required settings
-Assign to Azure AD group so Intune will automatically assign to all devices in that group. (I am a big fan of dynamic groups)

Use a dynamic Azure AD group to automate this step
– Consider static Azure AD groups for exceptions

Here are the deployment profiles that can be configured today.

Coming soon

Azure Hybrid AD join for devices that dont have line of sight to a domain controller, this is currently in testing and will use a VPN to call home. The support has been built into Windows 10 1909.

Step 3 – Deploy

Boot up the device or devices

Connect to a network either wired or wireless

Enter credentials if required (credentials not required for self-deployment profiles)

The device will now go away and provision based on your configuration within Microsoft Endpoint Manager, once complete all that is left to say is…

Welcome to Windows Autopilot!!! I will be writing a more in-depth post about Autopilot soon because off the configuration I am currently using for my home devices.

Image result for Welcome computer

Regards
The Author – Blogabout.Cloud

Topology Builder encountered an issue and cannot publish this topology.

Topology Builder encountered an issue and cannot publish this topology.

Note from the field

Recently I encountered the following issue when trying to publish a Skype for Business 2019 topology. Thankfully, this is the first or maybe the last time I have seen this issue.

Error Message

Topology Builder encountered an issue and cannot publish this topology.

Topology Builder has encountered an unexecpted error from Skype for Business Server 2019 Management Shell.

Error Details:
Get-CsManagementStoreLocation did not return a valid connection

To resolve this issue launch Skype for Business Management Shell and run the following cmdlet;

Remove-CSConfigurationStoreLocation

You will now be able to successfully publish your Skype for Business topology without receiving the error you encountered earlier.

Regards
The Author – Blogabout.Cloud

Understanding ProPlus Servicing Models

Understanding ProPlus Servicing Models

Office 365 ProPlus has adopted a servicing model for client updates, allowing new features, non-security updates, and security updates to be released on a regular basis, ensuring your users are always up to date with the latest functionality and improvements.

The client servicing model for Office 365 ProPlus provides options that allow organizations to manage the frequency at which features and updates are deployed using multiple release channels which can be configured for all users or a specific set of users within the organization allowing IT to manage update deployment.

Monthly Channel

The Monthly Channel is made available every month and is targetted to users that want the latest features and updates as soon as they are available.

The Semi-Annual Channel

The Semi-Annual Channel is made available every 6 months, in January/July and is best for organizations that don’t want to deploy the latest features of Office right away or that have a significant number of LOB applications, add-ins, or macros that need to be tested prior to broad deployment. This approach helps to avoid compatibility issues that can potentially stall deployments.

This channel has 18 months of support before the version will need to upgrade to the latest release of ProPlus.

The Semi-Annual Channel (Targeted)

The Semi-Annual Channel (Targeted) enables a group of early adopters who get the latest and greatest features four months in advance of a Semi-Annual release, allowing time for organizations to test the new features and updates. This is available every 6 months, in March and September.

This channel has 14 months of support before the version will need to upgrade to the latest release of ProPlus.

Below is a diagram about how the “Update Model” works.

The three primary Office 365 update channels, showing the relationship between the update channels and the release cadence

Check out my Office Pro Plus Tool Kit script designed to assist with testing and deployments.

https://github.com/TheWatcherNode/blogaboutcloud/blob/master/Get-OfficeProPlusToolKit.ps1

Regards,
The Author – Blogabout.Cloud