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