/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` |

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 one extra prerequisite.

If they're deploying Outlook:

• **Bedrock is not currently supported for Outlook.** If they picked `bedrock`

in Step 1, Outlook is off the table for now — generate only the `office` manifest.

• **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.

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 Account --output text)
ISSUER="login.microsoftonline.com/${TENANT_ID}/v2.0"

# OIDC identity provider. Thumbprint is required by the API; AWS validates
# major IdPs via its own trust store, but the param can't be omitted.
THUMBPRINT=$(openssl s_client -servername login.microsoftonline.com \
  -connect login.microsoftonline.com:443 </dev/null 2>/dev/null \
  | openssl x509 -fingerprint -sha1 -noout | cut -d= -f2 | tr -d ':')

aws iam create-open-id-connect-provider \
  --url "https://${ISSUER}" \
  --client-id-list "${CLAUDE_APP_ID}" \
  --thumbprint-list "${THUMBPRINT}"

PROVIDER_ARN="arn:aws:iam::${ACCOUNT}:oidc-provider/${ISSUER}"

# Role with trust policy gated on aud.
aws iam create-role --role-name ClaudeBedrockAccess \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "All