• Running the Directory sync in vRealize Automation 7.x fails.
• In vRealize Automation 7.x UI, you see error:

  Connector Communication failed with Response

• In the /storage/log/vmware/horizon/connector.log file of vRealize Automation, you see entries similar to:

  ERROR (tomcat-http--14) [;;] com.vmware.horizon.common.api.token.SuiteToken - No keystore file or URL specified.
  INFO (tomcat-http--14) [;;] com.vmware.horizon.common.api.token.SuiteToken - Suite token failed to initialize.
  WARN (tomcat-http--14) [3002@ESILAB;-;127.0.0.1] com.vmware.horizon.common.api.token.SuiteToken - SuiteToken revocation check failed. The SuiteTokenConfiguration.getRevokeCheckUrl was not set.
  INFO (tomcat-http--14) [3002@ESILAB;-;127.0.0.1] com.vmware.horizon.common.api.token.SuiteToken - Initializing keyStore for SuiteToken.
  ERROR (tomcat-http--14) [3002@ESILAB;-;127.0.0.1] com.vmware.horizon.common.api.token.SuiteToken - No keystore file or URL specified.
  INFO (tomcat-http--14) [3002@ESILAB;-;127.0.0.1] com.vmware.horizon.common.api.token.SuiteToken - Suite token failed to initialize.
  INFO (tomcat-http--14) [3002@ESILAB;-;127.0.0.1] com.vmware.horizon.connector.mvc.RestControllerInterceptor - Invalid suite token.

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

1. Verify the primary tenant (VSPHERE.LOCAL) config-state.json for corruption even though the issue is observed in some secondary tenants.
   
   Corruption can be confirmed  If the files is of zero size or the data is like:
   {
     "isConfigured" : false,
     "version" : 15,
     "mol" : {
       "isConfigured" : null,
       "url" : null,
       "tenantId" : null,
       "clientId" : null,
       "clientSecret" : null,
       "metaData" : null,
   ......
   
   Caution: This resolution is applicable only if config-state.json file has corrupted or become blank or reset with null values. Check all the tenants and ensure to follow this KB steps for all affected tenants.
   
   To resolve the issue:

1. Take a snapshot of the vRealize Automation Appliance.
2. SSH to vRealize Automation Appliance using root credentials.
3. Change directory to the location of the config-state.json file by running the command:
   
   cd /usr/local/horizon/conf/states/<TENANT_NAME>/<TENANT_ID>
   
   For Example: cd /usr/local/horizon/conf/states/VSPHERE.LOCAL/3001 
    
4. Back up current configuration file by running the command:
   
   mv config-state.json config-state.json.1
    
5. Copy application backup of the configuration file by running the command:
   
   cp -p config-state.json.backup_v1 config-state.json
    
6. Change the owner of the config-state.json to horizon user by running the command:
   
   chown horizon:www /usr/local/horizon/conf/states/VSPHERE.LOCAL/3001/config-state.json
    
7. Change the permission of the config-state.json file by running the command:
   
   chmod 640 /usr/local/horizon/conf/states/VSPHERE.LOCAL/3001/config-state.json
    
8. Restart vIDM/Workspace service by running the command:
   
   service horizon-workspace restart
9. If the revert of file works, backup the backup copy:

2. Connector comes up after performing the above steps but the authentication for ad user using this connector are still fail.
   The reason being the idp information might be lost as the connector was retrieved from the backup and the backup may not having the directory and idp information.
   
   in the config-state.json file, you see the entries similar to:
     "idp" : {
       "isConfigured" : false,
       "host" : null,
       "tenantId" : null,
       "id" : null,
       "name" : null,
       "cert" : null,
       "key" : null
     }
   
   To resolve this, Re-create the directory
   1. login from local tenant admin.
   2. Delete the directory.
   3. Create the directory again.
      
      This will re-configure the idp for this connector.
       
3. In case of vRA, if the tenant admin configured for ad users are unable to access the director and getting the error User is not authorized to perform the task. 
   
   When a user or a group is removed from vIDM (either by deleting the directory or simply excluded from the sync for any reason) and then re-added again, vIDM considers it a different user/group. The vRA, however, is retaining the permissions for that user/group as vRA is identifying them by different means. The result is that the user seems to have all the permissions in vRA but is not able to perform any actions in vIDM.
   
   To resolve this issue, see Tenant administrator loses permissions to manage items under Directories Management in vRealize Automation 7.x (2143798).