/setup

description: Setup wizard — provision Vertex/Bedrock/Foundry/gateway, admin consent, generate manifest(s)

Claude in Office — Direct Cloud Setup

You are walking an enterprise admin through configuring the Claude Office add-in to call their own cloud instead of Anthropic's API. The output is a customized `manifest.xml` they deploy via M365 Admin Center.

**Before anything else:** the setup log lives at `~/Desktop/claude-for-msft-365-install-setup.md` (resolve `~` for their platform). If it exists, read it first — you may be resuming a prior run and can skip completed steps. Start a new `## Run — <timestamp>` section and append each command and its captured output (IDs, URLs) as you go.

**Check for Node.js** — Steps 4 and 6 shell out to `node` and `npx`. Run `node --version`. If it's missing, **ask before installing** — it's their machine. If they say yes, `brew install node` (mac) / `winget install OpenJS.NodeJS` (win) / whatever their package manager is. If no, stop here.

**When capturing values from the admin** (IDs, URLs, secrets pasted back from a console) — don't use AskUserQuestion. That's a choice picker; they're holding a string. Just say "paste the Client ID when you have it" and read it from their next message. Use AskUserQuestion only for the actual branch points (gateway vs vertex, per-user vs org-wide).

Step 1 — How does the add-in reach Claude?

Ask this first, because it's the thing admins get wrong: **do you already run an LLM gateway (LiteLLM, Portkey, Kong, etc.)?**

• **Yes → `gateway`.** Even if the gateway routes to Vertex or Bedrock under

the hood — the add-in talks to *your gateway*, not to Google or AWS. You just need the gateway URL.

• **No → `vertex` or `bedrock`.** The add-in authenticates directly to the

cloud provider. Pick where your infra lives.

| Path | What it means | Provisioning | Manifest keys | |---|---|---|---| | `gateway` | Add-in → your gateway → (whatever) | None | `gateway_url` (+ `gateway_api_format` if not `/v1/messages`) | | `vertex` | Add-in → Google Vertex AI, directly | Google OAuth client | `gcp_project_id`, `gcp_region`, `google_client_id`, `google_client_secret` | | `bedrock` | Add-in → AWS Bedrock, directly | IAM OIDC provider + role | `aws_role_arn`, `aws_region` | | `foundry` | Add-in → Azure AI Foundry, directly | Foundry resource + API key | `azure_resource_name`, `azure_api_key` | | `foundry` (keyless) | Add-in → Azure AI Foundry, per-user Entra sign-in | Foundry resource + your Entra app | `azure_resource_name`, `entra_sso=1`, `graph_client_id`, `entra_scope=https://cognitiveservices.azure.com/.default`, `gateway_auth_source=entra` |

Bedrock and per-user config (bootstrap endpoint or extension attrs) need `entra_sso=1` — the add-in acquires the user's Entra ID token to authenticate those flows. See the Entra SSO section in [manifest](manifest.md).

Step 1b — Which Office apps?

Ask: **Excel/Word/PowerPoint, Outlook, or both?** Outlook is a separate manifest and has extra prerequisites.

If they're deploying Outlook:

• **Outlook needs a newer model.** On a third-party platform, Claude for

Outlook supports only Claude Opus 4.7 and later and Claude Sonnet 5 and later. Confirm one of those in Step 6: with only older models enabled, the add-in connects and then fails on every message.

• **Microsoft Graph admin consent is required.** Run

[consent](consent.md#outlook--microsoft-graph-consent) — a Global Admin opens one URL and clicks Accept. Do this before generating the manifest so you can ask whether they're using Anthropic's app (no `graph_client_id` needed) or their own Entra app (capture `graph_client_id`).

Branch to the matching section below.

---

Vertex AI

1a. Prerequisites

Confirm with the admin:

• GCP project ID (they should know this)
• Region with Claude model quota (typically `us-east5`)

1b. Create the OAuth client

No `gcloud` command exists for this. Open the console link (substitute their project ID), walk them through, they paste back the client ID and secret.

> Open: `https://console.cloud.google.com/apis/credentials?project=<PROJECT_ID>` > → **Create Credentials** → **OAuth client ID** > - Application type: **Web application** > - Name: `Claude for Office` > - Authorized redirect URI: `https://pivot.claude.ai/auth/callback` > → **Create** → copy the **Client ID** and **Client Secret**

Enable the Vertex API while they're there:

gcloud services enable aiplatform.googleapis.com --project=<PROJECT_ID>

Capture: `gcp_project_id`, `gcp_region`, `google_client_id`, `google_client_secret`.

Continue to [Step 3](#step-3--decide-whats-org-wide-vs-per-user). Vertex uses Google OAuth, not Entra, so admin consent isn't needed unless you also opt into per-user config (in which case come back to Step 2 after deciding in Step 3).

---

Bedrock

1a. Prerequisites

Confirm with the admin:

• AWS account ID and a region with Claude model access (usually `us-east-1`)
• Their Azure tenant ID (from Entra admin center, or `az account show --query tenantId`)
• `aws` CLI configured against the target account

1b. Create OIDC provider + role

Three `aws iam` calls. The trust policy's `aud` condition is the security boundary — only tokens Azure minted for the Claude add-in can assume this role.

If a manifest will carry their own Entra app (`graph_client_id`, captured in "Step 1b — Which Office apps?"), the add-in signs in as that app, so the ID token's `aud` is that app's client ID and AWS rejects it unless it is listed. Set `CLAUDE_APP_ID` below to their app's ID instead; if one manifest uses their app and the other Anthropic's, list both IDs (`--client-id-list "<id1>" "<id2>"`, and `["<id1>", "<id2>"]` as the value of the trust policy's `aud` condition).

Substitute their tenant ID and region:

TENANT_ID="<their-azure-tenant-guid>"
CLAUDE_APP_ID="c2995f31-11e7-4882-b7a7-ef9def0a0266"
AWS_REGION="us-east-1"
ACCOUNT=$(aws sts get-caller-identity --query Ac