PS Oneliner to get local device compliance state

Getting local Azure AD / Intune device compliance state with a PowerShell Oneliner

The Graph API and Intune portal(s) give insight into device compliance status, but what about a local equivalent? How can we locally detect from e.g. a script on a Windows 10 laptop if the device is compliant or not?

I couldn’t find any documentation, WMI properties or registry keys, but I did find that the Company Portal shows the compliance status and caches this in a file. So, although it isn’t pretty, I’ve settled for this method for now and created a UserVoice item requesting a local W10 API/regkey/WMI property to query Intune compliance status of the device.

((get-content -Path (Get-Childitem –Path (Join-Path $env:LOCALAPPDATA `
-ChildPath "Packages\Microsoft.CompanyPortal_8wekyb3d8bbwe\TempState\ApplicationCache") `
-Include *.tmp* -File -Recurse | sort-object -Descending -Property lastWritetime)[0] | convertfrom-json).data | convertfrom-json).ComplianceState

Using pipeline identity for Connect-AzureAD, Graph and other endpoints

Azure Pipelines and Azure Functions (and Automation Accounts) can have managed identities, in other words, a service principal. This service principal can be assigned to Azure AD roles (e.g. to modify users / devices) or graph / Azure RM resources. A service principal could even be a global admin, and Service Principals don’t have to do MFA…. 🙂

In both Pipelines and Functions the new Az module is enabled and logged into your tenant by default as the service principal, how cool would it be to use that identity to do those (hopefully few) things that are still only supported by e.g. the AzureAD module?

Here’s an example on getting tokens for Azure AD and for Graph, obviously you could also get tokens for other audiences the same way:

$context = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile.DefaultContext
$graphToken = [Microsoft.Azure.Commands.Common.Authentication.AzureSession]::Instance.AuthenticationFactory.Authenticate($context.Account, $context.Environment, $context.Tenant.Id.ToString(), $null, [Microsoft.Azure.Commands.Common.Authentication.ShowDialog]::Never, $null, "https://graph.microsoft.com").AccessToken
$aadToken = [Microsoft.Azure.Commands.Common.Authentication.AzureSession]::Instance.AuthenticationFactory.Authenticate($context.Account, $context.Environment, $context.Tenant.Id.ToString(), $null, [Microsoft.Azure.Commands.Common.Authentication.ShowDialog]::Never, $null, "https://graph.windows.net").AccessToken

Write-Output "Hi I'm $($context.Account.Id)"

Connect-AzureAD -AadAccessToken $aadToken -AccountId $context.Account.Id -TenantId $context.tenant.id

get-azureaduser -Top 5

If you want to do this from an old fashioned Azure Runbook (please move to functions!) then you’ll have to log in to Az first:

try
{
    $servicePrincipalConnection = Get-AutomationConnection -Name "AzureRunAsConnection"
    Connect-AzAccount -Tenant $servicePrincipalConnection.TenantID `
        -ApplicationId $servicePrincipalConnection.ApplicationID   `
        -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint `
        -ServicePrincipal
}catch {
    Write-Error -Message $_.Exception
    throw $_.Exception
}

Programmatically creating an azure runas account with your automation account

As there is no ARM feature in Azure yet to provision an automation runas account when provisioning automation accounts, I had to code something up to do this on the fly while we’re waiting for a Uservoice article to get prioritized.

Use my script in your pipeline to automatically provision a RunAs account. Note, the account credentials you use there should not be MFA protected or it will fail to log in.

https://gitlab.com/Lieben/assortedFunctions/blob/master/New-RunAsAccount.ps1

Duplicate AzureAD Device Cleanup

When you swap a device by reimaging or reinstalling, the Hardware ID stays the same. This results in multiple Device Entries in Azure AD and causes issues with Conditional Access as Intune thinks the older version isn’t actually compliant even though Intune just has 1 record.

Most methods (such as Nicola’s) to combat this is by cleaning up stale devices in Azure AD based on their last Active Date. However, the downside of this method is that it may touch devices which weren’t duplicates, just dormant during, e.g. a vacation. Additionally, a bug in AzureAD can cause the older duplicate’s active date to be updated instead of the correct device.

The following script detects duplicates based on the Hardware ID and registration date instead and disables all but the most recent entry. It can supplement stale device removal based on Last Activity.

Note: only works for Windows registered devices.

Git: disable-duplicateAzureAdDevices.ps1

Office 365, Azure, Enterprise Mobility and DevOps