'Login script using EmailSignature.NewMessageSignature property does not populate in Outlook

I have been experimenting with this object.property in a logon script and have the following snippit of code. It does not seem to populate in Outlook in the default signatures. Has anyone had any luck with this? I am using MS Office 2016

    ...
    SigFilename = "CompanyDefault.htm"
    ...
    'Applying the signature in Outlook’s settings.
    Set objWord = CreateObject("Word.Application")
    Set objSignatureObjects = objWord.EmailOptions.EmailSignature
    
    'Setting the signature as default for new messages.
    objSignatureObjects.NewMessageSignature = SigFilename
    
    'Setting the signature as default for replies & forwards.
    objSignatureObjects.ReplyMessageSignature = SigFilename
    objWord.Quit
outlookvbscript


Solution 1:[1]

Firstly, NewMessageSignature and ReplyMessageSignature take the name of the signature (e.g. "CompanyDefault"), not the file name ("CompanyDefault.htm").

If you want to manipulate Outlook signatures directly, you can do so using Redemption (I am its author) - it exposes the RDOSession.Signatures collection (returns RDOSignatures object), as well as RDOAccount.ReplySignature and NewMessageSignature properties (retuirn and take RDOSignature object).

Solution 2:[2]

Make sure that you assigned a logon script to a local user account.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.

I'd suggest making sure the code works correctly when it is run manually. If not, try to run the code under the debugger to find out what is wrong and where it fails. At least you can add logging statements.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 Eugene Astafiev

Related Questions