Outlook Roaming Signatures

Support for Roaming Signatures is found in DS-Manager 6.8.0

In November 2022 Microsoft started in earnest rolling out the long-awaited feature called Roaming Signatures.

When you enable Outlook to store your settings in the cloud, settings for your Microsoft 365 account will automatically roam across all your devices that use Outlook for Windows.

When this feature is enabled it fundamentally changes the way signatures are store locally on the PC.

There is now a new file naming scheme in place. Previously signatures were store using only the signature name, but now they also include the email account that are attached to a signature. Like seen here on the below picture (from %appdata%\Microsoft\Signatures)

With this new naming scheme there is segregation between signatures if you have multiple account configured in Outlook.

When selecting an account in the settings dialog, it is no longer possible to see/assign signatures that are not directly generated for this account. Previously all signatures could be used for all accounts.

DynamicSignature now has new mechanisms to handle this. (DSM 6.8.0+)

1. If Outlook only has one account set up DS will make all generated signatures belong to this account.

2. If Outlook has more than 1 account it will scan the generated signature content for email addresses, and match those to the accounts Outlook has configured, and make an automatic mapping. So, you are advised to always include the users email in you template design. Please also note it will use the FIRST occurrence of email address found. So, please ensure that addresses to be used for mapping is above other addresses. If it finds NO address in a signature it will map it to the first mailbox configured in Outlook, which will in all likelyhood be the principal account.

Common mailboxes

This offers up an opportunity also, if you are deploying multiple signatures to users that also use a shared mailbox.

E.g., you want to deploy a signature to users of the sales team. A generic signature. You then include the email address of this shared mailbox "sales@comany.com" in the template design. When it is deployed, it will automatically be assigned to that mailbox.

Remember you can use the name override in a call: /U:salesteamUK to send a signature of another user then the actual logged on user.

A calling script could look like so:

Set objShell = CreateObject("WScript.Shell")

objShell.Run "\\company.local\NETLOGON\DynamicSignature\DSClient\DynamicSignature.exe /I:Adoc.ini" ,,True

objShell.Run "\\company.local\NETLOGON\DynamicSignature\DSClient\DynamicSignature.exe /I:Sales.ini /U:SalesTeamUK" ,,True

The first command makes a signature for the logged-on user, and the second line makes a signature for the sales shared mailbox.

But you could of course just make a template that is purely hardcoded and does not pull any data from AD. This may be the easiest approach. Then you don't need a user override in the call either.