> For the complete documentation index, see [llms.txt](https://docs.vectra.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vectra.ai/configuration/response/siem/migrating-from-vectra-xdr-azure-functions-to-the-vectra-rux-ccf-connector.md).

# Migrating from Vectra XDR (Azure Functions) to the Vectra RUX CCF Connector

### Why Upgrade

If you are currently running the **Vectra XDR (using Azure Functions)** integration, you are running a deprecated ingestion architecture. The Azure Function App connector was Vectra's first generation Microsoft Sentinel integration and served well as a foundation: but it has reached end-of-development. All new capabilities, improvements, and support are exclusively focused on the Codeless Connector Framework (CCF) connector.

**The Function App connector requires you to own and operate ingestion infrastructure that Microsoft now handles natively.** Every deployment requires an Azure Function App, an Application Insights instance, a Storage Account, and associated compute resources, all of which must be monitored, maintained, and kept running by your team. When something breaks, the failure surface spans Azure Functions telemetry, App Insights exceptions, Storage Account connectivity, and Function App scaling limits. Troubleshooting requires navigating all of these before you can even determine whether the issue is with Vectra or with Microsoft.

The CCF connector eliminates this entirely. Microsoft Sentinel handles all polling, transformation, and ingestion natively through Data Collection Rules. There is no Function App to maintain, no Application Insights to monitor, and no Storage Account to manage. Connector health is reported directly in Sentinel's native `SentinelHealth` table: one place, one signal.

Beyond infrastructure, the CCF connector changes how your team works with Vectra data in the Defender portal:

**Detection-centric incidents.** The legacy integration creates one incident per Vectra entity, bundling every detection for that entity into a single large incident regardless of how many distinct behaviors it represents. The CCF connector creates one incident per qualifying detection — but the threshold for what warrants an incident is the same. You are not getting more noise; you are getting a clearer signal. Each incident represents one specific behavior, with its own timeline, closure decision, and MTTI/MTTR measurement, rather than a single catch-all incident that conflates unrelated activity.

For entities with multiple active detections, the Detection Timeline workbook ties the incidents together. Analysts can see all detections associated with the same entity from a single view, understand how they relate, and navigate between them without pivoting back to the Vectra portal. The result is greater clarity about what is happening, not greater volume of work.

**A new data model.** The CCF connector uses a richer, event-based data model that captures every state change across a detection's lifetime: creation, evidence additions, context adjustments, investigation status transitions, and closure. The Detection Timeline workbook (new with this release) lets analysts trace the complete history of any detection from a single view, eliminating the need to pivot back to Vectra to understand what happened.

**Unified Defender XDR experience.** Vectra incidents appear in the same unified queue as Defender endpoint, identity, and cloud incidents. Vectra data is immediately available in Advanced Hunting alongside Defender XDR telemetry: allowing cross-platform correlation in a single KQL query without any context switching.

**No more Azure portal dependency.** After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available exclusively in the Microsoft Defender portal. Migrating now means you complete this transition on your timeline rather than under deadline pressure.

> **Deprecation notice:** The Vectra XDR (Azure Functions) integration is deprecated. Existing deployments will continue to operate, but no new features, enhancements, or support investments will be made to that integration. Plan your migration to the CCF connector.

### What's New in This Release

The Vectra RUX solution package already installed in your environment has been updated to include the new CCF components. These items appear as **Not Installed** in Content Hub alongside the components you already have. The table below describes each new component and what it does.

> **Note:** This table covers only the new additions. Your existing playbooks (Logic Apps) remain installed and the majority remain fully compatible with the CCF connector. See Components Already Installed below for the complete list.

#### New Components to Install

<table><thead><tr><th width="340">Component</th><th width="130">Type</th><th>Description</th></tr></thead><tbody><tr><td><strong>Vectra RUX Security Data Connector (via Codeless Connector Framework)</strong></td><td>Data Connector</td><td>The new CCF-based connector that replaces the Azure Function App. Polls the Vectra RUX API natively through Microsoft Sentinel with no customer-managed compute required. Configures three independent data streams: Detections, Entities, and Lockdown.</td></tr><tr><td><strong>Vectra RUX - Create Incident for Escalated Host Detection or Unresolved Priority Host</strong></td><td>Analytics Rule</td><td>New analytics rule that creates one incident per host detection that is escalated or unresolved priority. Replaces the legacy entity-level rule with a detection-centric model and correct host entity mapping.</td></tr><tr><td><strong>Vectra RUX - Create Incident for Escalated Account Detection or Unresolved Priority Account</strong></td><td>Analytics Rule</td><td>Same as above for account detections. Two separate rules are required to ensure correct entity mapping, hosts map to hostname, accounts map to username/UPN.</td></tr><tr><td><strong>VectraRUXSecurityDashboard</strong></td><td>Workbook</td><td>Updated security operations dashboard covering entity priority and scoring, detection activity, MITRE ATT&#x26;CK mappings, data source classification, lockdown state, and entity-to-detection drilldowns with deep links into Vectra.</td></tr><tr><td><strong>VectraRUX Detection Timeline</strong></td><td>Workbook</td><td>New SOC investigation workbook showing the complete event history of an individual Vectra detection: every evidence addition, context change, investigation status update, and closure event. Designed for use from within a Sentinel incident.</td></tr><tr><td><strong>VectraDetectionTimelineLink</strong></td><td>Playbook</td><td>Automatically posts a comment on each new Sentinel incident with a direct link to the Detection Timeline workbook pre-filtered to the relevant detection ID. Attach to an automation rule triggered on incident creation.</td></tr><tr><td><strong>VectraCloseDetectionsOnIncidentClose</strong></td><td>Playbook</td><td>Automatically closes the associated Vectra detection when a Sentinel incident is closed. Maps the Sentinel closure classification to the appropriate Vectra reason (True Positive → Remediated; all others → Benign). Attach to an automation rule triggered on incident close.</td></tr><tr><td><strong>VectraSetDetectionStatus</strong></td><td>Playbook</td><td>Automatically acknowledges or closes detections based on Sentinel incident status. Closes with mapped reason on incident close; sets acknowledged on incident active. Designed for automation rule triggers at both Active and Closed status transitions.</td></tr><tr><td><strong>VectraAddNoteToDetections</strong></td><td>Playbook</td><td>Adds a note to all detections associated with a Vectra entity. Supports both structured incident comment input and a Microsoft Teams Adaptive Card fallback.</td></tr><tr><td><strong>VectraAddTagToDetections</strong></td><td>Playbook</td><td>Adds tags to all active detections associated with a Vectra entity. Preserves existing tags. Supports incident comment and Teams input.</td></tr><tr><td><strong>VectraDownloadPcapFileToStorage</strong></td><td>Playbook</td><td>Retrieves PCAP files for specified detections from the Vectra platform and uploads them to an Azure Storage Account. Requires a Storage Account with a file share matching the account name.</td></tr><tr><td><strong>Parser for VectraDetectionsCombined (Azure Function + CCF)</strong></td><td>Parser</td><td>Combined parser that joins data from both the legacy <code>Detections_Data_CL</code> table and the new <code>Detections_Data_CCF_CL</code> table. Provides continuity across the migration period so workbooks and queries reflect both old and new data.</td></tr><tr><td><strong>Parser for VectraEntities</strong></td><td>Parser</td><td>Parser for the new CCF entity table <code>Entities_Data_CCF_CL</code>. Provides normalized field access for entity scoring, prioritization, assignment state, and metadata.</td></tr></tbody></table>

#### Components Already Installed

The following playbooks were installed with the legacy integration and **remain compatible** with the CCF connector. You do not need to reinstall them. They operate against Vectra entity data extracted from the incident regardless of which connector ingested the underlying data.

`VectraGenerateAccessToken` · `VectraCloseDetections` · `VectraOpenClosedDetections` · `VectraAddNoteToEntity` · `VectraAddTagToEntity` · `VectraAddTagToEntityAllDetections` · `VectraAddTagToEntitySelectedDetections` · `VectraAssignStaticUserToEntity` · `VectraAssignDynamicUserToEntity` · `VectraStaticAssignMemberToGroup` · `VectraDynamicAssignMemberToGroup` · `VectraIncidentTimelineUpdate`

> **Note:** `VectraIncidentTimelineUpdate` is not compatible with Sentinel workspaces connected to Microsoft Defender XDR. If your workspace is connected to the Defender portal, this playbook should not be used. `VectraDetectionTimelineLink` (new with this release) is the Defender XDR-compatible replacement for incident timeline enrichment.

### Migration Steps

#### Step 1: Collect the Detections Checkpoint Value

Before stopping the Function App, capture the highest detection event ID that has already been ingested. The new CCF connector will use this as its starting point, ensuring no detection events are missed or duplicated in the transition.

1. In the Defender portal, go to **Investigation & response** > **Hunting** > **Advanced hunting**.
2. Run the following query:

```kql
Detections_Data_CL
| summarize checkpoint = max(id)
```

3. Record the returned value. You will enter this as the **Detections Starting Checkpoint** when configuring the new data connector in Step 4.

> **Important:** Run this query while the Function App is still running so you capture the most recent event ID. Do not stop the Function App before completing this step.

#### Step 2: Stop the Azure Function App Functions

The Azure Function App contains several individual functions. Stop the Security Operations data functions at minimum. Optionally, if your organization is not currently using **Vectra Audit** or **Vectra Health** data in Sentinel, the entire Function App can be stopped.

**Minimum: stop these five functions:**

| Function          | Data It Ingests                  |
| ----------------- | -------------------------------- |
| `AccountEntities` | Account entity scoring and state |
| `Detections`      | Detection events                 |
| `EntityScoring`   | Host entity scoring and state    |
| `HostEntities`    | Host entity metadata             |
| `Lockdown`        | Entity lockdown records          |

These are the data sets that the new CCF connector will take over. Stopping them prevents duplicate ingestion into the legacy tables while the new connector begins populating the CCF tables.

**Optional: stop the entire Function App:**

If you are not actively using `VectraAudit` or `VectraHealth` data in Sentinel dashboards, rules, or queries, the entire Function App can be stopped rather than stopping individual functions. A future CCF-based operations connector will replace Audit and Health ingestion: that integration is currently in development.

**Steps to stop functions:**

1. Open the [Azure portal](https://portal.azure.com/).
2. Navigate to **Function Apps** and select your Vectra Function App.
3. Select **Functions** from the left menu.
4. Select each function listed above and select **Disable**.
5. Alternatively, to stop the entire Function App, return to the Function App overview and select **Stop**.

#### Step 3: Update the Solution in Content Hub

Since the new components are bundled into the existing Vectra RUX solution package, install them by updating the solution in Content Hub.

1. In the Defender portal, go to **Microsoft Sentinel** > **Content management** > **Content hub**.
2. Locate the **Vectra RUX** solution (shown as **Installed** with **Updates** available).
3. Select the solution and choose **Update** (or **Manage** → select all new components → **Install selected**).
4. Review what will be installed and confirm.

This installs the new data connector, parsers, workbooks, analytics rule templates, and playbooks listed in the New Components section above.

#### Step 4: Configure the New Data Connector

1. In the Defender portal, go to **Microsoft Sentinel** > **Configuration** > **Data connectors**.
2. Search for **Vectra RUX Security Data Connector** and select **Open connector page**.
3. Under **Configuration**, add three connections: one per data stream. Create dedicated API client credentials in Vectra for each stream (Configuration → Access → API Clients, Security Analyst role).

> **Important:** Wait at least one minute between adding each connection to avoid OAuth2 API rate limiting.

**Detections stream: enter the checkpoint value from Step 1:**

| Field                          | Value                                       |
| ------------------------------ | ------------------------------------------- |
| Connection Alias               | `CCF-Detections` (or your preferred naming) |
| Vectra API Base URL            | `https://<your-brain>.portal.vectra.ai`     |
| Client ID                      | Client ID from your Vectra API client       |
| Client Secret                  | Client Secret from your Vectra API client   |
| Data Stream                    | Detections                                  |
| Detections Starting Checkpoint | The `checkpoint` value recorded in Step 1   |

**Entities stream:**

| Field               | Value                                   |
| ------------------- | --------------------------------------- |
| Connection Alias    | `CCF-Entities`                          |
| Vectra API Base URL | `https://<your-brain>.portal.vectra.ai` |
| Client ID / Secret  | Separate API client credentials         |
| Data Stream         | Entities                                |

**Lockdown stream:**

| Field               | Value                                   |
| ------------------- | --------------------------------------- |
| Connection Alias    | `CCF-Lockdown`                          |
| Vectra API Base URL | `https://<your-brain>.portal.vectra.ai` |
| Client ID / Secret  | Separate API client credentials         |
| Data Stream         | Lockdown                                |

After 10–15 minutes, verify ingestion using Advanced Hunting:

```kql
Detections_Data_CCF_CL | take 10
Entities_Data_CCF_CL   | take 10
Lockdown_Data_CCF_CL   | take 10
```

#### Step 5: Disable Legacy Analytics Rules, Enable New Rules

The legacy integration used entity-level analytics rules that created one incident per Vectra entity. The new CCF connector uses detection-level rules that create one incident per detection. Both sets of rules should not be active simultaneously.

**Disable legacy rules:**

1. In the Defender portal, go to **Microsoft Sentinel** > **Configuration** > **Analytics**.
2. Search for your existing Vectra analytics rules (typically named with the legacy **Vectra XDR** prefix).
3. Select each rule and **Disable** it.

**Enable new CCF rules:**

1. Select the **Rule templates** tab.
2. Search for `Vectra RUX`.
3. Select each of the two Vectra RUX rule templates and click **Create rule**.
4. Review the configuration and enable each rule.

| Rule                                                                                        | Purpose                                                |
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| Vectra RUX - Create Incident for Escalated Host Detection or Unresolved Priority Host       | Incidents for prioritized/escalated host detections    |
| Vectra RUX - Create Incident for Escalated Account Detection or Unresolved Priority Account | Incidents for prioritized/escalated account detections |

#### Step 6: Save Workbooks

Save both workbooks to My Workbooks before deploying the new playbooks. The `VectraDetectionTimelineLink` playbook requires the `VectraRUXDetectionTimeline` workbook to already be saved — it retrieves the workbook's ARM resource ID during configuration and will fail if the workbook does not exist as a saved resource.

1. In the Defender portal, go to **Microsoft Sentinel** > **Threat management** > **Workbooks**.
2. Select the **Templates** tab.
3. Search for `VectraRUXSecurityDashboard`, open it, and select **Save** to add it to My Workbooks.
4. Repeat for `VectraRUXDetectionTimeline`.

Once saved, you can retrieve the workbook's resource ID for use during playbook configuration using Azure Resource Graph:

```bash
az graph query -q "resources | where type =~ 'microsoft.insights/workbooks' | where resourceGroup =~ '<your-resource-group>' | project DisplayName=tostring(properties.displayName), ResourceId=id" --query "data[].{DisplayName:DisplayName, ResourceId:ResourceId}" -o table
```

> **Note:** Workbooks installed from Content Hub are templates and do not appear as ARM resources until saved. If the query returns no results, confirm the workbook has been saved (not just installed as a template).

#### Step 7: Install and Configure New Playbooks

Complete the installation of the new playbooks by authorizing their API connections and granting Key Vault access. These steps are required for every newly deployed Logic App.

For each new playbook (`VectraDetectionTimelineLink`, `VectraCloseDetectionsOnIncidentClose`, `VectraSetDetectionStatus`, `VectraAddNoteToDetections`, `VectraAddTagToDetections`, `VectraDownloadPcapFileToStorage`):

1. Open the Logic App in the Azure portal.
2. Navigate to **Development Tools** > **API Connections** and authorize each connection.
3. Navigate to **Settings** > **Identity**, copy the **Object (principal) ID**.
4. Open your Azure Key Vault, go to **Settings** > **Access Policies**, and create a new policy granting this identity All Key and All Secret permissions.

The following playbooks also require the **Microsoft Sentinel Contributor** role assigned to their managed identity at the Log Analytics workspace:

* `VectraDetectionTimelineLink`
* `VectraCloseDetectionsOnIncidentClose`
* `VectraSetDetectionStatus`

To assign the role: **Log Analytics Workspaces** > select workspace > **Access control (IAM)** > **Add role assignment** > search **Microsoft Sentinel Contributor** > assign to the Logic App managed identity.

Full deployment instructions for all playbooks are available in the [Vectra RUX Playbooks for Microsoft Sentinel CCF](https://docs.vectra.ai/configuration/response/siem/vectra-rux-playbooks-for-microsoft-sentinel-ccf) guide.

#### Step 8: Set Up Automation Rules

Attach the new playbooks to automation rules to enable automated incident lifecycle management.

1. In the Defender portal, go to **Microsoft Sentinel** > **Configuration** > **Automation**.
2. Create automation rules for the following:

| Trigger          | Condition                             | Playbook                               | Purpose                                                 |
| ---------------- | ------------------------------------- | -------------------------------------- | ------------------------------------------------------- |
| Incident created | Applies to Vectra RUX analytics rules | `VectraDetectionTimelineLink`          | Posts Detection Timeline link as incident comment       |
| Incident updated | Status changed to Active              | `VectraAssignStaticUserToEntity`       | Assigns entity in Vectra: starts MTTI timer (run first) |
| Incident updated | Status changed to Active              | `VectraSetDetectionStatus`             | Acknowledges detections in Vectra (run second)          |
| Incident updated | Status changed to Closed              | `VectraCloseDetectionsOnIncidentClose` | Closes detections in Vectra with mapped reason          |

> **Note:** Rule execution order matters. Configure `VectraAssignStaticUserToEntity` to execute before `VectraSetDetectionStatus` in the Active trigger so that assignment is recorded before acknowledgment state is written: this preserves accurate MTTI timestamps.

### Managing the Incident Transition Period

After enabling the new CCF analytics rules, the following situation will exist temporarily:

**Open incidents from the legacy integration** will remain open in the unified incident queue. These incidents were created under the entity-centric model, one incident per Vectra entity: and will no longer receive new alert updates once the legacy Function App functions are stopped. They will not be automatically closed.

**New incidents from the CCF integration** will begin appearing alongside the old ones: one incident per detection, reflecting the new detection-centric model. For the same Vectra entity, you may see both an old entity-level incident and new detection-level incidents open at the same time. This is expected.

**How to handle the overlap:**

There are two valid approaches depending on your team's preference:

1. **Work from the new incident.** The new detection-centric incident contains richer, more current data and is linked to the Detection Timeline workbook. Investigate and close it normally. Once the new incident is closed, close the corresponding legacy entity-level incident as a duplicate.
2. **Work from the existing incident.** If the legacy incident is already actively being worked, continue to closure there. Once it is closed, close any new CCF incident covering the same entity and detection as a duplicate.

There is no data loss risk: both the legacy `Detections_Data_CL` table and the new `Detections_Data_CCF_CL` table remain available in Advanced Hunting throughout the transition. The `VectraDetectionsCombined` parser (installed as part of this migration) joins both tables so that workbooks show a continuous historical view across the cutover.

Once the backlog of legacy incidents is cleared, only the new detection-centric format will be active and the transition period ends.

### Post-Migration Validation

Run these queries in Advanced Hunting to confirm the migration completed successfully:

**Verify new data is flowing:**

```kql
Detections_Data_CCF_CL
| where TimeGenerated > ago(30m)
| summarize count() by bin(TimeGenerated, 5m)
```

**Confirm checkpoint continuity: no gap at cutover:**

```kql
union Detections_Data_CL, Detections_Data_CCF_CL
| summarize min_id = min(id), max_id = max(id), count = count() by Type
| order by Type asc
```

**Verify connector health:**

```kql
SentinelHealth
| where TimeGenerated > ago(1h)
| where SentinelResourceType == "Data connector"
| extend DestinationTable = tostring(ExtendedProperties.DestinationTable)
| where DestinationTable in (
    "Detections_Data_CCF_CL",
    "Entities_Data_CCF_CL",
    "Lockdown_Data_CCF_CL"
  )
| project TimeGenerated, DestinationTable, Status, Description
| order by TimeGenerated desc
```

### Next Steps

With the migration complete, follow the [Vectra RUX Best Practices for Microsoft Sentinel CCF](https://docs.vectra.ai/configuration/response/siem/vectra-rux-best-practices-for-microsoft-sentinel-ccf) guide to operationalize the integration: including recommended automation rule sequencing, MTTI/MTTR metric capture, parser usage guidance, and SOC workflow recommendations for the full detection-to-closure lifecycle.

For complete connector configuration reference, see the [Microsoft Defender XDR Codeless Connector Framework (RUX)](https://docs.vectra.ai/configuration/response/siem/microsoft-defender-xdr-codeless-connector-framework-rux) guide.

For playbook deployment and configuration details, see the [Vectra RUX Playbooks for Microsoft Sentinel CCF](https://docs.vectra.ai/configuration/response/siem/vectra-rux-playbooks-for-microsoft-sentinel-ccf) guide.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.vectra.ai/configuration/response/siem/migrating-from-vectra-xdr-azure-functions-to-the-vectra-rux-ccf-connector.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.