Autopilot - this user is not authorized to enroll (80180003)

I was setting up a new demo tenant for testing this week and I encountered something I hadn't seen before. I had configured an Autopilot solution using deployment profiles but experienced this problem during testing.

I could see that my test device had been assigned a profile.

This was validated when I saw the Company Branding on the test device.

However I received the error:

"Something went wrong. This user is not authorized to enroll. You can try to do this again or contact your system administrator with the error code 80180003".

I'd seen this issue before. There are several reasons you can get this error. Microsoft have a pretty decent article describing it.

https://learn.microsoft.com/en-us/troubleshoot/mem/intune/device-enrollment/windows-user-cannot-enroll

This is an extract from that document:

These errors can result from any of the following conditions:

• The user has already enrolled the maximum number of devices allowed in Intune.
• The device is blocked by the device type restrictions.
• The computer is running Windows 10 Home. However, enrolling in Intune or joining Microsoft Entra ID is only supported on Windows 10 Pro and higher editions. 
• The Microsoft Entra setting Users may join devices to Microsoft Entra ID is set to None, which prevents new users from joining their devices to Microsoft Entra ID. Therefore Intune enrollment fails.

I checked all these conditions and couldn't find the problem.

The user had not enrolled any device previously so that wasn't it.

Windows MDM enrollments are allowed. I don't need Personally owned Windows devices as I'm not using Autopilot Device Preparation.

The device is running Windows 11 Professional.

All users are allowed to join devices to Entra ID.

The troubleshooting article doesn't mention licensing but I checked that too and all was good.

Then I found it. The MDM Authority was set to Unknown. I hadn't been asked to select it when setting up the tenant. I'd never seen this before.

Luckily there are a few ways to fix this. You can use this link to get directly to where you can select Intune as the MDM Authority    

https://intune.microsoft.com/#view/Microsoft_Intune_Enrollment/ChooseMDMAuthorityBlade

Alternatively you can use a Guided Scenario to force the page to show. 

Navigate to Troubleshooting + Support and select Guided scenarios (preview). Click Start.

The Choose MDM Authority page appears. Select Intune MDM Authority and click Choose.

The MDM Authority has been set to Intune.

I could see that reflected in the console. That's more like it.

That solved the problem and I could continue with my testing. 

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

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

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

Autopilot White Glove issue

Windows Autopilot white glove feature has been renamed to Windows Autopilot for pre-provisioned deployment. The pre-provisioning service allows partners or IT staff to pre-provision a fully configured and business-ready Windows 10 PC. From the end user’s perspective, the Windows Autopilot user-driven experience is unchanged, but getting their device to a fully provisioned state is faster.

I recently encountered a problem with the process while deploying Windows 10 v1909. 

This UAC prompt for User OOBE Create Elevated Object Server appeared just after the Device setup phase. 

Clicking No caused a real problem and the process started again, this time getting stuck for hours trying to join the organization. This was never going to work. I could see in the MEM console that the device had joined Azure AD and enrolled in Intune and the apps had successfully installed.

Clicking Yes allowed the process to successfully finish.

The prompt is caused by a setting in the security baseline - Local Policies Security Options > Administrator elevation prompt behaviour. It was configured by default to Prompt for consent on the secure desktop. Changing that to Prompt for consent on non-Windows binaries did the trick and removed the prompt.

Thanks to my former colleague Dan Padgett for figuring that out.

Until next time.....

AutoPilot hybrid - issue resetting devices

Issue

I'm implementing an AutoPilot process for a customer at the moment involving hybrid AAD join of Windows 10 1809 devices (Lenovo T480 laptops). In general the AutoPilot process works. However we ran into trouble when we retired or reset a device that had been previously joined to Azure AD. The behaviour was consistent and the devices never joined AD or AAD.

After sign in the devices were stuck on "Please wait while we set up your device". (The screenshot above shows 1809 VM on the left and 1903 on the right).

After about 30 minutes they would fail with:

“Something went wrong. Confirm that you are using the correct sign-in information and that your organization uses this feature. You can try to do this again or contact your system administrator with the error code 80070774”

This suggested that there was something preventing the Offline Domain Join from completing and the process timed out. I researched the problem and saw that I wasn't alone. Similar issues were reported in the TechNet forums.

https://social.technet.microsoft.com/Forums/en-US/fc2a8b82-7ee2-4e65-9b4a-b4ad4a0e102f/computer-stuck-at-quotplease-wait-while-we-set-up-your-devicequot-when-autopilot-profile-is

https://social.technet.microsoft.com/Forums/sharepoint/en-US/33430c1d-4f41-4e8f-8ace-3125dda40115/intune-hybrid-domain-join-error?forum=microsoftintuneprod

• I made sure that the devices did not still exist in AD or Azure AD but it did not make any difference.
• Also I made sure that the ODJ profile was assigned to a dynamic group of my AutoPilot devices. Remember the solution worked perfectly first time around. It only gave trouble when the devices were reset.
• The AutoPilot device group was based on the presence of the ZTDId attribute.

Workaround

I reached out to the product group and Michael Niehaus gave me some advice. He suggested that only way to get it to reliably work was to remove all the device objects (AAD, Intune, Autopilot) and then re-import the device to Autopilot to start over. He also suggested a possible workaround. Target the Domain Join device configuration policy to "All Devices" instead of AutoPilot devices only as that would help with the ODJ timeout problems. 

That's what I did. I changed the targeting and it worked. The devices joined both AD and Azure AD as normal. Thanks Michael.

I hope this helps you if you find yourself in the same situation. 

Until next time......

AutoPilot CSV file formatting issues

I've been uploading hardware IDs to Intune for my customer so that the devices can be provisioned using AutoPilot and Intune. We create CSV files in batches of 50 and everything has been going well so far. However the process started to fail today.

Intune would not accept the formatting of the CSV files. 

Each row must have a minimum of 3 columns

The formatting looked ok to me though. It was a CSV file of 50 devices created using the -append parameter.

Get-WindowsAutoPilotInfo.ps1 -OutputFile .\batch1.csv -append

The project leverages Microsoft Teams for collaboration and I subsequently discovered that the files had been uploaded to Teams and downloaded again. This must have caused some subtle issue with the formatting. Once I got the original files I was able to continue as normal.

I've also noticed that a simple edit of the CSV file can cause formatting issues. There was a duplicate line in one of the files but simply deleting the line caused an issue.

In the end I uploaded the file with the duplicate and just accepted the import error.

I hope this helps anyone else scratching their head with AutoPilot CSV formatting issues. My advice:

1. Use the original CSV file only
2. Keep editing of the CSV file to a minimum

Until next time....

Deploying Intune Connector for AD with a web proxy

I'm working on a Windows AutoPilot solution for a customer this week. This is a hybrid AD solution and the devices will join both Azure AD and the corp AD. I had previously deployed the Intune Connector for Active Directory for testing purposes and it's pretty straightforward. However it's a little different in an enterprise environment. 

I successfully installed the connector on a Windows Server 2016. However the connector never appeared in Intune. There were many errors in the ODJ Connector event logs

Example

"We are unable to complete your request because a server-side error occurred. Please try again. [Exception Message: \"DiagnosticException: 0x0FFFFFFF. We are unable to complete your request because a server-side error occurred. Please try again.\"] [Exception Message: \"Failed to get a value for Key: OdjServiceBaseUrl\"] [Exception Message: \"The given key was not present in the dictionary.\"

The proxy log files showed no activity so clearly I needed some way to ensure that the tool was directing traffic to the proxy.

This document discusses using the tool with on-premise proxies

https://docs.microsoft.com/en-us/intune/autopilot-hybrid-connector-proxy

However, it’s really not useful as it just recommends bypassing the proxy and configuring the tool (ODJConnectorUI.exe.config and ODJConnectorSvc.exe.config) to do that. We all know that is not practical. Most enterprise customers won’t allow you to bypass the proxy so I needed a way to make the Intune Connector use the proxy.

• Configuring the proxy in IE does not work
• Using “netsh winhttp set proxy” does not work 

Michael Niehaus worked on this and provided the code to add to the config files.

It worked perfectly and the Intune Connector was created (you have to restart the Intune ODJConnector Service).

The documentation will be updated accordingly. 

This is the code snippet that should be added to both the ODJConnectorUI.exe.config and ODJConnectorSvc.exe.config files.

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.net> 

    <defaultProxy>  

      <proxy usesystemdefault="false" proxyaddress="http://contoso-proxy:3128" />  

    </defaultProxy> 

  </system.net>

   <startup>

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />

  </startup>

  <appSettings>

  </appSettings>

</configuration>

 It was good to see successful communication in the event logs

Note:

It is important to include http:// in the proxy address. We didn't at first and we spotted the following in the event logs:

":"We are unable to complete your request because a server-side error occurred. Please try again. [Exception Message: \"DiagnosticException: 0x0FFFFFFF. We are unable to complete your request because a server-side error occurred. Please try again.\"] [Exception Message: \"The ServicePointManager does not support proxies with the xxx.int.domain.com scheme.\"]" 

I hope this helps someone to configure the Intune Connector for Active Directory behind a web proxy.

Until next time....

My favourite new Intune features

Hi all,

I've been quiet on my blog recently as I've been a bit busy with other things. However I have been keeping up with new Intune features as they've been released. There have been so many recently. These are a few of my favourites (in no particular order).

• Enrollment status page - this is a big one that we've been waiting for. We can now can block end users from accessing Windows 10 v1803 until Intune has finished deploying policies, apps, certificates and network profiles (and any other deployments) during the provisioning of AutoPilot devices. 

• MacOS - we can now upload MSIs and deploy to MacOS.

• Advanced Threat Protection - ATP and Intune are now fully integrated so we can create conditional access policies to control access to corporate resources based on ATP "health".

• Deleting devices - we can now delete a device from Intune without first having to remove company data or factory reset the device.

• Play sounds on iOS when in Lost mode - we can force supervised iOS devices in Lost mode to play a sound, which continues to play until the device is removed from Lost mode, or a user disables sound on the device. Pretty cool.

Normal blogging service will resume shortly. Until next time.......

What's new with Windows AutoPilot?

There have been a few recent developments with Windows AutoPilot so I wanted to take a closer look. You can read my original experience with AutoPilot here

New version of PoSH script

Version 1.3 of the Get-WindowsAutoPilotInfo script has been published

I decided to have a look through the versions to see the history of changes

V1.0
The original script was version 1.0

Syntax:

.\Get-WindowsAutoPilotInfo.ps1 -ComputerName <ComputerName> -OutputFile .\ComputerName.csv

Output:

Details captured:

• Device Serial Number
• Windows Product ID
• Hardware Hash

V1.1
The Append switch was added in version 1.1
Additional computer details are appended to the output file instead of overwriting the file.

Syntax:

.\Get-WindowsAutoPilotInfo.ps1 -ComputerName <ComputerName> -OutputFile .\ComputerName.csv -append

Output:

V1.2
The Credential switch was added in version 1.2
This allowed us to add the credentials necessary to connect to remote computers. This switch is not supported when gathering details from the local computer.


V1.3
The Partner switch was added in version 1.3
This allows us to specify that additional details required by the Partner Center are gathered (for use by CSPs). Presumably this will also be required when the OEM Vendors start to upload the computer details on our behalf.

Syntax:

.\Get-WindowsAutoPilotInfo.ps1 -ComputerName <ComputerName> -OutputFile .\ComputerName.csv -Partner

Output:

Details captured:

• Device Serial Number
• Windows Product ID
• Hardware Hash
• Manufacturer Name
• Device model

SCCM Report

The second development involves ConfigMgr. A new report has been introduced in 1802 TP. The "Windows AutoPilot Device Information" report lists all the information that we would normally gather using the PoSH script.

I hope this information is useful. Until next time.......