# Appendix 3 - Troubleshooting issues while onboarding ## Azure Policies That May Interfere With Deployment Some Azure built-in policies that may be in place in the deployment environment may interfere with successful completion of Vectra’s deployment templates. Policies that should be temporarily disabled during deployment are below: 1. **Storage accounts should have infrastructure encryption** * **Policy definition name**: AuditStorageAccountsInfrastructureEncryption * **Description**: Ensures that storage accounts have infrastructure encryption enabled, providing enhanced security. 2. **Storage accounts should prevent shared key access** * **Policy definition name**: AuditStorageAccountDisableSharedKeyAccess * **Description**: Audits if storage accounts allow shared key access, which is considered less secure than Azure AD-based authentication. 3. **Storage accounts should disable public network access** * **Policy definition name**: AuditStorageAccountsPublicNetworkAccess * **Description**: Evaluates if public network access is disabled to reduce the attack surface. Vectra has instructions for [Configuring Private Access for Azure Storage Accounts](https://docs.vectra.ai/deployment/cdr-for-azure/appendix-1-azure-configuration-notes#configuring-private-access-for-azure-storage-accounts) which will ensure that the deployment is compliant with item 3 above. If your team has concerns with disabling any of the other policies above, please contact your Vectra account team. ## Azure Template Deployment Errors This section covers errors that you may see during [automated deployment](https://docs.vectra.ai/deployment/cdr-for-azure/deployment/automated-deployment) and includes both [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment) and [remediating policies](https://app.gitbook.com/o/JzmsJ8tnfjhhOVPvs0G8/s/HJ1ltuWFvsArFWtevnRn/~/edit/~/changes/75/deployment/cdr-for-azure/deployment/automated-deployment#id-5.-remediate-policies). ### Validation failed **With "c is undefined":** If you see this message when attempting to deploy either template, it typically means that you did not select the Management Group before template validation occurred. Simply go back, select the Management Group, and try again. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-893233b165b1a3aba9662d8f3fcdd4c1b8d4960f%2Fcdr-for-azure-deployment-guide-47.png?alt=media) ### Your deployment failed **And the error details provided by Azure do not show the real failure reason:** If you see a **Your deployment failed** message and the details provided by Azure for the failure are not helpful, it may still be possible to find the real reason by looking in the Activity Log for the Management Group or Subscription. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-a18139b2a05af2276190bc5435a29e27d234d898%2Fcdr-for-azure-deployment-guide-48.png?alt=media) In this example above, the error details simply say that **The resource write operation failed to complete successfully, because it reached terminal provisioning state ‘Failed’**. This message is not very helpful. A more useful approach is to make use of Activity Logs in either (or both) Subscription Activity Logs or Management Group Activity Logs. * In the Azure portal, navigate to *Management Groups*, and choose the Subscription or Management group that you specified in the deployment. * Click on **Activity log** from the menu on the left. * Adjust the **Timespan** filter as needed to look in a time range around your deployment. * Policy template related deployments will typically have a `deployIfNotExists` policy action to look under. * In this case we can see that a previous deployment has re-used a deployment name that already exists in a different location. This is an example of a name collision during deployment. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-67ded3c0318701f9a135a4ce398fa5d228a47b24%2Fcdr-for-azure-deployment-guide-49.png?alt=media) ### Resolving Name Collisions During Deployment This error is not likely to occur for most customers who only do deployment against a single Azure region. This does not mean that you deployment does not cover other regions/locations. It only refers to the region choice that was made during [executing the main deployment](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#executing-main-deployment). The most likely scenario is that you have done a deployment to a lab that exists in one region and have now decided to do the production deployment in a different region. The screenshot above is an example of such a case that happened during policy deployment. In this case, the first time the remediation task was created in **westus** and then the second time it was created in **eastus**. This causes a name collision. The easiest solution is to remove the previous deployment. * From the Activity Log (see above), copy the duplicate name that is causing the error. * In this case it is `PolicyDeployment_9064182556784760002`. * You will see from the resource name that you need to look at the subscription level for this deployment. * In your Azure Portal, navigate to the subscription and then click into **Deployments** and search for this deployment name and **Delete** it. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-34dac70b4590dbb2730a8b754c132c86aca55bbe%2Fcdr-for-azure-deployment-guide-50.png?alt=media) * Now you should be able to retry the deployment step where this name collision occurred. ### Azure has a limit of 5 diagnostic settings for a resource. Vectra does not expect this limitation to be an issue for most customers. If you run into this issue, please contact your account team to discuss options. ## Azure Data Source Connector Potential Issues You may see a variety to status messages on your Microsoft Azure Data Source connection. A green checkmark means all is well. Other status messages may require attention. **Connection is paired and Last Seen / Last Log Received is recent.**
Last Seen: Feb 20 2020, 13:02 Last Log Received: Feb 20 2020 This condition is not an issue and is the expected state when all is well. *** **Connection has been created, but not paired:**
Edit this connection and use the Connection Setup Link to authorize Vectra to analyze your CDR for Azure logs. *** **Permissions upgrade case:**
This connection is working but its logs are degraded due to missing privileges. To fix this issue, edit this connection and use the setup link. *** **Connection is paired but not forwarding:**
There is an issue in connecting Vectra with the consent service. Please reach out to your Vectra admin or try again later.
Consent for CDR for Azure is revoked. To fix, edit this connection, copy the link use to [1. Grant Vectra Access](https://docs.vectra.ai/deployment/cdr-for-azure/automated-deployment#id-1.-grant-vectra-access), and send it to your Azure administrator.
It has been more than X minutes since this connection has been seen. Last Seen: Feb 20 2020, 13:02
It has been more than X minutes since a log has been received. Last Log Received: Feb 20 2020, 13:02
The token returned by the consent service has insufficient permissions. Please ensure that consent has been granted and try again.
There was an error during the token validation process. Please ensure that consent has been granted and try again.