Building Active Directory Based Outlook Signatures

One thing that many companies strive for is a consistent brand identity. There is many reasons for wanting this is anything just to appear to be a professional, unified front your customers. With email being one of the most prevalent communication forms in industry today, one of the best ways to achieve this brand identity.

Active Directory Directory Services, being the centralised gatekeeper of corporate information in a Microsoft environment, the service which feeds Exchange, SharePoint, Lync and many other services with user identity data is the ideal place to get the information needed to generate these signatures.

The key to making this work however is the dynamic automation. Any company can have their Marketing or HR department send a mail shot to the entire company asking the users to update their own signatures in Outlook, but there is always room for ‘creativity’ with this scenario; users trying to make small or subtle changes to the intended design affecting the corporate image.

Luckily, Outlook, or more specifically Word as a good Visual Basic for Applications (VBA) interface for programmatically generating documents and Active Directory Directory Services is one of the most easily and commonly accessed systems via VBScript.

The following script, broken down into chunks explained to allow you to make the script work for your own needs does exactly this.

Option Explicit
On Error Resume Next

Dim objSysInfo, strUser, objUser, strName, strJobTitle, strDepartment, _
    strCompany, strExtension, strPhoneLocal, strPhoneIntl, strMobileLocal, _
    strMobileIntl, strEmail, strCountry, strWebAddress, strPhonePrefix, _
    objWord, objDoc, objSelection, objEmailOptions, objSignatureEntries, _

The opening section quite simply tells the Windows Script Host to only accept variables which are defined (Option Explicit). Many people omit this option from scripts for simplicity of coding, however I think that it’s lazy. Defining your variables with a Dim statement means you know that no rogue variables exist and it helps to prevent typos down the line.

The next line (On Error Resume Next) tells Script Host to continue running the script even if an error occurs. This is needed to prevent the script from generating popup alerts on client computers were the script is running, potentially confusing users. So long as you thoroughly test the script before deploying it, you can be safe in the knowledge that errors won’t happen, but better safe than sorry.

Set objSysInfo = CreateObject("ADSystemInfo")

strUser = objSysInfo.UserName
Set objUser = GetObject("LDAP://" & strUser)

Here the connection to Active Directory Directory Services is made The connection is made in the context of the logged on user and is then placed into a variable.

If Err.Number <> 0 Then
End If

This section is vitally important in environments with laptop users. If a connection to the domain is not available and this section isn’t included then the script will continue to run, and the user will end up with a very nasty looking signature. If a domain connection cannot be established at this point then the script will exit before anything is modified in the signature, so any exiting signature will continue to take effect.

strName = objUser.fullName
strJobTitle = objUser.title
strDepartment = objUser.department
strCompany =
strExtension = objUser.telephoneNumber
strPhoneLocal = objUser.otherTelephone
strMobileLocal =
strEmail = objUser.mail
strCountry =

This section maps the user object attributes to the script variables. Depending on how you use the various attributes in Active Directory, you may need to tweak this, or if you want to pull more information such as building or office address. The format for each attribute is objUser.attributeName. Using a tool such as ADSI Edit will allow you to view all of the attributes in the schema for the user object and their LDAP names.

Select Case strCountry
Case "United Kingdom"
    strWebAddress = ""
    strPhonePrefix = "+44 "
Case "Ireland"
    strWebAddress = ""
    strPhonePrefix = "+353 "
Case Else
    strWebAddress = ""
    strPhonePrefix = ""
End Select

For some people, this section might not be needed so you could instead simply define the strWebAddress and strPhonePrefix variables. My test lab environment emulates a multi-national company and as such you want each users’ signature to reflect their region. The Case statements evaluate the value in the Country attribute in Active Directory and based on it set the country dialling code and the regionalised web address. Make sure you define a Case Else statement to catch any users who don’t have a Country defined.

If strPhoneLocal = "" Then
    If Left(strPhoneLocal, 1) = "+" Then
        strPhoneIntl = strPhoneLocal
        strPhoneIntl = strPhonePrefix + Right(strPhoneLocal, Len(strPhoneLocal)-1)
    End If
End If

If strMobileLocal = "" Then
    If Left(strMobileLocal, 1) = "+" Then
        strMobileIntl = strMobileLocal
        strMobileIntl = strPhonePrefix + Right(strMobileLocal, Len(strMobileLocal)-1)
    End If
End If

Here, the phone numbers retrieved from Active Directory are evaluated and if needed converted to international dialling format. The statements take the first character from the direct dial and mobile phone numbers and if it begins with a plus symbol then no conversion is done and the number is taken literally. If the first character is not a plus symbol, then the first number is removed and replaced with the country dialling code determined in the previous code block.

Set objWord = CreateObject("Word.Application")

Set objDoc = objWord.Documents.Add()
Set objSelection = objWord.Selection

Set objEmailOptions = objWord.EmailOptions
Set objSignatureObject = objEmailOptions.EmailSignature

Set objSignatureEntries = objSignatureObject.EmailSignatureEntries

Const wdParagraph = 4
Const wdExtend = 1
Const wdCollapseEnd = 0

objSelection.Font.Color = RGB(0,133,200)
objSelection.Font.Bold = True
objSelection.TypeText strName
objSelection.TypeText Chr(11)

objSelection.Font.Color = RGB(128,128,128)
objSelection.Font.Size = 10
objSelection.Font.Bold = False
objSelection.TypeText strJobTitle & ", " & strDepartment
objSelection.TypeText Chr(11)
objSelection.TypeText strCompany

objSelection.TypeText "Internal: " & strExtension

If strPhoneIntl = "" Then
    objSelection.TypeText " | " & "External: " & strPhoneIntl
End If

If strMobileIntl = "" Then
    objSelection.TypeText " | " & "Mobile: " & strMobileIntl
End If

objSelection.TypeText Chr(11)

objSelection.TypeText "Email: "
objDoc.Hyperlinks.Add objSelection.Range, "mailto:" & strEmail,,,strEmail
objSelection.TypeText " | " & "Web: "
objDoc.Hyperlinks.Add objSelection.Range, strWebAddress,,,strWebAddress

Here is the visual bit. The signature is built using a Word application. The script runs through the creation of the signature line by line. The phone number section is dynamic. If when the user information was retrieved from Active Directory one or more of the phone number fields were empty, then the label for that number type and also the number are omitted from the block.

Colours are all defined using RGB values. If you want to change these for your own use, simply use Word to find the colour you need, then select the Custom tab to view the RGB codes for it.

objSelection.StartOf wdParagraph, wdExtend
objSelection.Font.Color = RGB(128,128,128)
objSelection.Font.Size = 10
objSelection.Collapse wdCollapseEnd

Set objSelection = objDoc.Range()

The final and perhaps complicated thing going on here is the hyperlink generation. By default, the hyperlinks will adopt the default hyperlink style of blue text, size 11 font with an underline. Changes to this section should be heavily tested because at this point, Word begins moving the pointer caret through the document to select the hyperlinks which have been created to alter their style. Incorrectly placing the caret can result it items deleted or strangely laid out in the finished signature.

objSignatureEntries.Add "Test Corp Default", objSelection
objSignatureObject.NewMessageSignature = "Test Corp Default"
objSignatureObject.ReplyMessageSignature = "Test Corp Default"

objDoc.Saved = True

Last but not least, everything that has been done so far is saved into the document and configured in the default Outlook profile as the signature to be used for new messages and also reply messages.

If you wanted no signature to be added to replies then you could change the following line:

objSignatureObject.ReplyMessageSignature = ""

It would actually be possible to define a different signature for the reply messages if you so wished. To do this, you would need to save the new message signature and close the current Word object, then open a new Word object, define the signature and then save it to the reply message signature.


Richard works as a Cloud Consultant for Fordway Solution where his primary focus is to help customers understand, adopt and develop with Microsoft Azure, Office 365 and System Center. Richard Green is an IT Pro with over 15 years' of experience in all things Microsoft including System Center and Office 365. He has previously worked as a System Center consultant and as an internal solutions architect across many verticals. Outside of work, he loves motorbikes and is part of the orange army, marshaling for NGRRC, British Superbikes and MotoGP. He is also an Assistant Cub Scout Leader.

3 thoughts on “Building Active Directory Based Outlook Signatures

  1. Pingback: Richard J Green
  2. I have a follow-up question. Do you know a way to automate the running of this script? I’d like to have it run each time a user opens Outlook, to reset their default signature. I considered adding it to the login script, however Outlook must be running for the script to run, and that has not happened yet during the login process.

    1. Darrin,

      The way I have implemented the script, it only runs at logon for the user, however it does run at each and every logon to the signature block is reset each logon. If you wanted it to run every time Outlook is restarted, you probably have two options. 1) Write it as an Outlook Addin which then can integrate into the code of Outlook at startup. 2) Replace all your Outlook desktop shortcuts with a .bat, .vbs or .ps1 file which first runs the script, and then fires Outlook.exe. The latter is a really dirty method but would be simplest to implement.


Comments are closed.