What do you mean, no GPOs?

I hear this question a lot from customers, usually when I tell them that I don't recommend implementing a hybrid Azure AD join solution with Autopilot. It can be a challenge explaining that they don't actually need an Active Directory domain to manage their endpoint devices and that we can usually match the GPO functionality using cloud management only with Intune. It's not always easy and you have to be creative 😀😀😀. We accomplished that in our most recent Autopilot project.

First and foremost, I try not to fall into the trap of analyzing 20 years of GPOs and attempting to re-create them all verbatim in Intune. Rather I agree the requirements with the customer in advance. I've just successfully delivered one of these projects and I wanted to highlight the more difficult areas. I won't get into the specific details of the configurations, rather I will explain the high level approach in each case. Some things worked well, others didn't, so I had to change my approach as I progressed.

Certificates

It's very easy to deploy user certificates on endpoint devices via autoenrollment GPO and the Certificate Authority. It's not as straightforward to do this via Intune, but it's not too bad either.

We used the following approach to deploy PKCS certificates:

• Exported the root certificate and created a Trusted Certificate configuration profile, assigned to the Autopilot devices.
• Added and configured the Intune connector to an on-premises server.
• Configured a certificate template on the Certificate Authority.
• Created a PKCS certificate profile. This is where it got interesting. The user certificate had to be of a very specific format to be authenticated by Cisco ISE policies, to allow network access. We achieved this by configuring the Subject name format as follows: CN={{OnPrem_Distinguished_Name}},E={{EmailAddress}}

Thanks to my colleague Mark Doyle for working on this piece.

802.1x

Now that the certificates were deployed to the devices, we turned our hand to the 802.1x configuration required for network authentication by Cisco ISE.

I configured a workstation manually with the settings I needed.

On the properties of the network card I enabled 802.1x authentication. This started the Wired AutoConfig service and set it to automatic.  

I chose Smart card or other certificate as the authentication method and selected the Trusted Root certificates. There were a few other settings to configure also.

At a command prompt, I executed the following:

netsh lan show profiles

This told me the interface name. Then I exported the configuration to a profile:

netsh lan export profile folder=PATH_TO_FOLDER interface="INTERFACE_NAME"

This created an XML file in the specified folder, named by the interface name. Then I created a custom configuration profile using the OMA-URI setting and the String (XML file) data type.

 

./Device/Vendor/MSFT/WiredNetwork/LanXML

Two important lines from the XML file were as follows:

<OneXEnforced>false</OneXEnforced>

<OneXEnabled>true</OneXEnabled>

I wanted 802.1x to be enabled and used when it was needed. If it was enforced then users would not be able to work at home.

The approach for the Wi-Fi network was similar but in this case the OMA-URI setting was different:

./Vendor/MSFT/WiFi/Profile/WS-CORP/WlanXml

I assigned the profiles to the Autopilot devices.

Printing

I struggled a bit with printing. As a result of Print Nightmare, non-administrators are no longer able to do the following using Point and Print without an elevation of privilege to administrator:

• Install new printers using drivers on a remote computer or server
• Update existing printer drivers using drivers from remote computer or server

You can read more about this in KB5005652. Now when you manually browse to a printer and try to add the print queue, you are prompted for elevated privileges to install the printer driver. This plays havoc when you are trying to automate the solution with Intune.

You could just disable Point and Print restrictions. However this is very insecure and not recommended. There is a compromise. You should be able to remove the drivers installation restrictions based on printer class GUIDs. 

You need this policy which you can create with an Intune configuration profile (Administrative template):

Computer Configuration > Policies > Administrative Templates > System > Driver Installation > Allow non-administrators to install drivers for these device setup classes.

Enter the following GUIDs:

• Class = Printer {4658ee7e-f050-11d1-b6bd-00c04fa372a7}
• Class = PNPPrinters {4d36e979-e325-11ce-bfc1-08002be10318}

However this still didn't work as expected for me and I was still not able to install the print driers without the prompt for elevation. 

Installing the printer driver manually, I was able to look at the properties of the printer and this exposed a class GUID that I was previously unaware of {1ed2bbf9-11f0-4084-b21f-ad83a8e6dcdc}. I now know that this is for Local Print Queue. I added it to my policy but unfortunately it still didn't work.

Running out of time I changed my approach and decided to pre-install the drivers using a script and Win32 app. Thanks to Rahul Jindal for helping with prndrvr.vbs.

@echo off

mkdir c:\PrinterDrivers\Kyocera

xcopy *.* /h /c /k /e /r /y c:\PrinterDrivers\Kyocera

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs" -a -m "Kyocera TASKalfa 6004i KX" -i "C:\PrinterDrivers\Kyocera\OEMSETUP.inf"

The next step was to add the print queues. W32 app to the rescue again. I was aware that many of the users would be provisioning their devices at home using Autopilot. However the device needed line of sight to the printer in order to add the queue. Therefore I didn't want to add it as a Required app. I made the available app via Company Portal and noted in the description that it should only be installed when in the office. 

Add-Printer -ConnectionName \\PrintServer.domain.local\PrinterName

The script added the print queue.

$printerExists = Get-CimInstance -Class Win32_Printer | Where-Object {$_.Name -like "\\PrintServer.domain.local\PrinterName"}

if($printerExists) {

  Write-Host "Success"

  Exit 0

} else {

  Exit 1

}

The Win32 app allowed me to configured the detection script.

Thanks to Rahul for working on this with me.

Mapped drives

Anoop has a good solution to create mapped network drives without requiring network connectivity to the remote path. This is particularly useful in a scenario where users are provisioning devices at home without any connectivity to the on-premises network or with a VPN connection that may not be available immediately after enrolment. The mapped drives switch from “offline” to “online” when connectivity to the remote path is available. It works really well. 

Try it out.

Anoop has created an ADMX template that can be ingested into Intune using a custom configuration profile and this OMA-URI: 

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/DriveMapping/Policy/DriveMappingAdmx

Launch the local group policy editor and you will find the settings under User Configuration\Administrative Templates\Network Drive Mappings.

Then use another custom configuration profile to actually map the drives using this OMA-URI:

./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/Drive_K

You can't control the order in which policies apply. Therefore the network drives are not always available directly after Autopilot. This is solved by a reboot. 

Applications

It's generally straightforward to configure applications to be installed during Autopilot. I always use Win32 apps exclusively as mixing app types in Autopilot can lead to failures. This is well documented. However the configuration of apps is not always easy. The customer had a GPO for configuring SafeSend. This is an add-in for Outlook that helps prevent misaddressed email or inadvertent sharing of sensitive information. You can download an ADMX template where you can configure the application and license key and that seems to work very well with devices that are domain-joined.

Fortunately Intune provides a method of importing our own custom ADMX files, which were provided to me by SafeSend. Of course my first attempt at importing the ADMX file failed. 

"The upload of this ADMX file has failed. To continue, you need to delete this upload, address the action in the error details and try again".

Error Details 

"ADMX file referenced not found. NamespaceMissing:Microsoft.Policies.Windows. Please upload it first".

If you upload an ADMX file without the dependency, an error message will list the missing namespace. 

To see any namespace dependencies, open the ADMX file and search for "using prefix". Any dependencies will be listed. This is quite common and it's often because Windows.admx is missing. Download the latest administrative template for Windows 10, extract Windows.admx and import that.

That worked and I was able to import SafeSend.admx.

This allowed me to create a SafeSend configuration profile using Imported Administrative templates.

I could configure and deploy the SafeSend settings. This worked and I could see the applied setting on my Windows 10 and Windows 11 test devices.

However the success was short-lived. The policy started to fail on Windows 10 only.

• Error code: 0x20101
• Error details: The administrative template file failed to be sent to the device  

Rudy Ooms has a great post for troubleshooting ADMX imports but I had project deadlines so I decided on another approach and kept it simple.

I noticed that all SafeSend configurations were written to the registry at [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\SafeSend]. I exported this key to a .reg file and used regedit.xe and Win32 app to import the registry key to the Autopilot devices.

MD C:\Windows\Temp\Safesend

Copy "%~dp0*.reg" C:\Windows\Temp\Safesend /Y

Copy "%~dp0*.txt" C:\Windows\Temp\Safesend /Y

PUSHD C:\Windows\Temp\Safesend

regedit.exe /s Safesend.reg

The reference to .txt was to create a detection method for the Win32 app using a "detection file". I didn't want to use the SafeSend registry key as my detection method as I was told that I'd have to make a change in the near future.

The moral of the story 

"Win32 apps are your friend" and "friends don't let friends do hybrid". 😄😄

 I hope this helps. Until next time.......

Windows 10 devices not enrolling in Intune

This is just a quick post to describe a customer issue I encountered this week. Customer had previously configured Azure AD Connect and all devices were hybrid joined. They had just implemented a GPO to enrol the devices into Intune

Administrative Templates > Windows Components > MDM > Enable automatic MDM enrollment using default Azure AD credentials

However no devices were enrolled.

I looked a the event viewer on one of the devices and this told me where the problem was. In the DeviceManagement-Enterprise-Diagnostics-Provider log I saw this error

Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0x8018002b)

I figured that this was nothing to do with credentials but was caused by the user not being assigned a license. I was half right. The user had been assigned a license but it was a standalone Intune license. This is not enough for automatic Intune enrollment, that also requires an Azure AD Premium P1 license. I explained that it was still possible to enrol each device manually, but advised that wasn't a sustainable approach. 

Customer cancelled the Intune licenses and EM+S E3 licenses were provisioned. Problem solved and devices are now being automatically enrolled.

Moral of the story: Standalone Intune licenses are not recommended. You "may" get away with them if you are just managing mobile devices (Android & iOS), but not when you are managing Windows. EM+S or M365 is recommended.

Until next time....

Disabling screen rotation on Windows tablets with Intune

I had a recent requirement to disable screen rotation for Windows tablets. 

This is easy to do within Windows. There is a Display setting to turn on the Rotation lock. However, I had to automate this using Intune. There doesn't seem to be a Windows CSP for this so it's not possible to use a custom OMA-URI policy. 

However, this is something you can do by configuring the registry. If you navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AutoRotation you'll see that the Enable key is set to 1. This needs to be changed to 0 to disable screen rotation. This is easy to configure with a PowerShell script:

New-ItemProperty -Path Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AutoRotation -Name Enable -Value 0 -Force -PropertyType DWord

Once you have the script, upload it to Intune. Select Devices > Scripts > Add (Windows 10 and later). Choose the script location and configure the following:

• Run this script using the logged on credentials - NO
• Enforce script signature check - NO
• Run script in 64 bit PowerShell Host - YES

Assign the script to a group of Windows tablets and screen rotation will be disabled.

I hope this helps. Until next time......

We can't activate Windows on this device

I encountered this problem recently while carrying out Windows 10 Autopilot testing on a customer site. My test device would step up from Windows 10 Professional to Enterprise but would not activate.

I could see the error: We can't activate Windows on this device as we can't connect to your organization's activation server. Error code 0x8007232B.

Running slmgr /dli on the device showed me that the currently installed operating system was expecting to be activated using volume licensing (MAK key). This isn't expected when provisioning devices directly from the vendor through Autopilot. However this was a test device so I figured it was re-imaged in the past.

Running wmic path SoftwareLicensingService get OA3xOriginalProductKey from a command prompt gave me what I needed. This displays the Windows product key embedded in the computer’s firmware. This is the original Windows key that shipped with the device.

I selected Change Product Key at the Activation window.

I entered the original product key and clicked Next.

I clicked Activate.

Windows was activated with a digital license. We wouldn't normally expect to see this problem with devices shipped directly from a vendor. However it could come in handy during customer testing in order to validate the process.

Until next time....

Locating a Windows 10 device with Microsoft Endpoint Manager

This is my favourite new feature in the 2104 service release of Microsoft Endpoint Manager (formerly Microsoft Intune). We have been able to do this with iOS devices for quite some time. I remember Peter Daalmans and I demonstrating the feature at MMS in 2019. Now we can locate Windows 10 devices in the console.

There are two prerequisites before you can use this feature with Windows 10 devices.

Location Services

First you must turn on Location Services on your devices.

You can create a custom configuration policy to do this using the following OMA-URI 

./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessLocation

Configure an integer with value of 1 to forcibly turn on location services.

You could also create a configuration profile using the Settings catalog. In the Privacy category, choose Let Apps Access Location.

Location services are turned on. This is what it looks like on a test client.

Minimum operating system version.

This feature is only supported on the following Windows 10 versions:

• Windows 10 version 20H2 (10.0.19042.789) or later
• Windows 10 version 2004 (10.0.19041.789) or later
• Windows 10 version 1909 (10.0.18363.1350) or later
• Windows 10 version 1809 (10.0.17763.1728) or later

How to locate a Windows 10 device

In the MEM console, select Devices > Windows devices. Click on the device you want to locate. Click on the three dots on the Overview page.

This is my test client. Locate device seems to be greyed out. What could be wrong?

Ah, I see why. It's an unsupported Windows 10 version. This device is 10.0.18363.418 but must be a minimum of 10.0.18363.1350.

I updated the device.

Now the Locate device feature is available. Click Locate device.

You are presented with a warning about local laws and regulations around location data. Essentially there are privacy concerns. You're told that Intune will only retain the location data for 24 hours. 

A Bing map opens with the status Locate device pending.

Within a minute my test device was located and it's location was displayed. This is the Road view.

Click on the drop down arrow in the top right corner to choose the Aerial view. There is also a Bird's eye view but that wasn't available to me.

You can use the + and - buttons to zoom in and out.

This is a great view of the device location. I can see that the street names appear in the Irish language as well as English. I'm not sure where that setting comes from. Also, the location of the device is in the right area but it isn't 100% accurate. You can read more about location services here

Back in the console you will see the status change to Locate device: Completed.

On the device the user is notified that the location of the device has been accessed by the organization. That is crucial for transparency.

I hope this blog post has been useful. Until next time.......

Tip for capturing custom Windows 10 multi-session image for WVD

Azure gives us a nifty feature for capturing images from virtual machines. The high-level process is as follows:

• Create the VM with Windows 10 multi-session
• Install apps and customize
• Snapshot the VM for future use
  
• Sysprep and generalize the image
• Capture the image
• The image is then available in the gallery for creating WVD host pools
  

You'll find the capture feature in the Overview of the VM. Note that the capture renders the VM unusable and you can check a box to automatically delete the VM. If you want to revert you will have to create a new VM and apply the snapshot.

That all sounds great so what is the problem? The problem is actually a well known issue with capturing custom Windows 10 images. If you allow the reference computer (often a Hyper-V VM) to connect to the internet then the device can connect to the Windows 10 Store and update the built-in apps. This can cause Sysprep to fail. 

Sysprep fails after you remove or update Microsoft Store apps that include built-in Windows images

The easy way around that is to remove the NIC from the VM so that this cannot happen. 

However what can we do in Azure? You can't remove the NIC as you wouldn't be able to access the VM in that case. 

This is the Sysprep error I was seeing on my Azure reference computer. 

SYSPRP Failed to remove staged package Microsoft.PPIProjection_10.0.18362.449_neutral_neutral_cw5n1h2txyewy: 0x80070002.[gle=0x00000002]

I needed to prevent internet access but still maintain network access. DNS to the rescue. Normally a VM inherits DNS settings from the virtual network. However you can configure a custom DNS server for any VM. If you configure a DNS server that doesn't exist then the VM will not be able to access the internet but you still retain network access.

Click on the network interface for the VM.

 

You'll find that in the Networking blade.

Configure the dummy DNS server. Remember you have to be quick. Do this as soon as the VM is created. This worked for me and I was able to successfully syprep and capture the image. 

I hope this helps. Until next time........

Windows Virtual Desktop - AD join account requirements

It took me a while to figure out why my customer deployment of a WVD host pool would not work. Everything looked normal to me. The problem was that the VMs could be created but could not be joined to the domain (remember all Windows Virtual Desktops must be domain joined). Eventually I tracked down the problem to the domain-join account. This made me look more closely at the requirements for this account, so here we go.

What is the WVD domain-join account? 

This account has to be entered during the provisioning of a WVD host pool.

One of the required items is the AD domain join UPN. This is the account that will be used to join the VMs to your on-premises Active Directory. If you look at the tooltip you will see the following text:

"UPN of an Active Directory user that has permissions and will be used to join the virtual machines to your domain. For example, vmjoiner@contoso.com. A local user account with this name will be created on each virtual machine. Do not enter a user who has MFA enabled. See https://aka.ms/vmUsernameReq for invalid usernames".

There are a few takeways here.

• the account must have permissions to join AD (this is obvious)
• a local account is actually created on each VM
• the account cannot be MFA enabled
• take note of the URL for invalid usernames (see next section)

Requirement #1: MFA cannot be enabled on the WVD AD join account. 

(tip: you should create a service account for this).

Invalid usernames

The official WVD docs don't tell us much about the requirements for this account.

"Enter the user principal name and password. This account must be the domain account that will join the virtual machines to the Active Directory domain. This same username and password will be created on the virtual machines as a local account. You can reset these local accounts later".

However there are some specific requirements around invalid usernames, which are actually enforced by Azure (this was my problem). You can find them in the Azure VMs FAQ docs 

These are the blacklisted usernames. There are a number of popular contenders in there.

Requirement #2: the username cannot be one of the blacklisted usernames.

Password

You will find the password requirements in the same doc

Requirement #3: in general the password must be complex with a minimum of 12 characters.

I hope this helps you when implementing WVD. Until next time.....

LAPS not working after computer rebuilds

Many of my customers use the Microsoft Local Administrator Password Solution (LAPS) to manage local account passwords of domain joined computers. Recently I created a Windows 10 v1909 task sequence solution with ConfigMgr for one of these customers. Everything looked good in testing but after a few days I got a report to say that LAPS wasn't working. Admins couldn't sign into the devices uing the local administrator password.

I figured that was unusual so I reinstalled W10 v1909 on a test laptop and LAPS worked perfectly. That was a bit odd. What was the difference between my test and the customers test?

You have to delve a little deeper into how LAPS works to be able to answer that question. This Microsoft blog post explains what happens to LAPS during machine reinstalls.

“LAPS uses the attribute ms-MCS-AdmPwdExpirationTime on the computer object to remember the expiration time of local administrator password. It works pretty well during lifetime of computer. But what happens when computer is reinstalled? LAPS design expects that in this case, computer account is deleted and created again. But what if you decide to reuse computer account?

In this case, when you install the computer and then install LAPS CSE on it, during first GPO refresh after install, CSE looks to computer account and sees that it is not time to reset password yet: ms-MCS-AdmPwdExpirationTime attribute still has value populated by previous computer that used this computer account. This means that the password that is on local administrator account after setup may be there until the password expiration time set by previous computer expires: up to 30 days by default”.

That explained to me why my test computer worked and none of the others did. I ALWAYS delete the computer object from ConfigMgr and Active Directory before I re-image. The customer verified that they didn't do this for any of their tests.

The customer wondered why this not happen before. I explained that it did occur but they didn't notice as they didn’t test LAPS immediately. The solution corrects itself after the password expiration date.

It's easy to verify that this is happening:

I generated the password on 10th Feb but it was set to expire on 12th Feb. That was my first clue. The password should have been valid for 30 days.

I hope this helps you to explain the anomaly if you encounter it. It's expected behaviour. 

Until next time....

Note: several people have pointed out to me that it's better to automatically expire the existing password during the rebuild by including this script in the task sequence.

Windows 10 search broken after in place upgrade

I had this scenario last week and it was difficult to find the solution. After an in place upgrade from Windows 10 v1709 to v1809 (using a ConfigMgr in place upgrade task sequence) the search function was broken. I couldn't even type anything to search. I couldn't find anything similar online so I was a little stuck. Although there was an easy fix I needed to be able to apply it programatically.

The fix was to reset the Cortana app but I couldn't do this programatically in the task sequence. 

• the issue only occurred during in place task sequences (1709 -> 1809). It did not happen for bare metal builds.
• it only happened with existing profiles on a machine. New profiles were fine.
• the 1809 wim had the latest SSU and CU.

At first I thought it couldn’t be a group policy problem as it only affected in place upgrades. However then I noticed that it only happened with existing profiles and that made more sense. I tested with an OU blocked for inheritance and the issue didn't occur so I waded through all the customer GPOs.

The issue was solved by reverting these two settings that the customer had disabled: 

Computer Configuration\Administrative Templates\Control Panel\Regional and Language Options\Allow users to enable online speech recognition services

Computer Configuration\Administrative Templates\Windows Components\Search\Allow Cortana

I hope this helps someone else who encounters the same issue. Until next time....

Windows 10 v1909 and language packs - my experience

I've been working with Windows 10 v1909 and language packs for the first time this week. This used to be pretty easy with 1809 and Microsoft Endpoint Manager (formerly ConfigMgr or SCCM) but it's not so easy any more.

• Download the ISO matching the Windows version
• Extract the CAB files
• Install the one you want in the task sequence (dism.exe /norestart /online /add-package /packagepath:xxxx.cab)
• Apply regional settings with an xml file (e.e. rundll32.exe shell32,Control_RunDLL intl.cpl,,/f:"English_UK.xml")

What do we do now with v1909? I can see that 1909 has nothing new so we use the 1903 media, but which one? As well as the LXP files we can still download the .cab files as before. They are included in the Windows 10 version 1903 Language Packs (released May 2019) 32/64 MultiLanguage ISO (5852MB).

Tip: choose MultiLanguage as the language using the drop down menu.

I downloaded this ISO, extracted the cab files and organized them in folders (in the same way I had done for 1809, making sure that the files had the same name). Then I created packages (without programs) using these folders as source files. I "figured" that I just had to replace these packages in my existing 1809 task sequence and all would be good.

However it wasn't. In my testing, this breaks the search function and messes up some dialog on the regional settings

The search bar wouldn't work at all. I couldn't even type in it. That was a showstopper straight away. 

Also the regional settings contained a lot of garbage.

I did some research and others seemed to be having similar problems with no real resolution. 

Eventually I got this working by adding a step in the task sequence to install the January 2020 CU for 1909 before installing the language pack. 

KB4528760

Search bar now working......

....and this is how the Regional settings should look.

I hope this helps you if you encounter the same problem. Until next time.....