Trying out Scappman – Automated Third-Party patching in Intune

Scappman is a cloud only solution that automates the installation and updating of applications within Microsoft Intune. Over 400 different third-party applications are supported as of today. In this blog post, I will take a look at setting up Scappman and trying out the service as an automated solution for third-party patching within Intune. Basically, Scappman is installed as an enterprise application (Azure AD) in your tenant and the service principal then needs several Microsoft Graph permissions to do its job in Microsoft Intune.

Initial Setup
I headed to the Scappman portal and registered a trial.
I authenticated with a Global Admin Microsoft Account from my tenant and Scappman requested several permissions which I reviewed and then granted to the application.

Scappman requires the following permissions:

Microsoft GraphMaintain access to data you have given it access toDelegated
Microsoft GraphSign in and read user profileDelegated
Microsoft GraphRead and write all groupsApplication
Microsoft GraphRead directory dataApplication
Microsoft GraphRead and write Microsoft Intune devicesApplication
Microsoft GraphRead and write Microsoft Intune appsApplication

Adding Applications to Scappman
At this time of writing, Scappman supports over 400+ third-party applications.
Lets look at Adobe as an example. The following Adobe Applications are supported today:

As an example, let’s install Adobe Acrobat Reader DC. I have customized the displayname with my own Prefix called “Global”. Default, pressing install would assign the application as required to All Computers.

Since Scappman can read Users and Groups from Azure AD we can also select a specific user or a group for the application assignment (excellent for testing purposes for example). For the group assignment we can select a single group or multiple groups and select if the assignment should be include or exclude, per group.

If we select Advanced we get several more useful deployment options. For example, we get the option to specify our own custom pre-install commands if we need to do anything specific before this application deployment is installed.

In this case, I want to make sure other non-managed versions of Adobe Reader already installed in the device gets uninstalled prior to Scappmans deployment. This is provided for us by Scappman as a default pre-installation command.

As I mentioned before, default of an application deployment in Scappman is required but we can change this to available if needed instead, which also lets us decide if we want future updates of the application to arrive to All Users, All Devices or only the specific assigned group we assigned before. When everything we want is selected, press Install to start the provisioning of the application.

Viewing Installations, we can now see that the application deployment is being prepared.

Selecting the application will provide more details about its version, if updates are enabled and current assignments.

Editing of the application is also possible from this view if needed.

Navigating to Microsoft Endpoint Manager, the initial application and it’s update deployment has been created and assigned.

Viewing Global – Adobe Acrobat Reader DC in MEM, we can see what Scappman created for us, including it’s install/uninstall commands and detection methods.

Before installation I wanted to add the Microsoft Information Protection plugin as a dependency to Adobe Reader.
I added MIP Plugin for Acrobat Reader DC and selected the newly created Global – Adobe Acrobat Reader DC as dependency.

As seen below several Scappman published applications arrived in Company Portal.

I selected the MIP Plugin for installation and because of the dependency both Adobe Acrobat Reader DC + MIP Plugin got installed successfully.

For troubleshooting purposes logs are available at C:\ProgramData\Scappman\Logs.
According to the documentation Scappman collects logs for the IT Admin to view when an installation has failed.

To change the branding of Scappman from the default values, navigate to Settings / Branding and there we can easily change the Intune publisher name and also add the organizations own logo for the prompts issued by the Powershell App Deployment Toolkit.

Naming Convention
Scappman supports adjustment of prefix, postfix and custom naming on the different release rings of an application deployment.

Notifications & Reporting
When Scappman automatically have updated an application, this can be notified via email today. Hopefully in the future webhook-functionality gets implemented for Scappman so that this type of notification can arrive in for example Teams.

As an overview, the amount of application installations, computers and subscribed applications through Scappman can be viewed at the built-in Dashboard.

Overall status of all Applications published through Scappman is available under Reports. Here, version and amount of installed, failed, postponed, pending and other status values of application deployments can be viewed.

Existing Applications on Intune managed devices
Scappman cannot automatically detect existing applications from your Intune managed devices unless the application deployments are managed by Scappman. Hopefully this functionality gets added in the future, but as of now you need to know that a device has an older version of Adobe Reader for example and that can then be replaced with a Scappmans deployment which then gets automatically updated in the future.

Pricing of course depends on the size of the environment, but the current target price is 1€ per user per month. What I personally am hoping to see in the future is more reporting functionality and also integration with existing application deployments in Intune, all of the features launched and in development can be viewed at Scappmans Roadmap. Based on my testing Scappman is easy to setup, has fairly good support in terms of its application library and several customizable options for deployments. That Scappman is 100% Cloud only is a big plus. Suitable for small to mid cloud only environments where Intune is used, implementing the product could easily save lots of hours in terms of manual labor as long as the applications in use on the endpoints are supported by Scappman. 


Passwordless Authentication, Part 2: Temporary Access Pass, Security Key enrollment & Windows-Sign in

In my previous blogpost I demonstrated a basic enrollment of Passwordless authentication
into Azure AD with a FIDO2 Security Key.

Generally speaking, common use cases for FIDO2 certified hardware keys are as follows:

  • Strong Authentication
  • Securing Privileged Accounts
  • Passwordless Authentication
  • Shared Devices
  • Personal Security (Cloud Storage, Password Managers, Social Accounts)

In this post I will focus on provisioning Temporary Access Pass to end users for them being able to add a FIDO2 Security Key as Authentication Method for themselves in Azure AD.
FIDO2 Security Key can then be used as strong authentication during Windows Autopilot enrollment and is an alternative when mobile devices isn’t an option as MFA method.
Finally I will demonstrate that from there, the end user can either:

  • Provision their credentials into Windows Hello for Business (Security Key as MFA method)
  • Use FIDO2 Security Key as Sign-In method into Windows (recommended for a shared device)

Part 1. Temporary Access Pass and FIDO2 Security Key Enrollment

To provision a Temporary Access Pass we need to be able to enable the method and target it to a group (or All Users). This is done in Azure Active Directory \ Security \ Authentication Methods

We should note here that the properties and lifetime of the TAP-method can be adjusted as seen on the screenshots below. In my example I configured it like this:

When the method is enabled and targeted, we can add a TAP to a user graphically in the Azure Portal.
Select the user and Authentication Methods then select Add authentication method.

Select Temporary Access Method (preview) as method, then select Add.

The details are then provided for us and the next step should be to send the information to the end user for registration.

We can also provision TAP with Powershell instead of the GUI. See the example below:

# Install module
Install-module Microsoft.Graph.Identity.Signins -Scope CurrentUser
# Connect to Microsoft Graph API using Device Authentication and with correct API permissions
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
# Switch to beta API
Select-MgProfile -Name beta
# Specify User ID (Object ID in Azure AD on the User Object)
$UserID = "ABC123-b688-0000-1111-2b6afd1bf95f"
# Show TAP for Specific User
Get-MgUserAuthenticationTemporaryAccessPassMethod -UserID $UserID
# Create a TAP (one-time use), valid for 30 minutes
$TAP = New-MgUserAuthenticationTemporaryAccessPassMethod -UserID $UserID -IsUsableOnce -LifetimeInMinutes 30
# View the newly created TAP
view raw gistfile1.txt hosted with ❤ by GitHub

Part 2. Use TAP as Sign-in for enabling strong authentication method (FIDO2 Security Key)

The end user navigates to My Security Info and then enters their email.

Instead of being prompted for their password, the end user will be prompted to enter their Temporary Access Pass instead.

successful!

Let’s add Security Key as authentication method. Select Add method, choose Security key and click Add.

Select the type of the security key-

Insert the Security Key into the PC, then select Next.

Verify with OK, twice.

Time to create a PIN for this security key.

Verify with OK.

Finish the setup by touching the security key.

Finally, the end user needs to name the security key.

All Set!

We see that Security key now is available as an authentication method besides Temporary access pass.

Part 3. FIDO2 Security Key Sign-In, Autopilot Enrollment and Windows Hello for Business Provisioning

The end user has a new Windows 10 device which is in Windows Autopilot and the end user has access to the newly enrolled Security Key. Computer is powered on and the end user goes through the initial OOBE-steps until the end user arrives at the Sign-in.

Insert the security key into the PC. Here, the end user selects Sign in with security key. The end user then enters their security key PIN. And confirms their presence by touching the security key.

After successful Sign-In, Autopilot Enrollment is initiated.

Scenario A – Personal Device (WHfB Enrollment)
If the user or device is targeted with a Windows Hello for Business-policy (from MEM) the WHfB Enrollment will initiate usually at next Sign-in. This is the most suitable authentication method if the device is a personal device. When the Autopilot provisioning is done, the end user is prompted for setting up Windows Hello for Business.

Windows Hello for Business enrollment is initiated and since the PC has fingerprint sensor that method is presented first.

The end user then sets up the PIN for WHfB, encrypted and safely stored locally in the PCs TPM chip.

Success! Enrollment and Sign-In without using a password!

Scenario B – Shared Device (FIDO2 Windows Sign-in)
When the Autopilot provisioning is done (and Windows Hello for Business-policy is not targeted at the user), the end user can now Sign in into Windows with their Security Key instead of a password. This is the ideal authentication method when the device is shared or when mobile devices isn’t an option as MFA method.

The end user selects Sign-in options, then selects FIDO security key and inserts the key into the PC.

Enter PIN, then touch the security key.

Success! Enrollment and Sign-In without using a password!

For Passwordless Sign-In into Windows, see these Specific requirements for Azure AD Joined and Hybrid Azure AD Joined devices. If the device is using Windows 10 version 1903 or higher the end users themselves can adjust their security key biometric, PIN or reset their security key.
Windows Settings > Accounts > Security Key

As noted on Known Issues, administrator provisioning and de-provisioning of security keys is not yet available. However, we can at least as administrators remove the authentication method In Azure AD.


Passwordless Authentication, Part 1: Azure Active Directory & Yubikey

Passwordless Authentication today can be achieved using different methods towards different services. There has been work going on for several years now between different companies and vendors to establish a new authentication standard where goals have been to increase both security and productivity. This standard is called FIDO2 and has been established by what is called the FIDO Alliance. https://fidoalliance.org/fido2/

Quickly explained, FIDO2 is a combination of the two protocols called Client to Authenticator Protocol (CTAP) and WebAuthn. Basically the standard allows organizations to utilize a standard for signing in to their resources, without username and password and instead use an external security key.

Azure Active Directory & Yubikey

In the following example I will focus on Azure Active Directory as the IDP and Yubico as the provider for the hardware based key which will be used for attestation and authentication. One thing to note here is that Microsoft requires specific optional extensions which hardware vendors need to implement into their hardware keys for them to be fully secure and compatible with Azure Active Directory.

Yubico’s keys are neatly called YubiKeys. They come in different flavors and they support hundreds of different services, products and applications. Each key supports multiple methods for authentication. They are batteryfree and utilizes asymmetric cryptography (public and private key cryptography). In the following example, I selected YubiKey 5C Nano which is part of the Nano-series and meant to be attached into the device all the time connected to a USB-C port. There are other variants aswell, for example the YubiKey 5 NFC which is shaped more like a tradtional key and can be used both in a PC or a Mobile Device (using NFC).

YubiKey 5C Nano

It’s length is just above 1 centimeter and it’s 0,5 centimeter wide. As you can see connected to my computer it’s very small.

Surface Book 3 with YubiKey 5C Nano

Common use cases for FIDO2 certified Keys are:

  • Strong Authentication
  • Securing Privileged Accounts
  • Passwordless Authentication
  • Shared Devices
  • Personal Security (Cloud Storage, Password Managers, Social Accounts)

Setting up a Security Key for an end user in Azure Active Directory

Before we actually can use a FIDO2 Certified key as a Passwordless method in our AzureAD-tenant, we need to make sure the following technical pre-requisites are in place:

To get started when the methods are available for the end users, navigate to this URL to start the process:

  1. The end user signs in with their credentials. When the page has loaded: Add Method
  1. And then we select security key as method
  1. Press Add
  1. Confirm with Next
  1. Press Next and setup Azure MFA for the end user.
  1. When the MFA setup is complete, now when you Add method again we can select between two types of security keys. Since I’m using YubiKey 5C Nano, I select USB device .
  1. Then we should be ready with our Security Key. Press Next
  1. We are then redirected to the Security Key setup. Press OK.
  1. Confirm with OK.
  1. Let’s create a PIN for the security key, then press OK.
  1. Touch the security key.
  1. Success! Enter a name for the security key, press Next.
  1. Finished! Press Done.

to Microsoft 365 using a Security Key

  1. Let’s sign in to Microsoft 365 as our next step. We start by navigating to the URL (https://portal.office.com) and then clicking on Sign-in options.
  1. Select, Use a security key.
  1. Select Credential, in this case select Security key
  1. Enter the PIN, press OK
  1. Touch your security key.
  1. Sign-in successful!

Technical Details – Authenticator Attestation GUID

Based on the FIDO 2 specification, each security key provider needs to include a specific GUID used for the each key during it’s attestation.
The Authenticator Attestation GUID aka AAGUID is a 128-bit identifier indicating the key type (make and model).
This AAGUID must be identical between all similar keys (make/models) but different from all other AAGUIDS.
The reason for that is to make sure that the requirements of the specification are met and the respective key types security not tampered with.

To view details of a specific registered FIDO2 security key, we navigate to Azure Active Directory, Users then select a specific user. Then select Authentication Methods.

If we then click on the three dots to the right on the FIDO2 security key, we can view the security key details and it’s AAGUID.

Getting started with Intune App Protection and App Data Protection configuration framework

In this blog post I will go through the basics of App Protection Policies in Intune, the App Data Protection configuration framework and guide you in how to import related data-protection templates for Intune App Protection into your Intune tenant.

App Protection Policies

Configuring App Protection policies in Intune is important to protect data and prevent data leakage on both corporate and BYOD-devices within supported applications. Categories include Data Protection (Data-transfer, restrictions, encryption), Access Requirements (authentication access settings) and Conditional Launch (app and device conditions). 
One requirement of using these policies is that the applications are integrated with Intune SDK or wrapped by the Intune App Wrapping Tool. The current list of supported Intune protected apps can be found here.  

Require approved client app & require app protection policy

We want to make sure that we utilize a Conditional Access policy for granting the access to the applications by configuring approved client apps and app protection policy as required controls. You should also require multi-factor authentication if it’s not required in any other Conditional Access policy, but I would recommend using a separate policy for that. 

App Data Protection Configuration Framework 

The App Data protection configuration framework includes guidance on what Intune App Protection settings to configure, corresponding to different security levels aswell as a methodology for implementing them. The framework is divided into three different levels, each level representing Microsoft’s enterprise recommendations for protection. The framework also comes with a methodology for testing new settings in pre-production and the methodology explains how the rollout of your settings could be targeted at different rings at different phases (which to my mind is common sense when it comes to deployment). The security levels for the framework each has it’s own set of recommended configuration. Remember that these are general guidelines which should be tested before implementation and they can always be adjusted to your specific needs. 

Level 1 – Minimum data protection configuration 
Basic protection. Replaces the need for Exchange Online device access policies. I would recommend starting with level 2 which will enforce requirements on iOS and Androids major versions to match the supported version for Microsoft Apps. 

Level 2 – Enterprise enhanced data protection 
Recommended where users access access sensitive or confidential information. 

Level 3 – Enterprise high data protection 
Increased security, could be targeted at specific users or groups where the members are high value targets. 

Importing configurations into your tenant 

Microsoft have provided JSON Templates which you can use for a effective import and configuration of the settings. 
These policies will not be assigned and they can easily be adjusted after import.
To successfully import the templates you will need these pre-requisites: 

  • An intune tenant with a production or trial license and an account which have permissions to administer the Intune Service. The built-in role Intune Administrator will suffice.  
  • Powershell v.5.0 on Windows 10 x64 . 
  • The Graph APIs are used to configure the controls, and running these scripts for the first time requires you as an Global Admin to consent to the permissions of the application in your tenant. 
  • AzureAD or AzureADPreview-module for Powershell. Run the following in a elevated Powershell prompt: Install-Module –Name AzureAD -Force 

When the pre-requisites are in place, download the ManagedAppPolicy_Import_FromJSON.ps1 script and download the template(s) you want to import and put them and the script into the same folder. 

Run Powershell as Admin and navigate to the folder where the content reside. 

Run the script .\ManagedAppPolicy_Import_FromJSON.ps1 and specify your UPN for authentication:  

If the AzureAD Module is not found, remember to install it: Install-Module –Name AzureAD -Force 

Once authenticated (and when the consent for the application permissions is done for the first time), you are asked to specify the full path to one of the JSON template files you want to import. In my example I imported this one: : “C:\IntuneAppProtectionFramework\level-2-enterprise-enhanced-data-protection-iOS.json” Once provided, press enter and you will see the policy version, name, description and that is has been imported. 

Navigate to App Protection Policies in Intune. There we can verify that the policy has successfully been created. 

And if needed, it can also be modified: 

Next step is to assign the policy to a user or a user group and test the settings. Remember that this policy could be applicable to both corporate and BYOD devices. If you want to split this however, you can edit the policy and change that the Policy should only target unmanaged devices. One could also create a restrictive policy for the unmanaged devices, and a lighter one for the managed devices (which we will presume are MDM-enrolled).

Reference: Intune-Config-Framework

Attack Surface Reduction

In this blog post I will go through some of the different configuration options available for Attack Surface Reduction using Endpoint Manager (Intune), Defender for Endpoint and analyzing the rules locally using Powershell.

Short introduction
Attack Surface Reduction Rules in Windows 10 is a set of rules, designed to defend against different types of software behavior.
Examples of what they are aimed to do is prohibit malicious activities originating from:
– Executables and scripts (downloading or running files)
– Obfuscated and suspicious scripts
– Mitigation against uncommon behavior from apps (process-creation, execution etc.)

Attack Surface Reduction is available for Windows 10 Pro and Windows 10 E3 and E5.
E5 adds additional monitoring and analysis capabilities which natively is integrated into Defender for Endpoint.

Configuration options in Intune

Generally, your configuration options per rule are:
– Not Configured
– Audit
– Block

First option is to use a configuration profile in Intune (Endpoint Protection)
You will find it here: Endpoint Manager > Device Configuration Profile > Template > Endpoint Protection

Here you also have the ability to utilize exceptions for files and folders if needed. 

Second option is to use the new Settings catalog on the Category Defender will yield the same configurable settings as seen below.

Third option is to use the rules in a Security Baseline (MDM or Defender for Endpoint).
MDM Security Baseline – Rules are a bit scattered and located in the category Microsoft Defender. They needs to be configured manually per rule.

In the Defender for Endpoint Baseline the Attack Surface Reduction Rules are pre-configured for you.

Fourth option is configuring the settings using Endpoint Security
Endpoint Security > Attack Surface Reduction

Basically the same as the Endpoint Protection option. Controlled Folder Access is also included in this policy.
Fifth option is using OMA-URI but generally I would not recommend it.

Monitoring Attack Surface Reduction

Monitor locally in a Windows Device
When a Rule is in place, either in audit or block mode. With Windows 10 E3 you will need to monitor the status of the different ASR-rules in the local event log of the device.

Attack Surface ReductionMicrosoft/Windows/Windows Defender/Operational5007Event when settings are changed
 Windows Defender (Operational)1122Event when rule fires in Audit-mode
 Windows Defender (Operational)1121Event when rule fires in Block-mode
Controlled Folder Access /
Advanced Ransomware Protection
Microsoft/Windows/Windows Defender/Operational5007Event when settings are changed
 Windows Defender (Operational)1124       Audited controlled folder access event
 Windows Defender (Operational)1123       Blocked controlled folder access event

Monitor using Defender for Endpoint
If you are using Defender for Endpoint (are using M365 E5) then you can use the Security-portal for some of the configuration and also utilize it for optimal monitoring of ASR-detections.

Configurations –

Detections – https://security.microsoft.com/asr?viewid=detections
Here you will see detections and the full path to related applications, services who are impacted by the auditing or blocking. Since this is visible centrally, it’s the easiest place to find the information you need for mitigations/adjustments.
Advanced Hunting
Status of ASR-rules can also be verified through Advanced Hunting (in Defender for Endpoint or in the M365 Defender Security Center) Example KQL Query:

| where ActionType startswith ‘Asr’

Local ASR Script Analyzer and the ASR GUI
ASR Analyzer is a simple Powershell-script which will analyze your current ASR-rules settings in your device.
Script is from anthonws and can be downloaded here. Testing it on my device shows that currently, no rules are in audit nor in block mode.

If we just want to test things locally, without configuring anything centrally I would recommend using the ASR GUI by hemaurer. By running the ASR GUI we can in a very quick and easy manner enable every rule and then save the configuration (notice the current ASR-settings detected at the bottom).

If we run the ASR-Analyzer script again, we see that every ASR-rule now is in block mode.

Attack Surface Reduction technical defense role in a real world example
Below, you’ll see Doppelpaymer Ransomware’s attack chain to the right with each step categorized by MTRE ATTACK classifications. To the left you see the recommended mitigations and defenses against each technique where some of them are mapped to it’s corresponding ASR-rules.

Further reading from Microsoft on the topic of Ransomware and Attack Surface Reduction here.

Security Posture

I’ve updated my Powershell-script for detecting the status of different security related device features and settings related to Windows 10. The basic idea of this script is to quickly get an overview of the overall security posture of a Windows 10 device, at the device level.

Currently the script detects the status of:

  • Operating System
  • TPM
  • Bitlocker
  • UEFI
  • SecureBoot
  • Defender
  • CloudProtectionService (MAPS for Defender)
  • Defender for Endpoint
  • ApplicationGuard
  • Windows Sandbox
  • Credential Guard
  • Device Guard
  • Attack Surface Reduction
  • Controlled Folder Access

The script will write entries to a log file residing at the client (C:\Windows\Temp\Client-SecurityPosture.log)
which preferably is read using CMTrace or OneTrace.

Install the Script

Install-Script -Name SecurityPosture -force

Or you can download it manually from my Github.

Running the Script
Executing the script with the switch -Help (SecurityPosture -Help)
will display a brief description and all the current available options:

Next thing to try is running the script querying every function in it.
The status of more functions and features will be displayed:

Security Posture has support for running each individual check as a separate switch as well.
Here I query Operating System and Defender as an example:

As I stated in the beginning of this post. the script will write entries to a log file residing at the client at C:\Windows\Temp\Client-SecurityPosture.log which preferably is read using CMTrace or OneTrace.


Suggestions and ideas regarding improvement are always welcome.

SecurityPosture at Github & PowerShell Gallery

Manage authentication method (MFA in AzureAD, telephone-number)

Finally some new capabilites for us in regards to displaying, changing and turning off MFA-configurations for users. My past post regarding MFA-status can be read here which utilized Get-Msoluser. Now, Microsoft has released a new set of commands in the MSGraph api for Azure Multi-factor authentication which I’ll briefly go through in this post. Note that this is only in beta right now and more features will be added later.

First, let’s see what we can do as stated here:

“The new APIs we’ve released in this wave give you the ability to:

  • Read, add, update, and remove a user’s authentication phones.
  • Reset a user’s password.
  • Turn on and off SMS sign-in.”

Sweet, let’s try it out. We’ll start by navigating to Microsoft Graph and consent to the required permissions. For this example, be sure to use an account who is Global Administrator or Authentication Administrator.

Enter this information (change UPN to a test-user in your tenant):


Now select “Modify permissions” and be sure to consent to the permission UserAuthenticationMethod.ReadWrite.All 

Note that I’ve specified GET (fetch information) and when I press Run Query now, the result:

No value, which was expected in my case since my test-user does not have any phone number registered as authentication method for MFA. So let’s now try to POST the information instead and give the user a registered telephone number.

Change GET to POST

In the request Body, enter the following entries with your chosen values:

“phoneType”: “mobile”,
“phoneNumber”: “+46234567890”


Press Run Query again.. Success!

If you would like to verify the setting, change POST to GET again to fetch the same users Authentication Methods and now you’ll see the phone number:

The information can also be verified in AzureAD of course under Authentication Methods:

As Microsoft has stated here, more methods will be added in the future for these API-calls which will be much appreciated by many of us out there.

ABM – Invalid Profile during enrollment (Default Enrollment Restriction)

I stumbled upon a pretty dazzling error the other day where the solution wasn’t too obvious for me so I thought I would share my findings.

Prerequisites which all were in place:
– Apple Business Manager configured and Apple-devices where transmitted from reseller.
– Integration with Intune in place and devices successfully synced to my Intune-tenant.
– ABM-profile assigned to the successfully synced devices with User Affinity-setting configured.

During the provisioning of the device when the iPhone or iPad is turned on after the device has connected to cellular or WiFi, the ABM-profile is about to be downloaded to the device. But this time it only got prompted with “Invalid Profile”.

I tried deleting the device from Intune and re-synced ABM, I also tried modifying the settings for the ABM-profile and redeployed the ABM-token in Intune. I even tried resetting the whole ABM-integration between Intune and ABM but nothing solved my issue. The solution was instead, related to my Enrollment Restriction setup. You can find your enrollment restrictions in Endpoint Manager by going here and navigating to Devices/Enroll Devices and then Enrollment Restrictions.

Check out your Default restriction targeting All Users, and be sure to note the description of it:
This is the default Device Type Restriction applied with lowest priority to all users regardless of group membership.”

That’s what I had missed. I had made another Device type restriction with priority 1, that targeted my Intune Users and in that restriction iOS were allowed for enrollment. Beneath that one, in the Default restriction iOS was blocked. The result is that manual user driven Intune-enrollment for a mobile device works for users who are members of my Intune-Users group but the automatic enrollment by Apple Business Manager did not.

Conclusion: in other words, my bad! I had modified the default one way before the ABM-integration was in place and the regular iPhone-enrollments worked flawlessly. So be sure to double check your Enrollment Restrictions if you stumble upon any ABM Invalid Profile related errors.

Post a policy to Intune using Intune PowerShell SDK

In my last post regarding the MSGraph and the Intune PowerShell SDK I demonstrated how you installed the Intune PowerShell SDK and connected to the Graph Explorer to query information in your tenant of choice.

Today I will demonstrate how you can monitor (by the help of your web-browser) which json-values are produced when you create a Compliance Policy in Intune which you then in turn can use to create the same policy in Powershell to a tenant of your choice by the help of Intune PowerShell SDK. In my example I used Microsoft Edge as browser.

Start by logging in to your tenant of choice: https://endpoint.microsoft.com
Navigate to Devices/Windows/Compliance Policies.
Press F12 to start recording Network Activity in your Microsoft Edge browser.

To see in the recording what actually gets sent to the backend when you create something in Microsoft Endpoint Manager (Intune), let’s create a policy. In my example I chose a Compliance policy for Windows 10. Choose a name and a value for Minimum OS version. I used these values:
Name: Windows10-Compliance
Minimum OS version: 10.0.18363.778

When you have created your policy, you probably noticed that many things happened in the backend (to your right in the browser) during the recording of the network activity. To filter some of the results out you can type in “Devicecompliancepolicies” in the filter-field. Browse through the different entries until you find a POST entry with the graph URL under ‘General’ which is the one we are after right now.
Request URL: https:/graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies
Request Method: POST

As you see above, the information which got posted to the Graph is expandable.

Now, to the fun part. You can use the Intune Powershell SDK to post these values into a tenant of your choice. To do this, install (if you haven’t already), import the Microsoft.Graph.Intune module and then authenticate using Connect-MSGraph.

Install-Module -Name Microsoft.Graph.Intune -force
Import-Module -Name Microsoft.Graph.Intune -verbose
view raw gistfile1.txt hosted with ❤ by GitHub
When your UPN and your TenantID appears in Powershell, you’re successfully authenticated to the tenant and the module is now being operational.
#Windows 10 Compliance
$Windows10Compliance = New-IntuneDeviceCompliancePolicy `
-windows10CompliancePolicy `
-displayName "Windows10-Compliance" `
-osMinimumVersion 10.0.18363.778 `
-scheduledActionsForRule `
(New-DeviceComplianceScheduledActionForRuleObject `
-ruleName PasswordRequired `
-scheduledActionConfigurations `
(New-DeviceComplianceActionItemObject `
-gracePeriodHours 0 `
-actionType block `
-notificationTemplateId "" `
) `
view raw gistfile1.txt hosted with ❤ by GitHub

When you are connected to your tenant in your session, copy the code above to your current Powershell-window and run it to post a Windows 10 Compliance Policy to your tenant.

Guide: Advanced Installer

Packaging of a basic MSI-installer using Advanced Installer (Free Edition)
Recently I’ve been using Advanced Installer (Free edition) for basic packaging of different application installers. I work mainly with Microsoft Intune when it comes to application deployment so in between the newly released Win32-App-Packaging-Tool I’ve found a spot for preparation and packaging of install-files using Advanced Installer. Following below is a easy to follow guide for how you utilize the software and re-package your first MSI-installer.

The version of Advanced Installer I’m currently using is version 1.6.5, the Free Edition which can be downloaded here. Download and install it, start the application and then create a New Project. Be sure to change the project to “Simple” since that’s the version we are going to use here.

When the Project is provisioned, be sure to navigate to Resources and then Files and Folders. When this is done, drag your MSI-file from any location to the “Application Folder”. As you can see on the screenshot above the source-location of this file also get’s listed.

Next step is to customize the name, version and publisher of your package. Press Product Details under Product Information. To the right on “Version” of the product, press and then select your newly imported MSI-installer. This will automatically provision the version of the application to your package.

I have then chosen to call the application Edge Beta and Publisher will be my made up company “Virtual Company”.

After pressing OK, at this point press “Keep existing” since we don’t need to generate a new Product Code at this time.

After this is done, press Build to save your project and generate the newly configured installer. I’ll save mine locally to C:\Temp\Edge.

Wait until the build finishes and then press OK. As you see in the screenshot above, you’ll see where the newly generated package resides (C:\Temp\Edge\Edge Beta-SetupFiles\Edge Beta.msi).

Viewing the MSI-Installer show all the properties we just configured. Well done.

Advanced Installer also comes with a enterprise-looking template for the installation of packaged installers, see below for my screenshots from the user experience regarding manual installation of the application.

User experience using the installer