eMailSignature Outlook Web module

Compliant email signatures on Outlook Web clients

Compliance and Consistency of email signatures impacts your brand. eMailSignature's goal is to ensure that the signature portion of corporate email meets your branding standards - no matter where an email is sent from.

With eMailSignatures Outlook Web module, the same signature that appears in Outlook can now appear on emails sent remotely through Outlook Web. No longer will your client know if an email is sent from home or from the office. No longer will you have different signatures based on where the email is sent from. eMailSignature provides a professional look and feel that enhances your brand and delivers targeted marketing messages with each an every email.

About this guide

This guide describes how to set up eMailSignature to work with Microsoft Outlook Web (OWA) for Microsoft Exchange Server.

This guide is intended for Exchange administrators.

Requirements

eMailSignature works with all Outlook versions and with OWA for Exchange 2003, 2007, 2010 and 2013. The installation for OWA is not a stand-alone application. It only works in conjunction with eMailSignature.

Note: A fully functioning installation of eMailSignature must be up and running before it can deploy signatures to OWA.

Prerequisites for installing eMailSignature for OWA

  • Installed eMailSignature.
  • A running sign.exe that deploys signatures to Outlook.

No files need to be installed on the actual Exchange Server in order for eMailSignature for OWA to run. eMailSignature for OWA should be installed on a different server with the right setup and credentials to access the Exchange server.

eMailSignature for OWA will only work if you have a valid license key entered. For information on managing licenses, see the Administering eMailSignature Guide.

You must have the correct security permissions set and full access to the eMailSignature settings database. You gain access to the settings database via the same connection string as when you deployed eMailSignature:

  1. Open eMailSignature > Configuration, Database.
  2. Copy connection string.

eMailSignature for OWA uses Exchange Web Services (EWS) to connect to Exchange 2010 and Web-based Distributed Authoring and Versioning protocol (WebDAV) to connect to Exchange 2003 or 2007. It is essential to have basic knowledge of your Exchange environment and your security settings. In particular, you need to know the authentication method for OWA, and the way users connect to it. Please acquire this information prior to setting up eMailSignature for OWA.

Note: EWS must be enabled if using Exchange 2010 for all belonging web sites and all users. WebDAV must be enabled in Exchange 2003 and 2007 for all belonging web sites.

eMailSignature for OWA overview

You are already familiar with the eMailSignature setup and the backend database. The backend database contains the final signatures to be deployed to OWA. These signatures are updated each time sign.exe is run, as they are stored in the settings database. ~

In order to pull out the signatures from the backend database and deploy them to OWA environment, a signOWA.exe file is used. Unlike sign.exe, the signOWA.exe does not run each time the users log on. SignOWA.exe runs from a server in your network as a scheduled task. It can be any server within your network running a Windows Server 2000, 2003 or 2008 with the latest Service Pack applied. SignOWA.exe is then set up to run as a scheduled task that deploys signatures to OWA at a set time, e.g. once a day at 1 am.

Deploying email signature to OWA/Exchange Server

To set up eMailSignature to work with OWA, proceed as follows:

  1. Configure OWA in eMailSignature > Modules, Outlook Web.
  2. Install eMailSignature for OWA files on a server (other than the Exchange server) and create registry entries on the server where signOWA.exe will be running.
  3. Set up security permissions to access the Exchange server and fill in required information into the registry. The process is different depending on the authentication method used by your server.
  4. If using a single user to run signOWA.exe, set up account rights for this user.
  5. Test signatures on a few OWA users.
  6. Set up signOWA.exe as a scheduled task and then deploy.

Each of the steps is described in the following sections.

Configuring OWA/Exchange Server 2010/2013 in eMailSignature

In order to administer the OWA settings, first you must enable the OWA module. If you have entered a valid license for the OWA module, the module will be enabled. If the OWA module is not enabled, please obtain a valid license key.

To configure the OWA module, proceed as follows:

  1. eMailSignature > Modules, Configuration:

    The Basic Configuration window appears. The first time you open the Configuration window it will show dummy sample settings. These must be changed in order for OWA deployment to work.

  2. Select the Exchange Server version that you are running:
    • Exchange 2010.
  3. In the Authentication Method section select the method used on your server:
    • Integrated Windows Authentication for OWA
    • Forms Based Authentication for OWA

      Please consult your Exchange administrator to learn what method is used by your server.

      Note: Using Windows Authentication for the "exchange site" is the recommended practice for signOWA.
  4. Check the Secure Socket Layer (https) option if you are using HTTPS to connect to OWA.
  5. Enter the URL of your Exchange OWA server in the OWA URL field. Leave out HTTP and HTTPS before the URL.

    If you are using Exchange 2010, do not append anything as in the following example: "myserver.mydomain.local". (E.g. do NOT add /owa or /exchange)

    Security Warning: We recommend to write the internal address of the OWA server to avoid any possible security issues.
  6. Click Save to keep these settings, and then click Close to exit the Basic Configuration window.

You are now ready to continue with installing OWA files.

Installing OWA files

Now that you have set up your OWA information in eMailSignature, you must install OWA files on a server (other than the Exchange server), where you want to run the job as a scheduled task.

Create a folder on the server and extract these three files into that folder.

Double-click the signOWA.reg file and accept to add the registry entries to the registry.

Note: You must have write access to the HKEY_LOCAL_MACHINE hive of the registry.

SignOWA.reg will add to the registry entries that will contain the username and password which signOWA.exe will use to authenticate. This information can be encrypted.

Note: SignOWA.exe will not be able to function without these registry entries.

Entries for proxy values are also added to the registry. Normally these are left blank and should not be modified. They are only needed in very rare cases.

Setting up security for Exchange Server

SignOWA supports different authentication schemes depending on the setup of the Exchange server:

  • Basic Authentication.
  • Integrated Windows Authentication.
  • Forms Based Authentication.

The following registry values are used to control how signOWA authenticates with the Exchange server:

Registry key Value
OWAuid The user name that is to be used when connecting to the Exchange server. If left blank the credentials of the logged in user will be used. Do not include the domain in the user name.
OWApwd The password for the user specified in OWAuid. If OWAuid is left blank, the OWApwd value is ignored.
OWAdomain The domain of the user specified in OWAuid. If OWAuid is left blank, the OWAdomain value is ignored.

Once SignOWA.reg successfully adds entries to the registry, start regedit.exe to change these registry settings.

The following sections will describe the different registry settings to use for each authentication scheme.

Basic Authentication

When using basic authentication and running signOWA as a scheduled task the recommended approach is to use the "run as" feature. SignOWA will run in the context of the provided user when connecting to the Exchange server. In this case, OWAuid must be left blank.

When using basic authentication the password is sent in clear text to the server.

Security Warning: Never use basic authentication without SSL.

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server (when not using "run as").
OWApwd The password for the user specified in OWAuid (when not using "run as").
OWAdomain The domain of the user specified in OWAuid (when not using "run as").

Integrated Windows Authentication

When using integrated Windows authentication and running signOWA as a scheduled task the recommended approach is to use the "run as" feature. SignOWA will run in the context of the provided user when connecting to the Exchange server. In this case, OWAuid must be left blank.

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server (when not using "run as").
OWApwd The password for the user specified in OWAuid (when not using "run as").
OWAdomain The domain of the user specified in OWAuid (when not using "run as").

Forms Based Authentication

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server.
OWApwd The password for the user specified in OWAuid.
OWAdomain The domain of the user specified in OWAuid.
Security Warning: Never use forms based authentication without SSL.
Note: Exchange 2010 uses different authentication schemes for OWA and for EWS that is used by signOWA. This means that you can use Windows or Basic Authentication for signOWA even though you are using Forms Based Authentication for OWA users.

Using encryption for OWAuid and OWApwd values

When using the registry values OWAdomain, OWAuid, and OWApwd the user name and password of a user are visible to anyone who has access to registry on the machine running signOWA. Therefore, signOWA provides encryption of OWAuid and OWApwd. The encryption is done using the built-in Windows DPAPI.

Security Warning: Encrypting the user name and password gives an extra level of security. However, if a malicious person manages to execute code on the machine running signOWA, the encrypted credentials may still be decrypted.

To use encryption, run signOWA.exe from command prompt once with the following options:

signOWA.exe -encrypt -uid:theusername -pwd:thepassword

SignOWA encrypts "theusername" and "thepassword" and writes the encrypted values to OWAuid and OWApwd to the registry. Also, the registry value OWAuseencryption is added to the registry and set to "1".

Note: The encryption is machine dependent. The encrypted registry values cannot be copied to another machine.
Note: Do not manually change the value of OWAuseencryption.

Setting account rights for the account running signOWA.exe

As described above, either signOWA runs in the security context of the user running signOWA, or it uses the credentials of a single user provided in the registry when connecting to Exchange server.

To run signOWA.exe through just one user, create a new account in the Active Directory (including a mail box). This will be the account used for OWAuid as previously described, i.e. the account in which context you wish to run signOWA.exe.

It is recommended to create a domain user with very limited rights for the single purpose of running signOWA.exe. Specifically, the user should not be part of the Administrators group. The user must have the following rights:

  • The user must have some extended rights on the Exchange mail store in order to be able to set the signature for all other domain users. These settings vary between Exchange 2003 , 2007 and 2010.
  • The user must have read access to the HKLM hive of the registry on the machine running signOWA.exe.
  • The user must have read/write/update access to the table ldgaUsers in the settings database.
Note: When you run signOWA, all users who are registered in the settings database (i.e. the users you see in Diagnostics) will have their signatures updated in OWA.

Creating and setting up rights for a user for Exchange 2010/2013

The new account must have the "Receive as" extended rights on the mailbox store. To set these rights, proceed as follows:

  1. Start Exchange Management Shell.
  2. Run the following command in the Management Shell:

    Add-adpermission -Identity "Mailbox Database" -User "MyUserName" -ExtendedRights "Receive-As"

    Substitute "Mailbox Database" with the name of your mailbox store. This information can be found in the Exchange Management Console.

  3. Additionally, in the Management Shell run the cmdlet command for the newly created account in domain "DOMAIN" accountname "signOWA". For example:

    New-ManagementRoleAssignment -Name "impersonationAssignmentName" -Role "ApplicationImpersonation" -User "DOMAIN\signOWA"

  4. It may be necessary to restart the Microsoft Exchange Information Store service to propagate the changes.

Checking site authentication in Exchange 2010/2013

When OWA is installed, Exchange 2010/2013 installs a number of web sites. Two of these web sites are important in this context. The "exchange" web site is among other things used for programmatically accessing mailboxes using technologies such as EWS. The "OWA" web site is used for letting users access their own mailbox with the well-known OWA user interface. In Exchange 2003, the two web sites were grouped together in one web site. The split into two as of Exchange 2007 allows us to define different authentication settings for the two sites.

SignOWA uses the "exchange" web site. Thus, it works independently of the settings for the "OWA" site. This means we can set up Forms Based Authentication (FBA) for the users accessing the OWA interface while using Windows Authentication for signOWA.

To configure authentication for the "exchange" site, proceed as follows:

  1. Open the Exchange Management Console as shown in the following screen shot.

  2. Double-click the "Exchange (Default Web Site)" item to view the properties for the web site. Choose the Authentication tab in the Properties window.

  3. Change the authentication settings for the "exchange" web site as necessary. Click OK to save.
    Note: Using Windows Authentication for the "exchange" site is the recommended practice for when using eMailSignature for OWA.
  4. In order for the changes to take effect, the Internet Information Server (IIS) must be reset. To do this run the command "iisreset" from a command prompt or by choosing "Run" from the Windows Start menu and typing "iisreset".
    Note: Even though it is possible to configure authentication for the web site using the IIS management console, it is recommended to always use the Exchange Management Console as described above.

Troubleshooting Exchange 2010/2013

Error: "The response received from the service didn't contain valid XML." Resolution: You have probably noted a wrong server name if you are using a Exchange cluster.

Error: "The mailbox that was requested doesn't support the specified RequestServerVersion." Resolution: Please make sure that you have given the appropriate permissions to each of the Exchange mailboxes containing the users you want to deploy the signatures for.

Configuring OWA/Exchange Server 2007 in eMailSignature

In order to administer the OWA settings, first you must enable the OWA module. If you have entered a valid license for the OWA module, the module will be enabled in eMailSignature. If the OWA module is not enabled, please obtain a valid license key. To configure the OWA module, proceed as follows:

  1. Double-click the eMailSignature icon on the desktop, and open the Modules tab. Then click Configuration button for Outlook Web Access.

    The eMailSignature for Outlook Web Access - Basic Configuration window appears. The first time you open the Configuration window it will show dummy sample settings. These must be changed in order for OWA deployment to work.

  2. Select the Exchange Server version that you are running:
    • Exchange 2007
  3. In the Authentication Method section select the method used on your server:
    • Integrated Windows Authentication for OWA
    • Forms Based Authentication for OWA

      Please consult your Exchange administrator to learn what method is used by your server.

      Note: Using Windows Authentication for the "exchange site" is the recommended practice for signOWA.
  4. Check the Secure Socket Layer (https) option if you are using HTTPS to connect to OWA.
  5. Enter the URL of your Exchange OWA server in the OWA URL field. Leave out HTTP and HTTPS before the URL.
    If you are using Exchange 2007, do not append anything as in the following example: "myserver.mydomain.local". (E.g. do NOT add /owa or /exchange)
    Security Warning: We recommend to write the internal address of the OWA server to avoid any possible security issues.
  6. Click Save to keep these settings, and then click Close to exit the Basic Configuration window.

You are now ready to continue with installing OWA files.

Installing OWA files

Now that you have set up your OWA information in eMailSignature, you must install OWA files on a server (other than the Exchange server), where you want to run the job as a scheduled task.

Create a folder on the server and extract these three files into that folder.

Double-click the signOWA.reg file and accept to add the registry entries to the registry.

Note: You must have write access to the HKEY_LOCAL_MACHINE hive of the registry.

SignOWA.reg will add to the registry entries that will contain the username and password which signOWA.exe will use to authenticate. This information can be encrypted.

Note: SignOWA.exe will not be able to function without these registry entries.

Entries for proxy values are also added to the registry. Normally these are left blank and should not be modified. They are only needed in very rare cases.

Setting up security for Exchange Server

SignOWA supports different authentication schemes depending on the setup of the Exchange server:

  • Basic Authentication.
  • Integrated Windows Authentication.
  • Forms Based Authentication.

The following registry values are used to control how signOWA authenticates with the Exchange server:

Registry key Value
OWAuid The user name that is to be used when connecting to the Exchange server. If left blank the credentials of the logged in user will be used. Do not include the domain in the user name.
OWApwd The password for the user specified in OWAuid. If OWAuid is left blank, the OWApwd value is ignored.
OWAdomain The domain of the user specified in OWAuid. If OWAuid is left blank, the OWAdomain value is ignored.

Once SignOWA.reg successfully adds entries to the registry, start regedit.exe to change these registry settings.

The following sections will describe the different registry settings to use for each authentication scheme.

Basic Authentication

When using basic authentication and running signOWA as a scheduled task the recommended approach is to use the "run as" feature. SignOWA will run in the context of the provided user when connecting to the Exchange server. In this case, OWAuid must be left blank.

When using basic authentication the password is sent in clear text to the server.

Security Warning: Never use basic authentication without SSL.

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server (when not using "run as").
OWApwd The password for the user specified in OWAuid (when not using "run as").
OWAdomain The domain of the user specified in OWAuid (when not using "run as").

Integrated Windows Authentication

When using integrated Windows authentication and running signOWA as a scheduled task the recommended approach is to use the "run as" feature. SignOWA will run in the context of the provided user when connecting to the Exchange server. In this case, OWAuid must be left blank.

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server (when not using "run as").
OWApwd The password for the user specified in OWAuid (when not using "run as").
OWAdomain The domain of the user specified in OWAuid (when not using "run as").

Forms Based Authentication

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server.
OWApwd The password for the user specified in OWAuid.
OWAdomain The domain of the user specified in OWAuid.
Security Warning: Never use forms based authentication without SSL.
Note: Exchange 2007 uses different authentication schemes for OWA and for WebDAV that is used by signOWA. This means that you can use Windows or Basic Authentication for signOWA even though you are using Forms Based Authentication for OWA users.

Using encryption for OWAuid and OWApwd values

When using the registry values OWAdomain, OWAuid, and OWApwd the user name and password of a user are visible to anyone who has access to registry on the machine running signOWA. Therefore, signOWA provides encryption of OWAuid and OWApwd. The encryption is done using the built-in Windows DPAPI.

Security Warning: Encrypting the user name and password gives an extra level of security. However, if a malicious person manages to execute code on the machine running signOWA, the encrypted credentials may still be decrypted.

To use encryption, run signOWA.exe from command prompt once with the following options:

signOWA.exe -encrypt -uid:theusername -pwd:thepassword

SignOWA encrypts "theusername" and "thepassword" and writes the encrypted values to OWAuid and OWApwd to the registry. Also, the registry value OWAuseencryption is added to the registry and set to "1".

Note: The encryption is machine dependent. The encrypted registry values cannot be copied to another machine.
Note: Do not manually change the value of OWAuseencryption.

Setting account rights for the account running signOWA.exe

As described above, either signOWA runs in the security context of the user running signOWA, or it uses the credentials of a single user provided in the registry when connecting to Exchange server.

To run signOWA.exe through just one user, create a new account in the Active Directory (including a mail box). This will be the account used for OWAuid as previously described, i.e. the account in which context you wish to run signOWA.exe.

It is recommended to create a domain user with very limited rights for the single purpose of running signOWA.exe. Specifically, the user should not be part of the Administrators group. The user must have the following rights:

  • The user must have some extended rights on the Exchange mail store in order to be able to set the signature for all other domain users. These settings vary between Exchange 2003, 2007 and 2010.
  • The user must have read access to the HKLM hive of the registry on the machine running signOWA.exe.
  • The user must have read/write/update access to the table ldgaUsers in the settings database.
Note: When you run signOWA, all users who are registered in the settings database (i.e. the users you see in Diagnostics) will have their signatures updated in OWA.

Creating and setting up rights for a user for Exchange 2007

The new account must have the "Receive as" extended rights on the mailbox store. To set these rights, proceed as follows:

  1. Start Exchange Management Shell.
  2. Run the following command in the Management Shell:

    Add-adpermission -Identity "Mailbox Database" -User "MyUserName" -ExtendedRights "Receive-As"

    Substitute "Mailbox Database" with the name of your mailbox store. This information can be found in the Exchange Management Console.

  3. It may be necessary to restart the Microsoft Exchange Information Store service to propagate the changes.

Checking site authentication in Exchange 2007

When OWA is installed, Exchange 2007 installs a number of web sites. Two of these web sites are important in this context. The "exchange" web site is among other things used for programmatically accessing mailboxes using technologies such as WebDAV. The "OWA" web site is used for letting users access their own mailbox with the well-known OWA user interface. In Exchange 2003, the two web sites were grouped together in one web site. The split into two as of Exchange 2007 allows us to define different authentication settings for the two sites.

SignOWA uses the "exchange" web site. Thus, it works independently of the settings for the "OWA" site. This means we can set up Forms Based Authentication (FBA) for the users accessing the OWA interface while using Windows Authentication for signOWA.

To configure authentication for the "exchange" site, proceed as follows:

  1. Open the Exchange Management Console as shown in the following screen shot.

  2. Double-click the "Exchange (Default Web Site)" item to view the properties for the web site. Choose the Authentication tab in the Properties window.

  3. Change the authentication settings for the "exchange" web site as necessary. Click OK to save.
    Note: Using Windows Authentication for the "exchange" site is the recommended practice for when using eMailSignature for OWA.
  4. In order for the changes to take effect, the Internet Information Server (IIS) must be reset. To do this run the command "iisreset" from a command prompt or by choosing "Run" from the Windows Start menu and typing "iisreset".
    Note: Even though it is possible to configure authentication for the web site using the IIS management console, it is recommended to always use the Exchange Management Console as described above.

Configuring OWA/Exchange Server 2003 in eMailSignature

In order to administer the OWA settings, first you must enable the OWA module. If you have entered a valid license for the OWA module, the module will be enabled in eMailSignature. If the OWA module is not enabled, please obtain a valid license key.

To configure the OWA module, proceed as follows:

  1. Double-click the eMailSignature icon on the desktop, and open the Modules tab. Then click Configuration button for Outlook Web Access.

    The eMailSignature for Outlook Web Access - Basic Configuration window appears. The first time you open the Configuration window it will show dummy sample settings. These must be changed in order for OWA deployment to work.

  2. Select the Exchange Server version that you are running:
    • Exchange 2003
  3. In the Authentication Method section select the method used on your server:
    • Integrated Windows Authentication for OWA
    • Forms Based Authentication for OWA

      Please consult your Exchange administrator to learn what method is used by your server.

      Note: Using Windows Authentication for the "exchange site" is the recommended practice for signOWA.
  4. Check the Secure Socket Layer (https) option if you are using HTTPS to connect to OWA.
  5. Enter the URL of your Exchange OWA server in the OWA URL field. Leave out HTTP and HTTPS before the URL.

    If you are using Exchange 2003, append "exchange" to the URL as in the following example: "myserver.mydomain.local/exchange/".

    Security Warning: We recommend to write the internal address of the OWA server to avoid any possible security issues.
  6. Check the option Remove Image tags from HTML signatures if you experience duplicate signatures in OWA for Exchange 2003. This is a known bug, which sometimes can display two identical signatures when using the signature. This is only related to Exchange 2003 and means that all images need to be removed. Leave this option unchecked if your signatures look normal and are functioning well.
  7. Click Save to keep these settings, and then click Close to exit the Basic Configuration window.

You are now ready to continue with installing OWA files.

Installing OWA files

Now that you have set up your OWA information in eMailSignature, you must install OWA files on a server (other than the Exchange server), where you want to run the job as a scheduled task.

Create a folder on the server and extract these three files into that folder.

Double-click the signOWA.reg file and accept to add the registry entries to the registry.

Note: You must have write access to the HKEY_LOCAL_MACHINE hive of the registry.

SignOWA.reg will add to the registry entries that will contain the username and password which signOWA.exe will use to authenticate. This information can be encrypted.

Note: SignOWA.exe will not be able to function without these registry entries.

Entries for proxy values are also added to the registry. Normally these are left blank and should not be modified. They are only needed in very rare cases.

Setting up security for Exchange Server

SignOWA supports different authentication schemes depending on the setup of the Exchange server:

  • Basic Authentication.
  • Integrated Windows Authentication.
  • Forms Based Authentication.

The following registry values are used to control how signOWA authenticates with the Exchange server:

Registry key Value
OWAuid The user name that is to be used when connecting to the Exchange server. If left blank the credentials of the logged in user will be used. Do not include the domain in the user name.
OWApwd The password for the user specified in OWAuid. If OWAuid is left blank, the OWApwd value is ignored.
OWAdomain The domain of the user specified in OWAuid. If OWAuid is left blank, the OWAdomain value is ignored.

Once SignOWA.reg successfully adds entries to the registry, start regedit.exe to change these registry settings.

The following sections will describe the different registry settings to use for each authentication scheme.

Basic Authentication

When using basic authentication and running signOWA as a scheduled task the recommended approach is to use the "run as" feature. SignOWA will run in the context of the provided user when connecting to the Exchange server. In this case, OWAuid must be left blank.

When using basic authentication the password is sent in clear text to the server.

Security Warning: Never use basic authentication without SSL.

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server (when not using "run as").
OWApwd The password for the user specified in OWAuid (when not using "run as").
OWAdomain The domain of the user specified in OWAuid (when not using "run as").

Integrated Windows Authentication

When using integrated Windows authentication and running signOWA as a scheduled task the recommended approach is to use the "run as" feature. SignOWA will run in the context of the provided user when connecting to the Exchange server. In this case, OWAuid must be left blank.

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server (when not using "run as").
OWApwd The password for the user specified in OWAuid (when not using "run as").
OWAdomain The domain of the user specified in OWAuid (when not using "run as").

Forms Based Authentication

The following registry values must be set:

Registry key Value
OWAuid The user name to be used when connecting to the Exchange server.
OWApwd The password for the user specified in OWAuid.
OWAdomain The domain of the user specified in OWAuid.
Security Warning: Never use forms based authentication without SSL.

Using encryption for OWAuid and OWApwd values

When using the registry values OWAdomain, OWAuid, and OWApwd the user name and password of a user are visible to anyone who has access to registry on the machine running signOWA. Therefore, signOWA provides encryption of OWAuid and OWApwd. The encryption is done using the built-in Windows DPAPI.

Security Warning: Encrypting the user name and password gives an extra level of security. However, if a malicious person manages to execute code on the machine running signOWA, the encrypted credentials may still be decrypted.

To use encryption, run signOWA.exe from command prompt once with the following options:

signOWA.exe -encrypt -uid:theusername -pwd:thepassword

SignOWA encrypts "theusername" and "thepassword" and writes the encrypted values to OWAuid and OWApwd to the registry. Also, the registry value OWAuseencryption is added to the registry and set to "1".

Note: The encryption is machine dependent. The encrypted registry values cannot be copied to another machine.
Note: Do not manually change the value of OWAuseencryption.

Setting account rights for the account running signOWA.exe

As described above, either signOWA runs in the security context of the user running signOWA, or it uses the credentials of a single user provided in the registry when connecting to Exchange server.

To run signOWA.exe through just one user, create a new account in the Active Directory (including a mail box). This will be the account used for OWAuid as previously described, i.e. the account in which context you wish to run signOWA.exe.

It is recommended to create a domain user with very limited rights for the single purpose of running signOWA.exe. Specifically, the user should not be part of the Administrators group. The user must have the following rights:

  • The user must have some extended rights on the Exchange mail store in order to be able to set the signature for all other domain users. These settings vary between Exchange 2003 , 2007 and 2010.
  • The user must have read access to the HKLM hive of the registry on the machine running signOWA.exe.
  • The user must have read/write/update access to the table ldgaUsers in the settings database.
Note: When you run signOWA, all users who are registered in the settings database (i.e. the users you see in Diagnostics) will have their signatures updated in OWA.

Setting up a user for Exchange 2003

The new account must have the "Receive as" extended rights on the mailbox store in Exchange. To set these rights, proceed as follows:

  1. Open the Exchange System Manager and browse to the information store.

  2. Right-click on the information store and choose Properties from the pop-up menu. Choose the Security tab in the Properties window.

  3. Add the account you recently created.
  4. Check Allow option for the Receive as permission of the user. Do not modify any other permission settings. Click OK to save and exit.

Testing the system

Once you have configured the security settings, before you deploy the signatures to all OWA users, you need to test that eMailSignature for OWA works properly.

To test the system, we recommend that you try it for a few users to verify that the security settings are good and that everything works as it should.

In order to test for a few users follow these steps. In the example we test for the users JOHNDOE and ADMIN:

  1. Open the Modules tab in eMailSignature and click Configuration button for Outlook Web Access. The Basic Configuration window appears. Please verify that the settings are valid.
  2. Open the Status Monitor from the 'Diagnostics' tab where you can see the deployment status of your users. Please only select those users for whom the signatures are correctly deployed. In order to enable the test for specific users please scroll horizontally to the right and select the checkmark in the column ‘OWA Test’ for those users whose signatures will be tested.

  3. To deploy the test signatures, run signOWA.exe manually with debug messages. Open the command prompt and write C:\>signOWA.exe -v The command prompt will show the progress similar to the following screen.

    When you see a status 'HTTP/1.1 200 OK' the signature is deployed successfully.

    Both the signOWA.exe and the BM.signOWA.dll files must be located in the same folder for the program to function correctly.
  4. Open the test users' mail boxes from OWA to check that the signatures are deployed as expected.
  5. If the signatures are deployed correctly, before going 'Live' clear all check-marks for the users you have selected for this test.
    Please remember that you need to be logged off OWA when performing changes to your default signature in OWA.

Setting up signOWA.exe as a scheduled task

To set up signOWA.exe to run on schedule, proceed as follows:

  1. Open the Scheduled Task administration in the Control Panel on your server.
  2. Browse to the folder containing signOWA.exe and click Next.
  3. Choose how often you want to deploy signatures to OWA. Common setting is Daily. Then click Next.
  4. Select the time of execution and click Next.
  5. Enter the user name and password for the account and click OK.
  6. Finally, test run the task and make sure it works as expected.

You can run the schedules task from anywhere basically, but it is recommended that you use the same server from where you also run other tasks and services on your network.

Tips and tricks

  • You can see the status of a deployment by opening the Status Monitor in eMailSignature. Select the user whose status you want to see and browse to the end of the log file by scrolling the horizontal bar if your screen is too small.

  • The message 'HTTP/1.1 200 OK' in the 'OWA Status' column means that the signatures are deployed successfully for that user.
  • If a user is logged on to OWA, the user cannot see the change in the signature. This is by design in OWA. The user needs to log off and then log on again in order to see the new signature.
  • You can see the signature made available in OWA in the Status Monitor by clicking the last column 'View Signature'.

How to create signatures in Outlook Web without using Outlook

How to create signatures in Outlook Web without having to run sign.exe first to create the signatures!

You need to create a registry entry in HKCU\SOFTWARE\Office add-on\eMailSignature name "RunBatch" and give it value 1. Next time you run sign.exe it will run sign.exe for the users who is a member of the groups you have selected in the form when you click 'Batch Run'.

Please make sure you have enough licenses when running this. Also note that it will overwrite any individual settings made for the users it will run for, so please make sure that you only run this for users who do not run sign.exe.

Troubleshooting

If you experience errors, please check your security settings and registry settings, and evaluate the following possible solutions carefully. If none of these solutions help the problem, please search for more solutions on www.emailsignature.eu website.

How to fix general OWA problems BEFORE running SignOWA.ex

Outlook Web (OWA) allows users to check their email anywhere using only a Web browser. Unfortunately, OWA doesn’t always work the way that it’s supposed to. Here I’ll show you what to do when OWA breaks down.

What OWA does

An OWA environment is nothing more than an IIS-based Web application with an interface to the Exchange stores. Clients access the OWA site by making a request to the IIS server over port 80 (HTTP) or port 443 (HTTPS). Once the initial request has been processed, the IIS Server asks the client for authentication credentials. The OWA Server takes these credentials and attempts to authenticate the client. Once they’re authenticated, clients can access their Exchange email accounts.

Problems with OWA

Problems with OWA can usually be traced to one of the following areas:

  • The client’s Web browser
  • The client’s connection to the IIS Server
  • An IIS problem
  • An Exchange problem

Any one or any combination of these problems can keep OWA from functioning. Naturally, some of the problems that I just described are a little tougher to troubleshoot than others. Therefore, I’ll start with the easier solutions and build up to the more complex troubleshooting issues.

Client problems

There are many different types of OWA problems, but what the client gets often yields clues as to the nature of the problem. For example, a message stating that a Web site can’t be found means something completely different from a message indicating that the page isn’t displaying correctly.

If the client receives a message stating that the OWA Web site can’t be found, there are a number of possible causes to investigate. I recommend troubleshooting such a problem by first trying to access the OWA server from another computer. If other computers can access the OWA site, then the problem is likely with the computer in question’s Internet connection and not with OWA.

On the other hand, if none of the computers that you attempt to access OWA through can attach to the OWA server, then you have a more serious problem. The WAN connection linking the OWA Server to the Internet may be down; IIS could be malfunctioning; or there could be an invalid DNS entry that’s pointing the OWA server’s FQDN to an invalid or incorrect IP address. I’ll discuss these problems in a bit more detail later on.

Another possibility is that the client is able to access the OWA site, but the site displays incorrectly, or the user isn’t allowed to log in. Again, begin the troubleshooting process by trying a different computer. This particular problem is often due to someone using an unsupported Web browser to access OWA. However, if you discover that none of your test computers can authenticate into the OWA Server, it’s likely that you have an authentication problem on the server end rather than a Web browser problem.

IIS connection errors

IIS connection problems and other IIS-related malfunctions are among the most common causes of OWA errors. It’s a lot of work to thoroughly troubleshoot IIS problems, but the necessary steps aren’t especially difficult. I recommend beginning the troubleshooting process by going to the OWA Server and verifying its connection to the Internet. If you can surf the Web from the OWA server, you can rule out a connectivity problem.

Next, go to a computer outside your network and attempt to ping your OWA server. Try pinging first by IP address and then by FQDN. If both pings fail, it probably means that your firewall is set to block ICMP packets and that the server won’t respond to a ping. If this happens to you, I recommend trying the ping test from behind your firewall.

A failure of both pings could also mean that there is no connectivity between the machine that you’re pinging from and the OWA server. This won’t apply in this particular case, though, because you’ve already established that the communications link is good.

If the ping by IP address is good but the ping by FQDN fails, then you likely have a DNS problem. Remember that DNS servers resolve FQDNs to IP addresses. Therefore, if a ping by IP address is successful, you can verify that the communications link is good. If this is the case, then the only thing that should cause a ping by FQDN to fail is if the FQDN isn’t being resolved.

Firewall problems

So far you’ve verified that you’ve got a good communications link and that the DNS server is doing its job. If your clients are still unable to connect to the OWA server, it’s probably either due to a firewall problem or an IIS failure.

Testing for a firewall problem is easy. Just try to access the OWA server from behind your firewall. If both the OWA server and the client machine exist on your private network behind the same firewall, you can use the client machine to test the OWA server without the firewall interfering. If the test is successful, then the firewall is your problem. Verify that ports 80 and 443 are open to inbound traffic.

IIS problems

If the firewall doesn’t seem to be the source of your problems, then there’s a really good chance that IIS is causing the problem. To test IIS, begin by selecting the Programs | Administrative Tools | Services commands from the Start menu. When you do, Windows will open the Service Control Manager. Go through the Service Control Manager and verify that the following services are running:

  • World Wide Web Publishing Service
  • IIS Admin Service
  • Protected Storage
  • Remote Procedure Call (RPC)

This is also a good time to verify that the various Microsoft Exchange-related services are running as well.

Once you’ve verified that the necessary IIS services are running, open Internet Explorer directly on the OWA Server and enter the OWA Server’s IP address into the browser. If the OWA session starts, IIS is working correctly. If you can’t get OWA to start by entering the IP address, verify that IIS is configured to use the correct IP address.

To verify that IIS is configured to use the correct IP address, select Internet Services Manager from the Administrative Tools menu. When the Internet Information Server console opens, select the OWA Web site from the console tree. Before continuing, verify that the word Stopped doesn’t appear in parenthesis next to the Web site name. If it does, simply right-click the site and select the Start command. If you receive an error message, your OWA site probably has an IP address conflict with another site on the server. To solve this problem, read the following instructions for verifying the IP address, and then try to start the site again.

Verifying the OWA site's IP address

To verify the site’s IP address, right-click the OWA site and select Properties. On the site’s property sheet, select the Web Site tab and verify that the IP address is correct. By default, the IP address will be set to All Unassigned. However, the All Unassigned setting should be used only for the default Web site. The OWA site should have a dedicated IP address. While on the Web Site tab, you should also verify that the OWA site is configured to use port 80.

If all of your settings are correct but you still can’t access the OWA Web site, the best thing to do is to implement a sample Web site to verify IIS’s functionality. To do so, open the Control Panel and double-click the Network And Dial Up Connections icon. When the Network And Dial Up Connections window opens, right-click your main network connection and select Properties.

On the connection’s property sheet, select the TCP/IP protocol from the list and click the Properties button to reveal the TCP/IP property sheet. On the TCP/IP property sheet, click Advanced to reveal the Advanced TCP/IP Settings property sheet. On the IP Settings tab of the Advanced TCP/IP Settings property sheet, click the Add button under the IP Addresses section and add a unique IP address to the server. Click OK on all of the open windows to close them.

Now, create a directory called Test on your hard disk and place a few random HTML files into it. Be sure to name one of the files INDEX.HTM. At this point, return to the Internet Services Manager. Right-click the server name in the console tree and select New | Web Site. This will launch the Web site creation wizard.

Click Next to bypass the wizard’s introduction screen. You’ll then be asked to enter a description of the site. Enter the words Test Site and click Next. On the following screen, select the IP address that you added to the server from the Enter The IP Address To Use For This Web Site drop-down list. Verify that the site is configured to use TCP port 80, and then click Next. On the following screen, enter C:\TEST as the path to the home directory. You should also make sure that the Allow Anonymous Access To This Web Site check box is selected. You’ll then see a screen asking what permissions should be set for the home directory. Accept the default choices by clicking Next, followed by Finish.

When you’ve completed the test site, you’ll see it appear in the IIS tree with the words Stopped in parenthesis next to it. Right-click the new site and select the Start command from the shortcut menu. The site should now be started.

Next, open Internet Explorer and enter the new site’s IP address followed by index.htm. For example, if you assigned the address 133.100.100.100 to the site, the format would be http://133.100.100.100/index.htm. If you can access your test site, then IIS is functional and you likely have an authentication problem.

If you discover that IIS is malfunctioning, I recommend reinstalling it. You can do so through the Add/Remove Programs applet in the Control Panel. IIS is located in the Windows Components section.

Authentication problems

The authentication portion of Outlook Web Access tends to be one of the trickiest parts to troubleshoot. When troubleshooting authentication problems, it’s helpful to keep in mind that when your users use OWA, they aren’t telling OWA which Exchange server their mailboxes exist on. Instead, OWA is performing an Active Directory query during the authentication process. This query tells OWA which Exchange server to connect the user to.

It’s quite possible that the Active Directory query could be causing the problem. The easiest way to find out is to enter the URL of the OWA site into the Web browser in a way that conveys the name of the user’s mailbox. For example, if you normally enter http://server_name/exchange, try entering http://server_name/exchange/user_name instead. If this technique works, then the problem could be due to the OWA server’s TCP/IP settings not referencing a DNS server that’s aware of your Active Directory. The other possibility is a problem with the authentication protocol, which is what I’m about to show you how to fix.

When it comes to Windows 2000 authentication, the NTLM authentication protocol is more secure than basic or anonymous authentication. However, in an OWA environment, you must use basic authentication. NTLM doesn’t work if your clients are communicating with the server over HTTP or HTTPS. Likewise, anonymous authentication does work, but it would give everyone in the world access to your server. Therefore, basic authentication is your only real choice.

To verify what type of authentication is being used, open the Internet Services Manager, right-click the OWA Web site, and select Properties. Select the Directory Security tab on the OWA site’s property sheet, and click the Edit button found in the tab’s Anonymous Access And Authentication Control section. When you do, you’ll see the Authentication Methods dialog box. Verify that the Anonymous Access check box is not selected. Now, take a look at the Authenticated Access section and verify that only the Basic Authentication check box is selected. As you look at the various check boxes, you’ll notice an Edit button just to the right of the Basic check box. Click the Edit button and verify that the correct authentication domain is selected.

At this point, close all of the open windows by clicking OK in each. You’ve now specified that the OWA Web site will use basic authentication exclusively, and that a specific domain will perform the authentication. The final step in the process is to verify that the OWA server can communicate with the domain that you’ve specified.

You can start out by attempting to ping domain controllers in the specified domain from the OWA server. If the pings are successful, the next step is to verify that the OWA server is configured to use the same DNS server as all of the domain controllers. Unless all of the servers use a common DNS server (or linked DNS servers), the OWA server may have trouble accessing Active Directory information from the domain controller.

404 Not Found

The most likely cause for this error message is that the receive-as permissions has not been set correctly. Please check this first.

Another possible reason: WebDAV in Exchange 2003 or 2007 or EWS in Exchange 2010 has been disabled for IIS on the server running OWA.

If WebDAV/EWS is enabled, the URL may be wrong. Please review your OWA URL settings:

  1. Open the Modules tab in eMailSignature and click Configuration button for Outlook Web. The Basic Configuration window appears.
  2. Enter the URL of your Exchange OWA server in the OWA URL field. Leave out HTTP and HTTPS before the URL.
    If you are using Exchange 2003, append "exchange" to the URL as in the following example: "myserver.mydomain.local/exchange/".
    If you are using Exchange 2007/2010/2013, do not append anything as in the following example: "myserver.mydomain.local". (E.g. do NOT add /owa or /exchange)
  3. Click Save to keep the updated settings.

The security settings on the Exchange server for the user running signOWA may also be incorrect. Review the settings as described in the "Setting account rights for the account running signOWA.exe" section of this document.

Additional check

If the above does not solve it, then try to put in the URL to the Exchange Mailbox store and not to the CAS to avoid the "404 Not found" error.

403 Forbidden

Make sure that the version of the Exchange Server is specified correctly:

  1. Open the Modules tab in eMailSignature and click Configuration button for Outlook Web Access. The Basic Configuration window appears.
  2. Select the Exchange Server version that you are running:
    • Exchange 2003
    • Exchange 2007
    • Exchange 2010
    • Exchange 2013
  3. Click Save to keep the updated settings.

The error may also indicate that you are not using SSL (HTTPS) when required. Please make sure that HTTPS/SSL is checked in eMailSignature if you are using SSL:

  1. Open the Modules tab in eMailSignature and click Configuration button for Outlook Web. The Basic Configuration window appears.
  2. Check the Secure Socket Layer (https) option if you are using HTTPS to connect to OWA.
  3. Click Save to keep the updated settings.

401 Unauthorized

Your OWA server is not set up to use Forms Based Authentication. Please configure signOWA to use Integrated Windows Authentication instead:

  1. Open the Modules tab in eMailSignature and click Configuration button for Outlook Web. The Basic Configuration window appears.
  2. In the Authentication Method section, select Integrated Windows Authentication for OWA option.
  3. Click Save to keep the updated settings.

Other causes may be an incorrect OWA URL or wrong user name/password.

Security Warning: We recommend to write the internal address of the OWA server to avoid any possible security issues.

Please review your OWA URL settings:

  1. Open the Modules tab in eMailSignature and click Configuration button for Outlook Web. The Basic Configuration window appears.
  2. Enter the URL of your Exchange OWA server in the OWA URL field. Leave out HTTP and HTTPS before the URL.
    If you are using Exchange 2003, append "exchange" to the URL as in the following example: "myserver.mydomain.local/exchange/".
    If you are using Exchange 2007/2010/2013, do not append anything as in the following example: "myserver.mydomain.local". (E.g. do NOT add /owa or /exchange)
  3. Click Save to keep the updated settings.

Also, review your settings for OWAuid, OWApwd, and OWAdomain registry keys, as described in section Setting up security for Exchange Server of this guide.

440 Login Time-out

This error is usually seen when trying to use Forms Based Authentication while having specified an incorrect URL.

Review your settings for Authentication Method and OWA URL, as described in section Configuring OWA settings in eMailSignature of this guide.

signOWA.exe only deploys signatures to a few users

Make sure that you have cleared all users after testing:

  1. Open the Modules tab in the eMailSignature and click Configuration button for Outlook Web. The Basic Configuration window appears.
  2. If there are any user names in the Test before going 'Live' field, clear them. Leave this field blank to deploy signatures to all OWA users.
  3. Click Save to keep the updated settings.

The email signature is the TXT version - not the HTML version

You've deployed OWA Signature, but when you connect to OWA, the signature is the TXT version - not the HTML version. By default OWA has a signature size limit and your signature just exceeded that limit. So the TXT signature is being used.

Exchange Server 2013

The default maximum OWA 2013 email signature size is 8Kb. The maximum OWA 2010 email signature size cannot be increased.

Exchange Server 2010

The default maximum OWA 2010 email signature size is 8Kb. The maximum OWA 2010 email signature size cannot be increased.

Exchange Server 2007

The default maximum OWA 2007 email signature size is 4096 bytes. The maximum OWA 2007 email signature size cannot be increased.

Exchange Server 2003

There is a registry setting on the back-end Exchange Server to extend the size limit from 4096 bytes to max 16K. HKLM\SYSTEM\CurrentControlSet\MSSexchangeWEB\OWA "SignatureMaxLength"=dword:00004120

Email Signature for users only using OWA (and not Outlook)

This will enable you to manage the default email signature in OWA without those users are using Outlook at all.

This is especially useful for users who don't run 'Sign.exe' on a continuous basis, but only occasionally. If these users need their email signature in OWA (and on emails sent from mobile devices), then the 'Batch' is very useful. When running 'Sign.exe' in 'Batch' means that you run on behalf of a number of users in certain groups. You can e.g. run Sign.exe on behalf of all users in group A and B.

Prerequisites

We assume that you already have a working version of eMailSignature running and Outlook Web runs without issues - Security and permission challenges have been solved and you can see the default Outlook email signature in Outlook Web.

'Batch' works as an expansion to the eMailSignature and Outlook Web functionality.

Generate the email signature for standalone OWA users

In order to create the signatures for OWA users not logging on you need to run the signature on those user's behalf. To do so you need to choose one or more groups for whom you want to run sign.exe for.

Now you can select the groups you wish to run it for:

Note: You can only use distribution lists in batch - not security groups!

Running sign.exe as scheduled task

Now that you have selected the groups, you need to set up Sign.exe to run scheduled. The most common way is to set 'Sign.exe' to run scheduled once per day.

  1. Install eMailSignature on a server and connect to your database.
  2. Open your registry browser and browse to the entry HKCUSOFTWAREOffice add-oneMailSignature, create an entry of type REG_SZ and name it 'RunBatch' and give it value "1".
  3. Open your Windows Scheduler and create a basic scheduled task:

    Now it will run as if these users ran eMailSignature.

Verifying that it works

When 'Sign.exe' is finished running in the batch, you will users appearing in the Status Monitor.

In order to see the email signature in OWA you need to run signOWA.exe as you normally do, which pushes the default email signature into the Outlook Web email client.

Prerequisites for a Remote Install of eMailSignature for Outlook Web

Purpose of the remote session

The purpose of the remote install is do demonstrate that eMailSignature for Outlook Web works in your environment.

We will not do any design changes to your signature or similar, but only demonstrate that it works, i.e. that you can see the signature in OWA when you click the 'New E-mail' button.

Requirements for a remote install of Outlook Web Module

When you have agreed for a paid install of eMailSignature for Outlook Web (remote access) please make sure that these requirements are fully met:

  • You must have a fully functional working version of eMailSignature either a trial install or a licensed copy. We must have access to the eMailSignature administrative console during the installation and you must be logged on as super user.
  • The settings database (backend database for eMailSignature) must be based on SQL Server. We do not do installations based on Access as this database is being phased out.
  • You need to have a server of PC with .NET 4 installed from where we will perform the installation.
  • You must have access to the Exchange Management Shell and access to create a service account in Active Directory (Check here what we must go through).
  • You need to find out which authentication method you use for OWA (integrated or FBA) (we cannot know this..).
  • You need to know the internal OWA URL for your OWA site (we cannot know this).

If the above information is not present, we are unfortunately not able to perform the installation and you need to find the information beforehand.

Important: Please note that you might risk images to show up as red x in OWA if you use images in your signature. It is not a part of the testing process to modify the signature to ensure this correctness - this is a part of our design services.

LiveZilla Live Help