OWA 2010/2013/2016 policy

CodeTwo Email Signatures for Email Clients lets you define policies that enable the creation of signatures in a new mail message in Outlook, OWA 2007/2010/2013/2016, Office 365 and Google Apps (G Suite). The type of the chosen policy determines its deployment method on email clients. Furthermore, depending on the policy type, they may be deployed using either the Central Updating Service (CUS) or the Client Applications.

This article contains the following sections:

• Defining the policy deployment method
• Creating policy along the signature
• Troubleshooting on-premises Exchange connection settings

Defining the policy deployment method

If you configure the OWA 2010/2013/2016 policy type, you will use the Central Updating Service to automatically deploy and update its settings on the email clients embraced by this policy type. Using the CUS greatly simplifies the policy deployment and update process by eliminating the need for installation of the Client Applications on the Client machines. Furthermore, once you Add this policy type for the first time (Fig. 1.), you will be asked to configure its deployment method first. If you don't configure the deployment, you won't be able to proceed with the further steps of the policy configuration.

Fig. 1. Adding OWA 2010/2013/2016 policy.

You can set up the policy's deployment method in two ways. You can either click Yes in the notification window that pops out once you add your policy for the first time or go directly to the Administration Panel's ribbon and hit the Deployment tab (Fig. 2.).

Fig. 2. Notification informing about the missing deployment configuration.

Both above mentioned actions will trigger the Policy deployment window to open.

Note that once you open the deployment window via the notification, OWA 2010/2013/2016 policy deployment will be activated by default (only OWA 2010/2013/2016 tab will be visible). On the other hand, if you choose to configure the deployment via its tab in the Administration Panel's ribbon, it will be deactivated until you mark the Deploy on-premises OWA 2010/2013/2016 policies checkbox (all policy tabs will be visible) (Fig. 3.).

Fig. 3. Policy deployment window.

To move on with the policy's deployment configuration, mark the Deploy on-premises OWA 2010/2013/2016 checkbox. This action will activate the Configure access link (Fig. 4.) which opens the OWA deployment options configuration wizard. The deployment wizard is responsible for establishing the connection to your on-premises Exchange Server. After setting up this connection, you will enable the program to use the Central Updating Service to deploy and update policy's settings on your OWA clients embraced by the created policy.

Fig. 4. Configure access link enabled.

Click the Configure access link. On the first screen of the deployment wizard that opens, define the server to which you want to connect to (Fig. 5.)

Fig. 5. Automatic configuration of the server's location.

If you want to connect to the Target server from the same domain there is not much to do: the Autodiscover function will locate the server automatically.

On the other hand, if you want to set up a connection to the Target server from a different domain, the Autodiscover function won't work. You need to enter the server's location manually instead of using Autodiscover. To do that, tick Configure connection manually and enter either the full Server name or its IP address (Fig. 6.). You don't have to enter the EWS URL field as it will be created automatically with the given server name.

Fig. 6. Manual configuration of the server's location.

In the next window, you will find the automatically added User Principal Name (UPN), which is the Administrator's UPN of your Target server. It will let you create signatures/disclaimers within your own domain. To enter the Target server Administrator's UPN e-mail address from outside your domain, enter it manually or automatically via the Browse button (Fig. 7.).

Fig. 7. Choosing the Administrator's UPN.

UPN is the internal account name of a user in an e-mail address format.

Make sure that the Administrator has their UPN configured. Otherwise, the program may work incorrectly and errors are likely to appear.

Once you choose the Browse button, you will be able to pull out the appropriate UPN from Active Directory. Furthermore, by clicking Locations you can determine the domain the target on-premises server Administrators' UPN will be taken from (Fig. 8.).

Fig. 8. Selecting the Administrator's UPN from Active Directory.

Please note that the Browse button can ONLY be used to list the UPN's of Administrators from the same domain or different trusted domains. This option is unavailable with the untrusted domains. Therefore, if you want to select UPN from an untrusted domain you will have to type it manually.

After choosing the desirable domain, enter your Administrator's name and select Check name - your user will be listed automatically. Once you confirm the configuration, the Administrator's UPN will be listed in the field provided (Fig. 9.).

Fig. 9. The Administrator's UPN entered along the password.

Next, enter the password and move on to the Verification stage.

The verification stage checks the server connectivity, the impersonation rights assignment status and the connection to the target PowerShell console (Fig. 10.).

Fig. 10. Verification stage of the OWA deployment wizard.

Additionally, this step offers hints to troubleshooting verification errors. If you encounter any, just click the Learn more link and you'll be navigated to the troubleshooting section.

Last but not least, you can check the Administrator's impersonation rights on the selected user mailbox - simply click the Test link to open the mailbox selection window, choose a user and run the test (Fig. 11.). If the test passes it means that the account used in the wizard has the sufficient rights to operate the program in terms of configuring signatures for the selected users defined within the policy.

Fig. 11. Impersonation rights test window.

Creating policy along the signature

To create the OWA 2010/2013/2016 type of policy, you need to click the Add button located in the Administration Panel of CodeTwo Email Signatures for Email Clients. Then, next to the button, a menu will open presenting available types of policies. To create the OWA 2007 policy, all you have to do is choose the OWA 2010/2013/2016 policy type (Fig. 12.).

Fig. 12. Choosing OWA 2010/2013/2016 policy type.

After defining the deployment options, the Edit policy window will display. This window consists of tabs that will let you:

• give the policy name and its description
• define the list of policy users
• create the signature
• define additional settings
• finalize the creation/edition of the policy

Giving the policy name and its description

The first tab that appears during the creation or the edition of the policy is called General (Fig. 13.). It lets you name the policy and describe it. The description may include various information, such as usage cases of the particular policy.

Fig. 13. The edition policy view - General tab.

The name of the policy should be entered into the field below the Policy name. Furthermore, the description should be entered in the area under the Policy description.

Defining the list of policy users

While you're creating or editing a policy, you need to define the list of users to which the particular policy will apply. On the other hand, you can also define here the exceptions from the users' list choosing the users to which the policy will not apply (Fig. 14.).

Fig. 14. The list of policy users and the exceptions from this list.

There are three types of users that can be chosen in the OWA 2010/2013/2016 policy type (Fig. 15.).

Fig. 15. Choosing the OWA 2010/2013/2016 policy user.

• Active Directory Users

  If you add Active Directory users to the Users List, the policy will only apply to these particular users (Fig. 16.). You can also define the Active Directory users in the Exceptions to the list above field located in the bottom area of the form. In this way, you will prevent these users from being taken into account while applying the policy.

  Fig. 16. Choosing the Active Directory user.

• Active Directory Group

  The policy will only apply to users assigned to Active Directory group or groups that were added to the Users list (Fig. 17.). Furthermore, the policy will not apply if the user will be a member of a particular AD Group added to Exceptions to the list above.

  Fig. 17. Defining the Active Directory group.

• Active Directory Organizational Unit

  In this case, the policy will only apply to users from one or many Active directory Organizational Units (so called Containers) which were added to the Users list (Fig. 18.). The Organizational Units can also be added to the Exceptions to the list above area located on the bottom part of the form.

  Fig. 18. Defining the scope of Active Directory Organizational Units.

Note that you can also choose to add the whole domain as the Organizational Unit. In such case, the policy will apply to all users within your organization, regardless of their group membership.

Creating the signature

While you're evaluating an OWA policy, you may create a signature that will be added at the time the new mail is being created. Furthermore, you may also define several additional options associated with a signature which are located in the Signature template tab (Fig. 19.).

Fig. 19. Signature template tab.

• Adding a signature to a new e-mail

  • To add a signature to the list of signatures in OWA you need to tick the Deploy signature template option. Checking this option enables a creation of o signature (the Edit button will be unblocked), which will be added to the OWA 2010/2013/2016 signatures list after it's created.

  • Automatically append a signature to outgoing messages - this feature when ticked, lets you set the default signature in OWA 2010/2013/2016. It means that whenever you create a new email the signature will already be there. Therefore, you won't have to add it manually from the list of signatures.

• Opening the Signature/Disclaimer Template Editor

  To open up the Signature/Disclaimer Template Editor, click the Edit button located on the right-hand side of the signature preview window (Fig. 20.).

  Fig. 20. The button that opens the Signature template editor.

  The Signature/Disclaimer Template Editor for OWA 2010/2013/2016 lets you create and edit footers in HTML and Plain Text formats (Fig. 21.). You can easily change the format by switching between HTML and Plain Text tabs. The editor contains the standard set of tools that let you create the professional looking signatures. You can choose the font type, size and color. Furthermore, you may change the background color, bold, italicize and underline text and add tables. In addition, the ribbon includes the Dynamic Field button which makes it easier to personalize your signatures. Thanks to this feature you will be able to insert AD variables automatically to your signatures.

  Fig. 21. The Signature template editor.

Other settings

While you're creating or editing the OWA 2010/2013/2016 policy type you may also define the appearance and e-mail format settings. Additionally, you can define settings associated with the font of a new e-mail. Please note that these settings are not associated with the signature itself, but apply to the whole new message composition. To define the additional settings, go to the Other tab while you're editing the OWA 2010/2013/2016 policy (Fig. 22.).

Fig. 22. The Other tab.

All options in the Other tab are switched off by default.

• Set default email format to option

  Once set, this option unblocks the default e-mail format choice: HTML and Plain Text (Fig. 23.).

  Fig. 23. Choosing the default e-mail format.

  This option changes the OWA 2010/2013/2016 default settings concerning new email format for the users listed on the Users list of the policy. From this moment, each new e-mail will have a default format set.

• Set new email message font to option

  Once set, this feature unblocks the tool that enables the edition of a new e-mail font. There are the following options available:

  • Font type selection - by clicking on the drop-down list, you may choose the most appropriate font type of the new email (Fig. 24.).

    Fig. 24. Selecting the e-mail font type.

  • Font size selection - in the drop-down list, a user will be able to choose the most appropriate font size of an e-mail (Fig. 25.).

    Fig. 25. Selecting the e-mail font size.

  • Bold font.

  • Italic font.

  • Underline font.

  • Font color selection - by clicking the Color button, a window will open where you can choose the appropriate font color of your e-mail (Fig. 26.). After the selection, your chosen color will display on the right-hand side of the Color button.

    Fig. 26. Selecting the e-mail font color.

The options included in the Other tab have the direct impact on the OWA settings. It means that even though you disable them, all the changes applied to your OWA will remain.

Finalizing the creation/edition of the policy

To finalize the creation/edition of a new/previous rule, click the Finish button located in the Edit policy window. Next, save your newly created/previous policy by clicking Save in the main window of the Administration Panel (Fig. 27.).

Fig. 27. Saving the newly created policy.

Troubleshooting on-premises Exchange connection settings

Below you'll find solutions to the most common problems associated with the Target on-premises Exchange connection settings:

• Server connectivity
• Impersonation rights
• PowerShell console connectivity

Server connectivity

This test checks if the program can establish a connection to the target server. The program tries to access Administrator's mailbox with EWS (Exchange Web Services) API. Next it tries to enumerate mailbox's Inbox folder.  

Error message:

"The request failed. The remote server returned an error: (401) Unauthorized."

Fig. 28. Incorrect Administrator's credentials error.

The error above (Fig. 28.) indicates that the Administrator's credentials entered in the previous step are incorrect or of the non-administrative user. To fix the problem make sure to enter the Administrator's credentials.

Error message:

"The request failed. Unable to connect to the remote server."

Fig. 29. Misspelled credentials/EWS address error.

This error occurs when the domain name in the Administrator's email is misspelled or the password is wrong. Go to the previous step of the connection wizard and make sure to enter correct credentials. Similar message (Fig. 29.) is also shown when the EWS URL is wrong. Go to the first step of the wizard and enter the correct EWS URL.

Impersonation rights

Checks if the Administrator user entered in the previous step of the wizard has application impersonation rights. It does so by running the Powershell command, get-ManagementRoleAssignment. If the result is negative the program tries to add such rights for the Administrator account.  

Error message:

"The server could not be contacted. The LDAP server is unavailable."

Fig. 30. The server could not be contacted error.

This error (Fig. 30.) might be caused by missing impersonation rights. Wizard tries to grant them automatically, but when it fails then the above message is shown.

Follow our Knowledge Base article to grant application impersonation rights manually and fix this issue. When the above solution is not helping - try creating a trust relationship between servers you are migrating.

PowerShell console connectivity

This test checks the remote PowerShell connectivity to the target Exchange server. After connecting to the target, it tries to execute PowerShell command Get-Mailbox to enumerate all mailboxes.  

Error message:

"Connecting to remote server failed with the following error message: The WinRM client cannot process the request."

Fig. 31. The WinRM client cannot process the request error.

This error occurs when the domain name in the Administrator's email is misspelled or the password is wrong. Go to the previous step of the connection wizard and make sure to enter correct credentials.

Similar message (Fig. 31.) is also shown when the EWS URL is wrong. Go to the first step of the wizard and enter the correct EWS URL.

Also, the error can indicate Administrator's credentials entered in the previous step are incorrect or of the non-administrative user. To fix the problem make sure to enter the Administrator's credentials.

See also:

Configuration of Outlook policy
Configuration of OWA 2007 policy
Configuration of Office 365 policy
Configuration of Google Apps (G Suite) policy