Deploying eMailSignature to OWA with Exchange Server 2010
To set up
eMailSignature to work with
OWA, proceed as follows:
- Configure OWA settings in the Cockpit.
- 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.
- 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.
- If using a single user to run signOWA.exe, set up account rights for this user.
- Test signatures on a few OWA users.
- Set up signOWA.exe as a scheduled task and then deploy.
Each of the steps is described in the following sections.
Configuring OWA settings in the Cockpit
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 the Cockpit. If the OWA module is not enabled, please obtain a valid
license key. In the
Standard Edition, only the Disclaimer module is enabled.
To configure the OWA module, proceed as follows:
- Double-click the Cockpit 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.
- Select the Exchange Server version that you are running:
- 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.
- Check the Secure Socket Layer (https) option if you are using HTTPS to connect to OWA.
- 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.
- Click Save to keep these settings, and then click Close to exit the Basic Configuration window.
You are now ready to continue with installing eMailSignature for OWA files.
Installing eMailSignature for OWA files
Now that you have set up your
OWA information in the Cockpit, you must install eMailSignature for OWA files on a server, (other than the Exchange server), where you want to run the job as a scheduled task.
Installation consists of three files that you received when purchasing the appropriate license:
- signOWA.exe
- BM.signOWA.dll
- signOWA.reg
Create a folder on the server and extract these three files into that folder. Both the signOWA.exe and the BM.signOWA.dll files must be located in the same 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 need in very rare cases.
Setting up security for Exchange Server
SignOWA supports different
authentication schemes depending on the setup of the Exchange server:
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¶
The new account must have the "Receive as" extended rights on the mailbox store. To set these rights, proceed as follows:
- Start Exchange Management Shell.
- 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. - 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"
- It may be necessary to restart the Microsoft Exchange Information Store service to propagate the changes.
Checking site authentication in Exchange 2010
When
OWA is installed, Exchange 2010 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:
- Open the Exchange Management Console as shown in the following screen shot.
- Double-click the "Exchange (Default Web Site)" item to view the properties for the web site. Choose the Authentication tab in the Properties window.
- 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.
- 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.
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:
- Open the Modules tab in the Cockpit and click Configuration button for Outlook Web Access. The Basic Configuration window appears. Please verify that the settings are valid.
- 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.
- 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.
- Open the test users' mail boxes from OWA to check that the signatures are deployed as expected.
- If the signatures are deployed correctly, before going 'Live' clear all checkmarks 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.
Trouble Shooting
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 deson'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.
Setting up signOWA.exe as a scheduled task
To set up
signOWA.exe to run on schedule, proceed as follows:
- Open the Scheduled Task administration in the Control Panel on your server.
- Browse to the folder containing signOWA.exe and click Next.
- Choose how often you want to deploy signatures to OWA. Common setting is Daily. Then click Next.
- Select the time of execution and click Next.
- Enter the user name and password for the account and click OK.
- 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.
Up to
Outlook Web Access Module for eMailSignatureBack to
Deploying eMailSignature to OWAForward to
Tips and Tricks