Draft documentation
This deployment guide is a draft. Validate it against the approved infrastructure design and customer operating procedures before use.
Manual deployment guide
This guide provisions the Election Readiness Tools virtual machine using the Azure portal or an internal manual change process.
The completed infrastructure is a privileged, on-demand Windows execution host for the tools. It does not create a Brief Connect application component.
Deploy a dedicated VM for each Brief Connect environment. Avoid sharing one tools VM, its identities, or retained output across multiple environments where possible.
Azure portal labels can change over time. If a label differs, use the setting values and verification criteria in this guide rather than accepting a portal default without review.
Deployment summary
The deployment consists of:
| Component | Required configuration |
|---|---|
| Tools VM | One Windows Server 2022 Datacenter: Azure Edition x64 Gen2 VM |
| Region | Same as the primary region of the Brief Connect resources for the selected environment |
| VM size | Standard_B2ls_v2 baseline: 2 vCPU and 4 GiB RAM |
| Pricing and licensing | Client policy, commercial model, and Windows licensing entitlement |
| Security type | Trusted Launch with Secure Boot and vTPM enabled |
| OS disk | 128 GiB Standard SSD LRS (E10) |
| Tools data disk | 64 GiB Standard SSD LRS (E6), LUN 0, host caching None |
| Network | One NIC on an existing approved subnet; dynamic private IP; no public IP created |
| VM identity | System-assigned managed identity enabled |
| SQL identity | Existing Brief Connect SQL user-assigned managed identity attached only when required |
| Key Vault access | VM system identity assigned Key Vault Secrets User on the existing Brief Connect Key Vault |
| Operator access | Microsoft Entra login extension and an authorised operator group assigned Virtual Machine Administrator Login on the VM |
| Patching | Azure Update Manager customer-managed schedule, periodic assessment enabled, and patch reboot set to Never |
| Diagnostics | Boot diagnostics enabled with managed storage |
The tools are self-contained win-x64 applications. The VM does not require a separately installed .NET runtime or SDK.
The deployment does not create or alter the customer's VNet, subnet, NSG, public IP, Bastion host, private endpoints, routes, DNS zones, service firewalls, backup policy, monitoring resources, or SQL database permissions.
Required information
Record the following values in the approved change record before starting. Do not record passwords, certificate values, connection strings, tokens, or private keys.
| Item | Value |
|---|---|
| Azure subscription | <subscription> |
| Tools resource group | <resource-group> |
| Brief Connect primary region | <region> |
| VM name | <vm-name> |
| Existing VNet and subnet | <vnet>/<subnet> |
| Existing Brief Connect Key Vault | <key-vault> |
| Authorised Entra operator group | <operator-group> |
| Active database model | Legacy DB or Latest DB |
| Existing SQL managed identity, if required | <sql-user-assigned-identity> |
| Approved administration path | <Bastion, VPN, private RDP, or equivalent> |
| Required tags | <tags> |
Confirm the active Brief Connect database model with the application owner. Do not configure access for both models as a fallback:
| Database model | Applicable versions | Required service paths |
|---|---|---|
| Legacy DB | Brief Connect 2.5.10 only |
Azure Storage Tables and Blob; Azure Cosmos DB when required by deletion |
| Latest DB | Brief Connect 2.5.10 and above |
Azure DocumentDB; Azure SQL when required by deletion |
Prerequisites
Before creating the VM, confirm:
- The target subscription and resource group are approved for the matching Brief Connect environment, and the deployment region is the primary region used by that environment's Brief Connect resources.
Standard_B2ls_v2and the selected Windows image are available in the target region and subscription. If unavailable, obtain approval for an equivalent or larger Windows-compatible SKU with at least 2 vCPU and 4 GiB RAM.- The existing subnet has sufficient address capacity and uses the required NSG, route table, DNS, firewall, proxy, peering, VPN, or ExpressRoute configuration.
- The administration path can reach TCP 3389 without exposing RDP broadly to the public internet.
- The subnet can reach the existing Brief Connect Key Vault and the services for the selected database model.
- Outbound HTTPS is available to Microsoft Graph, SharePoint Online, and the Microsoft Entra endpoints required by Entra VM login.
- Private DNS resolves every required Private Link endpoint from the subnet where applicable.
- The existing Brief Connect Key Vault uses Azure RBAC authorisation.
- An Entra security group contains only the authorised tool operators.
- The deployer can create VM, NIC, and disk resources and can create role assignments on the new VM and existing Key Vault.
- A strong bootstrap local administrator credential has been generated and can be stored and rotated using the customer's approved credential-management process.
- The intended output volume has sufficient capacity for the largest expected job. Output must survive process failure, operator sign-out, RDP disconnection, and VM restart.
Do not weaken an existing service firewall, enable public access, or add an allow-all rule solely to make the VM connect. Establish the approved private or restricted network path instead.
Create the VM
Open the VM wizard
- Sign in to the Azure portal and select the approved subscription.
- Open Virtual machines.
- Select Create, then Azure virtual machine.
Basics
Set:
| Portal setting | Value |
|---|---|
| Subscription | Approved target subscription |
| Resource group | Dedicated customer-controlled tools resource group |
| Virtual machine name | Approved <vm-name> |
| Region | Primary region used by the Brief Connect resources for the selected environment |
| Availability options | No infrastructure redundancy required |
| Security type | Trusted launch virtual machines |
| Secure Boot | Enabled |
| vTPM | Enabled |
| Image | Windows Server 2022 Datacenter: Azure Edition - x64 Gen2 |
| Size | Standard_B2ls_v2 |
| Username | Approved bootstrap local administrator name |
| Password | Approved bootstrap password; do not put it in a ticket or deployment notes |
| Public inbound ports | None |
| Existing Windows Server licence | Set according to the client's licensing policy and verified entitlement |
The bootstrap account is required to provision a generalized Windows image. It is not the normal operator identity. Store and rotate it according to customer policy, and use Entra ID for day-to-day operator access.
Disks
Configure the OS disk:
| Portal setting | Value |
|---|---|
| OS disk type | Standard SSD (locally-redundant storage) |
| OS disk size | 128 GiB / E10 |
| Delete with VM | Enabled |
Add one new data disk:
| Portal setting | Value |
|---|---|
| Disk name | <vm-name>-tools-data |
| Source type | None / empty disk |
| Size | 64 GiB / E6 |
| Storage type | Standard SSD LRS |
| Host caching | None |
| Delete with VM | Disabled / detach when the VM is deleted |
The data disk deliberately survives deletion of the VM resource. Treat retained disks as sensitive and remove them only through the customer's approved data-disposal process.
If the VM wizard does not expose managed-disk network settings, configure them after creation:
| Portal setting | Value | | Public network access | Disabled | | Network access policy | Deny all |
- Open the
<vm-name>-tools-datamanaged disk. - Open Networking.
- Set public network access to Disable.
- Set network access to Deny all where the portal presents it separately.
- Save and verify the disk cannot be exported over a public endpoint.
Networking
Configure:
| Portal setting | Value |
|---|---|
| Virtual network | Existing approved VNet |
| Subnet | Existing approved tools-capable subnet |
| Public IP | None |
| NIC network security group | Use the existing subnet or approved NIC-level policy |
| Public inbound ports | None |
| Accelerated networking | Disabled |
| Delete NIC when VM is deleted | Enabled |
Do not create a new permissive NSG. If an NSG change is required, use a separate approved network change and restrict RDP to the approved Bastion, VPN, privileged workstation, or equivalent source. Do not add inbound SSH for this Windows VM.
Management
Configure:
| Portal setting | Value |
|---|---|
| System-assigned managed identity | Enabled |
| Login with Microsoft Entra ID | Enabled, if shown in the wizard |
| Auto-shutdown | Disabled unless its schedule cannot overlap tool sessions or maintenance activity |
| Patch orchestration | Customer Managed Schedules |
| Periodic assessment | Enabled |
| Patch orchestration options | Manual updates; or other approved options with controlled restarts separately not during tools runtime, through an approved manual maintenance action |
If the wizard does not expose Entra login, install the extension after VM creation as described below.
Monitoring
| Portal setting | Value |
|---|---|
| Boot diagnostics | Enabled with managed storage |
| OS guest diagnostics | Customer policy; not required for template equivalence |
Advanced and tags
- Do not add custom data, scripts, secrets, certificates, or extensions other than the Microsoft Entra login extension required by this guide.
- Apply the approved tags required by customer policy.
- Do not domain-join the VM if Microsoft Entra VM login will be used. The Entra login extension joins the VM to Entra ID and is not compatible with joining the same VM to another domain.
Review and create
Before selecting Create, verify the summary shows:
- One Windows Server 2022 Azure Edition Gen2 VM.
- Trusted Launch, Secure Boot, and vTPM enabled.
Standard_B2ls_v2, or the approved replacement size.- A 128 GiB Standard SSD LRS OS disk.
- A 64 GiB Standard SSD LRS data disk.
- The existing approved subnet.
- No public IP and no public inbound ports.
- System-assigned managed identity enabled.
- No unexpected resources, marketplace plans, extensions, or broad access rules.
Submit the deployment and wait until provisioning succeeds. Do not continue if the VM or guest agent reports a failed state.
Configure identities
Verify the system-assigned identity
- Open the new VM.
- Open Identity.
- On System assigned, confirm Status is On.
- Record the principal/object ID in the deployment evidence. This identifier is not a secret.
Attach the SQL identity when required
Perform this section only for Latest DB deletion operations that require Azure SQL. Skip it for Legacy DB and for operations that do not use Azure SQL.
- On the VM, open Identity.
- Open User assigned and select Add.
- Select the existing Brief Connect SQL managed identity for the same environment.
- Confirm the identity name and resource group with the Brief Connect owner before adding it.
- Add the identity and verify it appears once on the VM.
Do not create a replacement identity and do not attach a general application identity. This procedure does not create or alter Azure SQL database users or roles. The existing identity already have the approved database permissions required by the tool operation.
Configure Key Vault access
Assign the role to the VM system identity, not the SQL user-assigned identity or the operator group:
- Open the existing environment-specific Brief Connect Key Vault.
- Open Access control (IAM).
- Select Add, then Add role assignment.
- Select the
Key Vault Secrets Userrole. - For assignment type, select Managed identity.
- Select members, choose Virtual machine, and select the new tools VM.
- Review and assign the role.
- Verify the resulting assignment is scoped to this Key Vault and identifies the VM system-assigned identity.
Configure Microsoft Entra login
Install or verify the extension
- Open the VM and select Extensions + applications.
- Confirm
AADLoginForWindowsis present and its provisioning state is Succeeded. - If it is absent, select Add, choose the Microsoft Entra ID based Windows login extension, and install it.
- Recheck that the VM system-assigned identity remains enabled.
The subnet must permit the Entra registration and authentication endpoints required by Microsoft. Extension failure must be resolved before granting operators access.
For Azure Global, required Entra VM login paths include:
https://enterpriseregistration.windows.nethttps://login.microsoftonline.comhttps://pas.windows.net- Azure Instance Metadata Service at
http://169.254.169.254
More information about this feature here: https://learn.microsoft.com/en-us/entra/identity/devices/howto-vm-sign-in-azure-ad-windows
Grant the operator group access
- Open the VM's Access control (IAM) page.
- Select Add, then Add role assignment.
- Select
Virtual Machine Administrator Login. - Assign access to User, group, or service principal.
- Select the approved Entra operator security group.
- Review and assign the role at the VM scope.
Configure patching and diagnostics
Patching
- Open the VM and select Updates or Update settings.
- Set patch orchestration to Customer Managed Schedules.
- Enable periodic assessment.
- Create or assign an Azure Update Manager maintenance configuration for the customer's approved patch-installation window.
- Set the maintenance configuration reboot option to
Neverso patch installation cannot automatically restart the VM. - Ensure the patch-installation window does not overlap planned or active EC Tools sessions.
- Configure monitoring for updates that require a restart and the Windows pending-restart state.
Configure VM restart as a separate, manually controlled maintenance action. Before restarting, confirm that no EC Tools process or job is active, retained output has been flushed to persistent storage, and operators have been notified. Restart the VM only in an approved maintenance window, then verify that the VM, guest agent, data volume, and required network paths are available before releasing it for tool use.
Do not use automatic guest patching, a maintenance configuration that permits reboot, or any other restart policy that can interrupt an active tool session.
Boot diagnostics
- Open Boot diagnostics under the VM's support or diagnostics settings.
- Confirm boot diagnostics is enabled using an Azure-managed storage account.
- Verify a current screenshot or serial-log status can be retrieved without exposing credentials.
Apply endpoint protection, monitoring, backup, disk-encryption, vulnerability-management, and access-review controls required by customer policy. These controls are intentionally outside the common deployment because their architecture differs by customer.
VM backup does not replace the tools' dry-run, checkpoint, journal, or evidence requirements. If the VM is deallocated when idle, compute charges stop but managed disk and other retained-resource charges continue.
Secure the managed data disk
Use the customer-approved administration path to sign in to Windows. Initialise only the new 64 GiB disk.
Initialise using Disk Management
- Run
diskmgmt.mscas administrator. - Identify the offline, unallocated 64 GiB disk. Do not select the OS disk or a temporary resource disk.
- Bring the disk online.
- Initialise it as GPT.
- Create one NTFS volume using the available capacity.
- Assign the customer-approved drive letter, such as
E:. - Use a descriptive volume label such as
ECToolsData.
Validate network access
Validate DNS resolution and TCP connectivity from the VM. Use read-only probes and do not print response bodies containing customer data or authentication material.
All environments require:
| Destination | Required access |
|---|---|
| Existing Brief Connect Key Vault | HTTPS 443 through its approved public or private path |
| Microsoft Graph | HTTPS 443 |
| SharePoint Online | HTTPS 443 |
| Microsoft Entra login and registration endpoints | HTTPS 443 |
| Azure Instance Metadata Service | Local link 169.254.169.254 as required for managed identity |
Validate only the active database model:
| Database model | Destination |
|---|---|
| Legacy DB | Required Azure Storage Table and Blob endpoints for Data storage account |
| Legacy DB | Required Azure Cosmos DB endpoint |
| Latest DB | Azure DocumentDB endpoint |
| Latest DB | Azure SQL endpoint, normally TCP 1433 or the customer's approved redirect/private path |
Example non-authenticated connectivity checks are:
Resolve-DnsName '<key-vault-name>.vault.azure.net'
Test-NetConnection '<key-vault-name>.vault.azure.net' -Port 443
Test-NetConnection 'graph.microsoft.com' -Port 443
Test-NetConnection '<tenant>.sharepoint.com' -Port 443
Add equivalent checks for the selected database endpoints. A successful TCP check proves network reachability only; the tool preflight must still validate authentication and permissions without writing customer data.
Do not use live deletion or SharePoint metadata updates as an infrastructure connectivity test.
Final verification
Complete this checklist before tool packages are installed:
| Check | Expected result |
|---|---|
| VM provisioning state | Succeeded |
| Guest agent | Ready |
| OS and image | Windows Server 2022 Datacenter: Azure Edition x64 Gen2 |
| VM size | Standard_B2ls_v2 or approved equivalent with at least 2 vCPU and 4 GiB RAM |
| Security | Trusted Launch, Secure Boot, and vTPM enabled |
| OS disk | 128 GiB Standard SSD LRS |
| Data disk | 64 GiB Standard SSD LRS, LUN 0, caching None, retained on VM deletion |
| NIC | Existing approved subnet and dynamic private IP |
| Public exposure | No public IP; no broad inbound RDP or SSH rule |
| VM system identity | Enabled |
| Key Vault role | VM system identity has only Key Vault Secrets User for required secret retrieval |
| SQL identity | Correct existing SQL identity attached only when required |
| Entra login extension | Provisioning succeeded |
| Operator role | Approved group has Virtual Machine Administrator Login at VM scope |
| Patching | Customer-managed patch schedule assigned, periodic assessment enabled, patch reboot set to Never, and separate manual restart process defined |
| Boot diagnostics | Enabled with managed storage |
| Data volume | NTFS volume online with sufficient free space |
| DNS and routing | Required endpoints resolve and are reachable through approved paths |
| Customer controls | Endpoint protection, monitoring, backup, encryption, retention, and access review applied as required |
Record resource names, resource IDs, non-secret configuration, role-assignment scopes, test dates, approvers, and outcomes in the deployment evidence. Do not include secret values or unrestricted service responses.
Handover
After infrastructure verification:
- Deliver the self-contained
win-x64tool packages through the customer's approved software-delivery channel. - Store packages and run configuration on the tools data volume.
- Configure exactly one compatible Legacy DB or Latest DB model for the target environment.
- Run each tool's non-destructive preflight and resolve every reported infrastructure or permission error.
- Perform deletion dry runs before any live deletion and follow the application shutdown, queue-drain, review, and explicit confirmation procedures in the deletion guide.
- Retain or dispose of deployment evidence and tool output according to customer governance policy.
Removal
Removal is a separate privileged change. Before deleting the VM:
- Confirm no tool run is active and required evidence has been retained.
- Remove the operator group's VM login role assignment.
- Remove the VM system identity's Key Vault role assignment.
- Confirm whether the tools data disk must be retained, archived, securely erased, or deleted.
- Delete the VM and NIC according to customer policy.
- Delete the retained tools data disk only after explicit data-owner approval.
- Review the existing SQL identity and Key Vault to confirm no obsolete assignment remains. Do not delete the existing Brief Connect SQL identity or Key Vault.