Azure AD sign in and audit log retention

Often we, as cloud admins, need our audit or sign in logs. Usually, we need real-time data because, for example, we’re debugging why that one user has conditional access issues. But sometimes, we need to go back further than 30 days. And that is not something Azure does by default, but can be enabled:

Our options when exporting logs are limited to a Storage account, Log Analytics or an Event Hub. All these options offer multiple extraction methods to cover your transport needs to other systems. The default retention period is then forever, which is nice as we might need audit info going back a bit as hacks are usually discovered after about 206 days.

If you don’t have specific tools or requirements, I recommend setting up a Log Analytics workspace and connecting that to Azure AD:

Whichever method you choose, a P1 or P2 license is required. You only need a single license for the entire tenant when using the export audit / singin log functionality of AzureAD. Once configured, the Logs option directly bring you to the Log Analytics workspace search results:

I’ve briefly shown how to configure AzureAD to send audit and sign in logs to Log Analytics so you can go back further than 30 days. Stay tuned for the next post that will utilize these logs to dive deeper into Guest User activity.

Devices that lack a bitlocker recovery key in AzureAD

With Intune’s new Bitlocker Encryption Report administrators have an effective way of seeing which of their devices have been encrypted.

But if we want to know if we can actually recover the bitlocker key of a device, we need to know if it was ever uploaded to AzureAD.

Network or local device issues can sometimes prevent the recovery key from reaching AzureAD, resulting in lost data if the device’s disk needs to be recovered for any reason. To hunt down devices that have not escrowed their recovery key to AzureAD, you can use my report function (in PowerShell as always):

GitLab source download link

Programmatically triggering a group licenses refresh for AzureAD

Azure AD allows us to assign licenses to groups, a nifty feature that has made a host of automation scripts dealing with bulk license assignment obsolete.

A problem I’ve encountered is that when you assign users to a group, license assignments are not processed right away, especially if you didn’t have enough licenses when you assigned the user to the group (and added licenses to the tenant later).

Azure AD has a button to trigger an update manually:

But of course, this can also be automated with PowerShell!

function Invoke-AzHAPIReprocessGroupLicenses{
        reprocesses group license assignment

        Author: Jos Lieben

        .PARAMETER AzureRMToken
        Use Get-azureRMToken to get a token for this parameter

        .PARAMETER groupGUID
        GUID of the group to reprocess licenses of
        - Global Administrator Credentials (non-CSP!)
        - AzureRM Module
        - supply result of get-azureRMToken function
        [Parameter(Mandatory = $true)]$AzureRMToken,
        [Parameter(Mandatory = $true)]$groupGUID
    $header = @{
        'Authorization' = 'Bearer ' + $AzureRMToken
        'X-Requested-With'= 'XMLHttpRequest'
        'x-ms-client-request-id'= [guid]::NewGuid()
        'x-ms-correlation-id' = [guid]::NewGuid()

    $url = "$groupGUID/Reprocess"
    Invoke-RestMethod –Uri $url –Headers $header –Method POST -Body $Null -UseBasicParsing -ErrorAction Stop -ContentType "application/json"

Source on GIT:

Disclaimer: the ‘hidden azure api’ is not officially supported.

Requires output from the Get-AzureRMToken function

Get an Office365 / Azure AD tenant ID from a user’s login name or domain

I often need a tenant ID for a given customer, the usual method to get it is to log in to the Azure portal and find it there. But what if you want to get the tenant ID programmatically? Without actually logging in? And you only know the log in name of a user? Or just one of the customer’s domain names?

Then this’ll help you out!

function get-tenantIdFromLogin(){
      Retrieves an Office 365 / Azure AD tenant ID for a given user login name (email address)
      $tenantId = get-tenantIdFromLogin -Username
      .PARAMETER Username
      the UPN of a user
      filename: get-tenantIdFromLogin.ps1
      author: Jos Lieben
      created: 8/3/2019
    $openIdInfo = Invoke-RestMethod "$($Username.Split("@")[1])/.well-known/openid-configuration" -Method GET
    return $openIdInfo.userinfo_endpoint.Split("/")[3]

Obviously, you can also get the tenant ID by just filling out bogus info in front of the user’s login (e.g., it’ll still work as only the domain part of the login is really used.

Hope this helps someone 🙂

Git link:

Deploying an embedded file (FONT) in a Powershell script through Intune MDM

Most solutions that describe how to deploy a font through Intune use an external source to host fonts such as Azure Blob storage.

If you want to KISS (keep it simple, stupid), you don’t want to maintain two different things (your script and externally accessible storage).

The following example shows how to embed a file in a PowerShell script, and then install it into the Fonts folder. This could, of course, be used for other purposes, but don’t forget that the script size limit in Intune is only 200kb.

First, execute the following in a PS window:

$inputFontPath = "C:\fonts\YourFont.ttf"
Compress-Archive $inputFontPath -CompressionLevel Optimal -DestinationPath (Join-Path $Env:TEMP -ChildPath "") -Force
[Array]$bytes = [io.file]::ReadAllBytes((Join-Path $Env:TEMP -ChildPath ""))
$b64 = [System.Convert]::ToBase64String($bytes)
$b64 | Set-Clipboard

You have now compressed and base64 encoded YourFont.ttf, and this is loaded in memory (clipboard).

Create a new file, e.g. YourFont.ps1 and add the following:

$byteContent = [System.Convert]::FromBase64String($b64)
$byteContent | Set-Content (Join-Path $Env:TEMP -ChildPath "") -Encoding Byte -Force
Expand-Archive -Path (Join-Path $Env:TEMP -ChildPath "") -DestinationPath (Join-Path $Env:TEMP -ChildPath "tempfontsfolder") -Force

$sa =  new-object -comobject shell.application
$Fonts =  $sa.NameSpace(20)
gci (Join-Path $Env:TEMP -ChildPath "tempfontsfolder") | % {$Fonts.MoveHere($_.FullName)}

Remove-Item (Join-Path $Env:TEMP -ChildPath "") -Force -ErrorAction SilentlyContinue
Remove-Item (Join-Path $Env:TEMP -ChildPath "tempfontsfolder") -Force -Recurse -ErrorAction SilentlyContinue

On the first line, follow the instructions (e.g. paste your b64-encoded font on that line). Now save and check if the size is below 200kb, then distribute the script to your users. For Fonts, don’t forget to let the script run in system context as administrative permissions are required when installing Fonts.

This method can be used to deploy other payloads as well, happy scripting!

Removing special characters from UTF8 input for use in email addresses or login names

When working with non-US customers, users often have characters in their names like ë, ó, ç and so on. Most of the time, a ‘human process’ converts these to their simple equivalent of e, o and c for use in computerized systems.

When searching for such a mapping of special characters to ‘safe’ characters I had a hard time finding a good list or PowerShell method to automatically convert special characters to standard A-Z characters so I wrote one:

function get-sanitizedUTF8Input{
    $replaceTable = @{"ß"="ss";"à"="a";"á"="a";"â"="a";"ã"="a";"ä"="a";"å"="a";"æ"="ae";"ç"="c";"è"="e";"é"="e";"ê"="e";"ë"="e";"ì"="i";"í"="i";"î"="i";"ï"="i";"ð"="d";"ñ"="n";"ò"="o";"ó"="o";"ô"="o";"õ"="o";"ö"="o";"ø"="o";"ù"="u";"ú"="u";"û"="u";"ü"="u";"ý"="y";"þ"="p";"ÿ"="y"}

    foreach($key in $replaceTable.Keys){
        $inputString = $inputString -Replace($key,$replaceTable.$key)
    $inputString = $inputString -replace '[^a-zA-Z0-9]', ''
    return $inputString

#example usage:
get-sanitizedUTF8Input -inputString "Jösè"

Edit: my colleague Gerbrand alerted me to a post by Grégory Schiro which solves this issue much more elegantly using native .NET functions. My slightly modified version to really ensure nothing non a-zA-Z0-9 gets past the function:

function Remove-DiacriticsAndSpaces
    $objD = $inputString.Normalize([Text.NormalizationForm]::FormD)
    $sb = New-Object Text.StringBuilder
    for ($i = 0; $i -lt $objD.Length; $i++) {
        $c = [Globalization.CharUnicodeInfo]::GetUnicodeCategory($objD[$i])
        if($c -ne [Globalization.UnicodeCategory]::NonSpacingMark) {
    $sb = $sb.Normalize([Text.NormalizationForm]::FormC)
    return($sb -replace '[^a-zA-Z0-9]', '')
#example usage:
Remove-DiacriticsAndSpaces -inputString "Jösè"

And an even easier oneliner I converted to a function by John Seerden:

function Remove-DiacriticsAndSpaces
    #replace diacritics
    $sb = [Text.Encoding]::ASCII.GetString([Text.Encoding]::GetEncoding("Cyrillic").GetBytes($inputString))

    #remove spaces and anything the above function may have missed
    return($sb -replace '[^a-zA-Z0-9]', '')

And the most advanced function I’ve found so far is by 
Daniele Catanesi (PsCustomObject): in which all features of above functions are supported and parameterized.

Reporting on global tenant storage usage and per site storage usage

As my employer is a Microsoft Cloud Service Provider, we want to monitor the total storage available and the total storage used by all of the tenants we manage under CSP, including storage used by Sharepoint and Teams. This called for a script!

per customer total storage usage overview

I slimmed down the resulting script to work for just a single tenant that you can use to generate an XLSX report of which of your sites / teams are nearing their assigned storage quota. You can either build your own alerting around this to raise site quota’s before your users upload too much data, or you can use it to buy additional storage from Microsoft before your tenant reaches the maximum quota 🙂

per site storage overview in excel

As usual, find it on Gitlab!

Finding files in Sharepoint Online or Teams that exceed 218 path length

A well known issue when migrating to Office 365 (Sharepoint, Teams and Onedrive) is path length.

Recently, Microsoft increased the maximum path length in Sharepoint Online from 256 to 400 characters (total length of the URL). This causes issues when you use Office, because Office 2013, 2016 and 2019 do not support paths over 218 characters in length.*

To help you proactively identify files that exceed this limit I wrote a PowerShell script you can run:

  • it can filter based on file type
  • automatically finds and processes all sharepoint sites in your tenant
  • automatically finds and processes all team sites in your tenant
  • it can handle multi-factor authentication

Find get-filesWithLongPathsInOffice365.ps1 on GitLab

It leans heavily on the great work done by the community around OfficePnP, all credits to the community for providing so much quality code for free!

*longer paths may still work, this is not a hard limit