In this blog post I will be showing you how to get started with certificate based authentication for Azure applications.

The story so far

The world has gone cloud crazy. But this is a good thing! Thinking back to my old admin days, any script I wrote would be deployed using GPO’s, Scheduled Tasks, RMM tools, ConfigMgr, Login Scripts and more. As we now focus our automation efforts on cloud services, the good old days of “dropping a script somewhere and running it” are coming to an end. Whether you are running scripts interactively to get data from Graph API or using Azure Functions to automate that task for you – you would have to authenticate at some point to prove you have the permissions to make that API call.

Thinking back to the old days, I would typically authenticate myself against Active Directory to prove I had the necessary permissions to perform a task. In the modern world, its a similar model and I now authenticate against Azure Active Directory to obtain the token I need to perform a particular function or call to the Graph API.

App Registrations

When I think about automation, I instinctively get drawn to Microsoft Graph. The API’s are rich and expose a wealth of information about my Microsoft Services. I can jump over to Graph Explorer aka.ms/ge and this is a great tool to familiarize yourself with queries to the Microsoft Graph but at some point you are going to want to use other programming logic to build your query that will get posted to the Microsoft Graph. To make calls to the Graph we need need to have an access token and to get that access token we need to authenticate to Azure Active Directory.

Now, typically you are going to use an Azure App Registration (a service principal) to get the token. The service principal is granted the necessary permissions it requires for your automation to do its thing. These permissions are explicitly granted on the service principal (see below) For example, if I wanted to read and write Win32apps in Intune, my app registration must be granted permission DeviceManagementApps.ReadWriteAll

Client Secrets

You will see A LOT of blogs and automation examples on the internet where the admin will use a very easy method to authenticate the Service Principal. A basic password – otherwise known as a Client Secret. Client secrets are quick and easy to use but they come at a price.

If we look at the Certificates and secrets blade on the app registration, you will see there are 3 ways to authenticate.

• Certificates
• Application Secrets
• Federated Credentials

The client secret is a short/long lived password. When we authenticate to the Microsoft Graph with our service principal, we need to present 3 pieces of information.

• Tenant ID (which tenant are we authenticating against)
• Application ID (same concept as a username)
• Client Secret (same concept as a password)

We don’t have the option of creating a secret that lasts forever, but a secret can be configured to be valid for up to 2 years

Would you let your users create a password that was valid for 2 years? Yuk – no way.

Once you create a client secret, it is only visible in the portal temporarily. When you navigate away from the blade the client secret is obfuscated

Authenticating with a client secret is considered basic authentication. Anyone with the Tenant Name/ID, Application ID and Client Secret can authenticate with the service principal in your tenant. Yeah its probably OK for testing with the minimum value of a client secret set to 90 days but will you go in and clear down your client secrets after performing your tests? The likelihood is no.

Where do I see Client secrets used badly? Hard coded in PowerShell scripts Please, for the sake of all things great and small, do not do this! If you insist on using Client Secrets, at least store them in a key vault but never hard code them in your scripts.

Jan wrote a really good article on using Client Secrets in conjunction with Azure Key vault at Securing Intune Enhanced Inventory with Azure Function – MSEndpointMgr

The IntuneManagementExtension.log will display the script body of a script pushed from Intune. If you hard coded a client secret in your script it will be visible to anyone who opens that log file.

You could mitigate some malicious abuse of your app registration if these credentials are leaked, perhaps by using Conditional Access, but I would argue its better to use a stronger form of authentication if you can. Think about what this Service Principal is allowed to do – create Win32 apps in your tenant! A malicious actor would love to create and deploy a Win32 app that dropped malware on your devices if they got hold of those credentials.

Certificates

Remember back to your basic training around authentication. Passwords are bad, strong authentication methods are good. When we think about Multi Factor Authentication we have something that others do not. A Certificate is something that I have, it is not a credential that can be used by anyone, which effectively makes it a stronger form of authentication than a client secret.

When I authenticate my Service Principal to get a token, I can use a certificate – but how does this work? A high level view of certificate based authentication:-

1. Create a certificate or obtain one from a trusted public authority
2. Upload the public key to the Azure app registration
3. The private key is used from the local device or uploaded and used from Azure automation
4. Authentication is successful
5. A token is returned which can be used to make calls to Graph

Create a Self Signed Certificate

Authentication with a certificate, from the perspective of automation at least, is quite simple. We often only need the private key on the local device performing the calls to Graph, normally the admin or developer, or it needs to be in Azure automation. We don’t need to send the certificate to all our clients which means its OK to create a self signed certificate for this function. A few caveats to consider when deciding to use a self signed certificate or one from a Public CA are:

1. Weaker Cipher suites may be used when self signed certificates are generated.
2. Outdated hashes may be used when self signed certificates are generated (Did you use SHA-1).
3. Only you have the private key – what if Dave want’s to use the same one or you leave the company and forgot to tell someone where you saved the private key.
4. You forget the password for your private key so cannot export it anymore

In summary, for production I would recommend consideration for certificates from a Public Certificate Authority but for testing, at the very least, self signed certificates are absolutely fine.

Certificate Requirements

There are many flavours of certificate that we can create. What should the cryptographic algorithm, validity period, key length be? Microsoft have a great article calling these out and I’ll list them below.

• A 2048-bit key length. While longer values are supported, the 2048-bit size is highly recommended for the best combination of security and performance.
• Uses the RSA cryptographic algorithm. Azure AD currently supports only RSA.
• The certificate is signed with the SHA256 hash algorithm. Azure AD also supports certificates signed with SHA384 and SHA512 hash algorithms.
• The certificate is valid for only one year.
• The certificate is supported for use for both client and server authentication

https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-create-self-signed-certificate

So that begs the question, “How do we create a self signed certificate”?

The “New-SelfSignedCertificate” PowerShell Cmdlet

The New-SelfSignedCertificate PowerShell cmdlet allows us to create a self signed certificate for the purpose of certificate based authentication to Azure AD.

If we just run the cmdlet and pass the Subject parameter, lets see what happens

New-SelfSignedCertificate -Subject "AzureCertIntuneTesting"

What happened then. It looks like a certificate was created somewhere. Let’s take a peek.

Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object { $_.Thumbprint -eq "24994e6e4a404978ea05476d940f6f88dd43d13c" }

certlm.msc show us some magic.

We can see the default properties of the certificate that was created. Information like the private key is exportable (useful if we need to export it for Azure Automation) and the default validity period is 12 months.

The default characteristics of the certificate, without passing any other parameters are:-

• A 2048-bit key length *
• Uses the RSA cryptographic algorithm (Azure AD currently supports only RSA)
• The certificate is signed with the SHA256 hash algorithm **
• The certificate is valid for only one year
• The certificate is supported for use for both client and server authentication

* While longer values are supported, the 2048-bit size is highly recommended for the best combination of security and performance.
** Azure AD also supports certificates signed with SHA384 and SHA512 hash algorithms.

Can we have a little more control? This snippet is useful to help you quickly create a self-signed certificate by splatting some params to the cmdlet.

$subjectName = "AzureCertIntuneTesting2"
$certStore = "LocalMachine"
$validityPeriod = 24

$newCert = @{
    Subject = "CN=$($subjectName)"
    CertStoreLocation = "Cert:\$($certStore)\My"
    KeyExportPolicy = "Exportable"
    KeySpec = "Signature"
    NotAfter = (Get-Date).AddMonths($($validityPeriod))
}
$Cert = New-SelfSignedCertificate @newCert

https://learn.microsoft.com/en-us/powershell/module/pki/new-selfsignedcertificate?view=windowsserver2022-ps

Export the Public Portion for use in Azure

Use the following snippet to export the public portion of the certificate as a .cer file which you can upload and use for your Service Principal (App Registration) authentication.

$certFolder = "C:\temp\certs"
$certExport = @{
Cert = $Cert
FilePath = "$($certFolder)\$($subjectName).cer"
}
Export-Certificate @certExport

Export the Private Portion for use in Azure Automation

Use the following snippet to export the private portion of the certificate as a .pfx file which you can upload and use when authenticating with the Service Principal (App Registration).

$certFolder = "C:\temp\certs"
$certThumbprint = $Cert.Thumbprint
$certPassword = Read-Host -Prompt "Enter password for your certificate: " -AsSecureString
$pfxExport = @{
    Cert         = "Cert:\$($certStore)\My\$($certThumbprint)"
    FilePath     = "$($certFolder)\$($subjectName).pfx"
    ChainOption  = "EndEntityCertOnly"
    NoProperties = $null
    Password     = $certPassword
}
Export-PfxCertificate @pfxExport

Create and Export the Public and Private Keys

We can take the examples above and run the following script block to generate a certificate and export the public and private keys – ready to be used for authentication.

$subjectName = "AzureCertIntuneTesting"
$certStore = "LocalMachine"
$validityPeriod = 24

$newCert = @{
    Subject           = "CN=$($subjectName)"
    CertStoreLocation = "Cert:\$($certStore)\My"
    KeyExportPolicy   = "Exportable"
    KeySpec           = "Signature"
    NotAfter          = (Get-Date).AddMonths($($validityPeriod))
}
$Cert = New-SelfSignedCertificate @newCert

#export public key only
$certFolder = "C:\temp\certs"
$certExport = @{
    Cert     = $Cert
    FilePath = "$($certFolder)\$($subjectName).cer"
}
Export-Certificate @certExport

#export with private key
$certFolder = "C:\temp\certs"
$certThumbprint = $Cert.Thumbprint
$certPassword = Read-Host -Prompt "Enter password for your certificate: " -AsSecureString
$pfxExport = @{
    Cert         = "Cert:\$($certStore)\My\$($certThumbprint)"
    FilePath     = "$($certFolder)\$($subjectName).pfx"
    ChainOption  = "EndEntityCertOnly"
    NoProperties = $null
    Password     = $certPassword
}
Export-PfxCertificate @pfxExport

We should end up with 2 files in our output directory as illustrated below.

The certificate, including the private key, will also be in the certificate store of the local machine as we saw earlier.

Configure Certificate Authentication for an App Registration

At the beginning of this post, we viewed the “Certificate & secret” blade on our app registrations. I will revisit that again now and show you how to add the certificate in readiness for certificate based authentication.

Navigate to Certificates & secrets blade and select Upload Certificate

Browse the the .cer file we created earlier and click Add

Great, the public portion of the certificate is right where we need it to be.

Authenticate to Azure AD using the application and the Private Key

If you are connecting from a Windows device, you may already have the certificate in your certificate store if you generated the self signed certificate from the same computer. If the certificate is not in certificate store, you can still generate JSON Web Token (JWT) for authorization. A great thread and code example can be found here. In this example I will assume you have the .pfx and want to make the authorization attempt from another location, like Azure Automation.

<#
.SYNOPSIS
    Authenicate using an Azure application and a certificate to obtain a token
.DESCRIPTION
    After generating a self signed certificate, use the pfx to authenticate to AzureAD to obtain a token
.EXAMPLE
    Get-CBAToken.ps1 -tenantId "0cebf1f4-e0c4-46d4-8c5a-0fc80bed6b2c" -applicationId "47727b19-7b3f-472a-8057-704affed1815" -pfxFile "C:\temp\certs\AzureCertIntuneTesting.pfx" -pfxPassword "123"
.NOTES
    
#>
[CmdletBinding()]
param (
    [Parameter(Mandatory = $true)]
    [string]$pfxFile,
    [string]$tenantId,
    [string]$applicationId,
    [string]$pfxPassword
)

$Scope = "https://graph.microsoft.com/.default"

If (-not $pfxPassword) {
    $pfxPassword = Read-Host -Prompt "Enter password for your certificate: " -AsSecureString
}
else {
    $pfxPassword = ConvertTo-SecureString -String $pfxPassword -AsPlainText -Force
}

#get certificate hash and create base64 string
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import($pfxFile, $certPassword, 'DefaultKeySet')
$cert64Hash = [System.Convert]::ToBase64String($cert.GetCertHash())  

function Get-Token {
    #create JWT timestamp for expiration 
    $startDate = (Get-Date "1970-01-01T00:00:00Z" ).ToUniversalTime()  
    $jwtExpireTimeSpan = (New-TimeSpan -Start $startDate -End (Get-Date).ToUniversalTime().AddMinutes(2)).TotalSeconds  
    $jwtExpiration = [math]::Round($jwtExpireTimeSpan, 0)  
  
    #create JWT validity start timestamp  
    $notBeforeExpireTimeSpan = (New-TimeSpan -Start $StartDate -End ((Get-Date).ToUniversalTime())).TotalSeconds  
    $notBefore = [math]::Round($notBeforeExpireTimeSpan, 0)  
  
    #create JWT header  
    $jwtHeader = @{  
        alg = "RS256"  
        typ = "JWT"  
        x5t = $cert64Hash -replace '\+', '-' -replace '/', '_' -replace '='  
    }  
  
    #create JWT payload  
    $jwtPayLoad = @{  
        aud = "https://login.microsoftonline.com/$tenantId/oauth2/token"  
        exp = $jwtExpiration   
        iss = $applicationId  
        jti = [guid]::NewGuid()   
        nbf = $notBefore  
        sub = $applicationId  
    }  
  
    #convert header and payload to base64  
    $jwtHeaderToByte = [System.Text.Encoding]::UTF8.GetBytes(($jwtHeader | ConvertTo-Json))  
    $encodedHeader = [System.Convert]::ToBase64String($jwtHeaderToByte)  
  
    $jwtPayLoadToByte = [System.Text.Encoding]::UTF8.GetBytes(($jwtPayLoad | ConvertTo-Json))  
    $encodedPayload = [System.Convert]::ToBase64String($jwtPayLoadToByte)  
  
    #join header and Payload with "." to create a valid (unsigned) JWT  
    $jwt = $encodedHeader + "." + $encodedPayload  
  
    #get the private key object of your certificate  
    $privateKey = ([System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAprivateKey($cert))  
  
    #define RSA signature and hashing algorithm  
    $rsaPadding = [Security.Cryptography.RSASignaturePadding]::Pkcs1  
    $hashAlgorithm = [Security.Cryptography.HashAlgorithmName]::SHA256  
  
    #create a signature of the JWT  
    $signature = [Convert]::ToBase64String(  
        $privateKey.SignData([System.Text.Encoding]::UTF8.GetBytes($jwt), $hashAlgorithm, $rsaPadding)  
    ) -replace '\+', '-' -replace '/', '_' -replace '='  
  
    #join the signature to the JWT with "."  
    $jwt = $jwt + "." + $signature  
  
    #create a hash with body parameters  
    $body = @{  
        client_id             = $applicationId  
        client_assertion      = $jwt  
        client_assertion_type = "urn:ietf:params:oauth:client-assertion-type:jwt-bearer"  
        scope                 = $scope  
        grant_type            = "client_credentials"  
  
    }  
  
    $url = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"  
  
    #use the self-generated JWT as Authorization  
    $header = @{  
        Authorization = "Bearer $jwt"  
    }  
  
    #splat the parameters for Invoke-Restmethod for cleaner code  
    $postSplat = @{  
        ContentType = 'application/x-www-form-urlencoded'  
        Method      = 'POST'  
        Body        = $body  
        Uri         = $url  
        Headers     = $header  
    }  
  
    $request = Invoke-RestMethod @postSplat  

    #view access_token  
    $request
}

Get-Token -tenantId $tenantId -applicationId $applicationId -scope $scope -cert $cert -certBase64Hash $cert64Hash

When we execute the script, we get a token!

And the Azure AD sign-in log shows the success authorization

Example: Authenticate with a certificate and make a Graph call to Intune

We can simplify things now. Lets use the access token to make a call to Microsoft Graph

$authToken = .\Get-CBAToken.ps1 -pfxFile "C:\temp\certs\AzureCertIntuneTesting.pfx" -tenantId "0cebf1f4-e0c4-46d4-8c5a-0fc80bed6b2c" -applicationId "47727b19-7b3f-472a-8057-704affed1815" -pfxPassword "123" 
Invoke-RestMethod -Headers @{Authorization = "Bearer $($authToken.access_token)"} -Method GET -Uri "https://graph.microsoft.com/beta/deviceAppManagement/mobileApps?$filter=(isof('microsoft.graph.win32LobApp'))"

Summary

In this post we looked at creating a self signed certificate for the purpose of authentication to Azure AD using a Service Principal. Certificates are a much better way to authenticate than client secrets. We created a JWT for authentication using the private key and made a simple call to Graph to prove it works. I feel part 2 might be in the works. We spoke about using Azure Automation with Certificate Base Authentication and I would like to give some examples of how that can be achieved when we store the .pfx in Azure Key Vault.

(4)

The post An easy way to get started with Certificate Based Authentication for Azure apps appeared first on MSEndpointMgr.

Over recent times we have seen Microsoft introduce a range of security hardening configuration options as the world continues to adopt to the fact that their internal infrastructure is no longer the main threat surface. In this post we will look at the latest of which (due to be enforced in January 2024).

The new Authentication Methods configuration is something which brings a welcome change, retiring per user based MFA configuration managed through the Microsoft admin portal, along with separate configuration methods for Azure AD Self Service Password Reset. This is welcomed change, especially for the legacy per user MFA configuration, which if you are still using it, please stop.

Bye Bye Per User MFA Configuration

Per user based MFA configuration has been around since “Office 365” was launched, providing the ability to enforce multi-factor authentication requirement for users. Management takes place within the Microsoft Admin portal (https://admin.microsoft.com), and by default resulted in users being provided with an “app password” which was used to sign into Microsoft Office applications, providing in effect an “MFA bypass” for those trusted applications due to the fact they had a defined password which was different to the user’s actual password.

The experience IMO was, shall we say.. terrible. This methods is also classed as legacy authentication and thus app passwords do not work with accounts which are required to use modern auth.

Since then thankfully the world has moved on quite a bit, and today, if you are using the legacy MFA configuration portal to enforce MFA, you are simply doing things wrong. Multi-factor challenge requirements should be all handled via conditional access, and identity protection policies, depending of course upon your Azure AD Premium licensing model.

Supporting Microsoft Learn Documentation
Enable per-user Multi-Factor Authentication – Azure Active Directory – Microsoft Entra | Microsoft Learn
What is Conditional Access in Azure Active Directory? – Microsoft Entra | Microsoft Learn
What is Azure Active Directory Identity Protection? – Microsoft Entra | Microsoft Learn

Authentication Configuration

As many of you might have spotted either in the Azure Active Directory blade, or within the new Microsoft Entra portal (https://entra.microsoft.com), authentication methods provides you the ability to enable and configure multiple authentication types which can be used within your Azure tenant.

If you haven’t spotted this, then you are also missing out on the fact that MFA app based challenges where due to be changed for all tenants on February 27th 2023, although this has been pushed back to May 8th 2023 when you read the documentation;

If that has come as a surprise to you, then I suggest you review the changes (Protecting authentication methods in Azure Active Directory – Microsoft Entra | Microsoft Learn) and issue communications to your user base as to avoid your helpdesk staff having to deal with “did you change something? I have to enter a number now” type questions.

Pre-Migration Considerations

Before you go ahead and make the jump to the new way of doing things, it is important you consider how removal of MFA enforcement will impact the security of your tenant. For example, if you have been using this method for your admins, you either need to enable security defaults (which brings limitations), or ensure / create conditional access policies are configured to cater for the different authentication scenarios.

Privileged Role Accounts

As an absolute minimum baseline, protecting your privileged role members can be undertaken through using the CA policy templates;

As always when creating conditional access policies, ensure you have a break glass / emergency admin account created, with a complex password, and excluded from the conditional access policy (just in case something goes bump in the night with the MFA service) – Manage emergency access admin accounts – Azure AD – Microsoft Entra | Microsoft Learn.

General User Access

I’m not covering conditional access policies for all scenarios in this post, as it is a large topic by itself. I would suggest that you take a persona based approach to your CA configuration however, and recommend that you read the Microsoft learn docs in relation to this – Conditional Access architecture and personas – Azure Architecture Center | Microsoft Learn

Security Questions

Within the migration to the new authentication methods configuration, the ability to use security questions for Azure Self Service Password Reset is retired. This in my opinion is only a good thing, as typically the answers to questions are either forgotten or the same answer is used for all questions.

The Migration Process

The process of moving from the old legacy portal to the new authentication methods configuration is quite simple, so let us step through this.

• In the Authentication Methods configuration (in either Azure portal Active Directory Authentication Methods or Entra portal Authentication methods) you will see a notice about the “Manage migration (Preview)” feature;

• Clicking on the “Manage migration (Preview)” link, clicking this will display the following slide in:

• When switching to the authentication methods configuration, the first thing that we need to is to set the tenant into a “Migration in Progress” state. What this does under the hood is to allow us to uncheck the supported MFA methods in both the legacy per user multifactor, and Azure AD Self Service Password Reset configuration pages
  

• With the tenant now in the new state, we can start with reviewing and removing the existing supported methods
• Going into the legacy MFA portal (Multi-factor authentication (windowsazure.com)), first of all you should review which methods are currently enabled;
  

• Going into the Azure AD Self-Service Password Reset configuration, again let’s review the existing methods here also;

• In this example we have then decided that I am going to retire SMS and Phone calls, moving to a model that uses the Authenticator app and Temporary Access Pass methods.
  
  I would recommend where possible retiring SMS and Phone call authentication as they are the weakest options, however, you could take a phased approach where these methods are phased out.
  
• Before we make changes, we need to disable the legacy MFA enforcement for all enforced users in the legacy MFA portal:

• Now going back to the Authentication methods configuration, we configure the required methods;

• In the configuration options for the Authenticator method, we can also specify to enforce number code matching before it is pushed by Microsoft to all tenants, and also include the options to display the location and application signing in, all of which are important information to present to the end user;

• The temporary access pass configuration is then also configured;
  

• With the new configuration set, in both the legacy MFA portal and AD SSPR configuration we then remove all methods;

• If you receive the following error, try refreshing the portal as the configuration has not been updated to allow you to have no methods specified (try refreshing / signing out and back in );

• Testing the updated configuration, we should receive an authenticator prompt with the additional number matching and location information displayed;

• At this point with all configuration items done, we can go and set the tenant state to “Migrated” in the Authentication Methods configuration;

• You should now receive a visual confirmation that the setting has been applied;

Closing Thoughts

Migrating to the authentication methods configuration is a straight forward process, resulting in a single configuration page for your auth methods.

So my suggestion is to plan your migration today, and not leave it up to January 2024 to be in a panic situation, especially when it comes to your conditional access policy configurations.

(186)

The post Migrating to Authentication Methods Policies – Happy days! appeared first on MSEndpointMgr.

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. in this Trilogy you can expect to learn the what, the how and the wow!

The story so far

We continue our mini series on Windows Hello for Business Cloud Kerberos Trust. In part 2 we walked through the configuration of Cloud Kerberos Trust for both on-premise infrastructure and clients.

If you missed part 1 of our series, your journey into “Cloud Kerberos Trust” should start here: Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 1

We love the elegance and simplicity of Cloud Kerberos Trust but in this final post of the mini series we will dive a little deeper and look at some of the mechanics and moving parts to help you understand and troubleshoot your way out of a hole- if you need to.

Hold tight and get your engineer brain engaged as we equip you with the tools you need to succeed!

Pick-up your engineering toolkit and come down the rabbit hole

Migrating from other Trust Models

This question often comes up, naturally. What if you are using hybrid key trust and you want to begin kicking the tires on cloud kerberos trust? The answer is simpler than you might think.

Migrating from a hybrid key trust model is very simple. For Azure AD and Hybrid Azure AD joined devices, simply deploy the Intune configuration to enable cloud kerberos trust and the user will switch to cloud kerberos trust. The extra requirement for Hybrid Azure AD joined devices is the device requires line-of-sight to a DC at first logon or it will fall back to using key trust.

Migrating from certificate trust has more moving parts. You must disable the existing certificate trust policy, deploy the Intune configuration to enable cloud kerberos trust, delete the existing hello credential and sign back in to the device.

Use the following command to delete the existing hello credential

certutil.exe -DeleteHelloContainer

The “Key” thing to understand, (see what I did there?) is that a policy that defines neither: “Use certificate for on-premises authentication (*1)” or “Use cloud trust for on-premises authentication (*2)” is considered as using the “Key Trust” model for authentication.

Privileged Accounts

Highly privileged accounts are not granted, by default, to use FIDO2 security keys and/or cloud kerberos trust to login to a device. The local security policy forbids it.

The msDS-NeverRevealGroup property is used to define which AD objects forbidden to have their passwords cached on the Kerberos RODC.

To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>).

Caution should be used when relaxing any local security policy. Understand the impact, if any, of what you are about to do

Next Generation Credential (NGC)

The Next Generation Credential (NGC) is important. Verify the NGC has been set on client devices correctly by using dsregcmd (in the user context) command. NgcSet: YES means that a hello key has been set for the current user

dsregcmd /status

Verify the NGC has been saved to the user object in AzureAD using Graph Explorer. Examine the deviceKeys attribute for the NGC assigned to the device the user logged on to using WHfB.

The NGC is present as a result of the normal WHfB authentication process – it is not specific to us enabling AzureAD Kerberos but it will be important when we look at other moving parts later in this blog.

The NGC contains the base64-encoded public portion of the asymmetric key pair used for WHfB authentication.

You can also see in the Windows event log that the NGC was created and written to the user object in Azure AD

In Graph Explorer, we can also see some other cool metadata that will be useful when we deep dive later!

Cloud Kerberos Trust under the Microscope

Before we dial in our microscopes it is best we define what the high level components are in a Windows Hello for Business Cloud Kerberos Trust relationship as this will help us sort through the finer details.

• AzureADKerberos
• Windows 10/11
• Windows Server 2016 or newer DC
• User account synced from On-Premise

Yes, it is basically just those few things, no PKI is explicitly required! And now we have that sorted, on to nitty gritty.

AzureADKerberos

In Part 2, we provisioned the Azure AD Kerberos Read-Only Domain Controller (RODC) object into the “Domain Controllers” OU of our local Active Directory domain.

So what happens when the object is created? It creates a server object that can issue Ticket Granting Tickets (TGTs) for Kerberos in your domain. The encryption key is then securely published to Azure AD, which allows it to issue a partial TGT as part of the magic behind Cloud Kerberos Trust. This partial TGT is received by the user via the Primary Refresh Token when they authenticate with Azure AD. The TGT includes only the user’s SID, and no authorization data.

This is a one-time operation, and for each on-premises domain, an object will represent it in Azure AD. No background processes are enabled to keep things in sync. It’s all very secure!

If you have more than one on-premises domain, each one will have a key in Azure AD that corresponds to the on-premises domain. Thus, if you have multiple domains, this is not an issue. However, if you have a single domain and multiple tenants, the issue becomes more complicated, as there is no option to just publish the encryption key of the current Azure AD Kerberos RODC object into another tenant.

It’s important to know that, since the encryption key (kbrtgt) is not synced after the initial publishing into Azure AD, it’s imperative to only use the Azure AD Kerberos PowerShell module to rotate the kbrtgt of the Azure AD Kerberos RODC object.

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userprincipalname -RotateServerKey

There is more of on the official Microsoft Learn site: Passwordless security key sign-in to on-premises resources – Azure Active Directory – Microsoft Entra | Microsoft Learn

Windows 10/11

ICYMI: Windows is required for Windows Hello for Business to function. But not just any version of Windows. Windows 10 21H2 and later are recommended because the Cloud Kerberos Trust feature was introduced with this build.

So what happens during sign-in, since it is important to have an updated version of Windows? Well it depends on what join-type your device is using – Hybrid Join or Azure AD Join. Let’s start with the most common “Hybrid Join”.

Hybrid Joined

There are many roads to Rome, and this one takes the longest of them all!

Azure AD Joined

Be prepared to be amazed at the simplicity of being in an Azure AD Joined state and doing SSO to your on-prem resources:

If you wanna get deeper into it and follow these awesome diagram flows from Microsoft, there is the official documentation at Microsoft Learn: How Windows Hello for Business works – Authentication | Microsoft Learn

Kerberos is King

Meet Michael, Ben and Fluffy the dog. Cerberos is the mythical creature that guards hades, the gates of hell. Fluffy is the watchdog of the underworld etc. In previous roles he was guarding Windows Vista and was born in the 80’s when no one cared what shampoo you used.

Kerberos has 3 parts/heads (Michael = User, Fluffy = KDC, Ben = Service)

So what is Kerberos and how does it help us when we are looking to SSO to our domain resources? Here are some Kerberos basics

• “Kerberos” is just a cryptographic ticketing system
• In order to request tickets to domain resources, the Kerberos protocol needs to know where the “Ticket Master” is
• The “Ticket Master” is called the Key Distribution Centre (KDC)
• The KDC in a Windows Domain is a Domain Controller

Basically I need to get a ticket from the domain controller, or KDC, to prove who I am to the service e.g. file server

Finding a KDC

Azure AD joined devices are not aware of your domain, so how do they find the KDC to get tickets? Thats easy and takes us back to the 80’s again. DCLOCATOR is a process used by Windows systems to locate the closest available Domain Controller

First my client needs to find the KDC, how does it do this when the client knows nothing about the domain? Ah-ha, remember we have some synced attributes that come down with our Primary Refresh Token at logon. DCLocator needs a domain hint, which it gets from the <onpremisedomainname> attribute that came down with this PRT. A Domain Controller (KDC) is returned to the client as a result of, effectively, a DNS query.

We can simulate what DCLocator does by running the nltest on a device and passing the domain name

nltest /dsgetdc:byteben.com

If on-premises DNS is broken or the client is not configured correctly for DNS. This query might/will fail. Its always DNS right?

Tickets Please

Now we know where the KDC is, lets go into a bit more detail on how Kerberos ticket issuance works and helps us to access domain resources.

1. The partial TGT we obtained from AzureAD is sent to the KDC.
2. The KDC validates the partial TGT.
3. The KDC then issues a “Golden” ticket to the user. The golden tickets, or Full TGT is proof the user authenticated. Authentication has a lot of overhead so we don’t want to keep doing it.
4. The user then sends that TGT (proof that they can come into the nightclub) along with another request to access a service, like CIFS (fileshare)
5. The KDC sees the user has a valid TGT (BTW, only the KDC can decrypt the TGT) and issues a “Service Ticket”. The service ticket contains things like group membership and service requested.

We can see the AS-REQ for a ticket come into the KDC (You can filter Wireshark using the KRB5 protocol to see this cool stuff)

When we try to access a file share, we see the client send a request to the KDC.

When we try to access a file share, we see the client send a request to the KDC. The request contains our TGT which validates who we are

The KDC then issues us a service ticket for the resource we just tried to access. In this example we accessed a file share on bb-app1.byteben.com

Klist

Klist displays all the service tickets we have been granted. Here is the service ticket we requested to access the file share on bb-app1.byteben.com

Klist also has another cool command when working with Cloud Kerberos Trust

klist /cloud_debug

Summary

Hopefully this 3 part mini series has been useful. Its always difficult to know how deep to go and keep the content engaging. If you would like any more info, please reach out!

Bookmark this page, because there is no way you will remember all of this stuff, and don’t forget that Ben and Michael work for likes and follows on Twitter and LinkedIn. Fluffy takes bones, peanut butter and cinema ticket stubs as donations.

(6)

The post Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 3 appeared first on MSEndpointMgr.

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. in this Trilogy you can expect to learn the what, the how and the wow!

The story so far

We continue our mini series on Windows Hello for Business Cloud Kerberos Trust. In part 1 we introduced the concept of Cloud Kerberos Trust and spoke to some of the challenges it can help organisations overcome. One of the things that we love is the simplicity of configuration – both for green field tenants and for organisations already using a different trust method with Windows Hello for Business (WHfB).

Simplicity is elegance

In this post, we will show you how to configure Cloud Kerberos Trust for your on-premises infrastructure and how to create a configuration policy for your client devices.

Enabling Azure AD Kerberos for Cloud Kerberos Trust

This is so easy. Honestly, put one hand behind you back, juggle some wet frogs and sing “I will always love you”, all at the same time, and you will still be able to configure Azure AD Kerberos too.

Enabling Azure AD Kerberos creates an “Azure AD Kerberos” server object in the domain.

This server object:

• Appears as a Read Only Domain Controller (RODC) object, but isn’t associated with any physical servers.
• Is only used by Azure AD to generate partial TGTs for the Active Directory domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object.

We will configure Azure AD Kerberos in our lab. Full prerequisites can be found here and the code samples are taken from the Microsoft docs here

1. Download and install the Azure AD Kerberos PowerShell module

from the PowerShell Gallery. This can be done directly on the Domain Controller or from a computer that can access the Domain Controller.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

TLS 1.2 is required to access the PowerShell Gallery. Run the following command if it is not enabled.

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

2. Run the following

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

3. Verify that the Kerberos server RODC object was created successfully.

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

4. Also verify that the krbtgt user account was created (it is intentionally disabled)

Configure Cloud Key Trust using Intune

We can either use a GPO or push a configuration from Intune. If you are interested in using a GPO, read more here. In this post we will push the configuration from Intune (this is the way).

Ensure the client devices are a minimum of Windows 10 21H2 / Windows 11 Pro or Enterprise SKU. Perhaps consider using an Intune Filter for targetting.

1. Create a configuration profile

Navigate to https://endpoint.microsoft.com and create a new Device Configuration Profile of type

Windows 10 and later > Templates > Custom

2. OMA-URI for Cloud Kerberos Trust enablement

Add the following settings

Name: UseCloudTrustForOnPremAuth
OMA-URI: 
./Device/Vendor/MSFT/PassportForWork/<tenant-id-guid>/Policies/UseCloudTrustForOnPremAuth
Data type: Boolean
Value: True

Tenant ID in the OMA-URI must be replaced with the tenant ID for your Azure AD tenant

3. Assignments

Assign the profile to your desired group. You can target either users or devices.

4. Test the policy worked

At this stage, after a synced user logs in using WHfB, verify that a partial TGT has been issued using the command:-

klist cloud_debug

You can also be verify in the event log if the policy has been set successfully on the client.

Summary

In part 2 of this mini series we looked at how to configure Cloud Kerberos Trust. In Part 3 we will dive a little deeper into some of the moving parts and help with some troubleshooting tips. Stay tuned for more fun!

(11)

The post Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 2 appeared first on MSEndpointMgr.

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. In this Trilogy you can expect to learn the what, the how and the wow!

The story so far

Windows Hello for Business Cloud Kerberos Trust – Every silver lining begins with a journey through pain, non optimal circumstance and wisdom gained through grit and determination. The trust model story has never been simple..

In this 3-part mini series, we will talk about concepts, strategies, configurations and pain points that we commonly come across when configuring Windows Hello for Business and why Cloud Kerberos Trust is the future.

What is Windows Hello for Business?

We won’t spend too much time peeling apart what Windows Hello for Business (WHfB) is but let’s remind ourselves of some key points.

• WHfB is a password-less authentication mechanism. Think of it as a type of user credential which is uniquely tied to a device – secured with a PIN or biometric
• WHfB is not the same same as Windows Hello. Windows Hello “convenience PIN” is targeted for the home market and is, essentially, like a password vault. A PIN or biometric is used to reveal the password(s) in that vault.
• WHfB key trust uses an asymmetric key pair, a password is never hashed and sent across “the wire” which is what makes it particularly secure. The private key is secured, normally, using the Trusted Platform Module (TPM). The private key never leaves the device and is unique for every device. An alternative to WHfB key trust is WHfB certificate-based authentication.

Why Windows Hello for Business?

Passwords are weak. Full stop. In a world where Identity theft is on the rise and password lists can be purchased from the dark web for the price of a McDonalds coffee we need to do more to secure the identity of our workforce. Passwords are transmitted over the wire and are susceptible to many man in the middle and eaves dropping practices.

This leads to the question…

Why does WHfB address the weak password conundrum?

WHfB is considered a “Strong” authentication type. The Biometric and PIN are unique to a user on a specific device where as passwords can normally be used to validate a user from any device.

WHfB differs because the “Password” or “Private Key” never leaves the device. For WHfB key trust, a cryptographic key pair is bound to the TPM or in Software (less secure). WHfB policy dictates where the key is generated. The Identity Provider (IDP) has the public portion of the key that is mapped to the user account during the registration process. Even when a token is generated by the Identity Provider (IDP) it is bound to that specific device.

Unlike some Multi-Factor (MFA) methods, WHfB is considered “Phish Resistant”. This means that strong authentication cannot be phished, unlike “One Time Passwords” and “Push Notifications”.

When we talk about WHfB, many orgs think about key trust but certificate trust is also another valid way to ensure a strong logon to a device. Certificate trust is used by orgs leveraging ADFS.

WHfB is great, and a much stronger alternative to passwords, but there are still scenarios where some might consider the PIN is weak compared with a password. If you deploy a WHfB policy and require a 4 digit PIN, will most users use the day and month of their birthday for the PIN – or perhaps a phone number? This information can be easily phished through social engineering.

Also consider if a laptop is stolen on a train and the PIN is shoulder surfed – an attacker has access to the device*

We are not saying don’t use WHfB because of these scenarios but you should be aware of them when deciding on your WHfB PIN policy and Conditional Access design.

* TPM anti-hammering can prevent an attacker guessing the PIN incorrectly too many times.

Key Trust

Many organizations have already deployed WHfB key trust. If you are still requiring your devices to access on-premise resources, the single biggest pitfall is during initial deployment.

A synced user identity is required in a hybrid environment. Image you have a shiny, internet born device, enrolled in Azure AD and managed by Intune but you want the user to still access resources within your domain. We spoke about this scenario and the requirements in our SSO mega series.

SSO to domain resources from Azure AD Joined Devices – The MEGA Series – Part 1 – Overview – MSEndpointMgr

During the provisioning of WHfB, there is a delay while the Next Generation Credential (NGC) is written back to the Active Directory User object – specifically the msDS-KeyCredentialLink attribute.

Below is a high level flow for a typical first logon in a hybrid scenario when the user is prompted to setup WHfB.

1. User signs in and is prompted to setup WHfB
2. PIN is set and Biometric (if applicable) is chosen
3. NGC written to Azure AD user object
4. ADConnect, by default every 30m, synchronizers the NGC to the Active Directory User object.

Until that AD Sync happens, the user cannot authenticate to on-premise resources with WHfB. This results in a poor first-run experience where users would setup WHfB and then be told by IT they need to sign back in with their password or “go and have some pie and wait an hour before trying again”.

Key Trust Pain Points

• Requires a Certificate Authority and a valid trust chain from the device to a 2016 DC.
• In order for SSO to function on an Azure AD joined device you need to publish a CRL. This can be challenging to configure and debug if you are not comfortable with Enterprise PKI.
• SSO will not work until the NGC is synced back to Active Directory

Certificate Trust

The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience of WHfB.

Companies using ADFS only had the option to use certificate trust. We still found, in our experience, that most companies used the key trust type for WHfB. Did anybody who configured certificate trust live to tell the tale even? Who knows!

Our thoughts on certificate trust are few, so we won’t dwell on it in this post.

Certificate Trust Pain Points

• Requires a Federated domain. AD federation with AAD. (Who else vomited a little in their mouth when they read ADFS?)
• Requires a PKI for SSO to on-premises resources. Users are issued certificates during enrollment to WHfB.
• Certificate requirements are complex – no one got no time for legacy PKI design.

What is Cloud Kerberos Trust?

WHfB hybrid key and certificate trust always had a lot of moving parts. AD Connect, Device Registration, PKI, sync wait times and more. There was often misunderstanding on configurations, timings and almost every blog post or Microsoft doc you looked at never quite explained the setup for your specific scenario.

Microsoft knew this complexity was a roadblock to many and they really wanted to help organisations improve their authentication posture – moving away from insecure passwords was an itch everyone was eager to satisfy.

The big challenge they had to solve was the reliance on the credential sync and complex configuration of many moving parts. Along came Azure AD Kerberos.

Azure AD Kerberos was first brought in to enable FIDO2 authentication on HAADJ devices. Azure AD Kerberos facilitates kerberos ticket issuance by Azure AD instead of on-premises Domain Controllers. Because a DC was not critical to the ticket issuance, neither was the wait for AD Connect to sync when a user first setup their WHfB credential. Azure AD Kerberos allows AzureAD to issue TGT’s that came down with the PRT – amazing stuff.

Onto a winner:-

• No need to deploy a public key infrastructure (PKI) or to change an existing PKI
• No need to synchronize public keys between Azure AD and Active Directory for users to access on-premises resources. This means that there isn’t delay between the user’s WHFB provisioning and being able to authenticate to Active Directory
• Passwordless security key sign-in can be deployed with minimal extra setup

At a high-level, “Cloud Trust” means, that we establish a chain of trust directly with Azure Active Directory. Instead of a triangle of trusts that involve our local AD, PKI, the device TPM storage things become incredibly simple, incredibly quickly.

The big game changer with Cloud Key Trust is WHfB works immediately after enrolment for SSO to domain resources

There is no need to wait for Azure AD Connect to sync some public key material to establish the trust, or anything like that. It. Just works. So, that’s the first problem Cloud Kerberos Trust solves – the users waiting for sync and the issues that arise from trouble with the msDS-KeyCredentialLink in AD.

The Second problem Cloud Kerberos Trust solves – no more PKI requirements or CRL over http required for hybrid devices.

A third problem Cloud Kerberos Trust solves, limited normally to large organisations, is the added CPU overhead for KDC Authentication when using key trust. In some instances those organisations had to spin up extra domain controllers to handle the extra processing load.

Can I get rid of the PIN requirement now?

“Silly rabbit! Trix are for kids” And tricks like removing the PIN code is not a thing.
You need the PIN as a fallback for your. biometrics, just like with any passwordless solution out there, we need a way for the user to recover in case their biometrics fail, or if there simply are no biometrics available.

Remember fundamental principles of multi-factor authentication.

• Something the user has: Any physical object in the possession of the user, such as a security token (USB stick), authenticator app, their device, etc.
• Something the user knows: Certain knowledge only known to the user, such as a password, PIN, etc.
• Something the user is: Some physical characteristic of the user (biometrics), such as a fingerprint, etc.

So if your argument is that the PIN seems insecure compared to a password, think again – it ONLY relates to the unlocking of your access token in the TPM for use in Windows Hello for Business. The password on the other hand will let you in from a remote location, which is ideal for a hacker or any bad actor.

But of course, protecting the PIN is still important, so here are a few strategies to consider if you feel that the PIN is a security risk (These are notes from the field and not necessarily to be considered recommendations).

1. Teach users to only use Biometrics, and have a policy of only using the PIN in a secure way (e.g. never in the open Office, and always looking over their shoulder while wearing a tin fil hat!)
2. IT can be a part of the WHfB provision process, and choose the unique PIN for the users. This PIN could be kept with IT, and never disclosed to the user unless required. If you choose this option, remember to disable PIN recovery for the users, and have a policy of never using the same PIN on multiple devices. Using this strategy is not recommended, as you are essentially creating a treasure chest for any bad actor to abuse (i.e. insider risk)
3. Make the PIN more complex but avoid making it possible for the user to replicate their actual password (if you are still providing them with such a relic). This could be achieved by adding a requirement for the use of lower case letters (not upper case) besides just the digits.

As a final word of advice – consider your very own smartphone. How do you login to that?
Face? Fingerprint? PIN? – Regardless of your answer, consider that you are holding on to that device 24/7 like a crack addict. And just put things into perspective, when you say that PIN seems less secure than a password.

How does authentication work to on-premise resources?

After Cloud Kerberos Trust s is enabled for the user (see the next post in our mini series), we can observe the following authentication flow when we attempt to access domain resources – after all, the main purpose of enabling Cloud Trust with WHfB is for SSO authentication to domain resources.

• There is still a requirement for the user to be synchronized from Active Directory. This is how we discover the domain name associated with the user in order to request tickets from the KDC. Authentication to Active Directory from an Azure AD joined device begins when the user first attempts to use a resource that needs Kerberos authentication.
• The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user’s domain.
• Using the hint, the provider uses the DClocator service to locate a 2016 domain controller.
• DCLocator needs a domain hint, which it gets from the onpremisedomainname that came down with the PRT.
• A Domain Controller (KDC) is then returned to the client to continue normal service ticket issuance.

Note If DNS is broken this lookup will fail – it’s always DNS when things fail
_{(except when it’s routing)}

• After locating an active 2016 domain controller, the Kerberos provider sends a partial TGT that it received from Azure AD from a previous Azure AD authentication with the domain controller.
• The partial TGT contains only the user SID and is signed by Azure AD Kerberos.
• The domain controller will verify that the partial TGT is valid.
• On success, the KDC returns a full TGT to the client so the client can begin requesting service tickets.

In summary, Azure AD Kerberos issues a partial TGT to the user. The partial TGT is then exchanged for a full TGT from the KDC and normal service ticket issuance continues when the user tries to access domain resources

TIP

DNS hit and miss in your place? You can test if DCLocator is able to return a list of valid DC’s by running the nltest command

nltest /dsgetdc:contoso.local

Summary

In part 1 of this mini series we introduced the concept of Cloud Kerberos Trust. Being able to receive partial TGT’s from Azure AD is a game changer in terms of speed to SSO logon for on-premises resources AND for simplicity of configuration for admins.

In Part 2 we will look at how to configure Cloud Kerberos Trust. Stay tuned for more fun!

(15)

The post Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 1 appeared first on MSEndpointMgr.

Finding Devices in need of Replacement

To start the device refresh process, endpoint managers first need to identify endpoints for replacement this year. Many organizations go about this in their own ad hoc way. For instance, some try to incorporate information about the machine purchase date into their naming convention. This too often leads to confusion if not executed properly.  

Another common device replacement strategy is to identify the machines that either already have their warranty expired or are up for expiration this year. Depending on the organization’s hardware inventory tracking system, this can be a very tedious task. IT teams must manually gather service tags and then go out and check them against the OEM’s warranty checking utility on their individual websites. This process can become a black hole for the team’s time, especially in organizations that have device counts in the thousands or tens of thousands.  

Identifying devices for replacement is the crucial first step. Only then can the team start to formulate a new hardware budget for the year.  

Device Warranty Information Reporting

Endpoint Insights from Recast Software, also the creator of Right Click Tools, reduces this friction with its warranty information reporting. Endpoint Insights gathers information about the devices (make, model, serial number, etc) and then sends it over to Recast where that information is normalized and passed over to the OEMs (over 100 supported) via an API. The warranty information is then returned right to your ConfigMgr database. This allows IT teams to cut out the manual process of checking different OEM’s websites to get the warranty information on the devices. This is especially useful after the pandemic caused supply shortages that forced many organizations to buy any hardware available. This often included hardware outside of the company’s norm. Endpoint Insights handles all of this for you and makes the information readily available for all your devices with reports that find the warranty information for a single computer or all devices via device collections to ensure you have a clear and complete view of your warranty statuses.  

Additionally, Endpoint Insights features a report that is specifically built to both identify devices needing replacement and assist in building a budget. The Computer Replacement Costs Calculator powerfully pulls all your device warranty information into one place and helps you build out a custom budget based upon your specific circumstances. The report gives you a clear picture of all devices currently out of expiration, as well as devices coming up for expiration in the next few years. This adds clarity and accuracy to your budget forecasts and planning. Furthermore, you can input your own data regarding how much you spend per device type (desktop, laptop, server, etc), as well as how long you typically keep each device. With your company-specific data entered, IT teams get a customized budget estimate. No need to pull together your own spreadsheets to gather a rough estimate. 

More Thorough Device Replacements

During the execution of a device refresh, there are a few scenarios that often result in additional follow-up appointments for the IT team. Case in point: arriving at the replacement appointment with missing components. This could include missing software, missing printers, or the wrong cables for the current monitor. These tedious issues cause headaches for both the IT staff and the end user, who is now missing hardware or software they need to continue working. More broadly, this issue agitates both the IT staff and end user, reducing confidence and trust in the institution. 

Here too Endpoint Insights can assist. In addition to warranty data, Endpoint Insights pulls in supplementary datapoints that provide a more detailed view of your endpoints than ConfigMgr offers natively. These additional data points include monitor information (yes, even the connection type), mapped printers, mapped drives, installed software (including user installed), docking stations, and more. With these pieces of information pulled into ConfigMgr, IT teams can ensure that their end users receive the best possible experience when transitioning to their new devices. The last thing you want to do when making the trek to replace a device is to have to return later because you brought the wrong display cables. It feels terrible reconnecting the old machine, then returning back to the home office without the task completed.  

Utilizing these additional Endpoint Insights data points and reports makes it easier to confidently show up to device replacements knowing you have all you need. The All-in-One Computer View report functions as a solid starting point for the computer needing replacement. This report provides valuable information including the monitors connected to the device, any docking station connected, as well as the applications installed on the device. To access this report within ConfigMgr, right click on the device, hover over Right Click Tools, then over Endpoint Insights, and finally select the All-in-One Computer View.  

Installing Mapped Drives and Printers on new Devices

To ensure that all the mapped drives and printers are added, Endpoint Insights offers other reports to assist. In ConfigMgr reports, accessible within the ConfigMgr console or in the web portal, all Endpoint Insights reports are stored in the namesake folder. Mapped printers and mapped drives reports are in the “Users” folder, for example. To get a list of all mapped drives on a device check the “Computer Mapped Drive Details” and select the specific computer. This provides a detailed list of all the drives on the device, including the drive letter and the UNC path for the mapped drive.  

Similarly, for the mapped printers check the “Computer Mapped Printer Details” report to get a list of all the printers on the device. This will detail the port the printer is installed on, as well as the server and share names if it is being hosted on a print server.  

Streamline Hardware Inventory Planning and Device Refreshes

Check out this Endpoint Insights page to learn more about the powerful hardware and software data and reports added to your ConfigMgr instance by Endpoint Insights. You can also request more information, including a custom quote here.  

Additionally, watch our recent five-part webinar series on Endpoint Insights. Garth Jones and the team dig into many of the core features in this multi-part webinar. 

(1)

The post Device Refreshes Simplified with Endpoint Insights appeared first on MSEndpointMgr.

In this post I will revisit Co-management workloads, capabilities and take a walk down memory lane.

Background

Ok, let’s expand on what “Moving to the Cloud” means to us – and that varies, a lot, depending on who you speak to. Quite often our journey to the cloud is complex. We don’t have a magic button that shifts everything from on-premises to the Cloud and then cuts our operational bill in half – that kind of thinking belongs with an eccentric wizard and his hobbit friends. More often the path is much more complex.

I remember being an admin when “The Cloud” burst onto the scene. Technologies were being born and new concepts like “Its a journey, not a destination” were being spread like wild fire. I had a feeling of urgency that I had to move our organisation with the times and current trends but it was more than that. There was a sense that the old days of baby sitting the Exchange server in the corner were coming to an end and this new, cloud first, world needed learning, chasing and embracing.

The biggest challenge that I remember churning through my over analytical brain was “How does this all come together and look at its conclusion”. I didn’t really have an overall picture of how this puzzle would look when it was complete. What part of my infrastructure would remain on premises and what would be in the cloud. It was very much a case of take baby steps and trust in the process. Cloud strategies hadn’t matured and many of us felt like early pioneers in the “Moving to the Cloud” gold rush. This was exactly how Ernest Shackleton must have felt on that fateful journey to Antarctica…our cloud journey was bound to end in disaster but we all crossed our fingers and trusted in the marketing headlines.

Configuration Manager “The steady ship”

Like me, many admins had managed a steady ship for years. She was the pride of the fleet. Maturing from year to year with no end in sight to her prowess. Configuration Manager was/is a master piece. We got a sense that the white fluffy things (clouds) were on the hymn sheets in Microsoft HQ when we saw technologies like IBCM and Cloud DP come into the portfolio.

Organisations started asking us if we could manage mobile devices with Configuration Manager, which was an interesting chapter in many of our lives, and we started to get a taste of something on the horizon. Intune was afoot…

https://learn.microsoft.com/en-us/mem/intune/fundamentals/ui-changes

Intune “The Cloud”

Intune burst onto the scene and felt like this bold, new, idea that would help us navigate seamlessly to the cloud. I and many others were wondering how and when to embrace the Cloud, Microsoft too were stepping into a new era with a stronger focus on the fluffy white stuff.

Intune matured, slowly at first but then more rapidly when released from the shackles of Silverlight. We could see how promising cloud management could be and like kiddies in a candy shop, we had no patience. We wanted ALL the features and control that we were used to in Configuration Manger and we wanted it now.

Intune, for all it promised to be, actually presented us with some difficult conundrums. We wanted to embrace the cloud but there wasn’t a simple “Do it” switch. Microsoft still hadn’t worked that part out. Instead, we were faced with challenges like hybrid identities, ADFS (painful memories), the advent of AD Sync, moving mobile device management from ConfigMgr to the Intune, ensuring GPO’s didn’t conflict with Intune policy. It was a hot spaghetti mess that would trip you up if you didn’t navigate the pot holes like a cautious badger on stilts.

Co-management “The Bridge”

Enter Co-management. This was hands-down the most promising technology yet to help us transition smoothly to device management from the Cloud. Co-management finally allowed us to move different workloads to Intune, at our own pace. We had options. It was no longer the choice of “do nothing” vs “big bang cutover”.

Fast forward to today. Co-management has matured – a lot. She still has a little way to go and the story isn’t complete but golly are admins faced with much easier migration challenges today than we were 10 years ago.

Workloads

I wanted to focus this post on something I have been looking at recently

Workloads is a concept that allows us to move individual “workloads” from Configuration Manager to Intune. What are the workloads we can move? The options have changed over recent years, today we have the following:-

• Compliance Policies
• Resource Access Policies
• Device Configuration
• Windows Update Policies
• Client Apps
• Office Click-2-Run Apps
• Endpoint Protection

Microsoft have a great doc explaining what moving each of the these workloads means, I won’t duplicate that information in this post. Go check out Co-management workloads – Configuration Manager | Microsoft Learn

The great thing about workloads is that you can move them, individually, at a pace that suits you and your adoption of the Cloud.

I wanted to focus this post on something I have been looking at recently and that is workload capabilities.

Capabilities

Capabilities have fascinated me since I blogged on them back in 2019

• Co-management Series “Merging the Perimeter” – Part 7: Co-management Capabilities (byteben.com)
• SCCM 1906 Co-management Capabilities Matrix (byteben.com)

Every workload has an associated numerical value. We refer to this as the capability number. You can very easily see the capability value assigned to the client in the ConfigMgr control panel applet and CoManagementHandler.log

Up until recently we grew familiar with the capability values. Enter ConfigMgr 2111 – enter crazy values.

We should remind ourselves what these values are and what they represent. Each workload has a corresponding value. Before ConfigMgr 2111, they looked like this:-

Now, they look like this

When we start to move workloads to our to Intune, the capabilities value reflects the combined workloads.

For example, moving client workloads for Compliance Polices and Client Apps used to give the client a Co-management capability of 67. But how do we get to this number? 67

Co-Management Enabled (1) + Compliance Policies (2) + Client Apps (64) = 67

Bitwise Operations

That looks fairly straight forward right? Well yes, we could calculate the value previously by doing a basic math sum, but capabilities are more complex when you dive a bit deeper. What we should actually be doing is a bitwise operation on the binary value of the capability number.

Lets look at the capability value binary representation.

We can perform a bitwise operation on multiple capability values to get a new capability value. What happens when we have “Co-management Enabled” (8193) and the “Compliance” (2) workload moved to Intune?

10000000000001 -bor 00000000000010 = 10000000000011

If we look at the bitwise calculation below, we are actually returning 1 when either one or both bits, in each corresponding column, equals 1

10000000000001
00000000000010
10000000000011 = 8195

PowerShell

My colleague Cody Mathis (brilliant brain) had previously written some neat code to work out the combined capability values using bitwise operations. Combining capabilities with the -bor operator and comparing them with the -band operator to convert Co-management workloads from and to their text representations. Take a look at his work script at CM-Ramblings/Convert-CoManagementWorkload.ps1 at master · CodyMathis123/CM-Ramblings · GitHub

What prompted me to re-think capabilities again was when I saw a tweet from Loan Popovici @MEM.Zone on Twitter

I had not considered using flags with enum definitions before with PowerShell. It actually makes the PowerShell much simpler. Lets take a look

[flags()] Enum workloads {
        CoMgmt_Enabled = 8193
        Compliance_Policies = 2
        Resource_Access_Policies = 4
        Device_Configuration = 8
        Windows_Update_Policies = 16
        Client_Apps = 64
        Office_Click2Run_Apps = 128
        Endpoint_Protection = 4128
    }

And we throw a capability value in

[workloads]8195

This is cool.

Functions

I put together a function that allows you to pass single or multiple capability values to see the workloads

Function Get-Workload {
    [CmdletBinding()]
    Param(
        [Parameter(Position = 0, Mandatory = $true)]
        [ValidateRange(1,12543)]
        [Int32[]]$capability
    )

    #Create enumurator for workload flags // ConfigMgr 2111+
    [flags()] Enum workloads {
        CoMgmt_Enabled = 8193
        Compliance_Policies = 2
        Resource_Access_Policies = 4
        Device_Configuration = 8
        Windows_Update_Policies = 16
        Client_Apps = 64
        Office_Click2Run_Apps = 128
        Endpoint_Protection = 4128
    }

    #Create an ordered hash table to capture all capabilities
    $allCapabilities = [Ordered]@{}

    ForEach ($capNum in $capability) {

        #Evaluate capabilities 
        If ($capNum -eq 1) {
            $capResult = @("CoMgmt_Disabled")

            #Build hash table of results
            $allCapabilities.Add([string]$capNum, $capResult)
        }
        elseIf ($capNum -eq 8193) {
            $capResult = @("CoMgmt_Enabled_NoWorkloads")

            #Build hash table of results
            $allCapabilities.Add([string]$capNum, $capResult)
        }
        elseIf ($capNum -lt 8193) {
            $capResult = @("Invalid_Workload_Value")

            #Build hash table of results
            $allCapabilities.Add([string]$capNum, $capResult)
        }
        else {
            Try {
                $workload = [workloads]$capNum

                #Build data if a valid flag is matched
                If ($workload -like "*_*") {
              
                    #Filter out CoMgmt_Enabled value - we assume it is enabled if we have a workload match
                    $capabilities = $workload -split ', ' -notmatch 'CoMgmt_Enabled'

                    #Tidy up and export capabilities sorted to an array
                    $capabilities = $capabilities | Sort-Object
                    $capResult = @($capabilities)

                    #Build hash table of results
                    $allCapabilities.Add([string]$capNum, $capResult)
                }
            }
            Catch {
                #Do Nothing, ignore invalid values
            }
        }
    }
    Return $allCapabilities
}

With the values sorted as an array in the hash table, we can throw this out as a JSON for giggle

It got me thinking. Thinking big. Lets use a similar function to generate ALL the possible workloads combinations.

ConfigMgr 2111+ Capability Values

A similar function will export all possible workloads

Function Get-AllWorkloads {
    
    #Create enumurator for workload flags // ConfigMgr 2111+
    [flags()] Enum allWorkloads {
        CoMgmt_Enabled = 8193
        Compliance_Policies = 2
        Resource_Access_Policies = 4
        Device_Configuration = 8
        Windows_Update_Policies = 16
        Client_Apps = 64
        Office_Click2Run_Apps = 128
        Endpoint_Protection = 4128
    }

    #Create an ordered hash table to capture all capabilities
    $allCapabilities = [Ordered]@{}

    8195..12543 | Foreach-Object {

        $capNum = [string]$_

        #Evaluate capabilities s
        Try {
            $workload = [allWorkloads]$capNum

            #Build data if a valid flag is matched
            If ($workload -like "*_*") {
              
                #Filter out CoMgmt_Enabled value - we assume it is enabled if we have a workload match
                $capabilities = $workload -split ', ' -notmatch 'CoMgmt_Enabled'

                #Tidy up and export capabilities sorted to an array
                $capabilities = $capabilities | Sort-Object
                $capResult = @($capabilities)

                #Build hash table of results
                $allCapabilities.Add($capNum, $capResult)
            }
        }
        Catch {
            #Do Nothing, ignore invalid values
        }
    }
    Return $allCapabilities
}

This is cool. Let’s throw that into a JSON

{
  "8195": [
    "Compliance_Policies"
  ],
  "8197": [
    "Resource_Access_Policies"
  ],
  "8199": [
    "Compliance_Policies",
    "Resource_Access_Policies"
  ],
  "8201": [
    "Device_Configuration"
  ],
  "8203": [
    "Compliance_Policies",
    "Device_Configuration"
  ],
  "8205": [
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8207": [
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8209": [
    "Windows_Update_Policies"
  ],
  "8211": [
    "Compliance_Policies",
    "Windows_Update_Policies"
  ],
  "8213": [
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8215": [
    "Compliance_Policies",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8217": [
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8219": [
    "Compliance_Policies",
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8221": [
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8223": [
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8257": [
    "Client_Apps"
  ],
  "8259": [
    "Client_Apps",
    "Compliance_Policies"
  ],
  "8261": [
    "Client_Apps",
    "Resource_Access_Policies"
  ],
  "8263": [
    "Client_Apps",
    "Compliance_Policies",
    "Resource_Access_Policies"
  ],
  "8265": [
    "Client_Apps",
    "Device_Configuration"
  ],
  "8267": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration"
  ],
  "8269": [
    "Client_Apps",
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8271": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies"
  ],
  "8273": [
    "Client_Apps",
    "Windows_Update_Policies"
  ],
  "8275": [
    "Client_Apps",
    "Compliance_Policies",
    "Windows_Update_Policies"
  ],
  "8277": [
    "Client_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8279": [
    "Client_Apps",
    "Compliance_Policies",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8281": [
    "Client_Apps",
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8283": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Windows_Update_Policies"
  ],
  "8285": [
    "Client_Apps",
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8287": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8321": [
    "Office_Click2Run_Apps"
  ],
  "8323": [
    "Compliance_Policies",
    "Office_Click2Run_Apps"
  ],
  "8325": [
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8327": [
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8329": [
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8331": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8333": [
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8335": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8337": [
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8339": [
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8341": [
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8343": [
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8345": [
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8347": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8349": [
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8351": [
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8385": [
    "Client_Apps",
    "Office_Click2Run_Apps"
  ],
  "8387": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps"
  ],
  "8389": [
    "Client_Apps",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8391": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8393": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8395": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps"
  ],
  "8397": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8399": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "8401": [
    "Client_Apps",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8403": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8405": [
    "Client_Apps",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8407": [
    "Client_Apps",
    "Compliance_Policies",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8409": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8411": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "8413": [
    "Client_Apps",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "8415": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12321": [
    "Endpoint_Protection"
  ],
  "12323": [
    "Compliance_Policies",
    "Endpoint_Protection"
  ],
  "12325": [
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12327": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12329": [
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12331": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12333": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12335": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12337": [
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12339": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12341": [
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12343": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12345": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12347": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12349": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12351": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12385": [
    "Client_Apps",
    "Endpoint_Protection"
  ],
  "12387": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection"
  ],
  "12389": [
    "Client_Apps",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12391": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12393": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12395": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection"
  ],
  "12397": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12399": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies"
  ],
  "12401": [
    "Client_Apps",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12403": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12405": [
    "Client_Apps",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12407": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12409": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12411": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Windows_Update_Policies"
  ],
  "12413": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12415": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12449": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12451": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12453": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12455": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12457": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12459": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12461": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12463": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12465": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12467": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12469": [
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12471": [
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12473": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12475": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12477": [
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12479": [
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12513": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12515": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12517": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12519": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12521": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12523": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps"
  ],
  "12525": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12527": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies"
  ],
  "12529": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12531": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12533": [
    "Client_Apps",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12535": [
    "Client_Apps",
    "Compliance_Policies",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12537": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12539": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Windows_Update_Policies"
  ],
  "12541": [
    "Client_Apps",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ],
  "12543": [
    "Client_Apps",
    "Compliance_Policies",
    "Device_Configuration",
    "Endpoint_Protection",
    "Office_Click2Run_Apps",
    "Resource_Access_Policies",
    "Windows_Update_Policies"
  ]
}

What Next?

The reason I created functions for this is because I am playing. I have never built my own API before and this dataset gives me the perfect excuse to go learn API’s. Over the coming weeks/months I intend to blog on my journey to create an API so we can display the workloads in a browser using a simple URL GET method. Fun times ahead

Summary

In this post I reminisced the journey from on-premises to the cloud and re-visited a favorite topic of mine – Co-management. I always wanted to re-create a table of the new Co-management capabilities like i did back in 2019 but instead of building a table – we automated it.

I hope the JSON is useful

Special thanks and credit to Loan Popovici for the inspiration and my colleague Adam Cook for helping with hash tables

(10)

The post Moving to the Cloud. Co-management workloads and capabilities (revisited) appeared first on MSEndpointMgr.

As the world becomes increasingly digital, the need for secure access to online accounts and systems becomes more critical than ever. One of the most effective ways to protect against unauthorised access is through the use of multi-factor authentication (MFA). In this article, we will explore the importance of MFA in the Microsoft Cloud and how it can help protect your organisations sensitive data and systems.

Introduction

Outline: For those who are unfamiliar with what a phishing attack is, it is where an attacker attempts to fraudulently obtain sensitive information from a user by posing as someone or something that the person/organisation trusts. Phishing attacks target passwords and usernames via various methods including email, pop-up windows, instant message, text messages, and social network sites. It ruins lives and cost companies millions of dollars each month. One of the best ways to protect against phishing attacks is through the use of MFA.

Takeaway: Use MFA or Passwordless. And do not click on links in unexpected emails from people you do or do not know. Always be suspicious of any link that requests you to enter your login credentials for an unknown site and be sure that a familiar sign-in page is using the right domain name in the address bar.

Disclaimer: There are a plethora of ways to put together MFA now a days, and not all scenarios or methods are covered in this article for the sake of readability.

What is multi-factor authentication?

Multi-factor authentication (MFA) is a process of verifying your identity by using more than one form of identification. It can be as simple or as complicated as you want it to be, but the goal is always the same: to make sure that only you can access your account.

There are three main types of MFA: SMS-based, app-based and hardware-based. Each type has its own advantages and disadvantages when compared with other methods, so let’s take a look at each one individually:

SMS-based MFA

This is the most basic form of two-factor authentication. When you enable it, you’ll receive a text message with a PIN code every time you log in to your account. You must enter this PIN into the site or app before gaining access to your account.

The benefit of SMS-based MFA is that it’s very easy to set up. You don’t need any special hardware or software, just a phone number and access to your email account. The downside is that there are often security issues with SMS messages—they can be intercepted by hackers or spoofed by scam artists who want to take over your account. If this happens, you’ll have no way to prove who you are without resetting all of your passwords.

App-based MFA

App-based MFA is similar to SMS-based MFA, but instead of receiving a code via text message, you receive it through an app on your phone. For Microsoft 365 users the best app is the Microsoft Authenticator, which can be downloaded for free from the Apple App Store or Google Play Store. Once you install it, all you need to do is scan a QR code using the app and then enter the six-digit code into the set up wizard. The benefit of app-based MFA is that it’s more secure than SMS-based MFA because the authentication process is tied to your physical device and not sent unencrypted over the airwaves.

The downside is that it’s more difficult to set up. You need to install an app on your phone and then scan a QR code using that app, which can be tricky if you’re not tech savvy.

Hardware-based MFA

The most secure way to set up Multi-factor authentication is with a hardware token. This device can look like a USB flash drive, but instead of containing files, it contains a secure chip that generates one-time passwords (OTPs). When you install the software on your computer and plug in the hardware token, you’ll be prompted to enter your username and password before it will generate any codes for you. This is a solution often used in companies where employees don’t have access to a phone, and hence they are unable to use SMS or App.

The benefit of hardware-based MFA is that it’s more secure than any other method of two-factor MFA authentication. The downside is that it’s more expensive and difficult to set up. You need to purchase the device and then install software on your computer that works with the token—something most people don’t have the time or inclination to do.

Again, why is multi-factor authentication so important?

Multi-factor authentication is a way to protect your accounts from being hacked by using more than one method of verification. It’s important to have this on all of your accounts because it works as an extra layer of security that prevents unauthorised access to your account and prevents identity theft.

Being passive about this type of security can actually leave you open to lawsuits. If your identity and the trust that others have in it, is used to commit fraud against others, then you are most likely going to be liable for the damages. These lawsuits have already happened and they are not in your favour if you as a person or as a company have been passive.

What has MFA done for the world?

MFA has reduced the amount of fraudulent sign-ins on accounts since its inception. In fact, MFA provides an added layer of security that gives users (and admins) peace of mind when it comes to their corporate/personal information and financial data.

MFA has:

• Reduced risk of account takeover
• Reduced risk of phishing attacks and identity theft
• Reduced risks associated with password reuse by requiring two-factor authentication every time you log in (even if you’re using a password manager)

Remember to thank your MFA device when you use it.

What is better than MFA?

A concept that is quickly gaining in popularity is the Passwordless sign-in. Which is the next step in authentication evolution. It is basically a method to login without a password, and thus prevents anyone from stealing it in the first place!

Microsoft offers easy on-boarding to Passwordless with their Authenticator Phone sign-in feature and for the Windows desktop they have Windows Hello for Business as an excellent offering.

Passwordless technologies aim to address some of the weaknesses of MFA. But, remember that any MFA solutions is better than no MFA solution!

But, I digress, this article was only meant to be about Multi-factor authentication (MFA). So, Follow along here on the blog for an article on passwordless in the near future!

In the mean time you can enjoy learning how to enable Passwordless using the Microsoft Authenticator, in this article on Microsoft Learn.

Conclusion

Multi-factor authentication is an essential tool for protecting against unauthorised access to online accounts and systems. By using a combination of something you know, something you have, and something you are, MFA provides an extra layer of security that makes it much more difficult for cybercriminals to gain access to your sensitive data and systems.

If you want to learn more about how MFA can protect your business, check out the article on Microsoft Learn that shows how you can get started on this important first step on your journey towards Zero-Trust and a Passwordless future!

(6)

The post 2FA/MFA – Why multi-factor authentication is important appeared first on MSEndpointMgr.

Importance of BitLocker

While we often speak of cyber security in terms of access to privileged accounts and our organization’s systems, there is another piece of the security puzzle that is just as important. Keeping physical devices safe deserves the same level of attention. Important company data is often stored on users’ laptops (whether it should be or not). With the amount of work travel that takes place, some devices are bound to get lost or stolen. The last thing any organization wants is the CEO’s laptop out in the wild unencrypted with confidential data ready for the taking. Enter Bitlocker, a tool that exists to keep that data safe when a device gets lost or stolen.

In a blog series on this site, Maurice Daly covered the topic of migrating away from standalone MBAM (Microsoft BitLocker Administration and Monitoring) to ConfigMgr BitLocker Management. Thankfully, Bitlocker management within ConfigMgr can be greatly simplified by using Right Click Tools. Whether you need a web-based report to pass over to security, a full view of how many of your devices are encrypted, or a simple way to retrieve a recovery key to get your end user back up and running, Right Click Tools streamlines your Bitlocker management within ConfigMgr.  

How Right Click Tools Helps

Whether you are just getting started with your BitLocker rollout or have Bitlocker fully implemented and only need to ensure all your devices are remaining properly encrypted, Right Click Tools can assist. The BitLocker Compliance Dashboard within Right Click Tools serves as a great resource to understand where your environment is sitting in terms of encryption. The dashboard gives you graphical overviews of recovery key storage (AD, CM BLM, MBAM, all locations, or the dreaded no keys stored), as well as unified compliance. You can click into any piece of the pie to see the endpoints that fall under that category. This will also uncover some more information about the devices including the encryption method used on the device. Knowing all this information is great, but the fully actionable dashboard makes it powerful. If you find any gaps, you can quickly act right away without needing to leave your ConfigMgr console.

The BitLocker Compliance Dashboard isn’t the only way Right Click Tools helps with BitLocker in your ConfigMgr console. If you need to quickly pull a BitLocker recovery key for a device, you can easily right click a device to access Right Click Tools, open security tools, and retrieve that device’s recovery key.

If you are looking to check up on the BitLocker compliance of a specific device, the Remote Windows Security Tool is the perfect place to get all the information you need in one place. From Remote Windows Security, users can gain insight into the drive with information on its protection status, the encryption method currently in use, and the key protectors currently active for that drive. Users can also take action right from within this tool. So, if organizations happen to find that the drive is not currently encrypted, they can take care of it right away.

As alluded to previously, the Right Click Tools Bitlocker Compliance Dashboard can also generate web-based reports to send over to security or management. Anybody who needs to see the compliance levels without accessing the ConfigMgr environment will find these reports helpful. Running a Recast Management Server (RMS), which is included with your Right Click Tools Enterprise License, gives users the ability to pass along web-based reports (including BitLocker compliance). Organizations can then keep the appropriate people up to date on compliance levels without having to worry about them entering directly into the ConfigMgr environment.

Bitlocker Streamlined

The BitLocker Compliance Tool dashboard is designed to get users quick information about BitLocker in their environment. It also enables users to quickly take action to remediate issues that they may find.

Let Recast know if you have any questions, or if you think the BitLocker Compliance Tool dashboard could help you. Reach out here.

(1)

The post How to Streamline BitLocker Management in ConfigMgr appeared first on MSEndpointMgr.

Introducing the MSEndpoingmgr Intune Audit Dashboard, a KQL workbook to make your life a little bit easier when it comes to auditing events in your Intune environment.

Auditing Events You Say…

Auditing, love it or hate it, provides an integral part of your infrastructure when it comes to the who, where, and why of what is going on. I’m sure many of you will have examples over the years where a colleague or an external consultant has changed something in your environment, resulting in something, somewhere going bang. On the flip side I know I have used these logs to prove it wasn’t me, so they can be your saving grace right when you need them.

Intune Audit Logs

Traditionally though audit logs are often overlooked, or when you go to use them, you might find that they appear to be difficult to work with. When it comes to Intune, we find the audit logs in the “Tenant administration” blade, and when we start to filter the actions, we can quickly see that for some admins the poses a challenge.

Which event should I search for? Which object ID was targeted? Unless you are using these logs regularly it came be less than intuitive at times to find that smoking gun. This is the kind of feedback we hear, and we wanted to do something about it.

First things first though..

Diagnostic Settings / Log Analytics

When setting up a tenant, the first thing I would always do is enable the diagnostic settings. The reason for this is simple, I want to have the logs available in a format that I can interrogate easily, and also control the retention of data within.

If you are not sure of where this is done, it is simple (please note you do need an Azure subscription and at least contributor rights to a log analytics workspace);

• Log into the Intune Admin Portal (yes, I am just calling it this from here on!) – https://endpoint.microsoft.com
• Click on “Tenant administration”
• Click on “Diagnostic settings”
• Clik on “Edit Settings”
• Select the logs you wish to send to Log Analytics;

• Click on “Send to Log Analytics workspace”
• Select the Subscription and Log Analytics workspace
• Click on “Save”

Once this is done you will start to see entries forming in the following Log Analytics workspace tables;

• IntuneDevices
• IntuneOperational Logs
• IntuneDeviceComplianceOrg
• IntuneAuditLogs

For the next part of this post, we are going to focus just on the IntuneAuditLogs and IntuneDevices tables, as they will be used to generate a reporting dashboard.

KQL FTW (Yes, Again)

You probably know that we are big fans of KQL, so I won’t bore you with the selling you the why, how, or where, but what I will do is to tell you, you need to start using this. Think of KQL as the new PowerShell, it helps you find and report on data quickly and efficiently.

Looking into the IntuneAudtLogs, we have a wealth of information, where we can quickly search and start to build up a picture about admin actions. This is great if you are familiar with KQL and writing queries, but we wanted to make this easy for you.

This is exactly what we have done, in the form of a KQL workbook that you can drop into your environment. Let us take a look at the latest in our workbook line;

Intune Audit Dashboard

The dashboard is broken up into several key areas;

• Summary
  The summary page gives you information such as the split of tasks and methods being undertaken by your admins, along with useful stats and trends
  

• Device Targeted Actions
  This page provides you with an overview of actions impacting on devices, such as wipe, reset, delete etc. Scrolling down you also see the following details;
  • Time Generated
  • Actioned By
  • Operation
  • Device Name
  • Device Id
  • Result
  • Management Type
  • OS
  • OS Version

• Target Actions
  On this page you will allow you to select actioned based on changes to policies, configurations etc

• Admin Actions
  Filter based on the actions of a particular admin

• Application Actions
  Filter based on the actions of a delegated application

• Detailed Audit Log
  The full detail of everything

More Details Please

Within the “Target Actions” and “Admin Actions” pages you will also see links to display additional information about the change event, such as in the example below;

Where audit events contain changes to profiles for example, the slide in workbook will also display the change details, comparing old against new values;

Workbook Source & Installation

The JSON source code for the main Intune Audit is available on our GitHub repo. During installation of the workbook, you will need to update elements within the JSON, or via the UI editor to display your information.

Intune Audit Dashboard – Main JSON – Reporting/IntuneAuditDashboard.json at main · MSEndpointMgr/Reporting (github.com)

• At lines 781 and 1801 where you see “%YourDomainHere%” replace that with your domain, i.e. MSEndpointMgr.
• At line 174 replace “%YourLogAnalyticsWorkspaceHere%” with the name of your Log Analytics workspace
• At line 7 replace the “%YourURLHere%” with the URL of your company logo

Intune Audit Details Dashboard – Details JSON – Reporting/IntuneAuditEventDetails.json at main · MSEndpointMgr/Reporting (github.com)

Conclusion

Through the use of Log Analytics and KQL, auditing doesn’t have to be a pain anymore, and if you have any suggestions on how we could extend this workbook, please let us know!

Please note that we will also be creating a solutions page soon with links to all of our KQL workbooks! Keep a lookout in the solutions section of the site.

(10)

The post MSEndpointMgr Intune Audit Dashboard appeared first on MSEndpointMgr.

Hi there! I am new to the MSEndpointMgr team and thrilled to be here!

In this blog post, we will look into Logic Apps and how we can achieve a governance-free model to how we can utilize this kind of low/no code technology and get the results that we want.
I have blogged about the subject earlier – how to e.g. get configuration changes made to Microsoft Intune. If you are interested you can read about that here.

What more is there to write? Well for starters Logic Apps are easy to work with if you use the built-in functionality, but what if you would like to be creative and draw outside the lines? You then enter a state where stuff can be complex and not very user-friendly as low/no code was built to be.

In this blog post, we will draw outside the lines. Why you may ask? Because Logic apps and their object typically have connectors into different services. These connectors either use your credentials or a service principle. Nothing wrong with that, but what if the user who build it, is no longer in your company? Yes, then the connectors used by your colleague will at some point not work anymore.
Your result will look like this and be published daily on your Teams channel.

How to get started

First we need to create a logic app. I will not demonstrate it here. It is straight forward and also demonstrated in the link provided in the top.

Go to your logic app and find Identity. Switch the tab to On and save it. A minute or two later a managed identity will be available to be used within the azure environment.

We will use our managed identity to access data in log analytics, so what we need is to assign the managed identity as a reader on the specific log analytics workspace where your Intune audit data is located. If you haven’t set up your Intune audit data yet, then follow this post on how to do so.

I am assuming you know how to locate your log analytics, and where to click to get started setting permissions on it.

Then we need to copy our code to the Logic App we created. Open your logic app

If you haven’t setup a Teams hook already, then here is a guide to do that.

1. copy the code from here
2. Paste it into the logic app
3. Replace in line 112 where it says a32a07c5-739b-40ce-9b3f-185733d5c0d0 and add your own Log Analytics workspace ID
4. Replace in line 225 where it says https://memtipsandtricks.webhook.office.com/webhookb2/d20c5efe-2f76-4897-8c90-2de8c0f76397@47a13e20-6415-4467-bfd3-b2acf62a3ed2/IncomingWebhook/ and add your own Teams hook
5. Save it

You will never ever have any surprises of changes in your Intune environment and neither will your colleagues.

(12)

The post Running logic apps without the need of governance appeared first on MSEndpointMgr.

If you have ever having issues with Autopilot or Enrollment Status page failing or timing out due to issues with Office installation, this blog post is for you. Over the years working in this area, the Office CSP has caused countless issues and deployments to fail. The Office CSP, commonly knows as the the built-in “Microsoft 365 Apps for Windows 10 and later” is actually not an app distribution in Intune. It is just a configuration policy. That means we are missing out on some of the normal app distribution features like requirements, dependencies and detection rules. The configuration policy tells Windows to download the Office Deployment Toolkit (ODT) and starts setup.exe with the configuration you provided either as XML or in the user interface.

With that in mind, I started looking into using Win32Apps in Intune for deploying the M365 Apps in a more controlled matter. Downloaded the ODT manually, created and XML file before finally packaged everything up as a Win32App and tested deployment. The Win32App package or IntuneWim file contained the content of ODT together with an XML file. This worked out really nice. The Office applications installed really fast and it was RELIABLE.

The issue with the “full” package”

Even though the metode above is a valid option, it is not dynamic enough. As there is a dependency between the ODT and the version of Office being deployed, the Win32App needs to be maintained over time by downloading a fresh ODT from time to time and update the package manually. There was also a request from customers using this to have some additional logging related to the installation for troubleshooting. So how can this be made super-dynamic and self-updating? In comes PowerShell.

The scripted way

All the issues with the “full” package could be solved using PowerShell as a wrapper to the installation. The install PowerShell script is doing the following:

1. A logging function takes care of the additional logging to a local file.
2. The script downloads the latest ODT direct from Microsoft every time
3. ODT is extracted to a temporary setup folder
4. The config.xml file is written to the same setup folder
5. Starting setup.exe with the config file to download and install according to your XML file.

In addition to this there is the detection scripts. This allows us to detect that whatever Office version or App we are installing is detected on the machine when installation is completed. Currently the provided script is checking if “any” x64 bit version is installed. This is to avoid issues with preinstalled M365 Apps on the machine or existing environments where office has been deployed the traditional way before. Updates of these apps should be handled by policies by Intune and not by deploying a newer version.

What is provided

In the Github repository containing this solution you willl find scripts and configurations files to handle the following:

• Installing M365 Apps
• Installing Visio
• Installing Project
• Installing or Uninstalling Proofing tools

The recommendation is to install only M365 Apps with a single language as required and then have these other options as available apps. If users needs Visio or a different proofing language, they should find then in Company Portal and install them,

You can find all the scripts and a more information on how to use this on GitHub: https://github.com/MSEndpointMgr/M365Apps

(2)

The post Installing M365 Apps as Win32 App in Intune appeared first on MSEndpointMgr.

Back in July last year we released a community version of our Windows Update Compliance dashboard, a KQL driven workbook that helped you visualise Microsoft Update Compliance data. Since then there have been a number of improvements both in the type of data and a version 2 schema update.

The good news is we have a new workbook for you, but some light reading first as to some of the changes at Microsoft’s end;

Microsoft Update Compliance Onboarding Change

Back on August 17th Microsoft also made a change to the onboarding process for Update Compliance, moving the onboarding out to the Microsoft 365 Administrative Center. The new onboarding process is straight forward, where we simply select the Azure subscription and log analytics workspace to be used for storage of your UC logs;

Personally I’m not quite convinced by the location of this onboarding experience at present, as I would prefer to see this in the Endpoint Manager Admin Center

This new onboarding process removes the requirement to push out a commercial ID, something which many admins have had frustration over due to the fact they still need to publish this value through OMA-URI in order to support Windows Pro licensed machines. This was due to the ADMX backed settings catalog policy only being applicable to Enterprise and Education editions.

Microsoft’s Own Native Workbook

Something that we also saw appear with the new onboarding experience, was an Update Compliance workbook from Microsoft. Located in the Monitor | Workbooks section of the Azure portal UI, the workbook offers quick oversights as to the health of your devices;

Its great to see Microsoft is committing to this format of report delivery, as this can only serve to benefit everyone in the community!

Windows Update Compliance Dashboard V8.0

Taking onboard all of the changes since our last community edition, along with elements that we have been adding working with clients, @jankeskanke, @sandy_tsang, and I are proud to release version 8.0 of the Windows Update Compliance Dashboard.

The dashboard has been massively overhauled to display items such as;

• Trending update compliance over time
• Windows Update for Business issues
• Feature update trends
• Delivery optimization details
• Windows 11 readiness
• Third-party application information

Below I am going to step through the individual tabs and elements of the dashboard, please note that in some cases some of the reports are not only dependent on the Update Compliance logs, but also leverage the Intune diagnostic logs, and custom hardware and application inventory logs gathered through PowerShell / ingested through a function app (Securing Intune Enhanced Inventory with Azure Function – MSEndpointMgr).

Please Note: Hardware and application inventory scripts are not provided as part of the community solution. Reporting UI elements requiring those features will be hidden where the logs are not present in your tenant. If you wish to avail of these additional enhancements, please contact CloudWay for more details.

Summary Page

The summary page is designed to offer you a at a glance overview of your entire environment. At the top right of the page the Microsoft log timestamps are displayed, Logs older than 3 days old will be highlighted with a service issue alert, otherwise they are considered to be up to date;

The quality update patch trend shows you devices which are fully patched, pending patches, or missing multiple patches. As you can see from the screenshot below, the trend will show a decline in compliance once per month (patch Tuesday) and an improvement in compliance as per your defined update rings;

The next graph shows compliance against particular KB updates over time, where you will see declining KB installations over time due to CU rollouts and supersedence;

The next set of graphs show you items such as patch installation states, compliance states, client activity, current Windows builds, and target builds;

On the left side of the summary tab you can see key information about devices showing in the UC logs, issues being reported from Windows Update for Business for those devices, and optionally information on restart activity from those devices.

Quality Update History

The quality update history tab provides you with a 0-30, 60-90, 90+ day approach to reporting on induvial KB compliance. This tab has been updated to now include links to the individual KB’s, so anyone reviewing the dashboard can get a quick overview of the security issues being resolved;

Quality Update Deployment – By Device

On this tab, the admin can get a full overview of updates being applied to specific devices, by default though it will show all devices;

Quality Update Deployment – By Update

On this tab, just like you had the ability to filter based on a specific device on the previous tab, here you can filter based on the individual updates, selecting multiple, one or all;

Update Issues

On this tab all blocking issues, including information such as updates pending restarts, compatibility issues, and safeguard holds are displayed;

Delivery Optimization

Knowing if your clients are using DO correctly is vital, on this tab you can see an overview of your DO state, with a ranked notification advising you if your DO states are Optimal, Good, Poor, or Bad. For those of you with custom hardware logs, you can also see DO traffic per subnet;

Feature Updates

On the feature update tab, you can see wealth of information showing the progress of your devices moving to new builds, overall counts per build, and with custom hardware reports available you can also see a breakdown of manufacturers and models per Windows build;

Windows 11 Readiness

This self explanatory tab provides you with an overview on how many devices in your estate are capable of running Microsoft’s latest client OS;

Microsoft Office, Edge & Third Party

Finally on the last tab we have information on applications within your environment. Please note that information on this tab requires custom application collection.

We are currently looking to integrate this tab with third party solution feeds from vendors such as Patch My PC and Scappman.

The Workbook

Want to use this workbook in your environment? No problem. Its available on our GitHub here – Reporting/UpdateComplianceV8.json at main · MSEndpointMgr/Reporting (github.com)

Conclusion

One of the main complaints from those coming from a Configuration Manager background is around reporting. Its a fair point, however, utilising several sources such as Intune, Update Compliance, and going custom, you can provide high quality dashboards. More to come on the blog soon…

(15)

The post Windows Update Compliance Dashboard V8.0 appeared first on MSEndpointMgr.

Manage Windows Hello for Business (WHfB) with Intune is very “easy”, you have so many options:

• At device enrollment: Tenant-wide policy
• After device enrollment, at least four methods:
  • Endpoint Security > Account protection (Preview)
  • Configuration profiles > Identity protection
  • Settings catalog
  • Custom OMA-URI

So which methods should we use? What if you have different scenarios that have additional requirements?

For example:

• Multiple users use the same device, but only some users should be using WHfB
• Only allow WHfB for some devices
• Different WHfB requirements for users

I hope you can find your answers after reading this post.

At device enrollment – Tenant-wide policy

Tenant-wide policy targets your entire organization and supports Windows Autopilot. This should be the perfect choice if you plan to enable or disable WHfB for your entire organization with the same WHfB configuration. The tenant-wide policy applied at device enrollment, it applied to the device for each user who login.

The tenant-wide policy has three options:

• Enabled. Select this setting if you want to configure Windows Hello for Business settings. When you select Enabled, other settings for Windows Hello are visible and can be configured for devices.
• Disabled. If you don’t want to enable Windows Hello for Business during device enrollment, select this option. When disabled, users can’t provision Windows Hello for Business. When set to Disabled, you can still configure the subsequent settings for Windows Hello for Business even though this policy won’t enable Windows Hello for Business.
• Not configured. Select this setting if you don’t want to use Intune to control Windows Hello for Business settings. Any existing Windows Hello for Business settings on 10/11 devices isn’t changed. All other settings on the pane are unavailable.

Which one should you use?

• If you have decided entire organization will use WHfB with the same configuration, choose “Enabled”
• If you have decided the entire organization will NOT use WHfB, choose “Disabled”.
  NOTE: When you use the “Disabled”, all other WHfB configurations will still apply, like Minimum PIN length is 4, Maximum PIN length 127, it just won’t allow you to enable Hello. So if you deploy another WHfB policy to devices, and if you configure different requirements example Minimum PIN length is 6, Maximum PIN length is 16, it will cause conflict and you will have unexpected behaviors, sometimes WHfB is unavailable, sometimes works.

• If you have multiple scenarios and usage cases of WHfB, choose “Not configured”

After device enrollment

Let’s assume you have configured tenant-wide policy as “Not configured” because you have multiple scenarios that require different WHfB configurations. As I mentioned before, at least four Intune methods allow you to manage WHfB. In my opinion, Account protection (Preview) and Settings catalog both are good options. Both have nice UI and allow you to configure all the necessary settings.

Account protection (Preview)

You will find Account protection (Preview) under Endpoint security

The policy itself worked as expected. I have tested assigning one policy to a device group and another policy to a user group.

• When policy is assigned to a device group, all users get prompt to configure WHfB at first-time log on to the device
• When policy is assigned to a user group (without policy assigned to the device), the targeted user didn’t get WHfB prompt at first log on, which is expected. After WHfB policy is synced, the targeted user gets WHfB prompt when log on to the device. Untargeted user will never get or allow to configure WHfB, if there is no other WHfB policy assigned to the device.

WHfB configuration worked, but however, reporting is missing some devices when the policy is assigned to users group.

My user account sandy@smsboot.com is logined to three devices, MVP24-001, MVP24-002 and MVP006, I confirmed WHfB is applied to all these three virtual machines for my user account. But as you can see in the report, it only shows all the devices that have sandy@smsboot.com as the primary user, but not the other two devices with different primary users or without a primary user.

Settings catalog

Settings catalog allows you to configure WHfB settings for devices or/and users. See details in PassportForWork CSP – Windows Client Management | Microsoft Docs

I configured a few settings with the settings catalog and deployed them to a user group. The result is good. WHfB settings are applied to my targeted user who login to those three virtual machines. I confirmed it from all those three virtual machines.

Let’s take a look at the settings catalog reports.

Device assignment status report. Same issue as Account Protection (preview). It only shows all the devices that have sandy@smsboot.com as the primary user, but not the other two devices with different primary users or without a primary user.

Per setting status report. This looks better, and it did show three records per setting name.

The device and user check-in status report looks good, it also shows 3 Succeeded, and the real-time report (View report) shows all the devices I was looking for. I am happy with this report.

Summarize

After all these tests, as for this moment, I will use the following:

• Tenant-wide policy set to “Not configured”
• Create a device group to allow WHfB
• Use the settings catalog to deploy the WHfB device configuration to the device group
• Create a user group to allow WHfB (if needed)
• Use settings catalog to deploy WHfB user configuration to the user group (if needed)

Device configuration will be my first choice because it applies to all users’ devices. Users will be prompted to set up WHfB immediately when they first-time log on to the device, doesn’t need to wait for the user policy to sync and then log on again. But of course, if you have scenarios that require different settings for different users, then you will need to use WHfB user configuration, be patient, allow policy sync, and apply user policy.

Hope this post will help your password-less journey.

Feature image is from Hello Greeting on Brown Board · Free Stock Photo (pexels.com)

(21)

The post Manage Windows Hello for Business (WHfB) with Intune appeared first on MSEndpointMgr.

In this blog post we cover the unusual characteristics of the Intel Optane drive, and how we need to approach task sequence builds to ensure we do not hit an unforeseen issue when it comes to in-place upgrades later in the device lifecycle.

Intel Optane Technology

Unveiled back in 2017, Intel’s Optane solution is a memory module that provides a burst of high speed data throughput using a new memory technology called 3D XPoint. Using built-in intelligent algorithms the solution works by keeping the data you use most frequently in the higher speed cache, reducing loading time and improving overall system performance.

More information on the specifics can be found on Intel’s site – Information about the Intel® Optane Memory M Series

Cache Disk Configuration

The cache disk is typically delivered in one of two flavours, these being a 16GB and 32GB, and this is where we can start to run into issues. The issue stems from the fact you need to run a utility to enable the cache association prior to running through your standard formatting and OS deployment, without doing this, the drive will be seen by your OS and this sets the scene for something very strange.

The utility in question is the Intel RST Configuration Utility (RstCliPro.exe) and this is where OEM instructions on the use of this tool, and the required versions, get a little bit blurred. For example, HP have their own post on how you should use the RST utility as part of your task sequence (HP PCs – How to Configure an OSD Task Sequence to Deploy Intel Optane in SCCM | HP® Customer Support), but in my testing I found that the sequence of events contained within and the versioning of their tools / WinPE drivers also fall short of providing an optimal working task sequence.

In-Place Upgrade Issues

Whilst working on an in-place upgrade task sequence upgrade for a client, I found in this instance that the documentation from HP in this instance was used, exactly as described, with one key failure however.

During an in-place upgrade from 1909 to 21H2, something happened which I had not seen before. During the task sequence when a restart step was run post OS upgrade, the device would fail the task sequence. When looking at the SMSTS log and status messages, it stated the following;

When I started to investigate this issue, I started to look at the disk partitioning, and it suddenly became evident as to why this was the case. The cache drive was still seen to the OS and was seen as Disk 0

In the below screenshot you can see that the drive is visible to the OS;

Given that the cache drive was being seen as disk 0, this caused the unexpected behaviour. If the Intel RST configuration was successfully run during the initial build, the disk would not be visible to the OS.

Root Cause Issue

Following the documentation, the first thing we need to ensure is that we have two key components available in order to image a machine with this drive, these being;

• Intel RST WinPE Driver
• Intel RST Configuration Utility

Taking a HP Dragonfly Max for example, the documentation by that vendor states the following;

1. Go to the HP Software and Drivers page for your computer or download HP Image Assistant to obtain the Intel RST driver softpaq.
2. Extract and save RSTCLI64.exe to the SPXXXXX\bin\src\Tools\WinPE folder.
3. Copy the RSTCLI64.exe utility to a shared location on the SCCM server to use as a source folder for the package.

Doing this verbatim, we end up with the following file;

Packaging up this tool however is only the first step. We need to ensure that the tool is supported by the Intel RST controller driver in WinPE, otherwise we end up with a failure like the one pictured below;

When this occurs, the association is not completed, and the cache partition is not configured correctly. In this instance the continue on error flag was enabled and it resulted in the machine being deployed in an incorrect state, resulting in the task sequence upgrade failure pictured above.

Documentation Variations

As the OEM’s instructions were used in this instance, I started to look over Intel’s own documentation and found discrepancies in the guidelines being offered.

In HP’s documentation, the task sequence flows as per the below screenshot;

At the start of the TS where the Optane disk is detected, the following WMI filters are suggested;

Intel Optane Cache Drive
SELECT * FROM Win32_DiskDrive Where Index = “0” AND Size < 34359738368

Intel Non-Optane Drive
SELECT * FROM Win32_DiskDrive Where Index = “0” AND Size > 34359738368

In comparison to Intel’s documentation (Intel® Optane Memory System Acceleration Corporate Re-imaging Guide), the difference is that they are also filtering based on the model;

Intel Optane Cache Drive
SELECT * FROM Win32_DiskDrive Where Index = “0” AND Size < 300000000000 AND Model LIKE ‘%intel%’

SELECT * FROM Win32_DiskDrive Where Index = “1” AND Size < 300000000000 AND Model LIKE ‘%intel%’

In Intel’s own documentation it covers if the drive is detected both as disk 0 and disk 1, but it also refers to the Intel RST tool as RSTCliPro.exe, which HP’s documentation referencing at the start but changes to RSTCLI64.exe later in their post.

The sequence of enabling the Intel association also is different, ensuring that the OS is only layered down to the OS disk once the association has been completed. I much prefer this approach as it ensures that your pre-requisites are met before you format your disks in preparation for the OS being installed.

Putting It Together – Task Sequence Deployment

Intel RST Configuration Tool

In order to ensure that you have the most update to date configuration utility, you should use the latest version from your chosen vendor, alternatively you can download it direct from Intel’s website – Intel® Rapid Storage Technology Driver Installation Software with Intel® Optane Memory (10th and 11th Gen Platforms)

After you have extracted the RST tool, package it up in Configuration Manager, and distribute it to your imaging DPs

WinPE Drivers

The next step is to ensure you have the latest WinPE storage drivers in your boot image. Below are a list of common OEMs and their associated WinPE driver site;

Extract, import, and update your boot image;

Task Sequence Flow

With the pre-requisites in place, you should now edit your task sequence to use the Intel WMI filters as referenced above. My recommendation is to create a child task sequence for this element of your task sequence, as part of a pre-OS deployment phase;

Note in the above screenshot, I am using the latest version from Intel, but you can substitute the tool naming from your OEM.

WMI Filters Applied:

Running the tool interactively to ensure it is working, we should see something like the below;

Post Deployment

Post OS deployment you should no longer see the cache drive in disk manager;

At this point the Intel Optane cache drive is working as intended and you should have no longer have any issues during your in-place upgrade task sequence.

Conclusion

Intel Optane’s disk configuration is something that might catch you out, so if you have deployed these devices and did not perform the association, update your task sequences accordingly and re-image those devices.

I hope this post helps you!

(2)

The post Task Sequence Basics – Intel Optane Drives appeared first on MSEndpointMgr.

In this quick post we will be removing built-in Windows 11 apps, for all users, and optionally showing you how to leverage a “Cloud-Source” as a reference file to select apps for removal.

Introduction

Appx Provisioned Packages – the evolution

There are many great examples of how to remove built-in Windows apps. I have been using a script from my friend @nickolaja for a while and have modified it to reflect the additional built-in apps that appear in subsequent Windows 10 feature updates and also Windows 11.

Microsoft often include additional apps in each release of Windows, meaning admins need to update their appx removal scripts frequently. This is normally fine, but in environments that require all scripts to be signed – this can (and does) lead to frustration. “I can’t sign off this dev ticket today boss until Jessica returns from the Maldives next week”. It is unlikely that pending doom is invoked because Jessica was on leave, but you get my point.

Take me to the Maldives, I don’t care about script signing

A different way to introduce variables

I was chatting with @mauriced and @jankeskanke about this scenario and they, as always, had an interesting idea and perspective. What if we could change our script variables without having to re-sign the scripts each time…

Great Idea! In this post I will include a script to remove built-in apps from Windows 11, with the apps defined as an array within the script (the old fashioned way if you like). I will also share a version of the script where I will use a reference file hosted on GitHub to dynamically build the array of apps to remove. Your reference file could be hosted on Azure Blob or any other cloud storage provider. The reference file, a text file in this example, will allow me to dynamically update the list of apps I want to remove from my devices. Change my mind on what apps I want remove? I simply update the .txt file on GitHub – no need to re-sign or redistribute the script!

“Text file….Heresy! Use a JSON or XML!” I hear you cry. Well yes, fair point. You will see why I choose to use a .txt file later. It is really quick and simple to differentiate between which apps I want to remove and the apps I want to keep.

Scripts

Windows 11 App Removal Script

This script will remove built-in Windows 11 apps without using a Cloud source reference file. Instead, the apps to remove are explicitly defined in an array in the script.

Simply modify the $BlackListedApps array list to include the appx provisioned packages you want to remove from the device. The full list of packages can be found in the comment block at the beginning of the script.

Windows/Remove-Appx-AllUsers.ps1 at master · MSEndpointMgr/Windows (github.com)

Windows 11 App Removal Script (Using Cloud Sourced reference file)

This script will remove built-in Windows 11 apps with a Cloud source reference file. If the app has a # prefixed in the reference file then we remove that built-in app.

The script will reference the blacklist_w11.txt file in GitHub. Change this line to reflect the location of your reference file

Windows/Remove-Appx-AllUsers-CloudSourceList.ps1 at master · MSEndpointMgr/Windows (github.com)

Windows/blacklist_w11.txt at master · MSEndpointMgr/Windows (github.com)

Script Overview

When either of the scripts above are distributed and run, the apps are removed from the device for all users. If you run the script(s) interactively, you will see the progress of the app removal.

If you re-run the script after changing the reference file, the additional apps selected will be removed

The script(s) can either packaged as Win32apps and distributed to devices. Win32apps are great because you can leverage Filters to accurately target your different device builds quickly. Remember to run the script in the System context so all users on the device are targeted. The script can also be distributed using the Intune scripts feature – but you still need to rely on Dynamic Groups for targeting.

A log is generated under the system temp folder.

Care should be taken when removing appx provisioned packages – it is not as easy to restore them as it is to remove them

Summary

Remember, Appx Packages are installed in the User profile. Appx Provisioned Packages are installed in the Windows image and are used to provision appx packages, to the user profile, for each new user logging on to the device.

Restoring the appx provisioned packages, after removing them from Windows, is not an easy process so care should be taken when choosing which packages to remove.

I shared two scripted examples. The first had the appx provisioned packages, to remove, explicitly defined within the script body. The second referenced a .txt file, stored in GitHub, to remove the appx provisioned packages from Windows.

In environments, that require scripts to be signed, using a reference file for script variables is interesting. Obviously in our example we didn’t have any sensitive information that shouldn’t be seen by the public, so GitHub was fine to store the reference file.

If you want to start to get creative with reference files that include sensitive data we can look to store the file in Azure Blob storage and use a Shared Access Token or managed identity to access that file securely – and that gives me an idea for a future blog post.

(4)

The post Remove Built-in Windows 11 apps leveraging a Cloud-Sourced reference file appeared first on MSEndpointMgr.

We recently shared the top 10 most-used Community Right Click Tools. This post will highlight the top 10 most-used Right Click Tools within the Enterprise Edition. See what Right Click Tools customers are using, along with an honorable mention below. We’ll cover each tool’s capabilities as well as some examples of basic ways you can utilize the tools in your environment.  

1. System Information  

The System Information tool is a great way to view and take action on all aspects of a machine. From the tool, you can see info about the OS, hardware, applications, updates, services, drivers, user profiles, user sessions, local group members, and batteries. The best part about having all of this info in one place is you can also make changes. Whether you need to start/stop a service or delete an old user profile that is taking up too much space, this is the place to go. If this leaves you wanting more, look into Endpoint Insights to broaden the scope of machine information and reporting. 

2. Remote Software Center  

If you’re sick of having to ask a user to install updates or an application, you will love this tool. Remote Software Center gives you the ability to access all of the functions of Software Center as if you were remoted in or sitting right at the machine. From Remote Software Center, you can install applications, run updates, kick-off task sequences, and run compliance policies.  

3. Remote Windows Security  

Remote Windows Security gives you access to the Windows security settings. With this tool, you can view and take action on BitLocker, TPM, Firmware, Defender, and Windows firewall settings. Need to add a Defender file exclusion, Windows Firewall rule, or just kick off a scan? Remote windows security gives you the ability to quickly act on a single device or a collection without ever needing to leave ConfigMgr. 

4. Software Updates Deployment Status  

The Software Updates Deployment Status dashboard is a great place to get a full picture of how up to date the endpoints across your environment are. From the dashboard, you can view how compliant your devices are and which categories of updates are missing. The real power of this tool is customizability- you can break your view down by collection and limit which types of updates you are concerned with (i.e. critical, security, etc.). Your security team will love this one.  

5. Active Directory Cleanup Tool  

The Active Directory Cleanup Tool gives you insight into devices that are found in AD but are not being managed by ConfigMgr and vice versa. This tool can be very helpful during an AD audit as it helps to find devices that need to be removed from ConfigMgr or that have fallen off the domain. You can even take right click actions within the dashboard. If you need to delete the device from AD you can do it right from the dashboard. Rather than sending your help desk employees on a wild goose chase comparing AD to what you have in ConfigMgr, give this dashboard a shot! 

6. Client Information  

Client Information gives you quite a few useful pieces of information on a ConfigMgr client all in one place. You can view data like cache info, applications, ConfigMgr client info, boundaries, and execution history from this tool. Much like our other tools, you can take action right from this view as well. From the application tab, you can even install or uninstall software. 

7. BitLocker Compliance Tool  

The Bitlocker Compliance Tool dashboard is a great way to view and take action on all things Bitlocker. The dashboard generates graphs representing key storage status and unified compliance status (MBAM, CM, or Both). You can choose to drill this down to a specific OU or pick a Collection. No matter which graph section you click into you can see information about the device taken from both graphs.  

8. AD LAPS Password  

The AD LAPS (Active Directory Local Admin Password Solution) Password tool gives you all of the information you would find using the LAPS UI without ever needing to leave your ConfigMgr console. You can check the current LAPS password for a machine. Worried about someone writing that password down and leaving it somewhere they shouldn’t? This tool allows you to set your own expiration time so it resets as soon as you want it to. No waiting for the next cycle! 

9. Content Distribution Monitor  

The content distribution dashboard gives you info about your distribution points in one centralized location. This dashboard gives you a graphical representation of successful, errored, and in-progress content across all of your DPs. The best part? Right from the graph you can either redistribute failed content to all DPs or drill down individually and view the status, redistribute, remove, or validate the content.  

  10. Send Notification‍ 

The name says it all with this tool. This can be used to send a custom notification to a device or collection. Need to give your users in accounting a warning that the accounting systems will be patched tonight? This is just the tool for the job. By default, this tool will try using a “Recast Toast” which allows you to add a custom image. I suggest adding your company logo so your users don’t get freaked out by the random pop-up! 

Honorable Mention  

LAPS Dashboard 

The LAPS Dashboard was too close to the top 10 not to give it a mention. The LAPS Dashboard provides you with a compliance overview of LAPS in your environment. You can break this down by selecting a specific Domain and OU. The interactive graphs give you the status of computers that do/don’t have a LAPS password in AD and that do/don’t have the LAPS client installed. Clicking into any section provides you with the computers that make up that portion of the graph.  

 
What’s your favorite Right Click Tool? Please let us know @RecastSoftware.  

Get started with our free Community Edition to immediately boost productivity. See the difference between the features included in the Community Edition versus the Enterprise Edition. Interested in learning more about the Enterprise Edition? Request a quote today! 

(4)

The post Top 10 Most Used Enterprise Right Click Tools  appeared first on MSEndpointMgr.

In this post we will look at the Office File Transfer feature and implement a simple solution to prevent “one way” that users can leak corporate data.

Mobile Devices – The Trojan Horse of Security

In this fast paced landscape, security teams are having to constantly respond to both new and legacy vulnerabilities to help protect us, our data and our devices. Sometimes, a curve ball will come at you and bring you out in a cold sweat – “oh geez, how did we miss this hole?!”

As my good friend @mauriced says, “Mobile devices are the smallest computers that you own” – and he is right! They can also be, by their very nature, the trickiest of devices to manage. Several years ago, it wasn’t uncommon for companies to issue corporate devices for employees to access corporate emails and documents. Those days are rapidly “going-going-gone” (almost) and users expect to be able to access corporate data from their personal mobile device. Using a combination of Conditional Access and App Protection Policies we have relatively good control over that experience to prevent, or at least drastically limit, corporate data leakage into the users personal apps.

Mobile Devices still prove to be that Trojan Horse that Compliance and Security Administrator’s fear. One reason, that echo’s true still today, is that no matter what controls you put in place how are you going to prevent someone taking a photo of sensitive data?

Microsoft Office app for mobile devices

The Microsoft Office app, for mobile devices, is generally well known and can be protected with App Protection Policies from Intune.

File Transfer

An often overlooked feature in the Microsoft Office app is File Transfer. This feature can be accessed from the actions menu.

After tapping Send or Receive, the user is prompted to pair their device by visiting transfer.office.com on their computer.

The user is prompted to scan the QR code to pair the mobile device with the computer before being able to transfer files.

App Protection Policy Efficacy

As per the Microsoft docs https://docs.microsoft.com/en-us/office365/troubleshoot/access-management/control-file-transfer

You can transfer only locally stored, non-managed data from a mobile phone to the desktop. You can’t transfer Intune-protected, organization-managed, or cloud files. The File Transfer feature follows the policies for Intune Mobile Application Management (MAM) that are applied on the Office app.

So we are good right? We can’t transfer data from Intune-protected apps that have been targeted with an App Protection Policy…

A chink in the armour

While it may be true that App Protection Policies can prevent corporate data being Sent from a mobile device, what protections are there to prevent Windows devices from allowing the Office mobile app to Receive data? Can a user, from their managed Windows device, transfer corporate data to a mobile device? Let’s try this with a personal iOS device that does not have any app protection policies targeted.

Wow! As can be seen from the results above, we were able to transfer corporate files, from a “managed” Windows device to an “unmanaged” personal device. We didn’t even need to sign into the Microsoft Office app on the mobile device to prove our corporate identity.

Workaround

After climbing down from the ceiling in shock, the best easiest way I could find to prevent this “back door data leak” scenario is to block managed devices from accessing the transfer.office.com URL(s)/IP’s. Microsoft call out the IP’s and URL’s in the following doc which will effectively turn off the ability for Windows devices to leverage the file transfer feature.

https://docs.microsoft.com/en-us/office365/troubleshoot/access-management/control-file-transfer#turn-off-file-transfer

URL’s to block

• filetransfer-prod-griffin-*.cloudapp.net
• transfer.office.com
• filetransfer.trafficmanager.net

IP’s to block

• 13.76.241.194
• 52.184.64.21
• 65.52.31.49
• 70.37.107.67
• 52.169.19.3

Defender for Endpoint

Here is a feather to add to the bow of persuasion for those still on the fence about Microsoft Defender. Defender for Endpoint Plan 1 and Plan 2 includes the ability to create indicators for IPs and URLs/domains. More reading on that below.

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/manage-indicators?view=o365-worldwide

Indicators allow you to detect and prevent access to known file hashes, IP addresses, URL’s and Certificates (.cer and .pem).

Create Indicator to block access to transfer.office.com

1 . Navigate to the Microsoft Security Portal and ensure the Custom network indicators advanced feature is enabled

https://security.microsoft.com/preferences2/integration

2 . From the same portal, navigate to Indicators

3 . Navigate to IP addresses, click Add Item, enter the IP address to block and click Next

4 . Choose the action to Block execution. Check Generate alert and enter an Alert title. Choose an Alert severity and Category for this alert.

5 . Enter a Description for the alert and click Next

6 . Review the alert information and click Save

7 . Repeat steps 3 to 7 for the other IP addresses listed in the Microsoft doc

• 13.76.241.194
• 52.184.64.21
• 65.52.31.49
• 70.37.107.67
• 52.169.19.3

When a user attempts to initiate a file transfer for corporate data on their managed device, they will be blocked

You can monitor these block events from the Defender Portal too (if you enabled alerting when creating the indicators).

Summary

In this post we demonstrated how users can move corporate data from a managed Windows device to a personal mobile device. We then looked at how we could use Microsoft Defender to block access to the required IP’s for the Office transfer endpoints using Indicators.

This type of data extraction can be leveraged from many other apps and services. Do you allow WhatsApp, Signal and other cloud services on users work devices? What do you have in place to prevent data transfer across those services? Are you going to add Indicators for all of those IP’s and URL’s too?

My main motivation and hope for this post is to get you thinking. Yes we closed one back door, killed off one trojan horse, but the challenges are many. Go spark a conversation with your team – how well do you understand your current position for protecting corporate data for the multitude of Cloud services that exist today.

(4)

The post Block the Office File Transfer Endpoints to help prevent data leakage on Managed Devices appeared first on MSEndpointMgr.

If there is one certainty when it comes to computing, it is that applications will at some point crash or hang. The reasons are widespread, incompatibility between installed frameworks, dynamic link libraries, or drivers, but the issue is universal. Today we are however protected for the most part from the horrible side effects of some of the crash and hang events, as Windows itself will attempt to silently recover the application, resulting in less blue screens of death.

There is one important thing to note though, and that is although Windows does a much better job at masking the issues today, they will not go unnoticed by the end user. The relaunching of background services might just manifest itself as a slight delay or “hang” on the system, where foreground applications might have to be relaunched and of course that is most noticeable.

Windows Reliability Monitor

Monitoring these events in Windows used to be something IT engineers would turn to the event logs for, and yes you still can, however, the build-in Windows Reliability Monitor provides a much nicer graphical representation of the system stability issues over time.

As we can see from the screenshot below, there are multiple critical events on this device, mostly focused around the “Killer Intelligence Center” (not pointing fingers, merely an example).

If we double click on one of these critical instances we obtain additional information around the application version, the faulting modules, manufacturer etc.

This is all helpful when troubleshooting stability issues on Windows devices, and elements of what we see in the Reliability Monitor are of course found in Endpoint Analytics today.

Endpoint Analytics

Endpoint Analytics in Microsoft Endpoint Manager, are a set of informative events focused around things such as;

• Startup Performance
• Application Reliability
• Resource Performance
• Battery Health (in preview)

Focusing on Application Reliability for the purpose of this post, we can then obtain information from one of the following categories;

• App Reliability Score
• App Performance
• Model Performance
• Device Performance
• OS Version Performance

Furthermore, limiting our focus to the App Reliability Score, we can then see how stable an application is, with the number of crashes, and the mean time to failure being included;

This is of course all very useful information, and is something that we can use to track how stable our systems are based on the combination of applications, OS versions etc. On reviewing the application stability events in Windows however, I found that there was a disconnect from what I was seeing here, both in terms of the crash events, and details such as which device was impacted, at what time, and additional information on the crash event.

This got me thinking, wouldn’t it be great to have the Windows Reliability Monitor ported to something in the cloud that we could monitor all of our devices with?

Log Analytics

At this point if you have read any of my previous log analytics posts, you would know I am quite the fan. I really appreciate that Microsoft has given us a platform other than SSRS or PowerBI, that we can send, query, and visualise datasets in. In fact, I did overhear Rod Trent coin the phrase “KQL is the new PowerShell”, and for some, the addition to find out what you can do with KQL is a major thing.

Using the Reliability Monitor as the template, I looked at the WMI class which contains the application reliability events, this being Win32_ReliabilityRecords (Win32\_ReliabilityRecords class | Microsoft Docs). Here we can see querying this class we get back a heap of useful information;

At this point we have the information about the type of event, the offending application, any associated modules, and the event time. Using PowerShell to extract this information we can then also combine that to obtain other items, such as the Computer Name, ManagedDeviceID, and signing information for both the application and associated modules. At this point we essentially have what the Windows Reliability Monitor uses, just not visualised in a friendly manner (I mean non admins here).

Taking that information and pushing up to Log Analytics however, results in not only the ability to gather information from all our devices, but also the ability to query, and use the information in a workbook (like PowerBI but easier IMO). So, I created a process to do just that, with examples available in GitHub for sending data by hardcoding the workspace ID and key, or using a function app such as the one Jan Ketil Skanke covers in this post – Securing Intune Enhanced Inventory with Azure Function – MSEndpointMgr

In the below example script, I can use a single script to collect the following information through Proactive Remediations on a scheduled basis (recommendation is every 24 hours);

<#
.SYNOPSIS
Collect application reliability and upload to Log Analytics for further processing.

.DESCRIPTION
This script will audit reliability events and upload this to a Log Analytics Workspace. This allows you to easily search in device hardware and installed apps inventory.
The script is meant to be runned on a daily schedule either via Proactive Remediations (RECOMMENDED) in Intune or manually added as local schedule task on your Windows 10 Computer.

.EXAMPLE
Invoke-CustomAppReliabilityWithAPI.ps1 (Required to run as System or Administrator)

.NOTES
FileName:    Invoke-CustomAppReliabilityWithAPI.ps1
Author:      Maurice Daly
Contributor: Jan Ketil Skanke / Sandy Zeng
Contact:     @modaly_it
Created:     2022-01-05
Updated:     2022-20-05

Version history:
1.0.0 - (2022 - 01 - 05) Script created
#>

#region initialize
# Define your azure function URL: 
# Example 'https://<appname>.azurewebsites.net/api/<functioname>'

$AzureFunctionURL = "https://<YOUR URL HERE>/api/LogCollectorAPI"

# Enable TLS 1.2 support 
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
#Set Log Analytics Log Name
$AppReliabilityLogName = "AppReliability"
$Date = (Get-Date)
#endregion initialize

#region functions
# Function to get Azure AD DeviceID
function Get-AzureADDeviceID {
    <#
    .SYNOPSIS
        Get the Azure AD device ID from the local device.
    
    .DESCRIPTION
        Get the Azure AD device ID from the local device.
    
    .NOTES
        Author:      Nickolaj Andersen
        Contact:     @NickolajA
        Created:     2021-05-26
        Updated:     2021-05-26
    
        Version history:
        1.0.0 - (2021-05-26) Function created
    #>
	Process {
		# Define Cloud Domain Join information registry path
		$AzureADJoinInfoRegistryKeyPath = "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo"
		
		# Retrieve the child key name that is the thumbprint of the machine certificate containing the device identifier guid
		$AzureADJoinInfoThumbprint = Get-ChildItem -Path $AzureADJoinInfoRegistryKeyPath | Select-Object -ExpandProperty "PSChildName"
		if ($AzureADJoinInfoThumbprint -ne $null) {
			# Retrieve the machine certificate based on thumbprint from registry key
			$AzureADJoinCertificate = Get-ChildItem -Path "Cert:\LocalMachine\My" -Recurse | Where-Object { $PSItem.Thumbprint -eq $AzureADJoinInfoThumbprint }
			if ($AzureADJoinCertificate -ne $null) {
				# Determine the device identifier from the subject name
				$AzureADDeviceID = ($AzureADJoinCertificate | Select-Object -ExpandProperty "Subject") -replace "CN=", ""
				# Handle return value
				return $AzureADDeviceID
			}
		}
	}
} #endfunction 
function Get-AzureADJoinDate {
    <#
    .SYNOPSIS
        Get the Azure AD device ID from the local device.
    
    .DESCRIPTION
        Get the Azure AD device ID from the local device.
    
    .NOTES
        Author:      Nickolaj Andersen
        Contact:     @NickolajA
        Created:     2021-05-26
        Updated:     2021-05-26
    
        Version history:
        1.0.0 - (2021-05-26) Function created
    #>
	Process {
		# Define Cloud Domain Join information registry path
		$AzureADJoinInfoRegistryKeyPath = "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo"
		
		# Retrieve the child key name that is the thumbprint of the machine certificate containing the device identifier guid
		$AzureADJoinInfoThumbprint = Get-ChildItem -Path $AzureADJoinInfoRegistryKeyPath | Select-Object -ExpandProperty "PSChildName"
		if ($AzureADJoinInfoThumbprint -ne $null) {
			# Retrieve the machine certificate based on thumbprint from registry key
			$AzureADJoinCertificate = Get-ChildItem -Path "Cert:\LocalMachine\My" -Recurse | Where-Object { $PSItem.Thumbprint -eq $AzureADJoinInfoThumbprint }
			if ($AzureADJoinCertificate -ne $null) {
				# Determine the device identifier from the subject name
				$AzureADJoinDate = ($AzureADJoinCertificate | Select-Object -ExpandProperty "NotBefore")
				# Handle return value
				return $AzureADJoinDate
			}
		}
	}
} #endfunction 
#Function to get AzureAD TenantID
function Get-AzureADTenantID {
	# Cloud Join information registry path
	$AzureADTenantInfoRegistryKeyPath = "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo"
	# Retrieve the child key name that is the tenant id for AzureAD
	$AzureADTenantID = Get-ChildItem -Path $AzureADTenantInfoRegistryKeyPath | Select-Object -ExpandProperty "PSChildName"
	return $AzureADTenantID
}
# Function to get all Installed Application
function Get-InstalledApplications() {
	param (
		[string]$UserSid
	)
	
	New-PSDrive -PSProvider Registry -Name "HKU" -Root HKEY_USERS | Out-Null
	$regpath = @("HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*")
	$regpath += "HKU:\$UserSid\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"
	if (-not ([IntPtr]::Size -eq 4)) {
		$regpath += "HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
		$regpath += "HKU:\$UserSid\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
	}
	$propertyNames = 'DisplayName', 'DisplayVersion', 'Publisher', 'UninstallString'
	$Apps = Get-ItemProperty $regpath -Name $propertyNames -ErrorAction SilentlyContinue | . { process { if ($_.DisplayName) { $_ } } } | Select-Object DisplayName, DisplayVersion, Publisher, UninstallString, PSPath | Sort-Object DisplayName
	Remove-PSDrive -Name "HKU" | Out-Null
	Return $Apps
}
#endregion functions

#region script

#Get Common data for App and Device Inventory: 
#Get Intune DeviceID and ManagedDeviceName
if (@(Get-ChildItem HKLM:SOFTWARE\Microsoft\Enrollments\ -Recurse | Where-Object { $_.PSChildName -eq 'MS DM Server' })) {
	$MSDMServerInfo = Get-ChildItem HKLM:SOFTWARE\Microsoft\Enrollments\ -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.PSChildName -eq 'MS DM Server' }
	$ManagedDeviceInfo = Get-ItemProperty -LiteralPath "Registry::$($MSDMServerInfo)" -ErrorAction SilentlyContinue
}
$ManagedDeviceName = $ManagedDeviceInfo.EntDeviceName
$ManagedDeviceID = $ManagedDeviceInfo.EntDMID
$AzureADDeviceID = Get-AzureADDeviceID
$AzureADTenantID = Get-AzureADTenantID

#Get Computer Info
$ComputerInfo = Get-CimInstance -ClassName Win32_ComputerSystem
$ComputerName = $ComputerInfo.Name
$ComputerManufacturer = $ComputerInfo.Manufacturer

# Collect log flag
$CollectAppReliability = $true

if ($ComputerManufacturer -match "HP|Hewlett-Packard") {
	$ComputerManufacturer = "HP"
}

#region APPRELIABILITY
if ($CollectAppReliability) {
	# Obtain reliability data
	$AppReliabilityInventory = @()
	$ReliabilityEvents = Get-CimInstance win32_ReliabilityRecords | Where-Object { $_.EventIdentifier -match "1000|1002" -and $_.TimeGenerated -ge (Get-Date).AddHours(-24) }
	
	# Loop and process reliability events
	foreach ($ReliabilityEvent in $ReliabilityEvents) {
		
		$ApplicationName = $ReliabilityEvent.ProductName
		$ReliabilityEventId = $ReliabilityEvent.EventIdentifier
		$ReliabilityEventType = $ReliabilityEvent.SourceName
		[datetime]$ReliabilityEventTime = $ReliabilityEvent.TimeGenerated
		
		$ApplicationPath = $ReliabilityEvent.InsertionStrings | Where-Object { $_ -like "*\$ApplicationName" } | Select-Object -Unique
		
		if (-not ([string]::IsNullOrEmpty($ApplicationPath)) -and (Test-Path -Path $ApplicationPath)) {
			$ApplicationDetails = Get-ItemProperty -Path $ApplicationPath
			
			# Get file siging details
			$ApplicationSigningDetails = Get-AuthenticodeSignature -FilePath $ApplicationDetails.FullName
			$ApplicationSigningCert = $ApplicationSigningDetails.SignerCertificate
			
			# Get application publisher details
			$ApplicationPublisher = $ApplicationDetails.VersionInfo | Select-Object -ExpandProperty CompanyName
			if ([string]::IsNullOrEmpty($ApplicationPublisher)) {
				$ApplicationPublisher = "Unknown"
			}
			
			# Get version information
			$ApplicationVersion = $ApplicationDetails.VersionInfo.FileVersionRaw
			if ([string]::IsNullOrEmpty($ApplicationVersion)) {
				$ApplicationVersion = "Unavailable"
			}
			
			# Get faulting module
			if ($ReliabilityEvent.Message -match "module name") {
				$ApplicationFaultingModule = ((($ReliabilityEvent.Message.Split(",")) | Where-Object { $_ -match "Faulting module name:" }).Split(":") | Select-Object -Last 1).Trim()
				$ApplicationFaultingModulePath = $($ReliabilityEvent.Message).Split() | Where-Object { $_ -like "*\$ApplicationFaultingModule" }
			} else {
				$ApplicationFaultingModule = $null
				$ApplicationFaultingModulePath = $null
			}
			
			# Create JSON to Upload to Log Analytics
			$ReliabilityEventPayload = New-Object System.Object
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "ManagedDeviceName" -Value "$ManagedDeviceName" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "ManagedDeviceID" -Value "$ManagedDeviceID" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "ComputerName" -Value "$ComputerName" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "Application" -Value "$ApplicationName" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "EventType" -Value "$ReliabilityEventType" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "EventId" -Value "$ReliabilityEventId" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "ApplicationPublisher" -Value "$ApplicationPublisher" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "ApplicationPath" -Value "$ApplicationPath" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "ApplicationSignatureCert" -Value "$ApplicationSigningCert" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "ApplicationVersion" -Value "$ApplicationVersion" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "FaultingModule" -Value "$ApplicationFaultingModule" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "FaultingModulePath" -Value "$ApplicationFaultingModulePath" -Force
			$ReliabilityEventPayload | Add-Member -MemberType NoteProperty -Name "EventGenerated" -Value "$ReliabilityEventTime" -Force
			
			# Add event to array
			$AppReliabilityInventory += $ReliabilityEventPayload
		}
	}
}

#endregion APPRELIABILITY

#Randomize over 50 minutes to spread load on Azure Function - disabled on date of enrollment 
$JoinDate = Get-AzureADJoinDate
$DelayDate = $JoinDate.AddDays(1)
$CompareDate = ($DelayDate - $JoinDate)
if ($CompareDate.Days -ge 1) {
	Write-Output "Randomzing execution time"
	#$ExecuteInSeconds = (Get-Random -Maximum 3000 -Minimum 1)
	#Start-Sleep -Seconds $ExecuteInSeconds
}
#Start sending logs
$date = Get-Date -Format "dd-MM HH:mm"
$OutputMessage = "InventoryDate:$date "

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Content-Type", "application/json")

$LogPayLoad = New-Object -TypeName PSObject
$LogPayLoad | Add-Member -NotePropertyMembers @{ $AppReliabilityLogName = $AppReliabilityInventory }

# Construct main payload to send to LogCollectorAPI
$MainPayLoad = [PSCustomObject]@{
	AzureADTenantID = $AzureADTenantID
	AzureADDeviceID = $AzureADDeviceID
	LogPayloads	    = $LogPayLoad
}

$MainPayLoadJson = $MainPayLoad | ConvertTo-Json -Depth 9

# Sending data to API
try {
	$ResponseInventory = Invoke-RestMethod $AzureFunctionURL -Method 'POST' -Headers $headers -Body $MainPayLoadJson
	$OutputMessage = $OutPutMessage + "Inventory:OK " + $ResponseInventory
} catch {
	$ResponseInventory = "Error Code: $($_.Exception.Response.StatusCode.value__)"
	$ResponseMessage = $_.Exception.Message
	$OutputMessage = $OutPutMessage + "Inventory:Fail " + $ResponseInventory + $ResponseMessage
}

# Check status and report to Proactive Remediations
if ($ResponseInventory -match "200") {
	$AppReliabilityResponse = $ResponseInventory.Split(",") | Where-Object { $_ -match "AppReliability:" }
	if ($AppReliabilityResponse -match "AppReliability:200") {
		$OutputMessage = $OutPutMessage + " AppReliability:OK " + $AppReliabilityResponse
	} else {
		$OutputMessage = $OutPutMessage + " AppReliability:Fail " + $AppReliabilityResponse
	}
	Write-Output $OutputMessage
	if ($AppReliabilityResponse -notmatch "AppReliability:200") {
		Exit 1
	} else {
		Exit 0
	}
} else {
	Write-Output "Error: $($ResponseInventory), Message: $($ResponseMessage)"
	Exit 1
}
#endregion script

The above script and the alternative script without the Azure function API integration are available on the MSEndpointMgr GitHub site here – Reporting/Scripts at main · MSEndpointMgr/Reporting (github.com)

Application Reliability Monitor Workbook

With the data now flowing from the clients to Log Analytics, we can visualise it within a workbook, something that your CIO will appreciate. Below then is the result of this, a combination of a master and child workbook that help you to visualise the following information about your environment;

• Application Event Timeline
  This time chart shows application reliability incidents over time defined in the time range drop down
• Application Event Type
  This area chart shows us the split between application crash and hang events over time

• Application Details
  The data grid provides detailed information including;
  • Time of the event
  • Computer name
  • Application Name
  • Application Publisher
  • Application Path
  • Application Version
• Application Error Events
  This data grid with bar chart shows the top applications which have critical errors

• Application Hand Events
  This data grid provides the same information as above, but focused on hang events only

• Manufacturer Summary
  This pie chart shows the manufacturer stats based on both hang and crash events

• Application Reliability Issues – By Exe
  This data grid with bar chart shows the top applications with events in your environment

Clicking on the applications highlighted in blue (linked) will then open a slide in workbook with additional details about the events impacting that executable.

This workbook contains the following additional information;

• Application Timeline
  Time chart of events based on the application

• Application Count
  Count of application versions detected in your environment
• Associated Faulting Modules
  Faulting modules (DLL’s etc)

• Computers Impacted
  List of devices which have events for the application

• Additional Application Issues
  Additional application events from the same manufacturer (this will dynamically display where the count is more than 0)

The workshop JSON’s (AppReliabilityDashboard & AppReliabilityDetails) are available here – Reporting/Workbooks at main · MSEndpointMgr/Reporting (github.com). Putting this together we have a reporting solution where you can do what you would like to with the data, including extending to logic apps or monitor events to inform you of spikes etc.

Workbook Configuration & Data Collection Prerequisites

Obviously there are some modifications that are required in order to get these workbooks to function, and you will need a Log Analytics workspace in the first instance to send the data to (something I am not covering here, but Microsoft docs have you covered – Create a Log Analytics workspace in the Azure portal – Azure Monitor | Microsoft Docs).

From a client device side of things, we are leveraging Proactive Remediations in this instance and therefore you will need to be licensed. You can view the Microsoft docs (What is Endpoint analytics? – Microsoft Endpoint Manager | Microsoft Docs) for more information, and it is possible to do something similar through scheduled tasks, but you will not have overview of the jobs, as you do within PR.

Deploying PowerShell script via Proactive Remediations

First things first, my recommendation here is to use a function app for log event ingestion as this provides the most secure method, with no hardcoding of workspace information. If you do opt to use the script with these values hard coded, just be aware that an admin of the device could obtain the workshop details, as they are in plain text.

• Log into the Endpoint Manager Admin Center
• Click on Reports
• Click on Endpoint Analytics
• Click on Proactive Remediations
• Now click on “+ Create Script Package”
  

• Give your PR script a name, “Collect Custom Inventory” for instance
• Click on the folder icon on the “Detection Script File” line to browse for the collection PowerShell script.
  
  Please note that you will have to either update the API URI or the Workspace ID / Primary key depending on which script you are using

• Add any required Scope Tags
• Assign the script to a Group of your choice, defining a time to run
• Click on Create at the “Review + Create” and now your clients will need time to check in

Workbook Modifications

Before we attempt to add the workbook, we should confirm that we have data to work with. Going into your Log Analytics workspace and click on Logs, check for the “AppReliability_CL” under your custom logs section, as per the screenshot;

Running a quick query on the custom log you should have something like the below;

Now onto the workbook modifications. Taking the JSON for the main workbook, and pasting that into a new blank workbook, you can click on Apply. At this point you should have something similar to the screenshot below;

In order to launch the details workbook, we need to specify a Log Analytics workspace ID and workbook ID, this is done by editing the parameters at the top of the main workbook.

Editing the Log Workspace parameter first, we need to specify the Log Analytics workspace name we are using for the log file, and then press the “Run Query” button, which should result in a single entry in the results pane.

For the child “App Details” workbook, you will need to import the JSON and save as “Application Reliability – App Details” (in this example), then editing the “DetailsWorkbook” parameter you should enter something similar to the below;

The above values are important for the child workbook, without that it will not work, so please ensure to edit these values. Once your clients check in, your workbooks should behave like in below video;

Conclusion

Leveraging PowerShell, Azure Functions (recommended), and Log Analytics we now have an application reliability dashboard that you can use to monitor the stability of client device applications across your entire environment (where of course you have internet, co-managed or Intune managed, and proactive remediations).

I hope you find this useful and I am looking for feedback on this, and any other functions you would like to have added.

Cost Note: Log ingestion costs will apply, however, they should be very small as the typically the payload sizes are less than 100Kb. As an example in an environment with 5000 devices, log ingestion would cost circa $75-$100 per month. You can monitor this cost, and I would suggest that the logs are stored within their own resource group and LA workspace for you to ensure you have clear visibility of the cost.

(25)

The post Application Reliability Monitor with Log Analytics appeared first on MSEndpointMgr.

In this post I will show you how to use Proactive Remediations and Log Analytics, together, to ensure Windows Update Settings are Optimal and Compliant on your devices. This post comes on the back of a session both Aria Carley and I presented at #MMSMOA this year – Fun times!

Background

I was working with a customer recently and we were having a conversation around the optimal settings to ensure a great experience when delivering Windows Update policy using Intune. It had occurred to me to mention that I had previously seen environments where legacy policy was either “breaking” updates completely or adversely affecting the update experience for the end users.

At around the same time, Aria had published a fantastic article on the Microsoft Tech community blog Why you shouldn’t set these 25 Windows policies

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/why-you-shouldn-t-set-these-25-windows-policies/ba-p/3066178

In the post Aria explains which settings will give your users a “sub optimal” experience with Windows Updates and which settings have absolutely no effect.

Previous experience taught me that there are also some legacy settings that will “absolutely break” the Windows Update experience for users – especially when the Windows Update workload is moved from ConfigMgr to Intune.

What are these bad settings you speak of?

NoAutoUpdate was a policy some ConfigMgr admins used to set back in the day. It was a way that some used to control duplicate Windows Update balloon notifications from appearing on Windows 7 devices. Largely, it is not used today but I still find this registry key tattooed on some of my customers devices.

DisableDualScan is another policy setting that can adversely affect the delivery of Windows Updates when you move workloads to Intune in a Co-management scenario. ConfigMgr will set DisableDualScan to 1 when the Windows Update workload is with ConfigMgr/WSUS. When you move the workload to Intune, ConfigMgr will change this value to 0 to allow the client to Dual Scan (against both the Windows Update Service and WSUS). If we run rsop.msc on the client we can see this policy enforced by Local Group Policy (ConfigMgr)

Once we move the workload to Intune, DisableDualScan is disabled

If you Disable Dual Scan using GPP/Script/CI then this value can be overwritten and cause issues when the workload is move to Intune. When the workload is with ConfigMgr, this setting is OK. When I move the workload to Intune, I expect the settings to stop being enforced (and not be overwritten).

Another “breaking” policy setting, if present when the Windows Update workload is moved to Intune, is DoNotConnectToWindowsUpdateInternetLocations

You guessed it, this setting will stop the client reaching out to the internet for Windows Updates. Not a setting you want if you move your Windows Update workload to Intune/WUfB.

As well as the 3 settings above, Aria also calls out the Legacy policy settings in her post that will either cause a non-optimal Windows Update experience or actually have no affect on Windows Updates at all – once the Windows Update workload is move to the Windows Update Service.

I have listed the registry keys below that will either cause issues, a sub-optimal experience or have no impact at all.

Service Breaking Settings

Service Affecting Settings

Service Settings that have no effect

What Intune Reports show me if I have these bad settings in my environment?

I like your sense of humour. But seriously, there is no reporting in Intune, today, that will show us if these settings are causing adverse effects on your devices and ultimately affecting your overall Windows Update Compliance level. I personally would like to see some of this stuff come up with telemetry to Update Compliance in Log Analytics but I am not expecting to see that anytime soon.

While we wait for Unicorns and rainbows in Intune, I have built my own interim solution, based on my previous experience and the advice given by Aria in the Tech Community post I listed earlier.

The Solution

The solution comes on the back of other great community solutions from the MSEndpointMgr team. We have been collecting Custom Inventory for a while now (thanks to @jankeskanke @mauriced @sandy_tsang @nickolaja).

Enhance Intune Inventory data with Proactive Remediations and Log Analytics – MSEndpointMgr

Running a Proactive Remediation, to inventory clients Registry/WMI information and sending the results to Log Analytics for rich reporting, is what the cool kids are doing these days. It allows us to report client state information almost instantly, without having to wait for Intune reporting to get its act together.

Whilst Intune reporting leaves something to be desired today, I know the product group are working really hard to improve this experience for all of us – so thank you for your diligent and hard work. We wait excitedly for a great reporting experience natively in Intune.

Using the same methods as we do with Custom Inventory, the solution will do the following:-

• Inventory the Windows Update Registry Settings that are known to affect the Windows Update experience
• Collect other useful device information such as:-

• Create a JSON payload and send the results to Log Analytics
• Visualise the results in a Workbook for easy Compliance Reporting

With this information, we can start to understand if there are any legacy settings in our environment that are adversely affecting how we expect Windows Update to behave.

Scripts

Grab the script(s) from the MSEndpointMgr GitHub Reporting repo. One script requires you to embed the Log Analytics workspace workspace ID and shared key into the script. The other script, which is more secure, uses a Function app in Azure to authenticate your devices. It only requires you to embed the Function app URL in the script. Only devices registered in your tenant will have permission to upload to Log Analytics using the Function app (so cool).

Script Option 1 (Shared Key Embedded in Script)

Reporting/Invoke-WUInventory.ps1 at main · MSEndpointMgr/Reporting (github.com)

You need to replace CustomerID and SharedKey (Lines 27 and 30) with the correct value from your Log Analytics workspace

CustomerID = Workspace ID
SharedKey = Primary Key

Script Option 2 (Function App URL Embedded in Script)

Reporting/Invoke-WUInventory_Funky.ps1 at main · MSEndpointMgr/Reporting (github.com)

As we pointed out earlier, using the Function app is a much better approach when sending data to Log Analytics because we don’t embed in secrets in the inventory script.

If you missed it, read more here about using Azure Function app to secure sending data to Log Analytics

Enhance Intune Inventory data with Proactive Remediations and Log Analytics – MSEndpointMgr

Proactive Remediation

Either of the scripts above can be run as a Proactive Remediation. You should only set the Detection Script, there is no Remediation script required as we are simply using the detection script to send data to our Log Analytics workspace. You should also set the Proactive Remediation to run in 64 bit PowerShell.

Log Analytics

The first device to run the script will create a custom log in your Log Analytics workspace.

The log name can be changed in either of the scripts around line 30.

All custom logs you create in Log Analytics will get a _CL suffix appended

As data starts to get uploaded, you will see a line entry each time the client sends data. We summarise multiple entries when we do reporting so we only show the latest record the client uploads. Here is an example of what the data will look like.

Workbook

We could spend all day long writing KUSTO queries in Log Analytics – but there is a better way and someone else has done all the hard work for you. Grab the workbook source (copy as raw) from the link below so we can start to visualise the data from the logs.

Reporting/Windows Update Device Settings.workbook at main · MSEndpointMgr/Reporting (github.com)

Create a new workbook in the same Log Analytics workspace

Tap the advanced editor

Paste in the raw data from the JSON above and tap Apply

Tap the Save icon

Specify a workbook name and validate the workspace settings

Tap Save and Done Editing

Your workbook should now start to look something like this. First we list some Windows Build Information. Remember, this is collected directly from the client and doesn’t rely on Update Compliance or Windows Telemetry data (which can be slow to update).

Next we show the “Service Breaking Settings”. If your devices show up here and the Windows Update workload is set to Intune/WUfB – they most probably are not getting Windows Updates!

Next we show you and settings on the devices that may affect the Windows Update experience i.e. it may be sub-optimal

Finally, on the dashboard, we show you settings that are in place that have no affect on the Windows Update experience – so why are you setting them?

The other tabs will also show you some useful information

Summary

Hopefully this post has helped you understand how awesome inventory scripts and Log Analytics are. We can manipulate the inventory scripts to collect a whole host of information from our devices.

This is Version 1 of the workbook. We have big plans on collecting more Windows Update related settings from devices and hopefully Version 2 of the workbook will TELL you which settings (GPO/GPP/CSP) that you need to change to ensure your devices are optimally configured to received updates using WUfB.

Big thanks to Aria for always being willing to share her brain and passion with the community.

DM me on Twitter if you want further clarification around the topics listed in this post.

(5)

The post Windows Update Settings Compliance appeared first on MSEndpointMgr.