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

If you manage email signatures in Microsoft 365 with PowerShell, the script that read a user's job title last month is already broken, and the script that wrote the signature onto their mailbox is next. The Azure AD and MSOnline PowerShell modules were retired through 2025. Exchange Web Services starts switching off in October 2026. Microsoft Graph the platform Microsoft points to for both, has never had an endpoint for managing signatures.

For most Microsoft 365 administration, the move to Graph is well documented and mostly mechanical. Signatures are the exception, because the specific method IT teams built around, reading a script that both pulls directory data and writes it into a mailbox, sits directly across all three changes at once.

Among the competing guides on this topic we've reviewed, none lay out the Azure AD retirement timeline, the Graph API gap, and the EWS shutdown date together, which is exactly why a script owner can fix one and still get caught out by the other two.

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

The 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, pointing admins to the Microsoft Graph PowerShell SDK as the replacement. The old cmdlets no longer authenticate.

The practical result: any script reading employee details through the Azure AD or MSOnline modules has to be rebuilt against Microsoft Graph PowerShell before it runs again. The part of the script that assembles and applies the signature is untouched by this specific change. Only the directory data feeding it stopped flowing, and a separate set of changes (below) affects the applying side.

The cmdlets a signature script 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.

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

Retiring the Azure AD and MSOnline modules was part of the same consolidation. Both ran on the older Azure AD Graph API, a set of separate interfaces that no longer met current security and cross-platform requirements. Microsoft Graph brings modern authentication and granular permission scopes, and leaves Microsoft with one surface to maintain instead of several.

For identity work, this is a genuine 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 a different problem, and Microsoft Graph doesn't currently solve it.

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: read employee data from the directory, then apply a signature to the mailbox. The move to Microsoft Graph changes the first job and leaves the second one stranded.

The directory 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's finite work: update the queries, test, redeploy.

The applying job is where a script actually runs out of road. 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. Because Microsoft Graph has no signature endpoint, nothing replaces it. The one native option that survives, Set-MailboxMessageConfiguration, still sets an Outlook on the web signature, but its SignatureHTML parameter stops applying once Outlook roaming signatures are turned on, now the default in many cloud tenants.

That upkeep is already costly before any of these changes land. 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.

Can you still manage Microsoft 365 email signatures with PowerShell?

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

Set-MailboxMessageConfiguration sets the Outlook on the web 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 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 a consistent, on-brand email signature that renders the same everywhere and updates itself from the directory. Exclaimer's State of Business Email 2025 report found 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.

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

A managed platform changes where that work lands. Rather than a script that reads the directory and writes 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 involved. When Microsoft retires a module or an API, absorbing that change becomes the vendor's job instead of 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.

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, and every platform change narrows where those places are.

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 every 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 whether your team keeps maintaining the scripts or hands the problem to something built to absorb these changes for you.