What happens to Microsoft 365 email signatures after the Azure AD PowerShell retirement?

If you manage email signatures in Microsoft 365 with PowerShell, the ground has shifted under those scripts. The Azure AD and MSOnline PowerShell modules were retired as of 2025, and Exchange Web Services began switching off in October 2026. Microsoft Graph is the official path forward for both.

For most Microsoft 365 tasks, that migration is well documented. Signatures are the exception. The methods IT has leaned on to apply email signatures across a tenant sit directly in the path of these changes, and Microsoft Graph, the recommended replacement, has no API for managing email signatures at all.

So this is less a migration than a dead end for the scripted approach. The sections below cover what's changing, what it means for any signature script you still run, and the route that sidesteps the churn.

Why did my PowerShell email signature script stop working after the Azure AD module retirement?

The Azure AD and MSOnline PowerShell modules were retired through 2025, so any signature script that read user details through them stopped running until it's rebuilt on Microsoft Graph PowerShell. The modules managed identity in Microsoft 365. Neither ever set a signature, yet their retirement still reaches the scripts that build them.

Both modules handled user and group management, including reading the directory attributes a signature script needs: names, job titles, departments, and phone numbers.

Microsoft deprecated the Azure AD, Azure AD Preview, and MSOnline PowerShell modules in March 2024 and retired them through 2025, directing admins to the Microsoft Graph PowerShell SDK as the replacement. The cmdlets no longer work.

The practical result: any script reading employee details through the Azure AD (Entra ID) or MSOnline modules must be rebuilt against Microsoft Graph PowerShell before it runs again. The signature-assembly code is untouched; only the directory data feeding it stopped flowing.

After October 2026, PowerShell scripts can no longer programmatically set Outlook signatures via EWS, and Microsoft Graph API still lacks native signature management support — so scripted approaches face a dead end while managed solutions continue working.

The cmdlets a signature script typically calls have direct Microsoft Graph PowerShell equivalents:

What is Microsoft Graph PowerShell and what does it replace?

Microsoft Graph PowerShell is a module built on the Microsoft Graph API, the single interface Microsoft now uses to reach data across Microsoft 365. Microsoft moved to it because one modern, consistent endpoint is easier to secure and maintain than the patchwork of older APIs it replaced.

Microsoft Graph connects the services in Microsoft 365. Rather than a separate interface for each one, it exposes users, mail, files, groups, and directory data through a single API and a single access token, reaching Microsoft Entra ID (formerly Azure AD), Exchange, SharePoint, and Outlook from one endpoint. Microsoft Graph PowerShell wraps that API in cmdlets, so admins can script across those services from one module instead of several.

Retiring the Azure AD and MSOnline PowerShell modules was part of that consolidation. Both ran on the older Azure AD Graph API, a set of fragmented interfaces that no longer met modern security and cross-platform demands, which is why Microsoft moved to the Graph-based SDK. Graph brings modern authentication, granular permission scopes, and wider platform support, and it leaves Microsoft with one surface to maintain rather than many.

For identity work, this is a real upgrade. A signature script that reads names, titles, and departments can have those queries rewritten in Microsoft Graph PowerShell and keep running. Microsoft Entra PowerShell, also built on Graph, is an identity-focused alternative with close compatibility to the retired modules. Applying the signature is the harder problem, and it's where Microsoft Graph currently offers no answer.

Getting connected takes three steps: install the module (Install-Module Microsoft.Graph), authenticate (Connect-MgGraph -Scopes User.Read.All), then run the equivalent cmdlets from the table above. Microsoft's Graph PowerShell get-started guide covers the full setup.

Timeline of Microsoft 365 changes

Does Microsoft Graph have an API for managing Outlook email signatures?

A scripted signature does two jobs: it reads employee data from the directory, and it applies a signature to the mailbox. The move to Microsoft Graph changes both, and the harder problem is the second.

The “reading” job has a clear path forward. Queries that pulled names, titles, and departments through the retired modules can be rewritten in Microsoft Graph PowerShell and will keep working. That work is finite: update the queries, test, redeploy.

The "applying" job is where things get messy. When EWS is blocked by default on October 1, 2026, ahead of full retirement in April 2027, the one programmatic route some tools used to read and write Outlook signatures closes, and because the Graph API has no support for managing signatures, nothing replaces it. The remaining native option, Set-MailboxMessageConfiguration, still sets an Outlook on the web signature, but its SignatureHTML parameter stops working once Outlook roaming signatures are enabled, now the default in many cloud tenants.

Important limitation: Microsoft Graph API currently does not support managing email signatures directly. Per Microsoft's own guidance, signatures are stored by the Outlook client rather than in the mailbox settings Graph can reach, which is why no Graph endpoint exists for this function.

So the transition doesn't modernize signature scripts. It narrows them. The data half needs rebuilding, the applying half loses its cleanest path, and every future platform change adds another round of testing on top of routine updates.

That upkeep is already costly: in Exclaimer's State of Business Email 2025 research, 35% of IT teams named email signature management one of their two most time-consuming tasks. A maintained signature script is an in-house build, and it carries the running cost of one. That’s worth weighing before you keep investing in it.

Can you still manage Microsoft 365 email signatures with PowerShell?

Partly. Two native methods survive the transition, the Set-MailboxMessageConfiguration cmdlet and Exchange transport rules, but each has real limits and both leave the upkeep on IT.

The cmdlet sets the Outlook on the web email signature one mailbox at a time, and you can script it across users. The constraint is scope: it governs Outlook on the web rather than desktop Outlook, and it stops applying once Outlook roaming signatures are turned on.

An Exchange transport rule takes the other approach, appending an HTML disclaimer to outgoing mail at the server so it reaches every user at once. The trade-offs are familiar to anyone who has run one. The disclaimer lands at the bottom of the entire thread instead of under the latest reply; it doesn't appear in the sender's Sent items, and it can't reliably pull per-user details or inline photos into a designed layout.

Neither method delivers what most organizations actually want: a consistent, on-brand email signature that renders the same everywhere and updates itself from the directory. Few teams manage to get there this way. In fact, our State of Business Email 2025 report highlighted that 80% of organizations still rely on manual methods or user self-service, and only 18% use centralized management.

Go deeper: PowerShell's limits for email signatures

For an in-depth look at where the scripted approach falters, see our guide to the limitations of PowerShell for email signature management.

Read now

How do I manage Microsoft 365 email signatures without PowerShell scripts?

A maintained signature script is a small in-house build, and the past two years show how exposed that build is to Microsoft's roadmap. The build-versus-buy question for email signatures comes down to who absorbs the next platform change: your team, or your vendor.

It's a familiar pattern. According to Exclaimer's Build vs Buy research, 71% of in-house IT builds are eventually abandoned. Signature scripts fit that arc closely. They start as a few tidy lines, then accumulate edge cases, dependencies, and rewrites every time the platform underneath them moves.

A managed service changes where that exposure sits. Rather than scripts that read the directory and write to each mailbox, a dedicated email signature management platform handles the whole job itself. Exclaimer's Directory Sync pulls the data fields from Microsoft Entra ID automatically, and Cloud deployment applies signatures server-side, keeping rendering consistent across desktop Outlook, Outlook on the web, and mobile without a script in sight. When Microsoft retires a module or an API, absorbing that change becomes the vendor's job rather than a weekend of rework for your team.

Exclaimer has done this for more than 25 years, since building the first email signature software in 2001, and Exclaimer's cloud solution now manages email signatures for over 80,000 organizations. IT keeps full control of policy and deployment while delegating design and content to marketing or HR, with no scripts to rewrite when the platform shifts.

Scripted approaches require manual rework for each platform change; managed solutions absorb changes automatically.

The scripted column is a list of future tasks. The managed column is a list of things you no longer have to think about.

What is the best way to centrally manage email signatures in Microsoft 365?

The scripted route to Microsoft 365 email signatures still works in places, but every Microsoft platform change makes it narrower and costlier to maintain.

If you run a handful of mailboxes and your email signatures rarely change, keeping a script going may be fine for now. For most organizations, the maintenance only grows: directory queries to rebuild, native methods losing ground, and a fresh round of testing with each platform shift.

A managed platform takes that work off IT's plate and keeps email signatures consistent while Microsoft's tooling keeps moving. The real decision is simply whether you want to keep maintaining the scripts, or hand the problem to something built to absorb these changes for you.

Next step: Take email signatures off the maintenance list with a free trial of Exclaimer.