Category: Office 365

At the beginning, we have to create a docx file. This is a normal file, containing a signature design as you want to appear and all variables from the script that you want to change (look at the end of the post for more information). This file has also to be saved on a share, where all the effected users have a read permission.
The script is written to create an Outlook signature and it is working if you have installed MS Word 2013 and MS Outlook 2013. It has been developed from a basic script on the Technet, but with additional checks and conditions as variables:

• $SignatureVer – A version of signature – Change it when you have to deploy a new signature;
• $UseSignOnNew – Use this signature when you send a new mail;
• $UseSignOnReply – Use this signature when you send a mail as reply;
• $ForceSignatureNew – Force this signature on a new mail. The user will not be able to change it (it will also force it on reply);
• $ForceSignatureReply – Force signature on reply to mails.

Be careful because using forcing signature, will create registry values. Cancelling these settings means that you have to delete manually the registry values.

Two new registry values used by the script are introduced:

• In the Path HKCU:’\Software\Microsoft\Office\15.0\Common\MailSettings, in the value VersionSignature, it is written a current version of the installed signature.
• In the Path HKCU:’\Software\Microsoft\Office\15.0\Common\MailSettings, in the value ADChangeDate, it is written the date when the signature was applied.

We need both values to determinate if the company changed the version of signature and the new one has to be deployed in addition if something changed in AD user object, since the last deployment of the signature. If the AD user was changed, the user can choose if deploying the changes or not (reason / example: AD User will also change if the user changes the password and we do not deploy the new signature).
The script should be run as a logon script and it is divided into two blocks:

1. The purpose of the first block is to determinate if the signature has to be deployed to user. Here we can see if the user already has a signature deployed and if something has changed from the last deployment. This block query AD User object and compare data from AD with local data.
2. The second block effectually deploys the signature and for the optimization of the speed and load it run only when the script has to be deployed. It copies the docx template to local machine, changes the variables with real data and generates the signature in Outlook. To do this, the Outlook will be closed if it is open. At the end, the script writes the two registry values and delete the signature template from the local machine.

The script does not delete or effect in any other way none of the signatures that are present in Outlook. The only effect will be that, if you select, it will change the default signature on new and / or reply mails. Of course all data of the AD User object can be retrieved; you just need to found a field name in AD and associate it with variable in the script. It is pretty easy.

In my script, there are some variables that have to be present in a docx template:

• DisplayName – Will be changed to Display value from AD
• E-Mail – Will be changed to E-Mail value form AD
• Title – Will be changed to Title value from AD
• AllAddress – Will be changed to complete address from AD (street, city, CAP)
• MobileN – Will be changed to Mobile number value from AD
• WorkingOffice – Will be changed to Office value from AD

Of course is up to you to change these values to any other value as you wish, but be careful that values defined in script, are presented the Word template document. Only in this case the script will be able to change them.

You can download script here: Mail_Sign script.