Office 365 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
• Binding Office 365 users to Active Directory
• Troubleshooting Office 365 connection settings

Defining the policy deployment method

If you want to configure the Office 365 policy type, you need to 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 type of policy 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 Office 365 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 Office 365 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 Office 365 policies checkbox. This action will activate the Configure access link (Fig. 4.) which opens the deployment wizard. The deployment wizard is responsible for establishing the connection to your Office 365. After setting up the 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, define the Office 365 administrator's (global admin) account, including the e-mail address and password (Fig. 5.). It will let you connect to your target server and create signatures/disclaimers within your domain.

Fig. 5. Entering the Office 365 Administrator's (Global Admin) credentials.

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. 6.).

Fig. 6. Verification stage of the Office 365 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.

Lastly, you can check the Administrator's impersonation rights on the selected user mailbox - simply click the Test link to open the mailbox selection window (Fig. 7.). Then select target mailbox and run the test.

Fig. 7. Impersonation rights test window.

Finally, after confirming your target server's settings in the verification step of the deployment wizard, you will be able to create signatures for your Office 365 users.

Creating policy along the signature

To create a new Office 365 policy type, click the Add button in the Administration Panel of CodeTwo Email Signatures for Email Clients. A menu with available policy types will be displayed next to the button (Fig. 8.). Choose the Office 365 policy option to start working on your new policy.

Fig. 8. Choosing Office 365 policy type.

The Edit policy edition window will be displayed. It contains multiple tabs which allow you to:

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

Important: Note that due to the Office 365 restrictions, once your policy is ready and saved within the program, it takes up to 15 minutes for the policy to be updated and pushed to Office 365. However, you can speed up this process by forcing the policy update and changing the interval via running the program in the advanced mode or logout from your account and login once again. Both these procedures should trigger the policy to be updated faster.

Giving the policy name and its description

The first tab in the policy edition window is called General (Fig. 9.). It allows the user to provide the name for the new policy and its short description. The description can contain general information about the policy, e.g. when is it applied and what does it do.

Fig. 9. Policy edition window - General tab.

The name and the description of the policy need to be entered in the fields below the Policy name and Policy description titles.

Defining the list of policy users

When creating or editing a policy it is necessary to define the users that will be encompassed by the particular policy (Fig. 10.).

Fig. 10. Lists of users affected by the policy and those not encompassed by it.

It is also possible to edit exceptions from the policy, and select users for whom it will never be applied.

There are two available user types to choose from for an Office 365 policy (Fig. 11.).

Fig. 11. Available user choices for an Office 365 policy.

• Office 365 OWA user

  The policy will be applied for Office 365 users that have been added to the Users list (Fig. 12.). A user account can also be added to the exceptions list in the lower section of the window (called Exceptions to the list above), to make sure the policy will never be applied when this person creates a new email.

  Fig. 12. Choosing an Office 365 user.

• All Office 365 OWA users

  If the option All Office 365 OWA users is selected when creating the Users list, all Office 365 users will be encompassed by the policy (Fig. 13.). If All Office 365 OWA users are added to the Exceptions to the list above section, the policy will not be applied at all.

  Fig. 13. Choosing all Office 365 users.

The Office 365 users may be bound to Active Directory user accounts. This option should be used if the Administrator prefers to insert the AD variables into the Office 365 signatures for the particular user instead of the ones from Office 365. The option is available in the Office 365 policy deployment window.

Creating the signature

When setting up a new Office 365 policy type, a user can create signatures which will be applied when editing a new mail message. Additionally, there are several settings to choose from regarding how or when the footer will be inserted into the messages. These are managed in the Signature template (Fig. 14.) tab.

Fig. 14. Signature template tab.

• Signature deployment options

  • Deploy signature template, selecting this option unlocks the Edit button. Once the template is created it will be added to the Office 365 signatures list.

  • Automatically append a signature to outgoing messages - this option allows to set the created footer as the default one in Office 365. When composing a new message the signature will be automatically inserted and visible in the email. It is not necessary to choose it from the list of available disclaimers.

• Opening the Signature/Disclaimer Template Editor

  Click the Edit button on the right-hand side of the signature preview (Fig. 15.) to open up the Signature/Disclaimer Template Editor.

  Fig. 15. Opening the Signature/Disclaimer Template Editor.

  The Signature Disclaimer Template Editor lets you create signatures in HTML and Plain Text format (Fig. 16.). To change the format just switch between the available tabs: HTML and TXT. The Editor is equipped with a standard set of tools necessary for designing professionally looking footers. It is possible to edit the fonts used in footers, insert images or create tables. Additionally, the toolbar contains a Dynamic Field button, which enables designing personalized signatures. The dynamic fields are variables that will be populated with data from the Office 365 mailbox (or Active Directory if a user is bound to AD) automatically, without any need to manually enter the credentials of the sender and create multiple copies of the same signature - one template with dynamic fields can be deployed for many users.

  Some dynamic fields can be retrieved from Active Directory only, that's why they will not be available for users who are not bound to AD. These fields are marked with AD only icon on the list of all dynamic fields.

  Fig. 16. Template Editor window.

Other settings

While creating or editing an existing Office 365 policy, it is possible to define the format of a new email message. Its default font settings can also be modified. Please note that these settings are not associated with the signature itself, but apply to the whole new message composition. To change the additional settings whilst editing an Office 365 rule, click the Other tab (Fig. 17.).

Fig. 17. Other settings tab.

All options in the Other tab are disabled by default.

• Set default email format to

  When this option is activated a new feature becomes unlocked - it will be possible to change the default format of a new mail message. The available formats are: HTML or Plain Text (Fig. 18.).

  Fig. 18. Setting the default format for new messages.

  Enabling this option will change the default format settings of each new Office 365 message for the user defined in the Users list within the policy. From now on, while creating a new email the user will start with a default format chosen in the policy.

• Set new email message font to

  Enabling this option will unlock the font edition features for a new mail message. From left to right, the following settings are available:

  • Font type - any of the available ones can be selected from the dropdown menu (Fig. 19.).

    Fig. 19. Email font type selection.

  • Font size - the desired one can be picked from the dropdown menu (Fig. 20.).

    Fig. 20. Email font size selection.

  • Bold font.

  • Italic font.

  • Underline font.

  • Font color selection - click the Color button to display the window in which you can pick the specific tint for the default font of new email messages (Fig. 21.). Once chosen, the new color will display on the right-hand side of the Color button..

    Fig. 21. Email font color selection.

All options defined in the Other overwrite the defaults of Office 365. When the policy is disabled, the changes it applied remain in the Office 365 settings.

Finalizing the creation/edition of the policy

To save your policy, click the Finish button in the Edit policy window. The changes need to be confirmed with the Save button in the toolbar of the Administration Panel (Fig. 22.).

Fig. 22. Saving a new policy.

Binding Office 365 users to Active Directory

When creating the policy for Office 365 in Active Directory (AD) environment, the Office 365 users can be bound to Active Directory. This option should be used if the Administrator prefers to insert the AD variables into the Office 365 signatures for the particular user instead of the ones from Office 365. Thanks to the user pairing, the Office 365 user can have a fully personalized custom signature. Data for the signature will be dynamically pulled from the AD account and paired with the Office 365 user's account. If, however, the binding option is disabled (no pairs available on the list), all variables will be pulled from Office 365.

After clicking the Bind users to Active Directory link on the Office 365 tab in the Policy deployment window, the Bind users to Active Directory window will display. The list contains all Office 365 users that have been paired with the corresponding Active Directory accounts (Fig. 23.).

Fig. 23. Bind Office 365 users to Active Directory list.

Learn more on how to:

• create a new user pairing
• remove the existing user pairing

Creating a new user pairing

To create a new Office 365 / Active Directory user pair click the Add button on the right side of the user list. A dialog box will be displayed, in which the Office 365 and Active Directory user names need to be provided (Fig. 24.).

Fig. 24. Selecting a new Office 365 user.

To add the Active Directory user, click the Browse button on the right-hand side of the Active Directory user field. A dialog box will be displayed, in which the Active Directory user name needs to be provided. Changes are confirmed by clicking the OK icon and the username will show in the respective field (Fig. 25.).

Fig. 25. Choosing a new Office 365 user, with the corresponding Active Directory account already added.

Now the Office 365 user needs to be selected. Its email address can be manually entered into the Office 365 OWA user address field.

If the Office 365 OWA Administrator's account has been configured beforehand, after clicking the Browse button a dialog box entitled Select Office 365 OWA user will be displayed. This window lists the Office 365 OWA users with their email addresses (Fig. 26.).

Fig. 26. List of Office 365 users.

Select the desired user and click the OK button on the list. The email address of the user will display in the respective field of the Add new user window (Fig. 27.).

Fig. 27. Choosing new Office 365 user window - with some users already added.

Finally, the new Office 365 OWA user selection can be confirmed with the OK button. The chosen user will be displayed on the list in the Bind users to Active Directory window along the corresponding Active Directory account.

Removing the existing user pairing

To remove the Office 365 OWA / Active Directory user pairing, select the desired pair from the Bind users to Active Directory list and click the Remove on the right-hand side of the window.

Troubleshooting Office 365 connection settings

Below you'll find solutions to the most common problems associated with the Office 365 connection settings:

• Server connectivity
• Impersonation rights
• PowerShell console connectivity

Server connectivity

This test checks if the program can establish the 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 (Fig. 29.) 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.

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 user.

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.

PowerShell console connectivity

This test checks the remote PowerShell connectivity to the target Exchange server. After connecting to the target, it tries to execute the Get-Mailbox PowerShell command 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 (Fig. 31.) 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 the correct credentials.

Also, the error can indicate that credentials entered in the previous step are of a 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 OWA 2010/2013/2016/2016 policy
Configuration of Google Apps (G Suite) policy
Learn more about assigning admin roles in Office 365