Intune Patch My PC - Full Guide - Part 1

This article will describe how to setup Intune Patch My PC. This will be a full guide! Because it was such a long blog post, I divided it in parts. Every part will be released day after day.

Situation:

Azure AD Joined Intune managed devices

Target:

Implementing Patch My PC for 3rd party applications and 3rd party applications update management

Patch my PC’s mission is to simplify how enterprises create, manage, update, and deploy third-party applications within System Center Configuration Manager. Our solution is used by over 1,600 enterprises worldwide, helping to maintain applications on over 5 million devices. They also have a public preview running for integration with Intune. In my blog post we will go over this and set it up. You can find more info about Patch my PC on their website. Requirements for running Patch My PC Publishing service:

Microsoft .NET Framework 4.5
Supported Operating Systems
- Windows Server 2008
- Windows Server 2008
- Windows Server 2012
- Windows Server 2012
- Windows Server 2016
- Windows Server 2019
- Windows 10 (x64) – Microsoft Intune only

Prerequisites for running Patch My PC Publishing service:

When using Windows Server operating systems, WSUS should be installed and configured.
If using Windows 10 client for Microsoft Intune only
- Optional feature RSAT: Windows Server Updates Services Tools should be pre-installed

Be sure to check out the new updates blog post from Patch My PC also: https://patchmypc.com/third-party-patch-management-for-microsoft-intune

1. Setting up a Windows 10 VM for the Patch My PC publishing service in Azure

Navigate to the Azure Portal. Click on ‘Resource Groups’. Click on ‘Add’.

Choose a subscription, give the resource group a name and choose a region that fits you best. Click on ‘Review + Create’.

Click on ‘Create’.

It will take only a few seconds for your resource group to deploy. Once deployed, click on ‘Go to resource group’.

Once in your resource group, click on ‘Add’.

Search for ‘Windows 10’ and click on ‘Microsoft Windows 10’.

Click on ‘Start with a pre-set configuration’.

Leave the settings as is, click on ‘Continue to create a VM’.
In the next screen, we have some settings to fill in:
- Subscription and resource group should be filled in already
- Virtual Machine Name: choose a name for your W10 VM
- Region: choose a region that fits your needs
- Size: choose a VM size that fits your needs (D1_v2 size (1 vcpu, 3,5gb memory) should be sufficient) – my choice was Standard F2s_v2 because of COVID-19 issues not letting us spin regular D ones.
- Administrator account: choose an admin name for your VM and choose a password
- Public inbound ports: choose ‘None’
- Save money: choose ‘Yes’. We will license the VM by signing in with a user who has a M365 license and license the machine this way
Click on ‘Next: Disks’

Depending on your choice you can choose Disk type on the next screen. SSD is not really necessary, but choose whatever fits your needs.

Now we can choose our networking settings. For this blog we’ll keep it simple and leave the settings as is. Make sure public inbound ports is still on ‘None’. Click on ‘Next: Management’.

In the management screen, choose the options that fit your needs. Make sure to put ‘Login with AAD credentials’ enabled. Click on ‘Next: Advanced’.

On the Advanced screen, you can choose your VM generation. I choose Gen2 in my blog. Click on ‘Review + Create’.

After the review passed, click on ‘Create’.

Now wait untill it is deployed.

2. Enabling Just-In-Time access

If you’re on Security Center’s standard pricing tier (see pricing), you can lock down inbound traffic to your Azure VMs with just-in-time (JIT) virtual machine (VM) access. This reduces exposure to attacks while providing easy access to connect to VMs when needed.

When just-in-time is enabled, Security Center locks down inbound traffic to your Azure VMs by creating an NSG rule. You select the ports on the VM to which inbound traffic will be locked down. These ports are controlled by the just-in-time solution.

When a user requests access to a VM, Security Center checks that the user has Role-Based Access Control (RBAC) permissions for that VM. If the request is approved, Security Center automatically configures the Network Security Groups (NSGs) and Azure Firewall to allow inbound traffic to the selected ports and requested source IP addresses or ranges, for the amount of time that was specified. After the time has expired, Security Center restores the NSGs to their previous states. Those connections that are already established are not being interrupted, however.

More info about JIT here.

Once deployed go to the VM and click on ‘Configuration’ in the left pane. Click on ‘Enable just-in-time’.

Double check now if the AAD Login Extensions (AADLoginForWindows) have been deployed to your VM. Navigate to your VM and click on ‘Extensions’. If they are deployed you can skip the next steps and move to part 3.

In my case, the extension was not deployed. This still happens a lot. But we can fix this. We’ll just need to provision it manually through Azure Cloud Shell. More info here. Click on the Cloud Shell icon.

Now we can get the command from the Microsoft Docs page I already mentioned above:
- az vm extension set \
  –publisher Microsoft.Azure.ActiveDirectory \
  –name AADLoginForWindows \
  –resource-group myResourceGroup \
  –vm-name myVM
This is how the command looks like for me:
- az vm extension set –publisher Microsoft.Azure.ActiveDirectory –name AADLoginForWindows –resource-group RG_PATCHMYPC –vm-name VMPatchMyPC

Now we can double check again if the extension is provisioned correctly on our VM. Click on ‘Extensions’ again. Now you should see the AADLoginForWindows extension there and it should say as status ‘Provisioning succeeded’.

Now we have to add our user as an ‘Virtual Machine Administrator Login‘. We can do this by clicking on ‘Access control (IAM)’ in the left blade. Then cick on ‘Add’.