Deployment

VirtualMetric DataStream Directors support flexible deployment options to match your infrastructure requirements and operational preferences. Whether you're running on physical hardware, virtual machines, or containerized environments, Directors can be deployed to optimize performance while maintaining data sovereignty.

For Director concepts, capabilities, and installation types, see Directors - Overview.

Options

As Physical Server

Deploy Directors directly on dedicated physical hardware for maximum performance and complete infrastructure control. This option provides maximum performance and resource allocation with complete control over hardware specifications. Without virtualization overhead, physical deployments are ideal for high-throughput environments.

Considerations

Physical server deployments involve higher infrastructure costs and maintenance overhead. They offer limited flexibility for resource scaling and require longer deployment and provisioning times.

As Virtual Machine

Deploy Directors on virtual machines across various hypervisors and cloud platforms for balanced performance and flexibility. Virtual machine deployments offer flexible resource allocation and scaling with cost-effective resource utilization. They simplify backup and disaster recovery procedures and are platform agnostic, supporting VMware, Hyper-V, KVM, AWS, Azure, and GCP.

Considerations

Virtual machine deployments introduce slight performance overhead from virtualization and create dependency on hypervisor platform stability.

Recommended VM Specifications:

Workload Size	CPU Cores	Memory	Storage	Notes
Small	2-4 cores	8GB RAM	50GB	Development/testing, < 10K EPS
Medium	4-8 cores	16GB RAM	100GB	Standard production, 10K-50K EPS
Large	8+ cores	32GB RAM	200GB+	High-volume production, > 50K EPS

Disclaimer

Actual requirements may vary depending on the workload.

As Container

Deploy Directors in containerized environments for modern infrastructure management and orchestration capabilities.

Docker deployments run as single-host containers with simplified dependency management. They offer easy scaling and updates, making them ideal for development and small production environments.

Kubernetes deployments provide multi-node orchestration with automatic scaling, built-in service discovery and load balancing. They support rolling updates with zero downtime and deliver enterprise-grade high availability and resilience.

Containerized deployments provide consistent deployment across environments with rapid scaling and resource optimization. They include integrated monitoring and logging capabilities and support DevOps-friendly CI/CD integration.

Platform-Specific Considerations

On Linux

Linux deployments offer performance advantages: network-based collectors (syslog, TCP, SNMP) operate more efficiently with lower resource overhead for network processing. Linux provides superior performance for high-volume data ingestion and native support for Unix/Linux system integration.

Agent Connectivity:

• Windows Agent: Full support for Windows systems via VirtualMetric Agent with optional pre-processing
• Linux Agentless: Complete support via SSH-based connections
• Windows Agentless: Full support via WinRM protocols

note

Microsoft has announced plans to deprecate WinRM in future Windows releases. VirtualMetric continues to support WinRM-based agentless monitoring. Consider using VirtualMetric Agent for long-term Windows endpoint monitoring strategies.

Recommended For:

• High-volume network data collection environments
• Mixed Windows/Linux infrastructure monitoring
• Cost-sensitive deployments requiring maximum efficiency

On Windows

Agentless Connectivity:

• Windows Agentless: Full support via WinRM protocols
• Linux Agentless: Complete support via SSH connections
• Universal Agent: Support for both Windows and Linux systems with optional pre-processing

note

Microsoft has announced plans to deprecate WinRM in future Windows releases. VirtualMetric continues to support WinRM-based agentless monitoring. Consider using VirtualMetric Agent for long-term Windows endpoint monitoring strategies.

Windows deployments provide native Windows service integration with Active Directory authentication support. They offer PowerShell-based management capabilities and seamless Windows ecosystem integration.

Recommended For:

• Windows-centric environments
• Organizations requiring agentless Windows monitoring
• Environments with existing Windows management infrastructure

Installation Process

Standalone Director Installation

info

Directors are always created as standalone instances. To create a clustered deployment for high availability, first create Directors using this wizard, then group them using the Clusters tab. See Clusters for configuration details.

Navigate to Home > Fleet Management > Directors and click Create new director to begin the 6-step setup wizard.

General Settings

Name:

Enter a unique identifier for the Director (3-64 characters). This name is used for identification across the platform.

Mode Selection:

Select the management approach using radio tiles:

• Managed - VirtualMetric manages Director infrastructure with automated updates, proactive monitoring, and reduced operational overhead
• Self-managed - User controls Director deployment with manual updates, custom security configurations, and full infrastructure control
• Orchestrated - For auto-scaling cloud environments where instances are automatically managed, scaled, and replaced by the platform
• Serverless - Runs on demand as a container without dedicated infrastructure, scaling automatically with load

For what each mode means operationally, see Platform Management Options. The mode cannot be changed after creation for Serverless Directors, and no other Director can be converted to serverless mode.

Self-managed Directors

A self-managed Director is indicated under the Mode column as Self-managed, with a warning icon when configuration has changed. Hovering over the icon displays a tooltip reading "Director configuration changed after last update. Please deploy the current configuration."

The actions menu contains a Download config option that downloads the vmetric.vmf file. Place this file under the <vm_root>\Director\config directory. Self-managed Directors skip access verification — monitor errors through the CLI or the files under <vm_root>\Director\storage\logs.

Container Type:

Selecting the Serverless mode reveals an additional required selection. It does not appear for the other three modes, and a container type cannot be submitted with them:

• Docker - Lightweight containerized deployment. Runs anywhere Docker is available, ideal for single-host or self-managed setups
• Kubernetes - Orchestrated container deployment. Scales across clusters with self-healing and rolling updates
• Azure Container Instances - Serverless containers on Azure. Fast startup with no cluster to manage, suited for bursty or short-lived workloads
• Azure Container Apps - Managed container platform on Azure. Built-in autoscaling and microservice support with managed identity integration

The container type determines the form of the deployment manifest generated in the Install and connect step, and it cannot be changed afterwards.

Managed Environment Settings:

Selecting Azure Container Apps adds an optional Managed environment settings block. By default the deployment manifest creates a managed environment for the Director, along with the virtual network it needs; the block also lets you point the Director at an existing environment instead. Click Show advanced settings to reveal the published ports (see Published Ports below) and, beneath them, the Autoscaling policy.

Selecting Kubernetes adds an optional Environment options block with the same published ports and Autoscaling policy, and a Service account setting (see Service Account below). The managed environment, and the choice of an existing one, are Azure Container Apps only.

Published Ports:

The published ports are stored as properties.serverless.exposed_ports. They renumber where each listener is published, keyed by the port the container listens on:

"serverless": { "exposed_ports": { "1514": "21514", "2020": "22020" } }

The container itself is never moved: a device bound to 1514 on a Director published as 21514 still binds 1514 (see Published is not the same as bound below). Azure Container Apps and Kubernetes accept the setting; Docker and Azure Container Instances refuse it, because they publish the listening port as it is.

Rule	Azure Container Apps	Kubernetes
Where the mapping lands	additionalPortMappings[].exposedPort, each also an ARM template parameter	The Service's port (published) against its targetPort (listening), and the pod's hostPort — see Kubernetes Node Ports under Install and Connect
Reserved ports	80 and 443, the platform's own ingress	None

On both, a key must be a port this Director publishes, and the proxy port is never renumbered. A value must be a port (1–65535), and two listeners cannot be published on one port. Kubernetes publishes the full default set — 1514 over UDP and TCP, which one key covers, 4317, 4318 and 6514 — plus the discovery port when discovery is enabled. Changing the mapping flags the deployment as out of date; the reinstalled manifest carries the new one.

Service Account:

Kubernetes only. By default the Director pod runs as the vmetric namespace's default ServiceAccount. Setting properties.serverless.service_account — an object, and {} is enough — has the manifest create a ServiceAccount named after the Director in vmetric and run the pod as it. Any other container type refuses the setting.

Its one option federates the account with an Azure managed identity through AKS workload identity:

"serverless": {
  "service_account": {
    "azure_workload_identity": {
      "client_id": "<managed identity client ID>",
      "tenant_id": "<tenant ID, optional>"
    }
  }
}

Field	Required	Description
client_id	Y, when azure_workload_identity is set	The managed identity's client ID, as a GUID. Rendered as the azure.workload.identity/client-id annotation on the account
tenant_id	N	The identity's tenant, as a GUID. Needed only when it differs from the cluster's. Rendered as the azure.workload.identity/tenant-id annotation

An ID that is not a GUID is refused with a 400. The manifest carries all three pieces the feature needs: the annotated account, serviceAccountName on the pod, and the azure.workload.identity/use: "true" pod label that the AKS webhook keys on. Without the label nothing is injected.

The platform cannot create the Azure side. The cluster needs the workload identity add-on and the OIDC issuer enabled, and the managed identity needs a federated credential for the subject system:serviceaccount:vmetric:<director-name>. Changing any of these values flags the deployment as out of date, and the re-apply updates the account and rolls the pod.

Autoscaling Policy:

A serverless Director on Azure Container Apps decides for itself how many replicas it needs, and the scale rule in its deployment manifest follows that decision (see Serverless Deployment Manifest under Install and Connect). On Kubernetes the same fields drive a HorizontalPodAutoscaler instead — see Autoscaling on Kubernetes below. Four fields tune the decision. The Autoscaling policy block is where you set them; each is stored as a node property under properties.autoscale in the Director's configuration, and the full key reference is Autoscale Policy in Service Configuration.

Field	Key under properties.autoscale	Director default	Meaning
Backlog per replica	backlog_per_replica	10000	Queued records one replica is expected to hold. The total backlog divided by this number is one estimate of the replicas needed
CPU target (%)	cpu_target_percent	75	The CPU utilization to hold each replica at
Memory target (%)	memory_target_percent	0 (off)	The memory utilization to hold each replica at
Maximum replicas	max_replicas	0 (no ceiling)	Ceiling on the replicas the Director asks for. The wizard pre-fills 2 — see below

Each of the three targets yields its own estimate of the replicas the current load needs, and the highest wins. Whatever the estimates say, the Director never asks for fewer than one replica: it is a collector, and at zero replicas its listeners would be closed with nothing arriving to wake it.

On Azure Container Apps, a change to any of these fields reaches a running Director within seconds and takes effect on the replica set that is already serving, without a redeploy. That is why the policy is Director configuration rather than a setting in the deployment manifest there: on Azure Container Apps a scale rule is part of the app's revision template, so retuning a threshold there would create a new revision and restart every replica.

Four behaviors are worth knowing before changing these fields:

• Every field opens pre-filled. Backlog per replica, CPU target and Memory target open showing the Director's own default. A value equal to the default is displayed but not saved, so a Director you never tune keeps following its own defaults from release to release. Clearing a field has the same effect: it goes blank, the default reappears as greyed placeholder text, and the decision is left to the Director.
• 0 is a real setting, and it means two different things. On the three targets, 0 stops that input counting toward the decision — it is not a target of zero percent. This is why memory is off by default: an idle Director already sits at roughly a quarter of its memory allocation and does not release memory promptly once a burst has passed, so with a memory target set, memory would drive every scaling decision and hold replicas up after the work is gone. Enable it only where memory is the constraint you actually scale on. On Maximum replicas, 0 means no ceiling — never "no replicas".
• Maximum replicas is pre-filled with 2, and that value is saved. Unlike the three targets, this pre-fill is a policy of the wizard's own rather than the Director's default, so a Director created without touching the field is capped at two replicas. Raise the number, or enter 0 to remove the ceiling. Clearing the field to blank also removes the ceiling, but only until the panel is next opened and saved, when the pre-filled 2 returns — so 0 is the durable way to say "no ceiling". The ceiling can only ever reduce: the Container App's own maximum replica count, which the manifest sets to 10, still applies on top, and the smaller of the two wins, so a value above it changes nothing.
• Scaling out does not drain an existing backlog. A new replica receives only new arrivals; records already queued on another replica stay there. Scaling out relieves incoming pressure rather than clearing a queue that has already built up, and when one replica holds nearly all of the backlog, the Director stops asking for more replicas on its account, because they would sit idle while that backlog does not move.

Enter whole numbers only; the two percentage fields accept values up to 100. A blank field is always valid.

Autoscaling on Kubernetes:

The Kubernetes manifest scales the Director with a native autoscaling/v2 HorizontalPodAutoscaler rather than a KEDA rule, so the cluster needs nothing installed beyond metrics-server. An HPA cannot read the Director's configuration, so the platform renders the policy into the manifest, and the keys map differently there:

Key under properties.autoscale	Azure Container Apps	Kubernetes
cpu_target_percent	Weighs the Director's own replica figure	The HPA's CPU averageUtilization (default 75). 0 leaves the CPU metric out
memory_target_percent	Weighs the Director's own replica figure	The HPA's memory averageUtilization. 0, the default, leaves the memory metric out
max_replicas	A ceiling below the platform's own maximum of 10	The HPA's maxReplicas. 0 or unset gives the manifest's default of 10
backlog_per_replica, sample_interval	Drive the Director's replica figure	Inert: nothing polls /scale on Kubernetes

The HPA's minReplicas is fixed at 1, and scale-down waits out a 300-second stabilization window.

Because the thresholds live in the manifest, changing one flags the deployment as out of date, and it takes effect only when the reinstalled manifest is re-applied. Updating the HPA restarts no pod.

• Both targets at 0 renders no HPA. kubectl apply never deletes an object the new manifest stops naming, so turning autoscaling off on a running Director leaves the earlier HPA scaling it on its old targets. Remove it after the re-apply:

  kubectl delete hpa <director-name> -n vmetric --ignore-not-found

  A Director first deployed with autoscaling off has no HPA to remove.

• metrics-server must be running. AKS and GKE run it by default; EKS does not. Install it, and confirm that kubectl top pods -n vmetric answers, before relying on the HPA. Without it the HPA reports <unknown> targets and holds the current replica count.

• The Deployment sets no spec.replicas, so a re-apply never resets the count the HPA chose. A Director deployed from the earlier manifest, which pinned one replica, and then scaled by hand above one drops back to one on the first apply of the new manifest. To keep the count, run kubectl apply edit-last-applied deployment/<director-name> -n vmetric, delete the replicas line and save, then apply. A Deployment that was never scaled by hand is unaffected.

• At most one replica per node. The pod publishes its ports on the node, so max_replicas must fit the node pool — see Kubernetes Node Ports under Install and Connect.

Access Management

Configure optional access controls for the Director.

Access tokens:

• Access tokens - Toggle to require token authentication
• Token Name - Identifier for the token
• Token Value - Auto-generated when token is created (use copy button to copy)
• Expiration - Token validity period (default: 3 months):
  • 1 month
  • 3 months
  • 1 year
  • Unlimited

Access restriction:

Restrict which IP addresses can connect to the Director:

• Restrict access - Toggle to enable IP filtering
• Type:
  • Single IP/IP block - Single IP address or IP block
  • IP range - IP address range (start-end)
  • CIDR - CIDR notation (e.g., 10.0.0.0/8)
• Trusted sources - List of allowed IP addresses/ranges

TLS Configuration

Select how TLS is managed for agent-to-director communication using radio tiles:

• Auto-generated - The Director manages its own certificate authority (CA) and certificates
• Custom certificate - The Director uses your certificate and private key, for organizations with an existing PKI
• TLS offloading - TLS termination is handled by your load balancer

Each mode exposes its own fields, along with the agent communication port and, where applicable, the discovery endpoint used for agent enrollment. For the full field reference, the mode-to-proxy_tls mapping, and the certificate resolution order, see Transport Layer Security.

Serverless Directors are subject to stricter port rules, because these values are written into the deployment manifest as the container's exposed ports:

Rule	Applies to
The agent communication port is mandatory and must be in the range 1-65535	All container types
The discovery port is mandatory, and must differ from the agent communication port, when discovery is enabled	All container types
Ports 80 and 443 are rejected	Azure Container Apps only — the platform reserves them for its own ingress
Device listener ports must be among those the manifest publishes	Enforced on Azure Container Apps and Azure Container Instances; advisory on Docker and Kubernetes — see Device Listener Ports below
No UDP listener port is published	Azure Container Apps and Azure Container Instances only — their templates render the TCP subset, see Device Listener Ports below

The Director is created when this step is submitted, so a port that violates these rules is reported here rather than at deployment time.

Device Listener Ports

A container Director receives device traffic only on the ports its deployment manifest publishes. These come from the install templates rather than from anything chosen when the Director is created:

Container Type	Published listener ports
Docker, Kubernetes	1514/udp, 1514/tcp, 4317/tcp, 4318/tcp, 6514/tcp
Azure Container Instances, Azure Container Apps	1514/tcp, 4317/tcp, 4318/tcp, 6514/tcp

The Docker and Kubernetes manifests are yours to edit, so a Director of either type can publish more than this. The Azure templates are deployed as rendered.

Neither Azure template publishes a UDP port

The two Azure container types are TCP-only for different reasons. Azure Container Apps ingress does not support UDP at all. Azure Container Instances does support UDP, but rejects a container group that publishes the same port number on both protocols, so the UDP twin of 1514 would fail the whole deployment. Either way both templates render the TCP subset only, so a device that listens on UDP cannot receive traffic on an Azure container Director. Because the syslog device's protocol defaults to udp, a syslog device created there without naming a protocol binds UDP 1514, reports itself Connected, and receives nothing.

None of the templates publishes port 514. The Director image runs as an unprivileged user, so a listener cannot bind 514 inside the container without platform-specific capability tweaks, which is why the defaults are 1514 and 6514. A platform can still publish an external 514 mapped onto the container's 1514 — the device's own port stays 1514.

A device whose listener port is not published is handled differently by container type:

Container Type	Behavior on save
Azure Container Apps, Azure Container Instances	Refused with DEVICE_LISTENER_PORT_NOT_PUBLISHED, naming the ports that Director does publish
Docker, Kubernetes	Saved with a warning — you apply these manifests yourself and may have added ports to the Compose file or the Service

The device creation wizard and the device's edit form report the same finding before anything is saved, under the Port field, and keep Next or Save changes disabled while a finding the save would refuse is shown. The check on save remains the backstop. See Devices: Management.

An update that changes neither the port, the transport, nor the bound Directors is downgraded to a warning, so an already-misconfigured device can still be edited. Self-managed, managed and orchestrated Directors publish nothing and constrain nothing. Outbound collectors — mssql, mysql, postgres, oracle, datagen, and the queue and object-store pulls — are exempt, because their port is the remote server's, not a local bind.

Published is not the same as bound

The published port is where senders aim; the bound port is where the device listens inside the container. Renumbering what Azure Container Apps publishes — 1514 to 21514, say — changes the address your senders use, but the device still listens on 1514 and its port must stay 1514.

Install and Connect

Installation Scripts:

• PowerShell Script - For Windows deployments
• Bash Script - For Linux/macOS deployments
• Copy Button - One-click copy to clipboard
• API Key - Auto-generated secure authentication key included in scripts

Run the provided script with administrative privileges on the target system. The installation downloads and configures the Director service with automatic service registration and startup configuration.

Serverless Deployment Manifest:

Serverless Directors do not use an installation script. This step instead presents a complete deployment manifest for the container type selected in General settings, and the PowerShell/Bash selector is not shown — the manifest is the same regardless of the platform you apply it from:

Container Type	Manifest	Applied with
Docker	A Compose service definition	docker compose up
Kubernetes	A vmetric namespace, a Secret, a Deployment, a LoadBalancer Service and, unless both autoscaling targets are 0, a HorizontalPodAutoscaler, plus a ServiceAccount when serverless.service_account is set	kubectl apply
Azure Container Instances	An Azure Resource Manager template for a container group, with a public IP and DNS label	Azure CLI or portal deployment
Azure Container Apps	An Azure Resource Manager template for a container app with external ingress and a scale rule that polls the Director's own /scale endpoint	Azure CLI or portal deployment

The manifest carries the API key as the VMETRIC_CONFIG_HASH environment variable, supplied through the platform's own secret mechanism rather than as plain text. The container name is derived from the Director name, reduced to lowercase letters, digits and hyphens and truncated to 32 characters so that it is valid on every supported platform.

warning

Reinstalling a Director issues a new API key and a new manifest. The previously issued manifest stops authenticating, so redeploy from the new one rather than reusing the old copy.

The Azure Container Apps scale rule

The Azure Container Apps manifest scales on the Director's own judgement. It carries a custom scale rule of type metrics-api that polls the Director's /scale endpoint and reads back the replica count the Autoscaling policy (see General Settings) has computed. Every replica reports the same replica-set-wide figure, so it does not matter which one answers the poll. The manifest also fixes the platform's own bounds at 1 to 10 replicas. Earlier versions of this manifest scaled on concurrent HTTP requests instead; a Director deployed from one of those keeps that rule until you reinstall it and redeploy from the new manifest.

The scale rule is an ordinary client of /scale, which sits behind the same access controls as the rest of the Director. When the Director has an access token, the manifest renders that token into an app secret for the rule to present. It is rendered once: a token rotated afterwards, or added to a Director that previously had none, does not reach the deployed rule, which is then refused with no symptom except a replica count that stops moving. Reinstall the Director to get a manifest carrying the current token.

The Kubernetes HorizontalPodAutoscaler

The Kubernetes manifest scales with an autoscaling/v2 HorizontalPodAutoscaler named after the Director. It targets the Director's Deployment between 1 and max_replicas replicas (10 by default), on the CPU and memory targets of the Autoscaling policy, and needs metrics-server on the cluster. The thresholds are rendered into the manifest, so a change to them takes a re-apply. See Autoscaling on Kubernetes under General Settings.

Kubernetes Node Ports:

The Kubernetes pod spec sets hostPort, equal to the published port, beside every containerPort: the proxy port, the discovery port, and each listener. Each port is therefore published on the node as well as through the LoadBalancer Service. Two pods cannot share a hostPort on one node, so the scheduler places at most one replica per node. The HPA can scale the Director no further than the cluster has nodes, and a max_replicas above that leaves the surplus replicas Pending. Size max_replicas to the node pool, or remove the hostPort lines from the manifest before applying it if you do not want node ports.

Self-Update on Azure Container Apps:

Restarting an Azure Container Apps Director does not update it: Container Apps restarts the container inside the replica it already has, and that replica keeps the image it booted with. A new version arrives only when the replica is replaced, which is what a revision restart does (see Update Management Tab under Management). Two template parameters let the Director restart its own revision, so that Restart to apply update in the console updates it with one click:

Parameter	Default	Description
enableSelfUpdate	false	Grants the app's system-assigned managed identity a role on this one container app (nothing on the resource group), and passes the app its subscription and resource group. On an update the Director then restarts its own revision
selfUpdateRoleDefinitionId	b24988ac-6180-42a0-ab88-20f7382dd24c (built-in Contributor)	The role granted to the app's identity, scoped to this one app. Used only when enableSelfUpdate is on

Every Azure Container Apps Director has a system-assigned managed identity, whether or not enableSelfUpdate is on. The deployment's principalId output is that identity's object ID: grant roles to it once the deployment has finished.

Turning enableSelfUpdate on requires the right to create role assignments. What the deployer needs on the resource group or subscription:

Deployer	enableSelfUpdate=true
Owner	✅ Nothing extra needed
Contributor + User Access Administrator	✅
Contributor + Role Based Access Control Administrator	✅ Can be conditioned, see below
Contributor only	❌ Leave the default false

warning

Without the right to assign roles, a deployment with enableSelfUpdate=true fails partway: the container app is created, then the role assignment step fails with an authorization error. Deploy with the default instead, or get the right role first.

For an automation principal, the least-privilege option is Role Based Access Control Administrator with a condition that allows assigning only the Contributor role (b24988ac-6180-42a0-ab88-20f7382dd24c), and only to service principals:

((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {b24988ac-6180-42a0-ab88-20f7382dd24c} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] StringEqualsIgnoreCase 'ServicePrincipal')) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {b24988ac-6180-42a0-ab88-20f7382dd24c}))

Pass it with az role assignment create … --condition-version 2.0 --condition "<condition>".

To grant the app only what an update needs instead of Contributor, create this custom role once at subscription scope and put its GUID in selfUpdateRoleDefinitionId:

{
  "Name": "VirtualMetric Director Self-Update",
  "Description": "Restart a Container Apps revision so it pulls a new image.",
  "Actions": ["Microsoft.App/containerApps/revisions/restart/action"],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}

The condition above allows assigning the Contributor role only. If the deployer holds the conditioned Role Based Access Control Administrator role, put the custom role's GUID in place of b24988ac-6180-42a0-ab88-20f7382dd24c in both GuidEquals clauses, or the role assignment is refused.

note

• Turning enableSelfUpdate on for an app that is already deployed changes the revision, so also set a new revisionSuffix in the same deployment, or Azure refuses it as a clashing revision.
• A Director deployed before these parameters existed cannot update from the console until it is redeployed once with enableSelfUpdate=true. The update logic runs in the Director being updated.
• In the first minutes after deployment an update can fall back to a plain restart while Azure propagates the new role assignment. The Director logs the reason, and the next attempt works.

Connection Verification:

After running the installation script, verify Director connectivity:

• Connecting - Director attempting initial connection
• Success - Director successfully connected to platform
• Failed - Connection attempt unsuccessful

Real-time connection status updates with visual indicators for each state.

If the Director is not yet connected, click Connect later to proceed without connection verification and return later to verify the connection.

Update Management

Configure the Director's update policy. By default the organization-level update settings apply; enable the Custom update policy toggle to override them for this Director. See Updates for the policy options.

Review and Complete Setup

A read-only summary of the values entered in the preceding steps. Click Complete setup to finalize the Director and navigate to its detail view.

Navigation

The wizard displays a 6-step progress indicator (General settings > Access management > TLS configuration > Install and connect > Update management > Review and complete setup). Click completed steps to navigate back. Invalid steps are marked with an error indicator.

Navigation Buttons:

• Cancel - Exit wizard (first step)
• Next Step - Advance to next step with validation
• Create director - Submit Director configuration and proceed to connection (from the Access management step; shown as Update director when returning to that step after creation)
• Connect later - Skip connection verification (Install and connect step)
• Back - Return to the previous step
• Complete setup - Finalize Director creation (final step)

Network Requirements

Critical: Pre-Installation Network Access

Before running installation commands, ensure the target system has outbound HTTPS access to both dl.vget.me and virtualmetric.blob.core.windows.net. The installation scripts are served from dl.vget.me, which then redirects every binary download to virtualmetric.blob.core.windows.net. If either host is blocked by firewall rules, installation will fail silently or with connection errors.

Outbound Connectivity:

• Port 443 (HTTPS) to dl.vget.me for the installation script and the binary download redirect
• Port 443 (HTTPS) to virtualmetric.blob.core.windows.net for the binaries themselves
• Port 443 (HTTPS) for DataStream cloud platform communication
• DNS resolution for dl.vget.me, virtualmetric.blob.core.windows.net and api-service.*.cloud.virtualmetric.com domains

The Director keeps using both download hosts after installation: it downloads its own updates, and the Agent binaries it serves to its Agents, from dl.vget.me, which redirects them to virtualmetric.blob.core.windows.net in the same way. A firewall that already allows Azure Storage (*.blob.core.windows.net, or the Storage service tag) needs only the dl.vget.me entry.

Serverless Directors

Serverless Directors do not download an installation script, so dl.vget.me access is not required for them. The container platform pulls the Director image from Docker Hub instead, and that registry must be reachable from wherever the manifest is deployed. Platform communication over port 443 applies as it does to every other mode.

warning

TLS certificate validation requires accurate system time. Ensure NTP is configured and the system clock is synchronized before installation.

Installation Script Delivery

The installation commands use dl.vget.me as the script delivery endpoint. This URL serves platform-appropriate installation scripts based on the requesting client:

Client	Script Served	Command Example
PowerShell	install.ps1	$h="<apiKey>"; iwr dl.vget.me | iex
curl/wget	install.sh	curl -sL dl.vget.me | h="<apiKey>" bash
Browser	Redirects to virtualmetric.com	N/A

The scripts automatically:

1. Detect the operating system (Windows, Linux, macOS, FreeBSD, etc.)
2. Detect the CPU architecture (amd64, arm64)
3. Download the appropriate Director binary from dl.vget.me/director/{os}/{arch}, which redirects to virtualmetric.blob.core.windows.net
4. Configure the Director with the provided API key
5. Install and start the service

Supported Platforms:

Operating System	Architectures
Windows	amd64, arm64
Linux	amd64, arm64, 386, ppc64, ppc64le
macOS (Darwin)	amd64, arm64
FreeBSD	amd64, arm64
Other Unix	amd64, arm64

Customizable Download URL

For environments where dl.vget.me is not accessible, the download URL can be configured via the VITE_INSTALLATION_DOWNLOAD_URL environment variable in self-hosted deployments.

Inbound Connectivity:

• Configure based on data source requirements
• Ports as defined in device configurations

Firewall Configuration

Outbound Rules (Required):

• Allow HTTPS (443) to dl.vget.me (installation scripts, and the redirect for binary downloads)
• Allow HTTPS (443) to virtualmetric.blob.core.windows.net (binaries, which dl.vget.me redirects to)
• Allow HTTPS/WebSocket Secure (443) to api-service.eu-west.cloud.virtualmetric.com (platform communication - Europe)
• Allow HTTPS/WebSocket Secure (443) to api-service.aus-east.cloud.virtualmetric.com (platform communication - Australia)
• Allow HTTPS/WebSocket Secure (443) to api-service.us-east.cloud.virtualmetric.com (platform communication - US)
• Allow DNS queries for name resolution
• Allow NTP for time synchronization

Firewall Rule Order

If your firewall processes rules in order, ensure the dl.vget.me and virtualmetric.blob.core.windows.net rules are evaluated before any blanket deny rules. Installation will fail if the target system cannot reach either endpoint.

Inbound Rules (As Needed):

• Open ports for configured data collection protocols
• Allow management access (SSH for Linux, RDP for Windows)
• Configure source restrictions based on security policies

Security and Performance

Security Considerations

Deploy Directors in appropriate network segments and implement network access controls and monitoring. Use dedicated service accounts with minimal privileges and enable logging and audit trails for security monitoring. Implement encryption for data at rest and in transit, and maintain regular security updates and patch management.

Performance Optimization

Monitor CPU and memory utilization patterns and allocate sufficient disk space for logging and buffering. Configure appropriate network interface capacity and plan for peak load scenarios and growth.

For data processing efficiency, optimize YAML pipeline configurations for performance and implement efficient parsing and transformation rules. Use appropriate batch sizes for different data sources and monitor processing latency and throughput metrics. Consider Agent pre-processing for high-volume deployments to distribute processing load.

High Availability Planning

Maintain regular configuration backups and version control. Document recovery procedures and test them regularly. Implement monitoring and alerting for service health and plan for disaster recovery scenarios.

For redundancy, group Directors into clusters for automatic failover and load balancing. See Clusters for configuration details and quorum requirements. Consider geographic distribution for disaster recovery and plan for seamless failover procedures.

Advanced Deployment Scenarios

Multi-Site Deployments

For organizations with multiple locations or data centers, deploy Directors at each site for local data processing. Implement centralized configuration management and coordinate routing and aggregation strategies. Plan for inter-site connectivity and failover.

Compliance and Regulatory Requirements

For regulated industries requiring specific compliance, implement appropriate data retention and disposal policies. Configure audit logging and compliance reporting, ensure data sovereignty and jurisdictional requirements are met, and plan for regulatory audit and inspection procedures.

Scalability Planning

As your environment grows, monitor resource utilization and performance trends. Plan for vertical scaling (more resources per Director) or horizontal scaling (clustering multiple Directors). Implement capacity planning and forecasting procedures to determine when to transition from standalone to clustered deployments.