Moving on From Outlook Signatures and the System Registry
With Microsoft’s intention to support cloud signatures for Outlook desktop (for Windows), I’ve been working through the challenges of generating and maintaining corporate email signatures for Office 365 users. Previously, I discussed what needs to be done to update the system registry settings for Outlook signatures and explained why the current situation works well for individual users but is a real pain for central management. Today, I want to turn my attention to OWA.
OWA and Outlook Have Different Signatures
It seems weird that after nine years of Office 365, OWA and Outlook desktop still use different signatures. It’s a pain for many reasons, including duplication of administrator effort to maintain signatures.
This situation might change (at least, I hope so) if Microsoft’s new cloud signatures for Outlook pick up some of the framework that exists to allow administrators update OWA signatures centrally. One thing that won’t go away is the absolute necessity of accurate directory information. If the directory doesn’t hold good data about users, it’s going to be much harder to generate good-looking (and useful) signatures.
The Set-MailboxMessageConfiguration Cmdlet and Signatures
OWA stores its signature information as mailbox settings. Two signatures can be defined: plain text and HTML and mailbox settings determine which is used for new messages and replies/forwards.
The Set-MailboxMessageConfiguration cmdlet is the core component in OWA signature management. Its important parameters are:
- SignatureHTML:. This signature is used for HTML messages.
- SignatureText: This signature is used for plain-text messages.
- AutoAddSignature: Controls if OWA applies signature to new messages.
- AutoAddSignatureOnReply: Controls if OWA applies signatures to replies and forwards.
You can ignore the SignatureTextOnMobile, UseDefaultSignatureOnMobile, and AutoAddSignatureOnMobile parameters. They only apply to the old OWA for Devices client and aren’t used by the Outlook Mobile client.
With these parameters in mind, a simple command to manage signatures for a mailbox is:
Set-MailboxMessageConfiguration -Identity James.Ryan -AutoAddSignature $True ` -AutoAddSignatureOnReply $False -SignatureText "From the desk of James Ryan" ` -SignatureHTML "<h2>From the desk of James Ryan</h2>"
Users pick up the amended signature the next time they refresh OWA.
Scripting Mailbox Signature Updates
We can reuse some of the code in the script to update Outlook signature settings in the system registry to serve the same function for an OWA signature. To generate and apply a individualized corporate signature to multiple mailboxes, we need to:
- Call Get-Mailbox to fetch the mailboxes. The call might fetch all mailboxes or use a filter to find mailboxes for a specific department, country, or location.
- Loop through each mailbox to retrieve information about its mailbox owner from the directory.
- Merge user properties with some HTML code (to add some formatting, insert icons, and so on) to build the signature, Once again I am indebted to Code Two’s Free email signature generator for help in figuring out some of the HTML. It’s a lot easier to amend HTML that you know works than to compose it from scratch.
- Optional code might add text to the signature based on mailbox properties, such as language-specific text for a country.
- Call Set-MailboxMessageConfiguration to update the mailbox with a command like this:
Set-MailboxMessageConfiguration -Identity $M.UserPrincipalName ` -SignatureHTML $SignatureHTML -AutoAddSignature $True ` -AutoAddSignatureOnReply $False
You can download a working script that illustrates the principals of how to go about centralized management for OWA signatures from the Office365ITPros GitHub repository.
To complete the solution, you could schedule a monthly run of the script to process mailboxes and update signatures. Perhaps every month the script could be updated to allow corporate PR to insert a new cheery catchphrase (or graphic about the latest corporate initiative) into signatures. Or maybe that’s a bad idea.
Another idea is for the script to create a report of missing directory properties and email the report to administrators when the script finishes to help improve the quality of the information in the directory.
Blocking User Edits to Signatures
Users can edit the signature created for their mailbox through OWA options. However, if you make the signature attractive enough, they’ll probably leave it alone. There’s no out-of-the-box method for administrators to block the option to update signatures, but you could try doing this with a user role assignment policy to remove user access to the Set-MailboxMessageConfiguration cmdlet.
What Microsoft Might Do with Cloud Signatures
OWA signatures prove the value of holding user signature information in the cloud. It’s so much simpler when administrators can run a PowerShell script to update signatures across an Office 365 tenant on a periodic basis. This doesn’t mean that the ISV market for autosignature products will go away because those products include a heap of functionality that I haven’t touched upon here. And those products are engineered by people who think about nothing but how to manage email signatures.
However, for those who would like to write and maintain their own signature generation code, it would be nice if Microsoft builds on what exists for OWA to have Outlook use the same signature information held in user mailboxes. And it would be even better if Outlook Mobile joined the party too. That might be too much to ask in the first round.
Worried that you can’t quite get your head around using PowerShell to manage Office 365? Subscribe to the Office 365 for IT Pros eBook and learn from the hundreds of examples in the book.