Category Archives: Uncategorized

Adding a font to an MSIX

My friends at Advanced Installer have an excellent article (actually the only authority on the subject) describing how to add a font to an MSIX.

However, I kept getting an invalid manifest 0x80080204 error when trying to save the manifest after adding the extension section while creating an MSIX for Visual Studio Code (which needs a specific font or icons won’t show).

I then noticed there was no xmlns link at the top of the package for uap4 πŸ™‚

Replace the following in your manifest:

<Package xmlns="" xmlns:uap="" xmlns:uap2="" xmlns:uap3="" xmlns:uap10="" xmlns:rescap="" IgnorableNamespaces="uap uap2 uap3 uap10 rescap">

with this (or just add uap4):

<Package xmlns="" xmlns:uap="" xmlns:uap2="" xmlns:uap3="" xmlns:uap4="" xmlns:uap10="" xmlns:rescap="" IgnorableNamespaces="uap uap2 uap3 uap4 uap10 rescap">

And it should work πŸ™‚

Copying filesystem permissions for long paths using AlphaFS nad Powershell

AlphaFS is my go-to library when working with Long Paths, since PowerShell’s built in functions do not support long paths and error out.

As I couldn’t find good PowerShell examples using GetAccessControl and SetAccessControl with the AlphaFS library, I wanted to post my script here for those googling an example πŸ™‚



$sourcePath = [Alphaleonis.Win32.Filesystem.Path]::GetLongPath($sourcePath)
$targetPath = [Alphaleonis.Win32.Filesystem.Path]::GetLongPath($targetPath)

    Write-Verbose "Detected sourcePath as FOLDER"
    $sourceObject = New-Object Alphaleonis.Win32.Filesystem.DirectoryInfo($sourcePath)
    Write-Verbose "Detected sourcePath as FILE"
    $sourceObject = New-Object Alphaleonis.Win32.Filesystem.FileInfo($sourcePath)
    Throw "sourcePath not found"

    Write-Verbose "Detected targetPath as FOLDER"   
    $targetObject = New-Object Alphaleonis.Win32.Filesystem.DirectoryInfo($targetPath)
    Write-Verbose "Detected targetPath as FILE"
    $targetObject = New-Object Alphaleonis.Win32.Filesystem.FileInfo($targetPath)
    Throw "targetPath not found"

$sourceACL = $sourceObject.GetAccessControl("Access")


AADSTS50131: Device is not in required device state: known. Or, the request was blocked due to suspicious activity, access policy, or security policy decisions with WDATP

If you’re trying to use the Windows Defender Advanced Threat Protection through the API or through PowerBI and get an AADSTS50131 error, you’ll probably check your sign in logs to see if you’re being blocked by conditional access. If there’s nothing there, as I had the joy of discovering (tsk Microsoft, you really should log this) then check your classic policies and disable if present (old anyway):

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