This software has been discontinued. If your organization uses Office 365, check out
CodeTwo Email Signatures for Office 365.
Google Apps (G Suite) 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 G Suite (formerly: Google Apps). 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:
- Configuring G Suite (Google Apps) API access
- Defining the policy deployment method
- Creating a policy together with a the signature
- Binding G Suite (Google Apps) users to Active Directory
- Troubleshooting G Suite (Google Apps) connection settings
CodeTwo Email Signatures for Email Clients can be configured for one domain only. If you’re using multiple domains, each domain will require one instance of the program’s Administration panel. Keep in mind that:
- Each instance of the Administration Panel needs to be installed on a separate machine.
- When providing the Super Admin credentials during the deployment of Google Apps / G Suite policy, the domain of the Super Admin account needs to match the domain of the users for whom you will manage signatures. You will not be able to manage signatures for users who do not belong to the same domain as the Super Admin.
Contact CodeTwo Support before installing further instances of the program to check if this requires making changes to your license.
Prior to creating any new Google Apps policies, CodeTwo Email Signatures for Email Clients must be first allowed to access your Google Apps / G Suite account API. To enable API access, log on to your Google Apps Admin Console using your Super Admin account - https://admin.google.com/ Once logged, click on the Security icon.
|Fig. 1. G Suite (Google Apps) Admin Console.|
In the Security section, click on Show more and then go to Advanced Settings to find and click on Manage API client access.
|Fig. 2. Google Apps Admin Console Security options.|
|Fig. 3. Google Apps Admin Console Advanced Security settings access.|
|Fig. 4. Google Apps Admin Console Advanced Security settings tab.|
In the “Client Name” field paste the below CodeTwo Email Signatures for Email Clients ID, which is:
Be careful to copy-paste the ID properly, exactly as it is. Failing to do so will result in the following or similar error message: URL ends with an invalid top-level domain name.
In the Scopes field paste the following:
|Fig. 5. Google Apps API client access management.|
Once finished hit Authorize button, go to Security again and now click on API reference.
|Fig. 6. Google Apps Admin Console Security options.|
Under API access check the “Enable API access” box and click save changes. You are good to go.
|Fig. 7. Enabling Google Apps API access.|
If you want to configure the Google Apps / G Suite 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 policy type for the first time (Fig. 8.), 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. 8. Adding Google Apps 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. 9.).
|Fig. 9. 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, Google Apps / G Suite policy deployment will be activated by default (only the Google Apps tab will be visible). On the other hand, if you choose to configure the deployment via its tab on the Administration Panel's ribbon, it will be deactivated until you mark the Deploy Google Apps policies checkbox (all policy tabs will be visible) (Fig. 10.).
|Fig. 10. Policy deployment window.|
To move on with the policy's deployment configuration, mark the Deploy Google Apps policies checkbox. This action will activate the Configure access link (Fig. 11.) which opens the Google Apps deployment configuration wizard. The deployment wizard is responsible for establishing the connection to your Google Apps server. 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 Google Apps clients embraced by the created policy.
|Fig. 11. Configure access link enabled.|
Click the Configure access link, this will open Google Apps policy deployment wizard. In the first step, the wizard will remind you about the necessity of configuring Google Apps API access.
|Fig. 12. Google Apps deployment wizard.|
In the second step (Fig. 13.) you need to click on the link provided. This will open a Google Apps / G Suite login website in your default web browser - sign in to your Google Apps using your administrator account.
|Fig. 13. Google Apps deployment wizard.|
Once logged, you will see Google's question regarding CodeTwo Email Signatures for Email Clients access to your Google Apps / G Suite account. You must allow it, otherwise it will not be possible to use CodeTwo Email Signatures for Email Clients with your Google Apps, so click Accept.
|Fig. 14. Confirming access for CodeTwo Email Signatures for Email Clients.|
As you agree to CodeTwo Email Signatures for Email Clients access to your Google Apps / G Suite, the wizard's window will refresh, now displaying Administrator's credential and the domain it manages.
It is not possible to change Super Admin credential in this windows as it is received from Google automatically based on the credentials you used to log on to your Google Apps / G Suite in the previous step.
|Fig. 15. Google Apps / G Suite deployment wizard.|
In the last step, click the Verify button to check if all has been done properly.
|Fig. 16. Google Apps / G Suite deployment wizard.|
|Fig. 17. Google Apps / G Suite deployment wizard.|
You will now be able to create signatures for your Google Apps users.
To create a Google Apps (G Suite) 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 Google Apps / G Suite policy all you have to do is choose the Google Apps policy type (Fig. 18.).
|Fig. 18. Choosing Google Apps (G Suite) 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
- finalize the creation/edition of the policy
Important: Note that due to the Google Apps 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 Google Apps (G Suite). 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 log out from your account and log in once again. Both these procedures should trigger the policy to be updated faster.
The first tab that appears during the creation or the edition of the policy is called General (Fig. 19.). It lets you name the policy and describe it. The description may include various information, such as usage cases of the particular policy.
|Fig. 19. The edition policy view - General tab.|
The name of the policy should be entered into the field under the Policy name. Furthermore, the description should be entered in the area under the Policy description.
While you're creating/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. 20.).
|Fig. 20. The list of policy users and the exceptions from this list.|
There are two options to choose from while selecting the Google Apps users (Fig. 21.).
|Fig. 21. Choosing the Google Apps policy user.|
If you add Google Apps users to the Users List, the policy will only apply to these particular users (Fig. 22.). You can also define the Google Apps 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. On the other hand, you may also specify All Google Apps users in the Users List enabling the signature addition to every Google Apps user. Furthermore, by choosing All Google Apps Users in the Exception to the list above field, you will block the signature insertion for all aforementioned users.
|Fig. 22. Choosing the Google Apps user.|
The Google Apps (G Suite) users may be bound to Active Directory. This option should be used if the Administrator prefers to insert the AD variables into the signature for a particular user instead of the ones from Google Apps. The option is available in the Google Apps policy deployment window.
While evaluating the Google Apps policy, you can design a signature that will be added at the time the new mail is being created (Fig. 23.).
|Fig. 23. Policy edition view - Signature template tab.|
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. 24.).
Fig. 24. The button that opens the Signature template editor.
The Signature/Disclaimer Template Editor for Google Apps lets you create and edit footers in HTML format only (Fig. 25.). The editor contains the standard set of tools that lets you create 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 Google Apps (G Suite) mailbox variables automatically to your signatures (if a user is bound to Active Directory, the variables are inserted from AD).
Fig. 25. The Signature template editor.
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 rule by clicking Save in the main window of Administration Panel (Fig. 26.).
|Fig. 26. Saving the newly created rule.|
While creating a policy for Google Apps (G Suite), users from Google Apps can be bound with the Active Directory user's account. Thanks to such solution, the Google Apps user can have a fully personalized custom signature. Furthermore, data for the signature will be dynamically pulled from the AD account paired with the Google Apps user. If, however, the binding option is disabled (no pairs on the list), all variables will be pulled from Google Apps / G Suite.
After clicking the Bind users to Active Directory link on the Google Apps tab in the Policy deployment window, the Bind users to Active Directory window will display. The list contains all the Google Apps users that have been paired with the corresponding Active Directory accounts (Fig. 27.).
|Fig. 27. Bind Google Apps users to Active Directory list.|
Learn more on how to:
To create a new Google Apps / Active Directory user pair, click the Add button on the right side of the users' list. A dialog box will be displayed, in which the Google Apps and Active Directory usernames need to be provided (Fig. 28.).
|Fig. 28. Selecting a new Google Apps 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's name needs to be provided. Changes are confirmed by clicking the OK icon, and the username will show in the respective field (Fig. 29.).
|Fig. 29. Choosing a new Google Apps user with the corresponding Active Directory account already added.|
Now the Google Apps user needs to be selected. Its email address can be manually entered into the Google Apps user address field.
If the Google Apps Administrator's account has been configured beforehand, after clicking the Browse button a dialog box entitled Select Google Apps user will be displayed. This window lists the Google Apps users with their email addresses (Fig. 30.).
|Fig. 30. List of Google Apps 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. 31.).
|Fig. 31. Choosing new Google Apps user window with some users already added.|
Finally, the new Google Apps 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.
To cancel the Google Apps / 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.
It may happen that the Google Apps (G Suite) deployment wizard fails.
A failure at the step of verifying access to Google Apps API (Fig. 32.) might be caused by disabled API access in your Google Apps (G Suite). Please see Fig. 7. in Configuring Google Apps API access section of this manual.
|Fig. 32. Google Apps deployment wizard failure.|
A failure at the step of verifying Super Admin account (Fig. 33.) might be caused by a wrong domain name provided in the wizard (see Fig. 15.) or any other problems related to your Admin credentials, such as a recently expired or changed password, etc.
|Fig. 33. Google Apps deployment wizard failure.|