Need Recedes for Unified Labeling Client

On April 11, Microsoft announced that they will retire the AIP client, aka the Unified Labeling client, aka the AIP add-on for Office, on 11 April 2024. The add-on has been in maintenance mode since January 1, 2022, so its final retirement was only a matter of time. Once retirement happens, users cannot assign sensitivity labels to documents through the add-on.

A Long Road

In 2016, when I first started writing about how to protect Office documents with labels, the labels were called Azure Information Protection labels and users needed to install the add-on to add elements like the information protection bar and the code to apply rights management to documents. The situation was natural because Azure Information Protection was a separate product that targeted Office but had no formal alignment with Office development. The add-on was only available for Office on Windows.

Things changed when Microsoft decided that sensitivity labels were strategically important to Office 365, which meant that they needed to build support for sensitivity labels across the infrastructure in apps like SharePoint Online and Exchange Online and desktop, browser, and mobile apps. Sensitivity label support is now broad and deep across Microsoft 365, including for container management of sites, groups, and teams. Regretfully, sometimes Microsoft demands additional licenses for features that seem very basic, such using the Syntex-SharePoint Advanced Management license to control the assignment of default sensitivity labels to SharePoint document libraries.

In 2019, Microsoft started the process of removing the add-on by incorporating the code to handle sensitivity labels in the Office applications (native mode protection). The goal is to provide the same or better functionality in the out-of-the-box Microsoft 365 apps for enterprise (Office desktop) versions of Word, Excel, and PowerPoint. Microsoft says that the Microsoft 365 apps for enterprise “now have most of the capabilities found in the AIP Unified Labeling add-in for Office as well as advanced capabilities not possible with the AIP Unified Labeling add-in for Office.” The most important of these capabilities are:

• PDFs exported from the Office apps retain protection applied by sensitivity labels.
• Sensitivity labels can protect meeting invitations (including attachments) and responses.
• Account switching.
• Users cannot disable labeling controls.

Microsoft has long stressed that incorporating code from the Microsoft Information Protection SDK to make applications natively aware of information protection leads to better performance and increased stability. In other words, something that’s built-in is likely to work better than when an application needs to load in external code.

Native protection is only available with the subscription versions of Office. The functionality isn’t supported by perpetual versions of Office like Office 2019.

Making Changes to Ease Migration

Technologies that affect how people work are usually harder to migrate to new platforms than background processing is. Changes to Office applications are good examples of the truth of this assertion (as anyone who remembers the introduction of the ribbon in Office 2007 can attest).

As an example, the add-on features an information protection bar that people like. The Microsoft 365 apps don’t use the information protection bar. Instead, Microsoft has changed the menu and title bars of the Office apps to highlight labels in a different way, including displaying different colors for different labels. The latest tweak is in Outlook desktop, where the latest builds feature a prominent new button to allow users to more easily assign a sensitivity label to emails (Figure 1).

Other Azure Information Protection Elements

I stopped using the unified labeling client two years ago. However, I have installed the unified labeling client on PCs to get other elements that came with the add-on such as the Azure Information Protection PowerShell module and the ability to classify and protection files from the Windows Explorer. The PowerShell module is especially helpful when the need exists to remove sensitivity labels from files.

Microsoft says that they are not retiring these elements, nor are they retiring the viewers that allow people to view protected content on Windows, iOS, and Android, or the Azure Information Protection Scanner. Microsoft says that following the retirement of the add-on, they will remove it from the installable package available in the Download Center. User will be able to install the new version of the package to access the other elements, which will also be rebranded as Microsoft Purview capabilities.

Time to Move On

The unified labeling client or add-on for Office has served its purpose. It’s time to let it go and migrate as quickly as possible to use the built-in capabilities that exist in Office. Apart from the small fact about the retirement, it’s clear that Microsoft has poured engineering effort into building out the sensitivity label infrastructure across Microsoft 365 for the last several years. Benefit of that work isn’t available to the add-on, which is a good a reason to move on as anything else.

---

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Azure Automation for IT Pros

I’ve spent a lot of time working with Azure Automation over the last few years. It’s an extremely useful facility for tenant administrators who want to run PowerShell scripts using a more modern mechanism than offered by Windows Scheduler. This is especially true so in large tenants where processing hundreds or thousands of objects is common, which is why I started to use Run As accounts with Azure Automation.

Converting scripts to run on Azure Automation isn’t too difficult, once you understand the headless nature of the beast and that PowerShell runs on virtual machines spun up for the purpose. The biggest issue often faced when moving scripts from running interactively to being an Azure Automation runbook is how to create output from scripts, but it’s possible to send email, post to Teams channels, and create files in SharePoint document libraries.

Microsoft seems to communicate with developers and administrators (aka IT Pros) in different ways. For instance, the news about the retirement of Azure Automation Run As accounts on September 30, 2023, didn’t appear in any notification in the Microsoft 365 admin center. In fact, apart from the notices posted in Azure Automation documentation (like that shown in Figure 1), I can’t find a formal announcement from Microsoft.

Informing the Technical Community About the Run As Retirement

The possibility exists that I might not be looking hard enough. Normally, I am reasonably proficient with search (Google), but the first hit I find is a 27 September 2022 Microsoft Answers post saying “On 30 September 2023, we’ll retire the Azure Automation Run As account that you use for Runbook authentication.” I can find an earlier “plan for change” note for July 2022 in the What’s new in Azure Automation page. Apart from that, Microsoft seems to have updated the documentation on 18 October 2022 (here’s the FAQ).

I suppose that it’s reasonable to expect people to learn about developments from documentation. In this instance, I think Microsoft dropped the ball and didn’t do a great job of telling people what’s going to happen when Run As accounts retire.

Managed Identities Are a Better Solution

The logic for retiring Run As accounts is undeniable. A better and more secure solution (managed identities) exists. Run As accounts authenticate using a self-signed certificate that needs to be renewed yearly. Microsoft has removed the ability to renew these certificates from the Azure portal, meaning that Run As accounts are counting down to a time when they won’t be able to authenticate. Microsoft has a script to renew certificates for Run As accounts and the script will run after September 30, 2023. However, Run As accounts will then be unsupported, which isn’t a great situation for production components.

The nice thing about managed identities from an Office 365 perspective is that the important PowerShell modules used for automation support managed identities. Some do so very smoothly (like the latest Exchange Online management module, where even the latest RBAC for applications feature supports managed identities) and some do it with a little extra work. For example, V1.0 of the Microsoft Graph PowerShell SDK needs to get an access token from the Azure Automation account that owns a managed identity while V2.0 will be able to sign in using a managed identity. Here’s an example of a simple runbook that:

• Connects to the Azure Automation account using a managed identity.
• Gets an access token from Azure AD.
• Uses the access token to connect to the Graph with Connect-MgGraph.
• Retrieves the service domain (like office365itpros.onmicrosoft.com) using the Get-MgOrganization cmdlet.
• Uses the service domain and a managed identity to connect to Exchange Online.
• Lists details of user mailboxes.

# Connect to Microsoft Graph with Azure Automation
Connect-AzAccount -Identity
$AccessToken = Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com"
Connect-MgGraph -AccessToken $AccessToken.Token
# Get Tenant service domain using Get-MgOrganization
$TenantName = (Get-MgOrganization).VerifiedDomains | Where-Object {$_.IsInitial -eq $True} | Select-Object -ExpandProperty Name
# Connect to Exchange Online
Connect-ExchangeOnline -ManagedIdentity -Organization $TenantName 
Get-ExoMailbox -RecipientTypeDetails UserMailbox | Format-Table DisplayName, UserPrincipalName

When V2.0 of the Microsoft Graph PowerShell SDK is available, you’ll be able to replace the first three lines of code with a simple Connect-MgGraph -Identity.

Another example of using a managed identity with Exchange Online is to monitor events gathered in the audit log to detect and report events that might indicate potential tenant compromise. Running the script on an Azure Automation schedule makes sure that audit events are checked without human intervention.

Time to Move Forward

Apart from the poor communication, I don’t have any problem with Microsoft’s decision to retire Run As accounts. They worked as a mechanism to connect resources to Azure Automation. We’re just moving on to adopt a new approach. Microsoft documents the migration steps to move from a Run As account to use managed identities. It’s a manual process, but not onerous.