Azure Pilot Hosting Plan

Updated 9 September 2026

Proposed Deployment

Availability check, 9 September: The smaller B1ms is unavailable for this subscription in Southeast Asia (NotAvailableForSubscription), both with Zone 1 and without a zone constraint. The portal offers B2als_v2 (2 vCPU / 4 GiB) at USD34.46/month for compute, or USD45.31/month with the same disks and IP. The user selected the Singapore alternative and approved creation. Azure reports deployment complete and the VM Running. SSH through the restricted gateway passed; Ubuntu initialization completed, with 64 GiB OS and 32 GiB data disks verified. The empty data disk is now formatted and mounted at /opt/ocdit/data. OCDIT and production dependencies are installed with Node.js 24.13.0 and a restricted service account. A temporary loopback-only fixture smoke test passed health, Inbox, Studio and SQLite integrity checks. The live service remains disabled until its client identity, Teams scope and protected configuration are ready. No old tickets were copied.

Use one Ubuntu 24.04 LTS virtual machine in the client-approved resource group, Southeast Asia. Run the existing Node.js service and SQLite databases on persistent local managed disks. Keep the central portal on the current owned host initially. This preserves the tested runtime and avoids a database or container-platform migration.

Rates retrieved from the Azure Retail Prices API on 9 September 2026: VM USD0.0472/hour; public IP USD0.005/hour; disks at the monthly rates above. Disk transactions, outbound traffic, backup storage and tax are extra. Use USD60/month as a planning allowance, not an enforced cap. Credits and subscription discounts are not assumed. Regional SKU availability, quota and the portal estimate still need validation. Do not create resources until the priced configuration is approved.

The Basv2 size specification describes the burst-credit model. AI inference runs at the provider, not on this VM; validate memory use, response time and CPU credits during testing. Build release assets before deployment. Resize only if measured usage warrants it.

This is an early pilot, not a high availability production deployment. Confirm image/security compatibility and regional availability before provisioning; do not silently weaken security or substitute a larger machine.

Network and Identity

• Create a dedicated VNet, subnet, NIC and NSG in the approved group. No peering or changes to existing networks, subscription roles or unrelated resources.
• Password SSH disabled; use a dedicated pilot key. SSH and HTTPS ingress to the VM are restricted to the existing gateway host. Node listens on loopback.
• Use the Azure public-IP DNS label for the VM's TLS endpoint. Permit port 80 only for certificate validation and HTTPS redirection. Verify TLS from the gateway.
• Keep the current public hostname. After readiness checks, update only the OCDIT Inbox, bot and connector proxy targets to the Azure runtime. The gateway verifies the upstream certificate; no insecure certificate bypass.
• Keep the old runtime and its data for rollback and central administration. Do not attach both runtimes to the same live connector at once.
• Register a separate single-tenant OCDIT Support app and free-tier Azure Bot. Do not reuse the central Administration app for Teams SSO or bot credentials.
• Central operators retain administration. The two supplied support identities receive support access only; proceed on the user's assumption that they already have Teams.

Deployment Order

1. Agent: Validate resource group, quota, SKU and the reviewed price in Azure.
2. User: Approve the chargeable deployment; complete sign-in or MFA when required.
3. Agent: Provision the isolated resources and install the existing runtime using a pinned Node version, restricted service account and protected credentials.
4. Agent: Create fresh customer databases and import the portable fictional source pack. Configure the two support IDs. Never copy the existing demo's ticket history.
5. Agent: Configure the separate support app, bot, exact SSO scope and client Teams package. Attempt only permissions available to the implementation account. Record any Teams-admin dependency instead of repeatedly contacting the client.
6. Agent: Add the new runtime to the central catalogue, verify signed delegation and access separation, and test backup/restore on an isolated copy.
7. Agent: Take consistent backups and switch the dedicated support proxy routes only after the new runtime passes readiness. Test assets may be reused, with credentials copied privately and only one active consumer per connector.
8. Testers: Complete real shared-support acceptance when available. Lung Hao may test the Admin Portal in his own time; it is not a prerequisite for infrastructure work.

Backup and Rollback

Keep SQLite online backups with restricted permissions. Local backups alone do not protect against VM loss: obtain an independent protected export before accepting the pilot, and select Azure backup storage within the approved allowance. Retain the old runtime, routing and credentials through acceptance. If rollback is required after new messages arrive, reconcile those messages; never restore an old database over new inbound work. VM deallocation stops compute billing, but disks and IP can still incur charges.

Current Boundary

Azure sign-in succeeded on 9 September. The initial VM creation page reported unregistered Microsoft.Network and Microsoft.Storage providers, which the signed-in account could not register. After the client's update, both providers were verified Registered in Subscriptions → Resource Providers, and a fresh VM wizard no longer showed that error. This blocker is resolved. The Entra Cloud Application Administrator role is separate from Azure subscription permissions. The remaining size restriction is described above; no repeat confirmation of tester Teams access is needed.

The approved VM, dedicated network/security group, public IP and disks are created. SSH is restricted to the existing gateway. Installation and data-disk setup are complete; HTTPS, certificate-validation rules and the separate client Teams app/bot are configured. Live configuration and connector cutover are outstanding. The original service and connector routing are unchanged. The separate single-tenant OCDIT Support app registration is created in Entra. Its replacement runtime credential is stored privately. Version 2 tokens and the Teams API identifier are configured. The delegated sign-in scope is enabled and both official Teams clients are authorized for that scope. Teams installation and real client sign-in verification remain outstanding. OpenRouter remains the live AI provider; Azure AI testing and cutover are separate.

Azure Bot Registration Resolved

The client registered Microsoft.BotService. The same prepared configuration then passed validation, and Azure reported the bot deployment complete on 9 September: F0 Free, Global, Single Tenant, using the existing support app in the approved resource group. Microsoft Teams Commercial channel settings are saved after publication terms acceptance. Runtime connectivity is still pending; this is not yet a live Teams test.

For future subscriptions, if the same provider error appears, a subscription administrator opens Azure Portal → Subscriptions → the pilot subscription → Resource Providers, searches Microsoft.BotService, and clicks Register. Wait for Registered, then retry. No broader implementation role is needed.

HTTPS Preparation

The VM's dedicated Azure DNS label resolves to its public IP. Nginx serves only /.well-known/acme-challenge/ on HTTP; all other paths return 404. Local checks passed. A Let’s Encrypt certificate is issued, expiring 8 December 2026; automatic renewal and the nginx reload hook are configured. The simulated certificate renewal passed.

The approved firewall rules are saved on this VM’s security group: TCP 443 from the existing gateway only, and TCP 80 for public certificate validation. The gateway verified TLS without bypassing certificate checks. HTTPS initially returned 503 while the application was stopped. The runtime now serves health and administration paths; support paths remain staged. existing support traffic stays on the original runtime until readiness checks pass.

Teams Admin Tenant Selection

For a client tenant, open https://admin.teams.microsoft.com/?delegatedOrg=<client-tenant-domain>. On 9 September this route selected the intended client organization, but returned INVALID_PRIVILEGE for the implementation account. The error page's Organization ID confirmed the client tenant. A tenantId query and switching organizations in My Account had continued to open the home tenant instead.

Selecting a tenant does not grant access. Cloud Application Administrator covers app setup, not Teams administration. A client administrator can either complete the team/app setup or assign the implementation account Teams Administrator for setup, then remove the temporary role afterward. No role was changed during this check. See Microsoft Teams Admin Roles.

The client subsequently assigned Teams Administrator. Entra confirmed it as an active direct assignment. After a fresh sign-in, the client dashboard opened, but Manage Teams still returned INVALID_PRIVILEGE and some catalog controls were absent. Do not request the same role again based only on this portal error. The official MicrosoftTeams PowerShell module successfully connected using the explicit client TenantId and device authentication; its team lookup succeeded. This provides a working setup route without increasing directory permissions.

The private OCDIT Support team and standard Support Pool channel are now created. Independent PowerShell verification confirmed exactly the two nominated testers, one owner and one member. The group ID, native Teams ID and channel ID are recorded privately for runtime binding. App installation, client sign-in and live connector routing remain unverified; the original demo has not been cut over.

Client Runtime Staged

The Azure runtime is running on loopback with the verified client identities and fresh support and Studio databases. Health and database checks pass; anonymous Inbox and Admin API requests return 401. Consistent backups of both databases pass integrity and foreign-key checks. No existing conversations were copied.

The central portal now lists 99 Venture alongside the existing test workspace. Jason's Microsoft sign-in, workspace selection and policy save passed through the HTTPS administration connection to Azure. Workspace-wide AI is enabled without a daily request cap; provider credit and Studio controls still apply. Sample agents and approved company knowledge are prepared as recorded below.

The client Teams package upload returned an organization catalog app ID. It has not yet been installed for the team or testers. Only Azure health and Admin API paths are enabled through its gateway-restricted HTTPS listener. Inbox and message paths remain staged; customer traffic still uses the original runtime. This is not yet a successful client Teams or messaging test.

Sample Agents and Installation Gate

The fresh client workspace now contains the portable sample pack: 21 sources, three reviewed knowledge items, three approved flows and published Ari/Rowan agents. The excluded source remains blocked. Eight deterministic scenario checks passed. One real GPT-5.4 Mini evaluation completed for the registration deadline at a reported US$0.00076725, without a customer send. Its reply included the current deadline, required CSV columns and organiser approval. Literal phrase scoring was 0.4 because wording differed; this is a heuristic result, not a general model-quality score.

App installation remains blocked on catalog verification. The upload returned an app ID, but later PowerShell catalog reads were empty. The client Manage Apps page still returned INVALID_PRIVILEGE to the guest administrator. Another app availability cmdlet failed local Windows broker authentication. These results do not establish that the upload was lost; do not create duplicate uploads blindly.

Both testers have no direct app policy assignments. The legacy global policy read showed an empty custom-app allowlist; effective availability under unified app management is not yet verified. No tester or global policy was changed. A tenant account administrator should inspect Manage Apps → OCDIT, confirm availability for the two testers, then coordinate installation with routing readiness. Assigning the same Teams Administrator role again is not the next step.

Client Approval Reported

The user reports that the client administrator completed the app availability task. The implementation account still receives an empty catalog response; this does not override the client confirmation or justify another upload. Verify installation with the nominated testers when routing is ready. WhatsApp recipient verification for the nominated tester is independently confirmed in Meta. The private tester contact note is updated. No test message or routing change was made for this check.

Routing Prepared, Awaiting Azure Sign-In

Both runtime databases passed integrity checks, and neither support job queue had queued or sending work. Fresh consistent backups of both databases and the dedicated nginx configuration were taken on both hosts before routing preparation.

Azure now serves the Inbox, authenticated Inbox API, bot endpoint and the three connector webhooks behind the existing gateway-only HTTPS firewall. From the gateway, TLS-verified checks passed for the Inbox shell, anonymous API/bot denial, invalid webhook signature rejection, a valid WhatsApp verification challenge and an empty signed WhatsApp callback. No customer message was sent or old history copied.

The public proxy configuration is prepared but not applied. Central administration and guides retain their existing routes. The proxy verifies Azure's TLS certificate and disables upstream retries. Azure portal sign-in is required to save the isolated client bot's messaging endpoint before activating public support routing.

Azure Support Routes Activated

The isolated client bot configuration was saved successfully with the existing public messaging endpoint. The public Inbox, Inbox API, bot and WhatsApp/LINE/WeChat webhook routes now forward to the client Azure runtime over verified TLS. Azure's service is enabled on boot. Central administration and hosted guides remain on the existing gateway; unrelated applications and their nginx files are unchanged.

The public Inbox returns 200 and its API rejects anonymous access with 401. The full origin route passed health, Inbox, API/bot authentication rejection, invalid webhook signature rejection, a valid WhatsApp challenge and an empty signed callback. A public-domain request originating from the gateway received 403; direct origin checks with certificate verification and external public checks passed separately. This is not yet evidence of a real provider-to-Teams round trip.

Client staff installation, Teams sign-in, notifications and a real WhatsApp reply remain the next acceptance checks. The former demo's support data is preserved, not copied into the client runtime. Its old Teams app no longer connects to the public Inbox; the client app and nominated client support identities are required.

First Client Inbound Test

The user's WhatsApp test message was captured exactly once in the new Azure client workspace and zero times in the previous demo. The Teams notification job has an uncertain outcome; no channel thread or personal bot registration is recorded. Do not automatically replay that job. This verifies WhatsApp capture and routing isolation, not successful Teams delivery or a complete reply round trip.

Tester Installation

1. Sign in to Teams with a nominated support account.
2. Open Apps, search for OCDIT, and add the organization app.
3. The OCDIT Support team owner adds the app to that team using the app's Add to a Team option, where available.
4. Open OCDIT's Inbox and confirm the test enquiry appears.
5. Reply from the Inbox; confirm receipt on the tester's WhatsApp.

If the app is missing or Teams refuses installation, capture the exact message. App availability approval does not by itself prove installation or successful SSO.