Documentation

Set up Google Workspace archiving & backup

As a prerequisite for MailVault to collect email, an administrator user needs to configure some settings in the organization’s Google Workspace account.

1. Create a Google API Console Project

1. Login to the Google Developers Console.
2. If prompted, login using a Google Account with administrative rights.
3. From the Project drop-down menu click Create a project.
   
4. Add a project name, e.g. MailVault Access and click Create.
   
5. From Menu APIs and Services, select Dashboard tab, click on ENABLE APIs AND SERVICES.
6. In the section API Library, enable Admin SDK, Gmail API, Google People API, Contacts API, Google Drive API, Google Calendar API.
7. If the APIs and the services page isn’t already open, open the console left side menu and select APIs & services, and then select Library.
8. Click the API you want to enable. If you need help finding the API, use the search field. Click ENABLE.
9. From the Credentials tab, click on Create credentials and select Service account from the drop-down list.
10. Under Service account details, enter a Service account name in the text box, Enter description and click on Create.
11. Under Grant this service account access to project select the role as Basic > Owner. Click on Continue. Click on Done.
12. Under Credentials tab, Service Accounts, click on Manage service accounts.
13. Under Actions, click on the drop-down menu, in the right corner of the service account created select Manage keys, click on Add key and select Create key.
14. Select the Key type P12 radio button and click on Create. The P12 file will now get downloaded on your system.
15. Submit the P12 file (e.g. MailVault Access-e035d2ad4f35.p12) to the MailVault registration form.
16. Close the Service account created dialogue box. MailVault Server does not require the private key password (i.e. notasecret).
17. Again under Actions, click on the drop-down menu, in the right corner of the service account created and select Edit.
18. Under the Service account status, click on the SHOW DOMAIN-WIDE DELEGATION dropdown and click on Enable G Suite Domain-wide Delegation check box.
19. If requested, enter MailVault as Product name for the consent screen and Click on Save.
20. Again under Actions, click on the drop-down menu, in the right corner of the service account created and select Edit.
21. Under the Service account status, click on the SHOW DOMAIN-WIDE DELEGATION dropdown. Note down the client ID/Unique ID and the email address shown under Service account details for use in the next step.

2. Grant access to the required APIs

1. Login to your Google Apps domain’s Admin console.
2. Select Security from the list of controls. If you don't see Security listed, select More controls from the gray bar at the bottom of the page, then select Security from the list of controls. If you can't see the controls, make sure you're signed in as an administrator for the domain.
3. Select API controls from the list of options.
   
4. Under Domain wide delegation, click on MANAGE DOMAIN WIDE DELEGATION, click on Add new.
   1. Note: This section may not be visible if you are not authorized. Please log in as “Super Admin”
5. In the Client ID text box enter the service account's Client ID noted down earlier (e.g. 123458593494909748351).
6. In the OAuth Scopes (comma-delimited) field enter the following scopes:
   1. https://mail.google.com
      
   2. https://www.googleapis.com/auth/admin.directory.user
   3. https://www.googleapis.com/auth/contacts.readonly 
   4. https://www.googleapis.com/auth/contacts 
      
   5. https://www.google.com/m8/feeds 
      
   6. https://www.googleapis.com/auth/calendar  
      
   7. https://www.googleapis.com/auth/drive
7. Click Authorize.

MailVault can now archive email from your Google Workspace account.

Note: Invalid_grant error has two common causes.

1. Your server’s clock is not in sync with NTP.

Solution: check the server time if its incorrect fix it.

2. The refresh token limit has been exceeded.

Applications can request multiple refresh tokens. For example, this is useful in situations where a user wants to install an application on multiple machines. In this case, two refresh tokens are required, one for each installation. When the number of refresh tokens exceeds the limit, older tokens become invalid. If the application attempts to use an invalidated refresh token, an invalid_grant error response is returned. The limit for each unique pair of OAuth 2.0 client and is 25 refresh tokens (note that this limit is subject to change). If the application continues to request refresh tokens for the same Client/Account pair, once the 26th token is issued, the 1st refresh token that was previously issued will become invalid. The 27th requested refresh token would invalidate the 2nd previously issued token and so on.