Client Rollout

Updated 9 September 2026

Bring OCDIT into your Microsoft 365 environment while keeping central administration with 99 Venture.

Current Position

Public support routes now point to the client Azure runtime. A separate Azure client runtime now has the client team/channel bindings, fresh databases, sample knowledge and published agents. Central administration lists both workspaces, and the client runtime has passed a real OpenRouter model check. The user reports that client app availability is approved. Teams installation, client staff sign-in and a real messaging round trip remain to be verified. See Azure Pilot Hosting Plan for current setup evidence. Azure inference has not replaced OpenRouter.

What Resource Group Access Covers

Azure resource group permissions control Azure resources in that group. They do not automatically grant permission to register applications in Microsoft Entra ID, approve API consent, publish a Teams application or assign Microsoft 365 licenses. The client needs an administrator for those separate tasks.

Azure AI Setup Result

The Azure OpenAI resource was created successfully in Southeast Asia with Standard S0, network access disabled, no private endpoints and no model deployment. The previous subscription-registration validation blocker is cleared.

No inference requests were made, keys retrieved or live provider settings changed. The empty resource is preparation only; model availability, quota, network access and the chosen model's cost still need review before an approved inference test. Standard inference is usage-priced; no provisioned throughput or fine-tuning was configured. See Azure OpenAI Pricing.

Next: Confirm the model, processing region and a small test budget. Then the implementation agent can prepare a controlled model test before any cutover.

Visual Studio credit eligibility and remaining balance must be checked separately; the subscription name is not evidence of available funds or production-use rights. See Visual Studio Azure Credit Eligibility.

Rollout Checklist

99 Venture operators alone receive OCDIT administration access. The customer's Microsoft 365 administrator approves installation without receiving portal access. Use Central Tenant Administration to configure the central gateway and separate customer runtime before onboarding staff.

1. Client: Open Azure Resource Groups. Share the intended resource group name, subscription and directory. Confirm the permitted region and a hosting budget.
2. Client: Nominate a Microsoft 365 administrator and the initial support staff. Confirm each tester has Teams access. Nominate the 99 Venture platform administrators separately.
3. Implementation Agent: Inspect the named group, effective access, existing resources and regional capacity. Prepare a priced hosting plan before creating chargeable resources.
4. Client Administrator and Implementation Agent: In Microsoft Entra, create the isolated client application identity and configure OCDIT sign-in. Preserve existing applications and policies. Complete the exact application consent when prompted.
5. Implementation Agent: Register the client Teams bot, prepare the client-specific app package and configure only the intended support team, channel and staff access.
6. Client Administrator: In Teams Administration, approve the OCDIT package for the selected testers. Avoid changing organization-wide upload policies solely for this test.
7. Client: Choose the business messaging accounts and complete any required provider login, verification or terms acceptance. Do not move an existing business number until its current use and migration path are confirmed.
8. Implementation Agent: Deploy a separate runtime with separate support and Studio databases, credentials and connector configuration. Import the portable sample pack; do not copy another organization's messages or credentials.
9. Client Testers and Implementation Agent: Test sign-in, assignment, shared replies, signatures, transfer, summaries, consented history and personal notifications. Confirm real multi-person access separation.
10. Client: Accept the results and approve the final routing change. Keep the existing demo available until the new instance passes acceptance.

Hosting and the Existing Address

The concrete pilot proposal and current retail estimate are in Azure Pilot Hosting Plan. The user has directed setup to proceed on the assumption that the two nominated testers have Teams access. Do not request another client confirmation or block infrastructure work on the second operator's portal test.

The existing address can remain during transition. It does not make the existing tenant's bot or authentication valid for another organization. Client identity, data and connector routing must be configured deliberately.

The simplest initial Azure deployment is one isolated Node.js runtime on Linux with persistent local storage for the existing SQLite databases. An Azure VM can preserve the current service and database format, but the VM, disks and network traffic are chargeable. Price it before provisioning. Do not place these SQLite files on a shared network filesystem or run several writers across scaled-out instances.

A separate test hostname is the simplest way to run both support tenants concurrently. The central administration gateway can manage separate runtimes; this does not make the shared Inbox and connector paths tenant-aware. Keeping one exact hostname for both support tenants requires reviewed path routing, callback URLs, cookie boundaries and application base-path support. Alternatively, keep the current demo on the existing address until an agreed support-runtime cutover. Do not change DNS while the current demo is in use.

Azure AI Feasibility

Yes: model inference can be billed to the client's Azure subscription. Azure OpenAI models sold through Microsoft Foundry are billed by Microsoft. OCDIT's knowledge, personalities and human-review workflow can remain in the application; moving inference does not require rebuilding the agent builder or buying Copilot Studio licenses. See Microsoft Foundry Cost Management.

The current transport is OpenRouter-specific. An Azure transport must adapt authentication, deployment naming, structured output, token accounting and error handling. Azure does not return OpenRouter's cost fields. Cost estimates must use the selected deployment's published rates and be reconciled against Azure billing. Existing pending reservations and provider provenance must remain intact.

Initial Setup Boundary

• Verify subscription eligibility, the exact resource group, region, model availability, quota and role permissions.
• Prepare a standard, usage-priced Azure OpenAI resource configuration. Create it only after confirming that the exact configuration has no standing charge and requires no paid dependencies.
• Do not provision throughput, fine-tuning, hosted agents, AI Search, private endpoints or other chargeable services for this feasibility check.
• Do not run model requests, deploy a chargeable model or switch the live provider during this check. Model inference is chargeable even if creating its resource is not.
• Keep OpenRouter active until a separate, budgeted Azure test verifies summaries, reply drafts, policy gates and accounting.

Azure region and deployment type affect model availability and data processing location. Resource group location alone does not determine inference residency. Review the chosen model and deployment with the client before enabling it. See Create an Azure OpenAI Resource.

Demo AI Quotas

Demo limits are deployment settings, separate from the provider's prepaid credit. A high application limit does not increase OpenRouter credit or guarantee provider availability. Administrators can review daily request and token limits in Administration and Studio. Raising quotas does not disable source permissions, review requirements, the execution stop or message-size safeguards.

Acceptance Before Cutover

The existing single-user transport tests do not replace this client acceptance.