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

Managing local admins on Azure AD Joined devices

We've been able to do this for quite some time. We've been able to add individual users as local administrators on Azure AD joined devices. More recently this has become a lot easier. We can now use Azure AD groups to manage this. With Azure AD Premium P1 or P2, you can create a role-assignable group and assign the Device Administrator roles to the group.

There are some additional considerations. Firstly, you can only configure a group to be role-assignable when you create the group. You cannot change this afterwards.

I've created a group called "Local admins test 1". See the configuration "Azure roles can be assigned to the group". I've toggled this to yes.

We're told that we cannot change this setting after the group is created.

Next I've created a group called "Local admins test 2". This time I didn't select that Azure roles can be assigned to the group.

You can see that this setting cannot be turned off after the group has been created.

It can't be turned on either.

Now when I add an assignment to the Device Administrators role, only "Local admins test 1" is available for selection.

Note that you must be a Privileged Role Administrators or Global Administrator to create the group in the first place. 

If you are not then the "Azure roles can be assigned to the group" option is not available (you can't even see it).

Finally this option is only supported for Assigned groups.

Just for kicks I've selected Dynamic User.

However it automatically changes to Assigned and greyed out, once I toggle the option to Yes. 

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

Tips for onboarding servers to Defender for Endpoint

This week is all about Microsoft Defender for Endpoint (MDE). It's very easy to onboard workstations (Windows 10/11) to MDE. Intune does that automatically for you.

Navigate to Endpoint Security > Endpoint detection and response, create the policy and assign to all devices. 

There is a little more to do for servers as they are not supported for enrollment in Intune.

First, how would you know if your server was already onboarded to MDE? Obviously you could search for the server in the Microsoft 365 Defender portal, but how can you tell on the server itself?

Look at the services. If the Windows Defender Advanced Threat Protection Service (Service name: Sense) is Automatic and Running, then the server has been onboarded. The screenshot above shows a server that has not been onboarded. The behaviour and the onboarding steps are slightly different depending on the server operating system.

Note: when you use Microsoft Defender for Cloud to monitor servers, they are automatically onboarded to Defender for Endpoint. For this blog post, I'm assuming you are not using Defender for Cloud. 

Windows Server 2012R2

2012R2 servers do not include Defender Antivirus or Defender for Endpoint natively. You must install the unified Defender solution on these servers.

Onboarding steps are as follows:

• Install the unified Defender client (this is downloaded from MDE portal). This installs Microsoft Defender Antivirus and the EDR sensor. It creates the Windows Defender Advanced Threat Protection Service. The service is not started and is set to Manual.
• Install the unified Defender client update package (KB5005292 - download here). This updates the EDR sensor, which communicates with MDE.
• Run the MDE onboarding script (this is downloaded from MDE portal). This onboards the server to MDE. It starts the Windows Defender Advanced Threat Protection Service and configures it to be Automatic.

Windows Server 2016

2016 servers natively include Defender Antivirus (as long as the Defender feature is added) but not Defender for Endpoint. You must install the unified Defender solution on these servers.

Onboarding steps are as follows:

• Verify that the Defender feature is added and updated. Defender must also be turned on.
• Run updateplatform hotfix (download here from Microsoft Malware Protection Center (MMPC)). This updates Defender to the latest version.
• Install the unified Defender client (this is downloaded from MDE portal). This installs the EDR sensor. It creates the Windows Defender Advanced Threat Protection Service. The service is not started and is set to Manual.
• Install the unified Defender client update package (KB5005292 - download here). This updates the EDR sensor, which communicates with MDE.
• Run the MDE onboarding script (this is downloaded from MDE portal). This onboards the server to MDE. It starts the Windows Defender Advanced Threat Protection Service and configures it to be Automatic.

You will get this error if you don't update the platform before you install the unified Defender client.

Please update Windows Defender Antivirus (KB4052623) to the latest version.

Windows Server 2019 (and 2022)

These servers already include Defender AV and the EDR sensor. The Windows Defender Advanced Threat Protection Service already exists but is not running and is set to Manual.

There is one onboarding step:

• Run the MDE onboarding script (this is downloaded from MDE portal). This onboards the server to MDE. It starts the Windows Defender Advanced Threat Protection Service and configures it to be Automatic.

The steps above can be automated using your server management solution. 

You've now onboarded the server and the Windows Defender Advanced Threat Protection Service is running. Where can you see the onboarding details?

You need to look in the registry. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SenseCM. Here you can see the Tenant ID and enrollment status. You should see EnrollmentStatus = 1.

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

Intune app install failed - an app update is available 0x87D13B9F

I'm working on an iOS management solution for a customer this week involving the integration of Apple Business Manager and Intune. I also integrated Apple VPP with Intune for the deployment of volume purchased apps. Everything was working well until I noticed that some apps were failing. Microsoft Teams and Microsoft OneDrive has reported as Failed (big red icon) in the Intune console, with this error:

"An app update is available. Available apps can be updated using Company Portal and required apps will auto-update on device sync. (0x87D13B9F)".

This wasn't quite right. The apps had installed, but Intune was telling me that there was a new version available. I didn't like the red "failed" icon so I wanted to fix it.

In Apple Business Manager I had a look at Teams and could see that a new version had just been published.

I had configured the VPP token in Intune to automatically update apps, so why did it fail? You can find the answer in the Microsoft docs. 

"By default, Intune syncs with the Apple Business Manager service twice a day".

Therefore the latest version of the app wasn't yet available in Intune. I could just have waited for the automatic sync and this would have just resolved itself. 

A manual sync of the VPP token does the trick.

The new version was automatically installed and reported successful.

This Microsoft doc has further information. 

"When updating a VPP app, it can take up to 24 hours for the device to receive the updated VPP app".

This is more an annoyance than an error, especially when you are doing customer demonstrations, but it is easily solved. 

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

Remove pre-installed HP software during Autopilot

This was a task I was given by a customer recently. They wanted all the pre-installed HP software removed when provisioning HP ProBook 450 G8 laptops using Autopilot and Intune. As I like to tell customers, "if you can script it you can do it with Intune".

This was the list:

1. HP Connection Optimizer
2. HP Documentation
3. HP ICS
4. HP Notifications 
5. HP Security Update Service
6. HP Support Assistant
7. HP Wolf Security

1. HP Connection Optimizer

This one is a little tricky and requires the help of an answer file. I got a little help from Reddit

Create an InstallShield answer file. Copy the text to Notepad and save as .iss file (I called it HPConnOpt.iss)

[InstallShield Silent]

Version=v7.00

File=Response File

[File Transfer]

OverwrittenReadOnly=NoToAll

[{6468C4A5-E47E-405F-B675-A70A70983EA6}-DlgOrder]

Dlg0={6468C4A5-E47E-405F-B675-A70A70983EA6}-SdWelcomeMaint-0

Count=3

Dlg1={6468C4A5-E47E-405F-B675-A70A70983EA6}-MessageBox-0

Dlg2={6468C4A5-E47E-405F-B675-A70A70983EA6}-SdFinishReboot-0

[{6468C4A5-E47E-405F-B675-A70A70983EA6}-SdWelcomeMaint-0]

Result=303

[{6468C4A5-E47E-405F-B675-A70A70983EA6}-MessageBox-0]

Result=6

[Application]

Name=HP Connection Optimizer

Version=2.0.18.0

Company=HP Inc.

Lang=0409

[{6468C4A5-E47E-405F-B675-A70A70983EA6}-SdFinishReboot-0]

Result=1

BootOption=0 

I copied the answer file to Azure storage and generated a shared access signature so that the file could be downloaded from anywhere.

Next is the script (UninstallHPConnOpt.ps1)

invoke-webrequest -uri "https://xxx.blob.core.windows.net/autopilot-scripts/HPConnOpt.iss?MySharedAccessSignature" -outfile "C:\Windows\Temp\HPConnOpt.iss"

&'C:\Program Files (x86)\InstallShield Installation Information\{6468C4A5-E47E-405F-B675-A70A70983EA6}\setup.exe' @('-s', '-f1C:\Windows\Temp\HPConnOpt.iss')

The script downloads the answer file and copies to C:\Windows\Temp. It then executes setup.exe for HP Connection Optimizer and calls the answer file. This uninstalls the app.

To deploy the solution via Intune, copy the script and answer file to a folder. Then create a Win32 app which results in a .IntuneWin file containing both files.

2. HP Documentation

This one is a bit more straightforward. The script sets the location to "C:\Program File\HP\Documentation" and then runs the uninstall command.

Set-location "C:\Program Files\HP\Documentation"

.\Doc_uninstall.cmd

Upload the script to Intune and assign to a group.

3. HP ICS

They're getting easier

$Prod = Get-WMIObject -Classname Win32_Product | Where-Object Name -Match 'ICS'

$Prod.UnInstall()

Upload the script to Intune and assign to a group.

4. HP Notifications

This one is the same format.

$Prod = Get-WMIObject -Classname Win32_Product | Where-Object Name -Match 'HP Notifications'

$Prod.UnInstall()

5. HP Security Update Service

Same format again.

$Prod = Get-WMIObject -Classname Win32_Product | Where-Object Name -Match 'HP Security Update Service'

$Prod.UnInstall()

6. HP Support Assistant

This one is a little different. It's an appx installation. Nicolaj Andersen has an excellent script for removing unwanted built-in appx apps during provisioning, except those that you explicitly whitelist. The script will remove the HP Support Assistant.

7. HP Wolf Security

Same format as before

$Prod = Get-WMIObject -Classname Win32_Product | Where-Object Name -Match 'HP Wolf Security'

$Prod.UnInstall()

These are the settings you need when you are deploying your scripts with Intune.

I hope this helps you and saves you time if have the same task. 

Until next time......