Microsoft Sentinel

Microsoft Azure SIEM

Synopsis

Creates a target that ingests log messages into Microsoft Sentinel workspace tables using Data Collection Rules (DCRs). Supports automatic table selection, field normalization, and filtering options.

tip

For more details on Microsoft Sentinel integration, refer to Microsoft Sentinel Overview and Microsoft Sentinel Integration. For Director Proxy deployment, see VirtualMetric Director Proxy. For cost-optimized ingestion with extended retention, see Microsoft Sentinel data lake.

Schema

- name: <string>
  description: <string>
  type: sentinel
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    tenant_id: <string>
    client_id: <string>
    client_secret: <string>
    function_app: <string>
    function_token: <string>
    rule_id: <string>
    endpoint: <string>
    streams:
      - name: <string>
        rule_id: <string>
    stream: <string[]>
    buffer_size: <numeric>
    batch_size: <numeric>
    keep_phantom_fields: <boolean>
    drop_unknown_stream_events: <boolean>
    cache:
      timeout: <numeric>
    field_format: <string>
    detection_rules:
      - name: <string>
        query: <string>
        language: <string>
    unmatched_tables: <enum>
    debug:
      status: <boolean>
      dont_send_logs: <boolean>

Configuration

The following fields are used to define the target:

Core Settings

Field	Required	Default	Description
name	Y		Target name
description	N	-	Optional description
type	Y		Must be sentinel
pipelines	N	-	Optional post-processor pipelines
status	N	true	Enable/disable the target

Authentication

Field	Required	Default	Description
tenant_id	N*	-	Azure tenant ID (required for direct authentication)
client_id	N*	-	Azure client ID (required for direct authentication)
client_secret	N*	-	Client secret (required for direct authentication)
function_app	N*	-	Director Proxy endpoint URL (required for proxy forwarding)
function_token	N*	-	Director Proxy authentication token (required with function_app)

* = Conditionally required. Use either direct authentication (tenant_id, client_id, client_secret) OR Director Proxy forwarding (function_app, function_token), OR omit all credentials to use Managed Identity.

Managed Identity Authentication

Azure targets support Managed Identity authentication for credential-free access when Director is deployed on Azure infrastructure.

How it works: When tenant_id, client_id, and client_secret are omitted from the configuration, the target automatically uses Azure's DefaultAzureCredential, which attempts authentication in the following order:

1. Environment variables (AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET)
2. Workload Identity (for Kubernetes deployments)
3. Managed Identity (system-assigned or user-assigned)
4. Azure CLI credentials
5. Azure PowerShell credentials

Deployment requirement: Director must run on Azure infrastructure that supports Managed Identity:

• Azure Virtual Machines
• Azure App Service
• Azure Container Instances
• Azure Kubernetes Service (AKS)
• Azure Functions

Required permissions: The Managed Identity must be granted the appropriate Azure RBAC roles documented in each target's IAM Permissions section.

note

Managed Identity eliminates credential management overhead and is the recommended authentication method for Azure-hosted Director deployments.

Stream Configuration

Field	Required	Default	Description
endpoint	Y		DCE Address or DCE Resource ID
rule_id	N		Default Data Collection Rule (DCR) ID
streams	N	-	Detailed stream configurations
stream	N	-	Legacy string array of stream names
buffer_size	N	1048576	Encoding buffer size in bytes (1MB), applied per destination stream
batch_size	N	1000	Maximum messages per batch, counted per destination stream. Must be greater than 0
keep_phantom_fields	N	false	Keep fields not defined in DCR schema
drop_unknown_stream_events	N	true	Silently drop events for undefined streams
cache.timeout	N	300	Stream cache timeout in seconds
field_format	N	-	Data normalization format. See applicable Normalization section

Detection Rules

A detection rule set assigned to this target turns its smart pipeline on: the target compiles the set with the Smart Engine processor and ships only the events those detections could need, field- and value-reduced.

In the web interface these entries are written for you — assign rules from Content Management > Detections, or from this target's own Detection Rules step and tab, and the assignment is regenerated on every configuration update. See Detections.

Field	Required	Default	Description
detection_rules	N	-	Detection rules to reduce against. Omit, or leave empty, to ship everything the pipelines produce
detection_rules[].name	Y		Rule name, used to report which detections matched
detection_rules[].query	Y		The rule's full source, inline. Not a reference to a rule stored elsewhere
detection_rules[].language	N	kql	Rule language: kql or yaral
unmatched_tables	N	keep	What to do with an event no assigned detection is scoped to: keep or drop

An entry missing either name or query is skipped, and the skipped count is reported in the debug log. If every entry is skipped the smart pipeline does not run at all, which ships everything rather than nothing — reduction fails open throughout.

unmatched_tables accepts keep and drop case-insensitively. Any other value is treated as keep and reported as a warning, so a typo is visible rather than a silent no-op.

warning

drop discards every event that no assigned detection is scoped to. A detection scoped to a table only applies to events that declare that table, so events with no declared table are never matched by a table-scoped rule and are governed entirely by this setting. Vet the assigned rule set against your traffic before switching it.

Scheduling

warning

Unlike most target types, sentinel does not flush once per notification when left unconfigured. With neither interval nor cron set it flushes every 30 seconds.

See Scheduling and Pool Behavior for the interval, cron and max_items fields shared by all targets, and for how to override or opt out of this default.

Debug Options

Field	Required	Default	Description
debug.status	N	false	Enable debug logging
debug.dont_send_logs	N	false	Process logs but don't send to target (testing)

Automatic Table Selection

When streams is not specified, tables are automatically selected based on input type:

Input Type	Target Table
Windows Event Log	Custom-WindowsEvent
Windows Application Log	Custom-WindowsEvent
Windows System Log	Custom-WindowsEvent
Windows Security Log	Custom-SecurityEvent
Syslog	Custom-Syslog
Linux Audit Report	Custom-CommonSecurityLog
Windows Audit Report	Custom-CommonSecurityLog

Available Tables

Standard Tables (Prefix: Custom-)

WindowsEvent SecurityEvent CommonSecurityLog Syslog

ASim Tables (Prefix: Custom- or Microsoft-)

ASimAuditEventLogs ASimAuthenticationEventLogs ASimDhcpEventLogs ASimDnsActivityLogs ASimFileEventLogs ASimNetworkSessionLogs ASimProcessEventLogs ASimRegistryEventLogs ASimUserManagementActivityLogs ASimWebSessionLogs

Details

The Microsoft Sentinel target enables direct ingestion into Microsoft Sentinel tables with flexible configuration options. It supports using the SystemS3 field to route messages to specific stream tables, using the format Custom-TableName.

Deployment Models

The target supports two deployment models:

Direct Authentication - Director connects directly to Azure using service principal credentials (tenant_id, client_id, client_secret). This model requires Director to have network connectivity to Azure endpoints and credentials for the target subscription.

Director Proxy Forwarding - Director sends processed data to VirtualMetric Director Proxy (Azure Function) deployed in customer environment. Director Proxy uses Azure Managed Identity for credential-free access to Microsoft Sentinel, eliminating the need to share Azure credentials with Director.

The Director Proxy model is particularly valuable for MSSP deployments where customers maintain complete control over Azure credentials while enabling centralized data processing and routing by the MSSP's Director infrastructure.

IAM Permissions

When using Service Principal or Managed Identity authentication, the following Azure roles are required for runtime data ingestion:

Azure Role	Scope	Purpose
Monitoring Metrics Publisher	Data Collection Rule	Send data via DCR ingestion API
Monitoring Reader	Resource Group	List DCEs and DCRs for stream auto-discovery

If you prefer not to grant read access on the whole resource group, Monitoring Reader can be assigned per resource instead. Both models are supported, and the same applies to the managed identity of a Director Proxy:

Azure Role	Scope	Purpose
Monitoring Reader	Data Collection Endpoint	Read the DCE and find the DCRs linked to it
Monitoring Reader	Each Data Collection Rule	Read the DCR's stream and table declarations
Monitoring Metrics Publisher	Each Data Collection Rule	Send data via DCR ingestion API

note

The VirtualMetric solution installed from the Microsoft Sentinel Content Hub creates one DCE and two DCRs: one for the standard tables such as Syslog and CommonSecurityLog, and one for the ASIM tables. With per-resource assignments, both DCRs need Monitoring Reader and Monitoring Metrics Publisher. A DCR that is missing a role is left out of discovery and only its tables fail. See the Troubleshooting section below.

If the setup functions (DCE/DCR/table creation) are used, additional roles are required:

Azure Role	Scope	Purpose
Monitoring Contributor	Resource Group	Create and update DCEs and DCRs
Log Analytics Contributor	Log Analytics Workspace	Create and update custom log tables

The target automatically detects table schemas and can clean messages to remove phantom fields that aren't defined in the schema when keep_phantom_fields is set to false.

warning

Disabling keep_phantom_fields may result in data loss for undefined fields.

Data is buffered per destination stream until batch_size records or buffer_size bytes are reached for that stream, or the flush schedule fires. Whichever limit binds first triggers the upload; the record that would have exceeded it rides the next one rather than being dropped. Because both limits are per stream, a target fanning out to several streams accumulates up to that much for each of them before a flush. Each stream type also has its own ceiling in the Log Analytics ingestion API.

warning

Enabling drop_unknown_stream_events silently discards unmatched events.

Field Normalization

The field_format property allows normalizing log data to standard formats:

• csl - Common Security Log
• asim - Advanced Security Information Model

Field normalization is applied before the logs are sent to Sentinel, ensuring consistent indexing and search capabilities.

Preconfigured Schemas

The target includes built-in schema definitions for standard tables like:

• Syslog
• Common Security Log
• Security Event
• Windows Event
• ASim tables (various types)

These predefined schemas ensure proper column mapping and validation when sending data to Sentinel.

warning

Large buffer sizes or batch sizes increase memory usage, and both are allocated per destination stream — a target writing to many streams multiplies the cost.

Autodiscovery

Director provides an autodiscovery feature that automatically configures Data Collection Rules and their associated streams.

The required permissions are:

• For Data Collection Rules

  Role	Scope
  Monitoring Metrics Publisher	Each DCR with name starting with vmetric

• For Resource Groups

  Role	Scope
  Monitoring Reader	Resource Group containing your DCE

As an alternative to the resource group, Monitoring Reader can be assigned on the DCE and on each DCR individually. Both models are described under IAM Permissions above.

warning

Assign the Monitoring Reader role at the Resource Group level or on the individual DCE and DCRs, never at the Subscription level.

The feature uses Resource IDs to discover DCRs and their configurations. It then automatically detects table schemas and validates fields, and prevents phantom fields through schema validation.

Autodiscovery adapts to environment changes automatically.

Examples

Basic

Configuration using Resource ID-based autodiscovery:

targets:
  - name: auto_sentinel
    type: sentinel
    properties:
      tenant_id: "00000000-0000-0000-0000-000000000000"
      client_id: "00000000-0000-0000-0000-000000000000"
      client_secret: "your-client-secret"
      endpoint: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Insights/dataCollectionEndpoints/myDCE"

Managed Identity

Using Managed Identity Authentication instead of App Registration:

targets:
  - name: managed_identity_sentinel
    type: sentinel
    properties:
      endpoint: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Insights/dataCollectionEndpoints/myDCE"

Director Proxy

Configuration using Director Proxy for credential-free forwarding:

targets:
  - name: proxy_sentinel
    type: sentinel
    properties:
      function_app: "https://my-director-proxy.azurewebsites.net/api/Sentinel"
      function_token: "your-proxy-authentication-token"
      endpoint: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Insights/dataCollectionEndpoints/myDCE"

Filtered

Using specific stream filtering and custom cache timeout:

targets:
  - name: filtered_autodiscovery
    type: sentinel
    properties:
      tenant_id: "00000000-0000-0000-0000-000000000000"
      client_id: "00000000-0000-0000-0000-000000000000"
      client_secret: "your-client-secret"
      endpoint: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Insights/dataCollectionEndpoints/myDCE"
      streams:
        - name: "Custom-WindowsEvent"
        - name: "Custom-SecurityEvent"
      cache:
        timeout: 300  # 5 minutes
      keep_phantom_fields: false
      drop_unknown_stream_events: true

High-Volume

Optimization for high-volume ingestion:

targets:
  - name: optimized_sentinel
    type: sentinel
    pipelines:
      - normalization
    properties:
      tenant_id: "00000000-0000-0000-0000-000000000000"
      client_id: "00000000-0000-0000-0000-000000000000"
      client_secret: "your-client-secret"
      endpoint: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Insights/dataCollectionEndpoints/myDCE"
      batch_size: 5000
      field_format: "asim"
      streams:
        - name: "Custom-ASimProcessEventLogs"
        - name: "Custom-ASimNetworkSessionLogs"

With Debugging

Configuration with debug options:

targets:
  - name: debug_sentinel
    type: sentinel
    properties:
      tenant_id: "00000000-0000-0000-0000-000000000000"
      client_id: "00000000-0000-0000-0000-000000000000"
      client_secret: "your-client-secret"
      endpoint: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Insights/dataCollectionEndpoints/myDCE"
      debug:
        status: true
        dont_send_logs: true  # Test mode that doesn't actually upload

Troubleshooting

This section covers the errors you are most likely to see with the sentinel target, what causes each one, and how to fix it. Everything here applies to the sentineldatalake target as well, because it authenticates, discovers streams, and uploads in exactly the same way.

Where to look:

• Director logs. Target errors are tagged with the target name and carry "Section":"SenderPool". The part after Reason: or after the last colon is the actual cause. See Target Delivery Errors for the message shapes every target shares and how Director retries them.
• The target's connection status in the web interface. It shows the same reason as the log line, prefixed with connection failed for <target name>:.

Which permission is missing?

Match the error you see against this table first. The role that is missing depends on how the target is configured.

Error text	Missing role	Scope
failed to list DCEs: ... RESPONSE 403 ... AuthorizationFailed ... 'Microsoft.Insights/dataCollectionEndpoints/read'	Monitoring Reader	The resource group that contains the DCE and its DCRs, or the DCE itself when assigning per resource
failed to list DCRs: ... RESPONSE 403 ... AuthorizationFailed ... 'Microsoft.Insights/dataCollectionRules/read'	Monitoring Reader	The resource group that contains the DCE and its DCRs, or each DCR when assigning per resource
Finalize failed on flush ... RESPONSE 403 ... OperationFailed ... does not have access to ingest data for the data collection rule with immutable Id 'dcr-...'	Monitoring Metrics Publisher	Each DCR the target sends to

The two read errors only occur in autodiscovery mode, that is when endpoint is a DCE Resource ID starting with /subscriptions/. In that mode Director reads the DCE and the DCRs linked to it, so Monitoring Reader is needed either on the resource group that contains them, or on the DCE and on every DCR. A role on the DCE alone is not enough, because the DCRs must be readable too. Director Proxy collects streams the same way, so the same scopes apply to its managed identity.

If you configure streams with a rule_id for each entry and set endpoint to the DCE logs ingestion URL (https://...ingest.monitor.azure.com), Director never calls the Azure management API. Only Monitoring Metrics Publisher on the DCRs is required, and Monitoring Reader can be omitted entirely.

No role is needed on the DCE itself for ingestion. Azure checks the ingestion permission on the DCR, and the DCR must be linked to the DCE.

note

Azure RBAC changes can take up to 30 minutes to propagate. Director retries automatically, so no restart is needed once the role is assigned.

What does "Failed to reinitialize target ... (attempt N)" mean?

[Error] [director] [target-<target id>] [auto_sentinel] Failed to reinitialize target "auto_sentinel" (attempt 70). Reason: Please provide at least one stream configuration

The target could not start, and Director is retrying. Retries back off from 5 seconds up to once per minute and continue until the target initializes, so the attempt counter grows for as long as the underlying problem persists. A high attempt count is not a separate fault. It only means the cause in Reason: has been present for a long time.

While the target is failing, nothing is sent to Sentinel. Incoming data waits in the Director queue and is delivered once the target recovers. Queued data is kept for queue.limit seconds (48 hours by default), and with the In-memory storage tier it does not survive a Director restart, so resolve long outages within that window. See Persistent Storage. Fix the reason shown and the next attempt picks it up. Restarting Director is not required.

"failed to list DCEs" or "failed to list DCRs" with RESPONSE 403 AuthorizationFailed

Reason: failed to list DCEs: GET https://management.azure.com/subscriptions/.../resourcegroups/myResourceGroup/providers/Microsoft.Insights/dataCollectionEndpoints
RESPONSE 403: 403 Forbidden
ERROR CODE: AuthorizationFailed
The client '<client id>' with object id '<object id>' does not have authorization to perform action 'Microsoft.Insights/dataCollectionEndpoints/read' over scope '/subscriptions/.../resourcegroups/myResourceGroup/providers/Microsoft.Insights' or the scope is invalid.

Cause: endpoint is a DCE Resource ID, so Director runs autodiscovery and needs read access to the DCE and its DCRs, but the identity in the error has not been granted it at any scope.

Fix:

1. Note the resource group in the error. It is the one named in your endpoint Resource ID.
2. In the Azure Portal open that resource group, then Access control (IAM) > Add role assignment, and assign Monitoring Reader to the application or managed identity whose client ID appears in the error.
3. If you do not want to grant read access on the whole group, assign Monitoring Reader on the DCE and on each DCR linked to it instead. With the Content Hub solution that means both the standard DCR and the ASIM DCR.
4. Wait for the next retry. If it still fails after 30 minutes, check that tenant_id is the tenant that owns the subscription, and that the resource group name in endpoint is spelled correctly. The or the scope is invalid part of the message means Azure could not even resolve the scope, which usually points to a typo.

Do not assign Monitoring Reader at subscription scope. Discovery only reads the resource group named in endpoint, so a subscription-wide assignment grants read access that is never used.

"failed to list DCEs" with an AADSTS code, or "ClientSecretCredential authentication failed"

Reason: failed to list DCEs: ClientSecretCredential authentication failed. ... AADSTS7000215: Invalid client secret provided.

Cause: the service principal credentials are wrong, so the very first Azure call fails before permissions are even checked. The AADSTS code tells you which field:

Code	Meaning	Check
AADSTS7000215	Invalid client secret	The secret ID was pasted instead of the secret value, or the secret was rotated
AADSTS7000222	Client secret expired	Create a new secret on the app registration and update client_secret
AADSTS700016	Application not found in the directory	client_id is wrong, or tenant_id is a different tenant than the one the app registration lives in
AADSTS90002	Tenant not found	tenant_id is not a valid tenant ID

If the reason instead starts with failed to resolve client secret (or tenant ID, client ID), the $secret{...} reference in the field could not be resolved. Check that the secret store exists and the reference matches.

"DefaultAzureCredential: failed to acquire a token" or ManagedIdentityCredential errors

Cause: at least one of tenant_id, client_id, and client_secret is empty. When any of the three is missing, even if the other two are filled in, Director treats the service principal as not configured and falls back to Managed Identity authentication. If Director is not running on an Azure resource with a managed identity, that fallback fails.

Fix: either fill in all three fields, or run Director on an Azure resource with a managed identity and grant that identity the roles listed above. A typical trigger is a client_secret whose $secret{...} reference resolves to an empty value.

"Please provide at least one stream configuration"

Cause: after autodiscovery and your own streams list were combined, the target had no stream to send to. One of the following applies.

1. endpoint is a logs ingestion URL and no streams are configured. An https:// endpoint disables autodiscovery, so you must list the streams yourself:

   endpoint: "https://my-dce-abcd.westeurope-1.ingest.monitor.azure.com"
   streams:
     - name: "Custom-Syslog"
       rule_id: "dcr-00000000000000000000000000000000"

2. No DCR in the resource group is linked to the DCE. Autodiscovery only returns DCRs whose Data collection endpoint property is the DCE in endpoint. Open each DCR in the Azure Portal and confirm the DCE is selected. DCRs in a different resource group than the DCE are not discovered, even when linked.

3. The Resource ID does not match exactly. The comparison is case-sensitive. Copy the Resource ID from the DCE's Properties page in the Azure Portal rather than typing it. A DCR created with a tool that stored the DCE reference in a different case (for example resourcegroups instead of resourceGroups) will not match either. Re-linking the DCR to the DCE in the Portal fixes the stored reference.

4. The linked DCRs declare no custom streams. Only streams under the DCR's streamDeclarations (names starting with Custom-) are discovered. A DCR that only uses built-in Microsoft- streams yields nothing. Create the DCR with the VirtualMetric automation templates, or add stream declarations.

5. The DCRs could not be read on an earlier attempt. When failed to list DCEs or failed to list DCRs appears on one attempt and this message on the next, the cause is the missing Monitoring Reader role, not the stream list. Fix the permission and both messages stop.

Discovered streams are cached for cache.timeout seconds (default 300). After adding or linking a DCR, either wait for the cache to expire or save the target configuration again to force a refresh.

"batch_size must be greater than 0"

Cause: batch_size is set to 0 or a negative value.

Fix: remove the setting to use the default of 1000, or set a positive value. The target does not start until the value is valid, so nothing is sent in the meantime.

"Please provide a Data Collection Endpoint (DCE)" or "failed to extract subscription ID from DCE resource ID"

Cause: endpoint is empty or is neither of the two accepted forms.

Fix: set endpoint to one of:

• The DCE Resource ID, starting with /subscriptions/, for autodiscovery.
• The DCE logs ingestion URL, starting with https:// and ending in .ingest.monitor.azure.com, for manual streams.

The DCE name alone, the configuration access endpoint (...handler.control.monitor.azure.com), and the Azure Portal URL of the DCE are not accepted.

"Finalize failed on flush" with RESPONSE 403 OperationFailed

Sender worker 3 Finalize failed on flush for target "auto_sentinel": POST https://my-dce.westeurope-1.ingest.monitor.azure.com/dataCollectionRules/dcr-.../streams/Custom-Syslog
RESPONSE 403: 403 Forbidden
ERROR CODE: OperationFailed
"message": "The authentication token provided does not have access to ingest data for the data collection rule with immutable Id 'dcr-...' PipelineAccessResult: AccessGranted: False, IsRbacPresent: False, IsDcrDceBindingValid: True, ..."

Cause: the target initialized, but Azure refused the upload. The two flags in the message tell you why:

• IsRbacPresent: False means the identity has no Monitoring Metrics Publisher role on that DCR.
• IsDcrDceBindingValid: False means the DCR is not linked to the DCE you are sending through.

Fix: assign Monitoring Metrics Publisher on the DCR named by the immutable ID, or link the DCR to the DCE. The assignment is per DCR. If the target sends to several DCRs, each one needs the role.

No data is lost while this error persists, within the queue retention limits described under the reinitialize entry above. Director discards the failed batch from memory, keeps the payloads queued, and redelivers them after the target reinitializes. Expect the queue to grow until the role is in place.

"Finalize failed on flush" with RESPONSE 404, or the DCR immutable ID is not found

Cause: rule_id is not a DCR immutable ID, or the DCE in endpoint is not the one the DCR is linked to.

Fix: open the DCR in the Azure Portal and copy the value labelled Immutable Id. It starts with dcr- followed by 32 hexadecimal characters. The DCR name and the DCR Resource ID are different values and are not accepted. Then confirm the DCR's Data collection endpoint is the DCE whose URL or Resource ID is in endpoint.

"target not initialized (Custom-...)" for some tables only

[Error] [director] [target-<target id>] [auto_sentinel] Sender worker 3 execute() failed for natsobj:/vm-pipeline-payloads/sender.auto_sentinel.<id>: target broken: target not initialized (Custom-ASimNetworkSessionLogs)
[Information] [director] [target-<target id>] [auto_sentinel] Target "auto_sentinel" reinitialized successfully (generation 2).

Symptom: the target initializes and data for some tables arrives in Sentinel, but events for one group of tables fail with this error. The stream in parentheses is the one Director tried to use. Each failure triggers a reinitialize, so the generation counter climbs while the problem persists. The error is only visible with drop_unknown_stream_events: false. At the default of true the same events are dropped silently and appear only in the target's dropped counters.

Cause: the DCR that declares that stream could not be read during autodiscovery, so its streams were never added to the target. This happens with per-resource role assignments when one DCR was skipped. The VirtualMetric solution from the Microsoft Sentinel Content Hub installs two DCRs next to the DCE, and the failing stream name tells you which one is missing a role:

Failing stream	DCR to fix
Custom-ASim*, for example Custom-ASimNetworkSessionLogs	The ASIM DCR, for example my-dcr-vmetric-asim
Custom-Syslog, Custom-CommonSecurityLog, Custom-SecurityEvent, Custom-WindowsEvent, Custom-Event	The standard DCR, for example my-dcr-vmetric-standard

Fix: open that DCR in the Azure Portal, then Access control (IAM) > Add role assignment, and assign both Monitoring Reader and Monitoring Metrics Publisher to the identity Director or the Director Proxy uses. Check the other DCR as well. Discovery picks the DCR up on the next refresh, after cache.timeout seconds or when you save the target again.

The target is healthy but nothing arrives in Sentinel

Check these in order.

1. Events are dropped as unknown streams. With drop_unknown_stream_events at its default of true, any event whose table does not match a configured stream is discarded without an error. Check the target's dropped counters in the stats view. If they climb, either your pipeline is not setting the destination table, or the table name does not match a stream. Set drop_unknown_stream_events: false temporarily to turn the drop into a visible error. It is logged as target not initialized (Custom-...), where the name in parentheses is the stream Director tried to use. If only the tables of one DCR fail this way while the others work, see the entry above on a DCR that is missing a role.

2. Azure rejects the stream name. If Azure answers InvalidStream, the stream name is not declared in the DCR. With drop_unknown_stream_events: true this batch is also discarded silently. With false it appears in the logs as Finalize failed on flush ... InvalidStream. Stream names are the DCR's input stream names, such as Custom-Syslog, not the destination table name. The Custom- prefix is added automatically if you omit it, so Microsoft- built-in streams cannot be targeted this way.

3. debug.dont_send_logs is enabled. In that mode events are processed but never uploaded. When debug.status is also enabled, startup logs Log sending is disabled for this target.

4. Ingestion delay. The target flushes every 30 seconds by default, and Azure adds its own latency before records become visible in the table.

Some fields are missing from the records in Sentinel

Cause: with keep_phantom_fields at its default of false, Director removes fields that are not in the stream's column list before uploading. In autodiscovery mode that list is the DCR's stream declaration. With manually configured streams, it is Director's built-in schema for that stream name, so a column you added to the DCR is still stripped until you change the setting.

Fix: add the columns to the DCR's stream declaration and to the destination table. In autodiscovery mode, re-save the target so the new declaration is picked up. With manual streams, also set keep_phantom_fields: true so Director passes the extra fields through. Azure only writes columns the DCR declares, so the DCR change is required in both cases.

RESPONSE 413 ContentLengthLimitExceeded, or RESPONSE 429

413: the Logs Ingestion API accepts at most 1 MB per call. This happens when buffer_size is raised above the default of 1048576. Set it back to the default or lower.

429: Azure is throttling the DCR or DCE. Director retries the batch automatically until it is accepted.

"context deadline exceeded", "i/o timeout", or TLS errors

Cause: Director cannot reach Azure. Each upload is bounded to 30 seconds.

Fix: allow outbound HTTPS (443) from the Director host to:

• login.microsoftonline.com for authentication
• management.azure.com, only when using autodiscovery
• your DCE ingestion hostname, *.ingest.monitor.azure.com

If you use a proxy, set HTTPS_PROXY for the Director service. Managed Identity token requests bypass the proxy and go to the Azure instance metadata endpoint directly, which is expected.

Errors when using Director Proxy

When the target forwards through Director Proxy, Director only talks to the proxy, and the proxy's managed identity does the Azure work. In YAML this mode is the function_app and function_token pair. In the web interface it is the proxy entry selected under Director Proxy in the target wizard, whose Proxy URL and Access Token are edited on the proxy's Configuration tab. Roles must be granted to the proxy's identity, not to Director. See VirtualMetric Director Proxy for the deployment and Proxy for managing proxy entries.

Error text	Cause	Fix
Function returned status: 400 Bad Request, body: Function token is not valid	The token Director presents does not match the one the Director Proxy expects	Update the proxy's Access Token on its Configuration tab, or function_token in YAML, to the token configured on the Director Proxy
Function returned status: 400 Bad Request, body: failed to list DCEs: (or DCRs)	The Director Proxy's managed identity lacks Monitoring Reader on the resource group, or on the DCE and DCRs when assigning per resource	Assign the role to the Director Proxy's managed identity at the same scopes as for Director. If the next attempt reports Please provide at least one stream configuration, it is the same missing role
Function returned status: 500 Internal Server Error, body: Failed to process log file: ... 403 ...	The Director Proxy's managed identity lacks Monitoring Metrics Publisher on the DCR	Assign the role to the Director Proxy's managed identity
Function returned status: 400 Bad Request, body: Data size exceeds the maximum allowed size of 1048576 bytes	buffer_size is above 1 MB	Set buffer_size back to the default
HTTP request failed: ...	Director cannot reach the Director Proxy	Check DNS and firewall rules from the Director host, and confirm the Proxy URL (function_app in YAML) is the address of the deployed Director Proxy