mjfnet: Cool Microsoft 365 and AI Dev Knowledge Sharing

Time Zone Converter - Meeting Planner

Mon, 04 May 2026 10:10:51 -0700

Time Zone Converter – Meeting Planner takes the guesswork out of scheduling meetings across multiple time zones. Designed for distributed teams, remote workers, and global organizations, the app visually compares participant availability and intelligently recommends the best meeting times—so everyone stays productive without late nights or early mornings.

With an intuitive timeline view, real-time clocks, and smart meeting quality analysis, you can instantly see who’s working, who’s outside normal hours, and which time best balances fairness and convenience. Planning global meetings has never been clearer—or faster.

Key Benefits

Save time and avoid scheduling mistakes
Instantly compare time zones and spot conflicts at a glance—no mental math required.
Choose the fairest meeting time
Smart recommendations highlight options that minimize disruption across all participants.
Reduce fatigue for global teams
Clearly see early, late, night, and weekend hours to avoid burnout.
Plan with confidence
Know exactly how a proposed meeting impacts everyone before sending the invite.
Seamless calendar integration
Turn the chosen meeting time into a calendar event in just one step.

Important Features

Multi‑Time‑Zone View
Add multiple cities or time zones and view them side by side with live clocks and UTC offsets.
Visual Meeting Timeline
Color‑coded hourly blocks clearly indicate:
- Working hours
- Slightly outside working hours
- Fringe hours
- Night / sleeping hours
- Weekend time
Smart Meeting Recommendations
Automatically suggests the best meeting start times based on participant availability and disruption level, with clear explanations for each option.
Meeting Quality Analysis
See an instant summary of how a selected time affects participants:
- Who is within work hours
- Who is outside or at night
- Overall impact rating (Low / Medium / High)
Date & Time Picker
Easily adjust meeting dates and times and instantly see updates across all time zones.
Add to Calendar
Create a calendar event with subject, location, description, and correct start/end times—all aligned across time zones.
Day/Night Toggle & Clean UI
Hide or show night hours to focus on relevant times and keep the interface uncluttered.

Time Zone Converter – Meeting Planner is built for modern, global collaboration—helping teams meet at the right time, every time.

Time Zone Converter - Meeting Planner - Privacy Policy

Mon, 04 May 2026 10:10:51 -0700

Privacy Policy

Time Zone Converter – Meeting Planner

Effective Date: May 4, 2026

Your privacy is important. This Privacy Policy explains how Time Zone Converter – Meeting Planner (“the App”) handles information and data.

Overview

Time Zone Converter – Meeting Planner does not collect, store, transmit, or share any personal data.
All functionality operates locally on the user’s device.

The developer does not receive, access, or process user data in any form.

Data Collection

The App does not collect any data, including but not limited to:

Personal information (name, email address, identifiers)
Location data
Usage data or analytics
Calendar data
Diagnostic or crash data
Device or system identifiers

All meeting times, locations, and scheduling details entered into the App remain on the user’s device and are never transmitted elsewhere.

The App does not share data with:

The developer
Third‑party services
Advertising networks
Analytics providers
Cloud services
Partners or affiliates

There are no server connections, trackers, or external APIs used to collect or transmit user information.

Calendar Access

If the user chooses to add a meeting to a calendar, this action occurs locally on the device using the operating system’s calendar feature.

The App does not read, store, copy, or transmit calendar data.

Third‑Party Services

The App does not integrate with third‑party analytics, advertising SDKs, tracking tools, or data processors.

Data Security

Because the App does not collect or store data, there is no user data retained by the developer to secure or manage.

Children’s Privacy

The App does not collect any personal data and is not designed to gather information from users of any age.

Changes to This Privacy Policy

If this Privacy Policy changes, the updated version will be made available with a revised effective date. Any future changes will continue to prioritize user privacy.

Contact

If you have questions or concerns about this Privacy Policy, you may contact the developer through the app’s official distribution platform.

Summary:
✅ No data collected
✅ No data shared
✅ No tracking
✅ No analytics
✅ No cloud storage

Your scheduling stays private—always.

MCP Servers and M365 (Part 4): Connect the Message Center MCP Server to a Declarative Agent (M365 Agents Toolkit)

Tue, 06 Jan 2026 08:00:00 -0800

In Part 3, we built an authenticated MCP server that calls Microsoft Graph using On-Behalf-Of (OBO).

In this post, you’ll connect that Message Center MCP server to a Copilot declarative agent that you build with the Microsoft 365 Agents Toolkit.

This is the “enterprise path” integration:

Your declarative agent calls your MCP server.
The agent authenticates the signed-in user (delegated OAuth).
Your MCP server performs OBO token exchangeto obtain a Microsoft Graph token.
The MCP tool runs as the signed-in user and returns results.

Integrating the Message Center MCP server

This server implements the MCP protocol and exposes a tool that retrieves Message Center posts from Microsoft Graph. It includes OBO (on-behalf-of) authentication so that it can call Graph on behalf of the signed-in user.

Message Center MCP server repo (reference implementation used in this series):

https://github.com/mjfusa/mcp-message-center-server

Key details (as described in Part 3):

Health: GET /healthz
MCP endpoint: POST /mcp (JSON-RPC 2.0)
Discovery: GET /discover and GET /.well-known/openid-configuration
OAuth proxy endpoints: GET /authorize and POST /token
Tool: getMessages
- Queries Microsoft Graph: GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/messages

Prerequisites

You’ll need:

Microsoft 365 Copilot available in your tenant (and access to test in https://m365.cloud.microsoft/chat)
Visual Studio Code
Microsoft 365 Agents Toolkit extension installed in VS Code

ℹ️ Important

The Message Center MCP server must be running locally or hosted (Part 3 walks through local setup). This post assumes it is already running and reachable.

A public HTTPS URL for the MCP server
- If running locally, use a tunneling service (Dev Tunnel, Cloudflare Tunnel, etc.) - more on that below
A Microsoft Entra app registration configured for the Message Center MCP server (Part 3)
A test user with the right Microsoft 365 role to read Message Center (for example, Message Center Reader)

Create and configure an Entra app registration for the MCP server

For the purposes of this blog post we only need the server Application registration. In the next part of the series we will integrate this server with a client and at that time we will register the client application registration.

Run the client app registration script:

ℹ️ Note

Before running this script, ensure you have created the server app registration as described in Part 3 and have the Server App ClientId available.

1

pwsh -NoProfile -File .\scripts\CreateClientAppRegMCP.ps1 -AppName "MCP Message Center Client" -ServerAppId <Server-App-ClientId> -CreateSecret

Note the output values: ClientId, TenantId, ClientSecret. You’ll need them when configuring the agent in the Agents Toolkit.

Minimum configuration recap (as completed in CreateClientAppRegMCP.ps1):

Authentication redirect URIs
- Add the redirect URI your Copilot Studio connection uses :

https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect
https://localhost:8080

Copilot gets an access token from this client app registration.
The token audience is your MCP server API (example: api://<server app reg clientId>).
The MCP server uses OBO to exchange this token for a Graph token.

Step 2 — Decide where the MCP server will run

Microsoft 365 must be able to reach:

https://<your-host>/mcp
https://<your-host>/authorize
https://<your-host>/token
https://<your-host>/.well-known/openid-configuration (or /discover)

Two common options:

Option A: Local server + tunnel (quick dev)

Start the server locally (default port in Part 3 examples is 8080).
Expose it with a tunnel.

Example with Dev Tunnel:

1
2
3
4
5


winget install Microsoft.devtunnel
devtunnel user login

# assuming your server is listening on 8080
devtunnel host -p 8080 --allow-anonymous --protocol https

Also see, scripts\dev-tunnel-persist.ps1 in the server repo to create a persistent Dev Tunnel.

Note the public HTTPS URL (example: https://<something>.devtunnels.ms).

Option B: Hosted URL (recommended for stable testing / production)

❗ The steps for hosting the server are outside the scope of this post. However they are documented in the server repo README.

Step 3 — Validate the server with curl

Set a base URL:

1
2


# Tunnel/hosted example
$BaseUrl = 'https://<your-local-tunnel-host>'

3a) Health check

1

curl.exe -sS -i "$BaseUrl/healthz"

You want 200 OK and {“ok”:true} responses.

If that succeeds, your server is reachable via a public URL.

Step 4 — Create the declarative agent project (Microsoft 365 Agents Toolkit)

This post assumes you’re using Microsoft 365 Agents Toolkit to build and provision a declarative agent.

In Visual Studio Code, open the Microsoft 365 Agents Toolkit extension.
Select Create a New Agent/App.
Choose Declarative Agent.
Choose the following starting point:
- Add an action
Choose ‘Start with an MCP Server Preview’.
Enter the your local-tunnel/hosted MCP server URL with ‘/mcp’. (for example: https://<your-host>/mcp).
Select a destination folder for your project.
Enter a project name (for example: Message Center Agent - MCP).

A new instance of VS Code will open with your new project.

Name the app (for example: Message Center Assistant).
When the new project opens, locate your app manifest file (commonly appPackage/manifest.json in Agents Toolkit projects).
You see the following prompts from the toolkit regarding the MCP server:

Click ‘Confirm’ to add the Copilot instructions for the Agents Toolkit MCP server.
Click ‘Fetch Action’ to fetch the tools from your MCP server.
Select the first option, showing the URL to the MCP server.
If you get an error, in mcp.json, click ‘Start’ the connect with the MCP server.
Then click “ATK: Fetch Actions from MCP Server”.
At the prompt ‘Select the action manifest you want to update’, Click on the ‘ai-plugin.json’.
Click on ‘getMessages’ to add the Message Center tool to your agent.
Click ‘OK’ to confirm adding the tool.
Do not click on ‘Provision’ yet.

At this point, you have a declarative agent project with the Message Center MCP server tool added. However, the agent can’t connect to the MCP server yet because authentication isn’t configured. This requires registering the client app registration with the Teams Developer portal. This provides a opaque ID that will be used to connect the agent to the MCP server using OAuth. This step stores the client app ID and client secret In the Teams developer portal. This provides a secure a way to secure the client app ID and secret.

Step 5 — Register the agent in the Teams Developer Portal

For this step you’ll the client ID and client secret created above. You’ll also need the server app registration ID created in Part 3.

Open the Teams Developer Portal. Roles required: Teams app develop or Teams Administrator or Global Administrator.
Click Tools
Click ‘OAuth client Registration’. You may be prompted to select the previous version of the portal.
click ‘New OAuth client registration’.
Fill in the following fields:
Registration name Any descriptive name (internal only).
Example: OAuth-MessageCenterMCP

Base URL The MCP Server Endpoint URL:
https://«your-host»/mcp/

Restrict usage by org

My organization only → internal use
Any Microsoft 365 organization → multi-tenant (this setting for testing)

Restrict usage by app

Any Teams app (testing/validation) for development
Existing Teams app if binding to a specific App ID

OAuth Settings

Client ID Client ID for agent obtained above

Client secret Client secret for agent obtained above

Authorization endpoint https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/authorize

Token endpoint https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token

Scope Use the exact scope your API exposes: api://«server app reg clientId»/access_as_user

PKCE

Keep ON for Authorization Code flow (recommended).

Review all settings and Click Save to create the OAuth client registration.

Copy the generated OAuth Client registration ID (found at the top of the form). You’ll need it in the next step.

Step 6 — Update the plugin manifest to connect to the MCP server

Return the to Visual Studio Code.
Open ai-plugin.json in the appPackage folder of your project.

Change the follow block from this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


"runtimes": [
 {
 "type": "RemoteMCPServer",
 "spec": {
 "url": "https://<<your-host>>/mcp",
 "mcp_tool_description": {
 "file": "mcp-tools.json"
 }
 },
 "run_for_functions": [
 "getMessages"
 ]
 }
 ]

To this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


"runtimes": [
 {
 "type": "RemoteMCPServer",
 "auth": {
 "type": "OAuthPluginVault",
 "reference_id": "${{OAUTH2_REGISTRATION_ID}}"
 },
 "spec": {
 "url": "https://<<your-host>>/mcp"
 },
 "run_for_functions": [
 "getMessages"
 ]
 }
]

Note the addition of the auth block with the reference_id property. Also, the “mcp_tool_description” has been removed. Make sure you update the ‘spec’, ‘url’ value to your MCP server endpoint. Update .env.dev or .env.production with this variable OAUTH2_REGISTRATION_ID with the actual OAuth Client registration ID obtained from the Teams Developer Portal in the previous step.

Step 5 — Add the function definition to ai-plugin.json

Currently the function definition for getMessages is missing from ai-plugin.json. You need to add it so the agent knows how to call the tool. It is expect this will be added automatically in a future version of the Agents Toolkit.

Open ai-plugin.json in the appPackage folder of your project.
Locate the functions array.
Add the getMessages function definition as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


"functions": [
 {
 "name": "getMessages",
 "description": "Retrieve Microsoft 365 Message Center messages from Microsoft Graph (admin/serviceAnnouncement/messages).",
 "parameters": {
 "type": "object",
 "properties": {
 "orderby": {
 "type": "string",
 "default": "lastModifiedDateTime desc",
 "description": "Order by clause for sorting results. Defaults to newest messages first (lastModifiedDateTime desc)"
 },
 "count": {
 "type": "boolean",
 "default": "true",
 "description": "Total number of records returned"
 },
 "prefer": {
 "type": "string",
 "default": "odata.maxpagesize=5",
 "description": "Specifies the maximum number of items to return in a result set"
 },
 "top": {
 "type": "integer",
 "description": "Number of records to return. Set to 0 to retrieve only the count (@odata.count) without any message data. Useful for count-only queries like 'How many messages are there?'"
 },
 "skip": {
 "type": "integer",
 "description": "Number of records to skip"
 },
 "filter": {
 "type": "string",
 "description": "Filter the results based on specific conditions. For count-only queries, combine with $top=0 to get just the total number of matching records. Use `contains(tolower(title),tolower('search term'))` to search within the title property for a specific term or phrase. For multi-word searches, include the entire phrase in quotes. For create time, use the 'startDateTime' property with a date format. For example, `startDateTime ge 2025-03-01T00:00:00Z` to filter messages created after March 1, 2025. For major change messages, use `isMajorChange eq true`. To combine filters, use `and` operator. For example, `contains(tolower(title),tolower('Copilot agent')) and startDateTime ge 2025-03-01T00:00:00Z`. For the 'Tags' field, here is an example of the a query segment for the tags field: tags/any(t: t eq 'New feature'). For the 'severity' field, you can filter by severity using `severity eq 'normal'` or `severity eq 'high'` or `severity eq 'critical'`. For the 'category' field, you can filter by category using `category eq 'stayInformed'` or `category eq 'planForChange'` or `category eq 'preventOrFixIssue'`. For the 'Services' field, here is an example of a query segment for the services field: services/any(s: contains(s, 'Copilot')). When searching an message center update for roadmap ids, these are found in the 'details' field. Here is an example of a query segment for the details field, when searching for RoadmapIds: details/any(d: d/name eq 'RoadmapIds' and contains(d/value, '501107')). Note the 'name' property is used to specify the type of detail being searched, in this case 'RoadmapIds'. The 'value' property is then used to search for the specific roadmap id. RoadmapIds is case sensitive and must be used exactly as shown. To filter by message body, use `contains(tolower(body/content),tolower('search term'))` to search within the body content."
 },
 "accessToken": {
 "type": "string",
 "description": "Optional: Graph access token for proxying requests. Use only for local testing; OAuth flow will replace this after browser sign-in."
 }
 },
 "required": []
 }
 }
]

Step 6 — Provision and verify tool discovery

Save your manifest changes.
In Agents Toolkit, select Provision again.
Open https://m365.cloud.microsoft/chat, select your agent, and start a new chat.

What you’re looking for:

During the first run, you should see a consent/connection experience if OAuth is configured.
Your MCP server should receive MCP handshake traffic (for example initialize, then tools/list).
When you ask a Message Center question, your server should receive a tools/call for getMessages.

Step 7 — Test the agent end-to-end

In Copilot chat (with your declarative agent selected), try:

“What changed for Copilot since yesterday?”
“Find messages related to Microsoft 365 Copilot published in the last 30 days.”
“Show message regarding updates from the last month that are related to Copilot and marked as major changes.”

Expected behavior:

The agent prompts the user to login.
The agent calls getMessages.
The MCP server performs OBO and calls Graph and validates the user has Message Center access.
The agent summarizes results and includes IDs/links when available.

Provide instructions to the agent

To improve the agent’s behavior, you can provide additional instructions the instruction.txt file in your project. For example, you might add:

1
2
3
4
5


When answering questions about Microsoft 365 Message Center messages, always use the 'getMessages' tool to retrieve the latest messages. Use the following guidelines when calling the tool:
- Always set 'top' to 5 to limit the number of messages returned.
- Use 'orderby' set to 'lastModifiedDateTime desc' to get the most recent messages first.
- If the user asks for a count of messages, set 'top' to 0 and use the '@odata.count' property from the response.
- When filtering messages, use the 'filter' parameter to narrow down results based on user criteria.

See the project Message Center Agent - MCP for an example of a completed project, including updated instructions, ai-plugin.json, and starter prompts.

Troubleshooting

Developer Mode

In Copilot chat, enable Developer Mode with the following prompt:
-developer on
Develop remote is useful in that it gives you a preview of the composed Odata query that will be called against the Microsoft Graph. For example:

Clicking on ‘Agent debug info’ shows the full request/response payloads exchanged between Copilot Studio and your MCP server. This is useful for debugging issues.

Summary

You now have a declarative agent (built with Microsoft 365 Agents Toolkit) calling an authenticated MCP server end-to-end:

The agent obtains an MCP API user token
Calls POST /mcp with Authorization: Bearer <token>
MCP server exchanges via OBO and calls Microsoft Graph
Returns Message Center results as tool output

In Part 5 of this series, we’ll create a custom agent in Copilot Studio that uses this MCP server to provide Message Center insights.

MCP Servers and M365 (Part 3): Implementing OBO Authentication to Call Microsoft Graph APIs

Tue, 06 Jan 2026 07:00:00 -0800

In part 1 we intentionally avoided authentication and focused on learning MCP fundamentals. In part 2 we wired a no-auth MCP server into a Copilot Studio agent.

Part 3 is where things get “real enterprise”: the MCP server is no longer calling a public API. It’s calling Microsoft Graph, and Graph requires user-delegated authorization to retrieve Message Center messages via the Microsoft Graph API /admin/serviceAnnouncement/messages.

That combination drives a specific OAuth pattern:

In this post, “your MCP API” means the protected API surface of your MCP server (specifically POST /mcp), represented by a Microsoft Entra app registration that you “Expose an API” for. Practically, it’s the resource clients request a token for, typically with an audience like api://<your-app-client-id> for your server.

The client (an agent or script) sends a user token meant for your MCP API.
The server exchanges that token for a Microsoft Graph delegated access token using On-Behalf-Of (OBO).
The server calls Graph and returns results as MCP tool output.

We’ll use the mcp-message-center-server repo as the reference model for the discussion.

TL;DR: If you just want the hands-on path, jump to Try it yourself.

Why OBO matters for MCP servers

If your MCP server calls Microsoft Graph with delegated permissions, it’s acting as a middle-tier service in a multi-hop authentication chain.

Here’s the key constraint that forces OBO:

When a client calls your MCP server, it presents an access token representing the user.
That incoming token is scoped for your MCP API (audience = your resource, e.g., api://<clientId>).
OAuth2 access tokens are not reusable across different resource servers.
- A token minted for your MCP API cannot be sent to Microsoft Graph, because Graph will reject it as the wrong audience.

The On-Behalf-Of (OBO) flow solves this by letting the MCP server exchange the incoming user token for a new access token:

The new token is scoped for Microsoft Graph.
The call still happens as the original user, preserving user identity and delegated permissions.

That creates the trust chain you want in an enterprise MCP deployment:

The user authorizes the client.
The client calls the MCP server on behalf of the user.
The MCP server calls Microsoft Graph on behalf of that same user.

Without OBO, you’re pushed into two architectural dead ends:

Server uses app-only auth to Graph: you lose user context (and often break least-privilege expectations for admin data).
Client obtains Graph tokens directly: you break the middle-tier pattern and move Graph complexity (and token handling risk) into every client. This works for calling Graph directly, but the MCP server cannot validate that token as authentication because the token’s audience is Graph, not the MCP server. In the reference server, Graph tokens presented as the caller credential are rejected by default (confused-deputy guardrail) unless you explicitly opt in for local testing. This prevents a “confused deputy” scenario where a token meant for one service (Graph) is misused to access another (MCP server).

OBO is what preserves user identity across service boundaries while still respecting the OAuth principle that tokens are valid only for their intended resource.

Client gets token scoped for MCP server (audience = MCP server)
MCP server validates that token (proving the client is authorized to call it)
MCP server exchanges it via OBO for a Graph token (audience = Graph)
Maintains security boundaries while preserving user identity

Microsoft Message Center MCP server

This server mcp-message-center-server exposes one tool:

getMessages: queries Microsoft Admin Center Message Center messages via Microsoft Graph: /admin/serviceAnnouncement/messages

It also exposes a few key HTTP endpoints:

GET /healthz (health)
POST /mcp (MCP JSON-RPC endpoint)
GET /discover (and GET /.well-known/openid-configuration) for discovery
/authorize + /token proxy endpoints (used by interactive and PKCE flows)

ℹ️

PKCE (Proof Key for Code Exchange) is an OAuth 2.0 protection for the authorization-code flow, designed for “public clients” that can’t safely store a client secret (like local tools, VS Code extensions, or scripts running on a dev machine). In PKCE, the client generates a one-time code verifier and sends only a derived code challenge during /authorize. Later, when exchanging the auth code at /token, the client must present the original verifier. If an attacker steals the auth code from the redirect, they still can’t redeem it without the verifier. In this project, PKCE shows up when a client uses the server’s /authorize + /token proxy endpoints (for example, the repo’s PKCE smoke test). It is not required for the normal OBO path where the client calls POST /mcp with Authorization: Bearer <MCP API token>.

Step 1 — Understanding the authentication token types

The server model makes a clear distinction between two token types:

MCP API user token (what the client sends)

Audience: your MCP server API (example: api://<clientId>)
Where used: sent by the client to POST /mcp in Authorization: Bearer <token> header.
Purpose: proves the user to your server

Microsoft Graph access token (what the server uses)

Audience: Microsoft Graph
Where used: sent by the MCP server to Microsoft Graph
Purpose: authorizes the server to call Graph as the user (delegated)

If you only remember one thing:

Clients should authenticate to the MCP server. The MCP server should authenticate to Graph.

Step 2 — The OBO flow (what’s actually happening)

In OAuth terms, OBO is a token exchange:

The client gets a user token for the MCP API (audience = your MCP API).
The client calls POST /mcp with that bearer token.
The server validates the inbound token, then calls Entra to exchange it for a Graph token.
The server calls Graph with the exchanged token.

At a high level, the runtime flow looks like:

POST /mcp receives MCP JSON-RPC
Server checks Authorization: Bearer <MCP API token>
Server performs OBO to get Graph token
Server calls GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/messages?...
Server returns tool output back to the MCP client

Why this is the right pattern for agents

This is a good match for agent ecosystems because:

The agent host (client) can be “thin” on Graph knowledge.
Authorization remains user-delegated, so Graph enforces user role requirements (e.g., Message Center Reader).
You can implement centralized controls (logging, throttling, input validation, safe defaults) at the MCP server.

Step 3 — App registration models (single-app vs two-app)

The reference repo supports two common setups:

Option A (simplest): single app registration (one app, two roles)

In this model, a single Microsoft Entra app registration serves as both:

The MCP API resource
- The caller obtains a user token whose audience is your MCP API.
- Common convention: set Application ID URI to api://<clientId>.
The confidential client for OBO
- The server authenticates as the app to Entra to perform OBO.
- For local/dev, this can be a client secret.
- For production, prefer certificate-based auth (see Key Vault section).

This “single app” model reduces moving parts and is great for learning.

Option B (recommended for agents): two app registrations (client app + server/API app)

For many agent scenarios (including declarative agents), it’s cleaner to separate responsibilities:

Server/API app registration (resource)
- Exposes the MCP API scope (commonly access_as_user) and represents POST /mcp.
- The inbound bearer token audience is your MCP API (for example, api://<server-app-id>).
- Uses delegated permissions to Microsoft Graph (e.g., ServiceMessage.Read.All) - validating user roles for Message Center access.
Client app registration (OAuth client)
- Used for interactive login/PKCE and represents the client identity.
- Requests tokens for the server/API scope (for example, api://<server-app-id>/access_as_user).

The repo includes PowerShell automation to create/configure both app registrations:

scripts/CreateServerAppRegMCP.ps1
scripts/CreateClientAppRegMCP.ps1

Step 4 — Why proxy `/authorize` + `/token` endpoints exist

MCP clients are not all the same. Some can do interactive OAuth directly against Entra, some can’t. Some need PKCE. Some need a consistent “discovery + authorization” surface.

The Message Center MCP server provides /authorize and /token endpoints that act as a controlled OAuth proxy:

They forward to Entra for the same app registration used by the server.
They allow tooling and scripts to run standard OAuth flows (especially PKCE) without every client needing bespoke Entra wiring.
They let the server enforce “safe defaults” and guardrails.

Redirect safety: allowlist is not optional

An OAuth proxy can become dangerous if it accepts arbitrary redirect_uri values.

That’s why the model server enforces a redirect URI allowlist (prefix-based) via MCP_OAUTH_REDIRECT_URI_PREFIXES.

Defaults include common safe cases:

VS Code loopback (http://127.0.0.1, http://localhost)
Copilot / Teams declarative agent redirect (https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect)

If your client uses a different redirect URI, you must explicitly allow it.

Try it yourself

This is the PowerShell-first path that validates:

the server is running
/authorize + /token proxy works with PKCE
the end-to-end OBO path works (MCP API token → Graph token → Message Center)
bypass paths work (and how to disable them in production)

Prerequisites

Node.js 20+
PowerShell 7+ (pwsh)
Azure CLI (az) authenticated (az login)
A Microsoft Entra app registration configured as described below
The signed-in user must have the right Microsoft 365 role for Message Center access (e.g., Message Center Reader)

Create and configure an Entra app registration for the MCP server

Follow Option B to create two app registrations one for the client and the other for the server/API.

Run the server app registration script:

1
2


pwsh -NoProfile -File .\scripts\CreateServerAppRegMCP.ps1 -AppName "MCP Message Center Server"
# Note the output values: ClientId, TenantId, ClientSecret

Clone the repo and run the server

1
2
3
4
5
6
7
8
9


git clone https://github.com/mjfusa/mcp-message-center-server

# Install dependencies (run inside the server folder)
cd mcp-message-center-server
npm install

# Create local env file
Copy-Item .env.local.sample .env.local
notepad .env.local

Minimum .env.local values for local dev OBO:

GRAPH_TENANT_ID=<your-tenant-guid>
GRAPH_CLIENT_ID=<your-app-client-id-guid>
GRAPH_CLIENT_SECRET=<client-secret> (local/dev simplest)

Then run the server:

1

npm run dev

In a new terminal, verify health:

1

curl.exe -sS -i http://localhost:8080/healthz

Entra app registration - MCP OBO Server configuration

The following are the details regarding the server side app registration. This is all completed by the CreateServerAppRegMCP.ps1 script.

Expose an API (defines “your MCP API”)
- Set the Application ID URI (recommended): api://<clientId>
- Add a delegated scope so clients can request a token for your MCP API:
  - Scope name: access_as_user
  - Who can consent?: Admins and users
  - Admin consent display name: Access MCP server as signed-in user
  - Admin consent description: Allows the app to call the MCP server API as the signed-in user.
  - User consent display name: Access MCP server as signed-in user
  - User consent description: Allows the app to call the MCP server API as the signed-in user.
Why this matters:
- Your scripts/clients need some delegated scope to request on your MCP API.
- In current Azure CLI usage, request a token for the specific scope using --scope api://<clientId>/access_as_user.
Microsoft Graph delegated permissions (what OBO will request)
- API permissions → Microsoft Graph → Delegated:
  - Add ServiceMessage.Read.All
- Click Grant admin consent (common cause of OBO failure if skipped).
- Note: Graph will still enforce the user’s Microsoft 365 role (e.g., Message Center Reader).
Authentication (redirect URIs used by /authorize + /token proxy)
- Add the redirect URI your client uses (examples):
  - Local loopback for PKCE smoke testing: http://localhost:8400/ (default used by the repo’s SmokeTokenProxyPkce.ps1).
  - Other loopback patterns: http://localhost:<port> or http://127.0.0.1:<port>.
Here are the default redirect URIs allowed by the server’s OAuth proxy:
- http://127.0.0.1
- http://localhost
- https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect
Certificates & secrets (confidential client credentials for OBO)
- Local/dev (simplest): create a client secret and set GRAPH_CLIENT_SECRET.
- Production (recommended): use a certificate (public cert uploaded to the app registration, private key stored in Key Vault). Not required for this dev/test path.

Smoke test the OAuth proxy endpoints with PKCE

From the repo root:

1

pwsh -NoProfile -File .\scripts\SmokeTokenProxyPkce.ps1

This flow exercises /authorize + /token and helps validate redirect URI allowlisting and PKCE behavior.

The script returns the obtained access tokens if successful.

Get an MCP API user token (audience = your MCP API)

From the repo root:

1
2
3
4
5


# First time may require interactive consent
pwsh -NoProfile -File .\scripts\GetMcpAccessToken.ps1 -Login

# Then fetch a token (prints the token)
$mcpToken = pwsh -NoProfile -File .\scripts\GetMcpAccessToken.ps1

Call the MCP tool using OBO (recommended path)

This validates the full chain:

client authenticates to MCP API
server exchanges token via OBO
server calls Graph

1
2
3
4


pwsh -NoProfile -File .\scripts\GetMessages.ps1 `
 -McpAccessToken $mcpToken `
 -Top 5 `
 -Count:$true

Congratulations! You’ve proven the core production pattern.

Production lock-down behavior (important)

If NODE_ENV=production, the model server rejects bypasses unless you explicitly enable:

ALLOW_MCP_ACCESS_TOKEN_ARG=true

This is a deliberate safety feature: it prevents “just paste a Graph token” from creeping into production workflows.

Troubleshooting

`AADSTS65001` / `consent_required`

You haven’t granted consent yet. Run:

1

pwsh -NoProfile -File .\scripts\GetMcpAccessToken.ps1 -Login

`401 Unauthorized` from the MCP server

You didn’t send an MCP API bearer token and MCP_REQUIRE_AUTH=true, or
Your bearer token is invalid/expired.

`401` from Microsoft Graph

Common causes:

OBO token exchange failed (missing delegated permission / missing admin consent)
Your app registration isn’t configured with the right audience (api://<clientId>) or token settings

`403` from Microsoft Graph

Your user likely lacks the required Microsoft 365 admin role for Message Center access (e.g., Message Center Reader).

Production bypass error (`accessToken_disabled`)

You’re trying to use a dev/test bypass in production mode. Use the OBO path instead, or explicitly opt-in:

ALLOW_MCP_ACCESS_TOKEN_ARG=true

Summary

In Part 3 you’ve added the authentication story for an MCP server calling Microsoft Graph using On-Behalf-Of (OBO):

The client authenticates to your MCP API
The server uses OBO to obtain a Graph delegated token
The server calls Graph and returns results as MCP tool output
/authorize + /token proxy endpoints support standardized OAuth flows with guardrails
Dev/test bypass paths exist, but are explicitly controlled and disabled by default in production

Next up (in Part 4): we’ll use this MCP server in an agent built with the Microsoft 365 Agents Toolkit.

MCP Servers and M365 (Part 2): Integrate the Roadmap MCP Server into a Copilot Studio Custom Agent

Wed, 31 Dec 2025 10:00:00 -0800

In part 1 you deployed the Microsoft 365 Roadmap MCP Server. In this post, we’ll integrate that server into a custom agent built with Copilot Studio.

This is intentionally the “happy path” integration:

The Roadmap API is public.
The MCP server requires no Entra app registration and no OAuth.
We’re focusing on how an agent discovers and calls MCP tools.

Later in the series we’ll layer on authentication using a different server (https://github.com/mjfusa/mcp-message-center-server). We are not adding auth to the Roadmap server.

What you’re integrating

Roadmap MCP server repo:

https://github.com/mjfusa/mcp-roadmap-server

Key details (from the server’s README):

Health: GET /healthz
MCP endpoint: POST /mcp (JSON-RPC 2.0)
Tool: getM365RoadmapInfo
- Arguments: filter, orderby, top, skip, count

Prerequisites

You’ll need:

Access to Copilot Studio (create/edit agents)
The Roadmap MCP server should be deployed and running (see Part 1 for setup instructions) on port 8081 or another port you choose.
A reachable URL for the MCP server:
- If running locally, use a tunneling service (e.g., Cloudflare Tunnel, DevTunnel) to expose http://localhost:8081 to a public URL.
- The quickest way is to user a local tunnel. See below. However, a hosted deployment (e.g., Azure Container Apps) is more stable for longer-term use.
- If hosted, ensure you have the base URL (e.g., https://your-app.your-region.azurecontainerapps.io).

You’ll also want:

curl available in your terminal (Windows curl.exe is fine)

Step 1 — Decide where the MCP server will run

Copilot Studio must be able to reach your MCP endpoint. Pick one:

Option A: Use a local tunnel (for quick dev)

If you run the server locally (npm run dev), expose it temporarily via a tunnel so Copilot Studio can call it.

Tools like Cloudflare Tunnel or DevTunnel work well.

Quick example with Dev Tunnel:

Install Dev Tunnel: winget install Microsoft.devtunnel
Login: devtunnel user login. You will need a GitHub or Microsoft account.
Start your MCP server locally: npm run dev (default port `8081)
Start the tunnel:

1

 devtunnel host -p 8081 --allow-anonymous

Note the tunnel URL (e.g., https://qx8mj0tl-8081.usw2.devtunnels.ms).

Start tunnel inspection using inspection url provided in the terminal (e.g., https://qx8mj0tl-8081-inspect.usw2.devtunnels.ms). We will use this to monitor requests to the Roadmap MCP server.

Option B: Use a hosted URL (for stability and production)

Deploy the server and use the resulting base URL. You should end up with:

https://<your-host>/healthz
https://<your-host>/mcp

Regardless of approach, your goal is a reachable https://.../mcp endpoint.

Step 2 — Validate the MCP server with curl (before Copilot Studio)

Do this first. It separates “server is working” from “Copilot Studio integration is working.”

Set a base URL:

1
2
3
4
5


# Local
$BaseUrl = 'http://localhost:8081' # or your tunnel URL, e.g., 'https://qx8mj0tl-8081.usw2.devtunnels.ms'

# Hosted example
# $BaseUrl = 'https://your-app.your-region.azurecontainerapps.io'

2a) Health check

1

curl.exe -sS -i "$BaseUrl/healthz"

You want 200 OK.

2b) Call the MCP tool (fetch 5 items)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


$body = @{
 jsonrpc = '2.0'
 id = 1
 method = 'tools/call'
 params = @{
 name = 'getM365RoadmapInfo'
 arguments = @{ top = 5; orderby = 'created desc'; count = $true }
 }
} | ConvertTo-Json -Depth 10

curl.exe -sS -X POST "$BaseUrl/mcp" `
 -H "Content-Type: application/json" `
 -H "Accept: application/json, text/event-stream" `
 --data-raw $body

2c) Go back to the tunnel inspection browser session (if using a tunnel)

Clicking on the payload tab you should see the request to the MCP server.

If that succeeds, you’re ready to wire it into Copilot Studio.

Step 3 — Create a custom agent in Copilot Studio

Open Copilot Studio.
Click ‘Agents’.
In the ‘Start building by describing’ field, enter :

1
2


An assistant that helps users find information about upcoming
features in Microsoft 365 and their planned release dates.

Click the arrow (⇨) to create the agent. You should see that Copilot Studio has given a name to the agent based on your description. (E.g. Microsoft 365 Feature Release Assistant) Also, instructions have been auto-generated. You can edit these later.
To only have information from the Roadmap MCP server, disable web and internal knowledge:

a. Click on the ‘Settings’ tab
b. Under ‘Knowledge sources’, toggle off ‘Web search’ and ‘Internal knowledge’
Add the following in Suggested Prompts: Title: “What are the latest Copilot roadmap items?” Prompt: “Show roadmap items regarding Copilot published in the last two weeks.”
Add the Roadmap MCP server as a tool/action:

a. Click on ‘Add tool’
b. Click on New tool
c. Click on Model Context Protocol
Complete the fields as follows:

Server name: M365 Roadmap MCP Server
Server description: This server provides access to Microsoft 365 Roadmap information via an OData interface
Server URL: https://<your-host>/mcp (replace <your-host> with your actual host / tunnel URL). Make sure you add the trailing /mcp.
Authentication: None
Click on Create

Create a connection to the MCP server.
Click ‘Add and configure’.
Go back to the tunnel inspection browser session Inspect each MCP request by clicking on the Payload tab. You should see the requests from Copilot Studio to the MCP server.

Note the ‘initialize’, ’notifications/initialized’, and ’tools/list’ requests.

Test the agent

In the ‘Test your agent’ chat, ask: “Show me the newest 5 roadmap items.”
Note: The first time you run the agent, you will need to establish a connection. Click on ‘Open connection manger’, Click ‘Connect’ to pick the connection created in the previous step, Click ‘Submit’. Close the browser tab, and then click ‘Retry’.

The agent will return something like this:

You can retrieve Microsoft 365 Roadmap items using the connected tool getM365RoadmapInfo. When asked about upcoming or recently released features, call agent will call the tool and summarize results.

Instruct the agent how to call the tool (minimal prompt contract)

You can update the instructions to describe how you want the roadmap information presented. Which fields to include, formatting, etc.

Even when a tool is connected, agents behave better when you give them a “mini contract”. Add guidance like:

Use getM365RoadmapInfo for roadmap questions.
Default to top=5 or top=10.
Prefer orderby="created desc" for “latest” questions.
Use count=true when asked “how many”.
When filtering titles, use case-insensitive contains patterns like:
- contains(tolower(title), 'copilot')

This keeps tool calls predictable without overprompting.

Step 6 — Test the agent end-to-end

In Copilot Studio’s test chat:

Ask: “Show me the newest 5 roadmap items.”
Ask: “Show roadmap items that mention multiple Microsoft 365 products like Copilot, Teams and SharePoint”
Ask: “Show roadmap items available for GCC High and DoD cloud instances with General Availability in the next month.”

Expected behavior:

The agent calls getM365RoadmapInfo.
It summarizes the returned value items (title, summary, dates).
The output includes links to the roadmap items on the M365 Roadmap site.

Troubleshooting

“Health works but tool calls fail”

Verify POST /mcp is reachable from the same network path as Copilot Studio (not just from your laptop).

`405 Method Not Allowed`

/mcp is POST-only.

Tool not discovered

Confirm the MCP endpoint responds to tools/list:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


$body = @{
 jsonrpc = '2.0'
 id = 1
 method = 'tools/list'
 params = @{}
} | ConvertTo-Json -Depth 10

curl.exe -sS -X POST "$BaseUrl/mcp" `
 -H "Content-Type: application/json" `
 -H "Accept: application/json, text/event-stream" `
 --data-raw $body

Summary

You now have a Copilot Studio custom agent that can call a real MCP tool end-to-end:

Copilot Studio agent discovers the MCP tool surface
Calls getM365RoadmapInfo through POST /mcp
The MCP server validates inputs (from OpenAPI-derived schemas) and proxies OData queries to the Roadmap API

Next up: we’ll expand integration patterns (including declarative agents), then switch servers to https://github.com/mjfusa/mcp-message-center-server to add authentication and token handling.

MCP Servers and M365 (Part 1): Deploy a Microsoft 365 Roadmap MCP Server

Tue, 30 Dec 2025 09:00:00 -0800

This series starts intentionally simple: one MCP server, no authentication, and one very focused capability—wrap the Microsoft 365 Roadmap public API so AI clients can call it as a tool.

But in this series you’re not building an MCP server from scratch first. You’re going to deploy an MCP server locally, then use it as a hands-on way to learn MCP’s basic architecture by running and testing the server end-to-end.

TL;DR: Skip down to the Try it yourself section to get started quickly.

If you’re coming to MCP for the first time, it can look like more work than just calling an API directly—and that reaction is fair.

Why MCP feels more complex

Abstraction layer: you define a capability as a tool, and then invoke it via tools/call. That’s extra steps compared to “make an HTTP request.”
Serialization & schema: tools need explicit input/output contracts (JSON Schema). That’s upfront work, and mismatches can be frustrating.
Context management: MCP is designed for agents that may chain multiple tools over multiple turns. That power adds structure (and therefore complexity).

Why it’s done this way

Standardization: MCP gives AI clients one consistent interface for many different tools, so they can discover and reason about capabilities in a uniform way.
Safety & validation: schemas let the server reject invalid inputs early and behave predictably.
Extensibility: once a tool is defined, it can be reused across models and workflows without rewriting the underlying API logic.
Simplicity: MCP provides a simplified interface. Without it, the client (agent, app, script) needs to understand the full API surface, auth, error handling, etc.

Is it more error-prone?

Initially, it can be—because you’re translating an API into a structured tool definition, and misalignment in schema, naming, or parameter handling can cause issues.

But in larger systems, MCP usually reduces long-term errors by enforcing consistency, making inputs explicit, and enabling better orchestration and troubleshooting.

The goal of Part 1 is to make that tradeoff concrete. By running a simple, no-auth server locally, you can see exactly where the “ceremony” is (schemas, validation, routing) and why it becomes valuable before you add enterprise concerns like authentication.

MCP (Model Context Protocol) is a standard for exposing tools to AI agents and other AI clients. The practical benefit is that you can publish a standard “tool interface” (names + JSON schemas) while your server handles the complex parts: validation, query construction, and talking to upstream APIs.

Important scope note: we are not adding authentication to this Roadmap server. Later in the series we’ll introduce auth (and the “real” enterprise token handling story) using a different server: https://github.com/mjfusa/mcp-message-center-server.

Microsoft 365 Roadmap MCP Server

The first server in the series is the Microsoft 365 Roadmap MCP Server. You’ll run it locally as-is, then use it to understand the moving parts of MCP.

It provides an MCP wrapper around:

The Roadmap site publishes estimated release dates and descriptions for Microsoft 365 features. The API is the “machine interface” behind that data, and it supports OData-style query parameters, which makes it ideal for a tool wrapper.

This server is “public-only”:

Queries the public Roadmap API (not Microsoft Graph)
Requires no Microsoft Entra app registration and no OAuth tokens
Passes OData parameters through (no extra proprietary filtering logic)

MCP Standard Calls

The server supports the following MCP standard calls:

initialize: initializes the MCP session.
tools/list: lists available tools (here, just getM365RoadmapInfo)
tools/call: invokes a tool with validated arguments

These are called via HTTP POST /mcp with JSON-RPC 2.0 payloads.

What does the server expose?

This server exposes:

Health check endpoint: GET /healthz
MCP JSON-RPC endpoint: POST /mcp
One MCP tool: getM365RoadmapInfo
- Supports OData parameters: filter, orderby, top, skip, count

The novel approach: OpenAPI 3.0 as the source of truth

Most MCP examples hand-write tool schemas. That’s fine for demos, but it breaks down as soon as:

you add endpoints,
you evolve parameters,
or the upstream API changes.

The approach in this series is: use OpenAPI 3.0 as the source of truth, and generate MCP tool schemas in code.

That means your server treats the OpenAPI definition as the authoritative contract, then derives:

tool names and descriptions (from operationId / summary)
JSON Schema for tool inputs (from parameters + request bodies)
validation rules (required vs optional inputs, types, enums)

Querying the Roadmap API (OData parameters)

The Roadmap API supports OData-style query parameters such as:

$filter (boolean expression)
$select (projection)
$orderby (sorting)
$top (limit)
$skip (pagination)
$count (return total count)

Here is the openapi.json file used in this server: https://raw.githubusercontent.com/mjfusa/mcp-roadmap-server/refs/heads/main/openapi/openapi.json

Note the description for each of the OData parameters supported by the Roadmap API. These descriptions are detailed and provide examples of how to use each parameter effectively. They are key to the AI understanding how to construct valid queries when invoking the getM365RoadmapInfo tool.

For example, the $filter parameter description states:

1
2
3
4
5


"FilterParameter": {
 "name": "$filter",
 "in": "query",
 "description": "OData filter expression. IMPORTANT: Use 'created' field for created date filtering (not 'createdDateTime'). Use the 'modified' field for last modified date filtering (not 'lastModifiedDateTime'). Supports contains(), tolower(), and date comparisons. Filter the results based on specific conditions. Use `contains(tolower(title),tolower('search term'))` to search within the title property for a specific term. For creation date filtering, use the 'created' property with ISO 8601 date format. For example, `created ge 2025-03-01T00:00:00Z` to filter roadmap items created after March 1, 2025. To combine filters, use `and` operator. For example, `contains(tolower(title),tolower('Teams')) and created ge 2025-03-01T00:00:00Z`. For the 'status' field, you can filter by status using `status eq 'In development'`, `status eq 'Rolling out'`, `status eq 'Launched'`, `status eq 'Preview'`, `status eq 'Planned'`, or `status eq 'Cancelled'`. For array fields, use the any() operator: For 'platforms' array, use `platforms/any(p: contains(tolower(p), 'desktop'))` to find items available on desktop platform, or `platforms/any(p: p eq 'Web')` for exact platform match. For 'products' array, use `products/any(p: contains(tolower(p), 'teams'))` to search within product names. For 'releaseRings' array, use `releaseRings/any(r: contains(tolower(r), 'general'))` to filter by release ring. For 'cloudInstances' array, use `cloudInstances/any(c: contains(tolower(c), 'gcc'))` to filter by cloud instance. For 'availabilities' array, use nested object filtering: `availabilities/any(a: a/ring eq 'General Availability')` to filter by release ring, `availabilities/any(a: a/year eq 2026)` to filter by year, or `availabilities/any(a: a/month eq 'March')` to filter by month. Date range filtering example: `created ge 2025-01-01T00:00:00Z and created le 2025-12-31T23:59:59Z`. For complex date ranges spanning multiple months and years, ALWAYS use proper parentheses grouping: `(availabilities/any(a: a/year eq 2025 and (a/month eq 'November' or a/month eq 'December')) or availabilities/any(a: a/year eq 2026 and a/month eq 'January'))`. Complex example: `contains(tolower(title), 'teams') and platforms/any(p: p eq 'Desktop') and (availabilities/any(a: a/year eq 2025 and (a/month eq 'November' or a/month eq 'December')) or availabilities/any(a: a/year eq 2026 and a/month eq 'January'))`. To find roadmap items that are 'major changes', use contains(tolower(title), 'major') or contains(tolower(title), 'breaking') or contains(tolower(description), 'major') or contains(tolower(description), 'significant'). Do not use '$filter=isMajorChange+eq+true' as it is not supported by the API."
}

Why use OpenAPI as the source of truth?

OpenAPI is a fair “source of truth” choice because it’s typically more portable, more discoverable, and more ecosystem-friendly than MCP tool schemas today.

That’s not a knock on MCP—it’s because OpenAPI and MCP optimize for different problems:

OpenAPI describes HTTP APIs. It answers: “How do I call this service?”
MCP describes agent tools. It answers: “How should an agent use this capability?”

In practice, OpenAPI has a few advantages that matter immediately:

It’s a mature, widely adopted contract. OpenAPI (OAS 3.x) is stable and has deep tooling support across gateways, SDK generation, docs (Swagger UI/Redoc), testing, and increasingly AI ingestion.
It’s easy to distribute and version. Specs are commonly published and treated as first-class artifacts in API programs, so they’re easy to find, review, and govern.
It avoids framework lock-in. An OpenAPI spec stands on its own; MCP schemas are usually coupled to MCP lifecycle semantics (initialize, tools/list, tools/call) and server runtime conventions.

The mental model I like:

OpenAPI is the system-of-record contract. MCP schema is the agent-consumable projection.

So the “wins” you get by making OpenAPI authoritative are still the practical ones:

Correctness: tool inputs match what the upstream API actually accepts.
Maintainability: changes become “update spec → regenerate” instead of hand-syncing schemas.
Safety & predictability: strict schemas reject invalid inputs early (especially important when the caller is an LLM).

Even if this server only exposes one tool right now, starting from OpenAPI prevents schema drift later—and lets the MCP layer stay small and purpose-built.

The code toolset (what does what)

It helps to think of this server as three layers:

Express (the web wrapper): exposes one HTTP endpoint (/mcp) and passes requests/responses through. (https://www.npmjs.com/package/express)
MCP SDK (the protocol engine): speaks MCP/JSON-RPC, advertises available tools, validates tool inputs/outputs, and routes tools/call to the right handler (supports JSON or SSE responses). (https://www.npmjs.com/package/@modelcontextprotocol/sdk)
The tool handler: takes the validated arguments, calls the Microsoft 365 Roadmap API with OData query params, and returns a clean result back to the client.

End-to-end request flow

At runtime, a call to getM365RoadmapInfo looks like:

MCP receives a tool invocation with JSON arguments.
Server validates arguments against the generated input Schema.
Server constructs the outbound request to https://www.microsoft.com/releasecommunications/api/v2/m365.
Server normalizes the response into a stable, tool-friendly shape.

Try it yourself

This is the fastest path to a first successful local deployment and a first successful call.

Prequisites:

Node.js 20+ installed - https://nodejs.org/
Git installed - https://git-scm.com/
A terminal (Command Prompt, PowerShell, Bash, etc.)
Familiarity with terminal commands
Basic understanding of HTTP requests (curl or similar)
Familiarity with npm (Node Package Manager)

Clone the repo:

1
2


git clone https://github.com/mjfusa/mcp-roadmap-server
cd mcp-roadmap-server

Install dependencies:

1

npm install

Run the server:

1

npm run dev

Start a new terminal and call the health endpoint:

1

curl -sS -i http://localhost:8081/healthz

You should see a 200 OK response. With the output: {“ok”:true}.

Call the MCP endpoint to fetch 5 roadmap items:

1
2
3
4


curl -sS -X POST 'http://localhost:8081/mcp' `
 -H 'Content-Type: application/json' `
 -H 'Accept: application/json, text/event-stream' `
 --data '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"getM365RoadmapInfo","arguments":{"top":5,"orderby":"created desc","count":true}}}'

You should see a valid MCP response with 5 roadmap items.

Congratulations!

You’ve deployed and tested your first MCP server locally! You can now explore the code, understand how the pieces fit together, and prepare for Part 2 where we’ll build a custom agent to call this server.

What’s next

In Part 2 we’ll integrate this M365 Roadmap MCP server into a custom agent built with Copilot Studio, so you can see how MCP tools get discovered and invoked from an agent experience.

Getting Started with “No-Hands” Automation: Building Autonomous Agents in Copilot Studio - Part 1 - Personal Agents

Wed, 26 Nov 2025 10:06:20 -0800

Introduction

As your organization and you personally begin to improve your productivity and job satisfaction with Microsoft 365 Copilot Studio, autonomous agents are an exciting new tool in your arsenal. With Copilot Studio, you can build autonomous agents that categorize and prioritize your emails, summarize your documents, or post updates into Teams—and it just works, because it runs as you.

The other important class of agents are enterprise-grade autonomous agents that run headless, touch sensitive data, and operate as part of your organization’s automation fabric. These agents need dedicated identities, least-privilege permissions, and robust governance. We’ll cover those in Part 2 of this series.

This article focuses on personal and maker scenarios—agents that run using end-user or maker credentials. You’ll learn:

How interactive and autonomous agents differ in practice
When user- or maker-bound authentication is acceptable
Where it breaks down as your automation grows
The governance guardrails you should apply even in “small” scenarios

In Part 2, we’ll move to enterprise-grade autonomous agents that run headless with Agent ID and least-privilege permissions.

Understanding Interactive vs Autonomous Agents

Interactive Agents: You in the Loop

Interactive agents are designed with a user-first approach. They operate in your session and under your Microsoft 365 permissions. You stay in control, invoking them when needed and reviewing the results.

Think of them as personal productivity boosters. Common examples include:

Reviewing calendars and reminders to keep your day organized
Automating email triage, categorization, and follow-up suggestions
Generating quick reports from your personal or team datasets

The key characteristics:

Scoped to you: They can only see what you can see.
User-driven: You decide when to invoke them.
Limited scope: Mistakes are usually limited to your own data.

Autonomous Agents: You Out of the Loop

Autonomous agents execute tasks without direct user interaction. They are event-driven and designed for headless execution—for example:

Watching a SharePoint library and summarizing new documents
Processing responses from a Forms survey and updating a list
Posting daily digests or insights into a Teams channel

ℹ️ Like interactive agents, autonomous agents can also run under the permissions of a user or maker account.

In this article, we focus on personal or team-scale autonomous agents—those that still operate primarily within the scope of a specific user or maker, even if they run automatically.

In Part 2, we’ll expand to enterprise-scale autonomous agents that act as infrastructure, affect many users, and must run independently of any individual account.

Personal Autonomous Agents

A few examples of personal autonomous agents include:

A personal agent that summarizes daily activity based on your own emails and documents
A team bot that posts updates into a project channel based on a single SharePoint library
An experimental agent that helps your small group test a new process

Build a Personal Autonomous Agent

See Create an Inbox Summary to Teams Chat Agent for a step-by-step guide on building a personal autonomous agent that sends you summaries of emails as they arrive in your inbox. You can use as you read this post to get hands-on experience with personal autonomous agents.

Authentication Models for Personal and Maker Use

The authentication model you choose determines who the agent really is in your environment.

End-User Credentials

End-user credentials are ideal for personal assistants and lightweight automations:

The agent acts exactly as the signed-in user.
The mental model is simple: “If I can see it, the agent can see it.”
It works well for scenarios like notifying you about changes, summarizing your own documents, or automating small workflows tied to your role.

Trade-offs:

Token lifecycle: Tokens expire; re-authentication is required.
Continuity risk: If the user is deprovisioned, changes roles, or loses a license, the automation breaks.
Limited scope: It’s a poor fit for shared, always-on system workloads.

Maker Credentials

What “maker‑provided credentials” means

Execution identity: The tool runs using the connection you configure—such as a service account, app registration, or API key. Scope: All users of the agent share this single connection. They do not sign in or consent individually. Use cases: Ideal for back‑end systems without per‑user authentication (e.g., line‑of‑business APIs), actions requiring elevated or consistent permissions, or scenarios that need an application identity.

Why use maker credentials? They’re commonly chosen when a builder wants the agent to act on behalf of a team rather than an individual—for example:

Posting updates into a shared Teams channel

They can be acceptable for:

Prototypes and proof-of-concepts
Low-risk internal workflows with clear ownership and limited data scope

However, they come with serious governance risks:

Oversharing: Remember that the agents access everything the maker can access. As makers are employees - like everyone else - all users of the agent will have access to the same data as the maker. This can lead to unintentional data exposure. The responses are in the security context of the maker - this is likely not appropriate for most scenarios.
Accountability: It can be hard to determine whether an action came from the maker or from the agent.
Fragility: If the maker leaves the organization or loses access, the agent quietly stops working.

Best Practices for Using Maker Credentials

Agents with maker credentials could be used to work for a small team, but it is important to understand the risks and limitations. For example, an agent that posts updates to a team channel based on a shared SharePoint library could be built using maker credentials. Since the agent operates with the maker’s permissions, it may inadvertently expose sensitive data to team members who should not have access. Therefore, while maker credentials can be useful for small team scenarios, it is crucial to assess the risks and consider transitioning to more robust authentication methods as the agent’s role expands.
Agents with maker credentials should not be used for enterprise-wide deployments or scenarios involving sensitive data. As the agent’s responsibilities grow, it is advisable to shift to dedicated identities like Agent ID to ensure proper governance, security, and compliance.
Agents with maker credentials should not be shared with others, except in very limited scenarios where the risks are well understood and mitigated. Co-development would be one example. Sharing such agents broadly can lead to unintended data exposure and complicate accountability.
Maker credentials should be treated as temporary and non-production for anything that starts to look enterprise-critical.

See Use End-User or Maker Credentials When for admin guidance on how to disable maker credentials for autonomous agents.

When Personal or Maker Authentication Is (and Isn’t) Acceptable

A simple way to decide whether to stick with end-user or maker credentials is to look at potential impact, business criticality, and longevity.

Use End-User or Maker Credentials When

The agent acts mainly on one person’s or one small team’s data
The data is low to medium risk (internal collaboration, drafts, non-regulated content)
Interruptions are tolerable (e.g., if tokens expire or the maker is out)
The goal is learning, prototyping, or local productivity, not shared infrastructure

❗ Caution

The ‘Credentials to use’ are set to ‘End user credentials’ to ensure the agent uses the connection of the user interacting with it. If enabled by the admin, there is the option to use ‘Maker-provided credentials’. This should be selected only if the agent is intended to always use a specific connection regardless of the end user. Note that all interactions will be in the context of the maker’s connection - which may have unintended consequences when the agent is shared with others. That is, instead of sending a message to the end user’s Teams chat, it would always send to the maker’s Teams chat. Additionally, when the access token for the maker’s connection expires, the agent will fail until the maker renews the connection. Admins can see here for information on disabling the option for maker-provided credentials: Control maker-provided credentials for authentication.

Move Beyond User/Maker Credentials When

The automation is now business-critical or supports multiple business units
It touches sensitive or tenant-wide data (finance, HR, legal, regulated content)
It must keep running regardless of who is on vacation, changes roles, or leaves
You need auditable, enforceable governance (Conditional Access, DLP, access reviews)

When your answers lean toward these enterprise needs, it’s time to move to Agent ID and app-only permissions—the subject of Part 2.

Licensing and Billing for Personal and Maker Agents

Licensing for personal and maker scenarios is typically user-centric:

Interactive agents and personal automation are covered by the user’s existing M365 Copilot license.
As long as the agent is acting as a licensed human user, and the scenario aligns with your licensing terms, you’re within the expected model.

However, there is a common anti-pattern:

Anti-pattern: Assigning a Copilot license to a “service account” and using it as a robot user.

This approach is problematic because:

It violates the spirit (and often the terms) of user-based licensing
It hides enterprise workloads behind a pseudo-user, making governance harder
It doesn’t scale operationally for hundreds of agents

The billing for personal autonomous agent scenarios are either zero-cost (included in a users M365 Copilot license) or billed via pay-as-you-go consumption (Copilot Credits).

The billing for enterprise-grade autonomous agents will typically be billed via Copilot Credits and not tied to any individual user license. We’ll cover that in Part 2.

Publishing Autonomous Agents for Personal and Maker Use

When you create an autonomous agent using end-user or maker credentials, you can publish and share it with others in your organization, but there are important caveats:

Connection setup: Each user must set up their own connections to the services the agent uses (e.g., Outlook, Teams). The agent will run in the context of their credentials.
Data access: The agent can only access data that the individual user or maker has permission to see.
Token lifecycle: Each user is responsible for maintaining their own authentication tokens. They may need to re-authenticate periodically.
Governance: Admins should monitor the use of personal and maker agents to ensure they comply with organizational policies.

❗ It is not considered best practice to share autonomous agents broadly across the organization like interactive agents. Instead:

Limit access to relevant roles or departments.

Implement governance policies (approval workflows, audit logs).

Scale sharing only after validating security, compliance, and operational impact.

Publishing to a channel is not required

Autonomous agents created with Copilot Studio do not need to be published to a channel like interactive agents do.

Here’s why:

Interactive agents are designed for user-driven conversations in Copilot, Teams, the web or other channels, so publishing to a channel is required to make them accessible to end users.
Autonomous agents, on the other hand do not require user interaction. They are typically triggered by events or schedules and operate without direct user interaction. Because of this, they don’t require channel publishing—they execute based on their configured triggers and permissions.

Checklist for Safe Personal Automation

Even for “small” automations, you can adopt habits that make later scaling much easier.

1. Know Which Identity the Agent Uses

Confirm whether the agent is running as you, as a maker account, or as an Agent ID.
Document that choice with a short description and owner.

2. Scope Data Access Narrowly

Limit access to the minimum sites, teams, mailboxes, or file locations required.
Regularly review what data the agent can access and adjust as needed.

3. Avoid Service Accounts with User Licenses

Do not use shared mailboxes or generic “robot users” with end-user licenses to run autonomous agents.
If a scenario truly behaves like a system, treat it as a system—use Agent ID.

4. Plan for Lifecycle from Day One

Ask: What happens if I change roles, lose a license, or leave the company?
For this scenario, admins can leverage access reviews to periodically review the access of makers to ensure that only active makers have access to the agents they created. You can use Microsoft Admin Center to monitor an agent’s owner status. See Ownerless shared agent management. If reassignment is needed, admins can use PowerShell to reassign the agent to a new maker. See Reassign an agent’s owner with PowerShell.
Avoid anchoring critical workflows solely on your personal identity.
If you see that happening, you’re already in Part 2 territory.

Make sure any collaborators understand that tokens expire and that they may be prompted to re-authenticate.
Document the steps needed to re-establish connections if they break.

What’s Next: From Personal Helpers to Enterprise Infrastructure

Personal and maker-bound agents are a powerful on-ramp. They help you:

Learn Copilot Studio’s capabilities quickly
Deliver value to yourself and your immediate team
Explore patterns and ideas before involving central IT

But as soon as your automation begins to:

Run continuously,
Touch sensitive or broad datasets, or
Become business-critical for many users,

you need a different approach.

In Part 2: Enterprise-Grade Autonomous Agents with Agent ID and Least Privilege, we’ll walk through:

Enabling Agent ID for Copilot Studio
Designing least-privilege permission models using Sites.Selected and similar scopes
Using PowerShell and Microsoft Graph to grant precise access to SharePoint
Applying Conditional Access, DLP, and audit to keep agents compliant at scale
Aligning billing and licensing with enterprise expectations

That’s where your agents stop being sidekicks—and start becoming part of your core automation infrastructure.

Boost Developer Productivity with AI‑Driven Intent Detection and OData Mapping

Fri, 07 Nov 2025 08:11:16 -0800

This blog post will dive into how a Copilot agent goes from this:
“What are the new features in Microsoft Teams?”
to this:
https://www.microsoft.com/releasecommunications/api/v2/m365?$filter=products/any(p:+contains(tolower(p),+'teams'))&$top=0&$count=true
and output this:

Introduction

Developers have long wrestled with interpreting user input—often resorting to writing complex explicit logic to translate intent into actionable queries. This approach works, but it’s tedious, error-prone, and hard to maintain. Enter AI. Modern AI tools can automate much of this complexity, freeing developers to focus on building great experiences rather than parsing logic. Instead of manually mapping every possible input, AI can understand user intent and generate sophisticated OData queries on the fly. In this post, we’ll explore how AI transforms this workflow, using the Copilot Agent - M365 Roadmap Agent - as a case study. You’ll see how AI processes user input step by step—from parsing natural language to producing optimized queries—making intent detection smarter, faster, and more scalable.

Parsing User Input

The first step in the process is parsing the user’s input. When a user submits a query or request, the AI system analyzes the text to understand its structure and meaning. This involves breaking down the input into smaller components, such as keywords, phrases, and context. Natural Language Processing (NLP) techniques are employed to identify the intent behind the user’s request.

M365 Copilot agents utilize advanced tokenization techniques to break the input into manageable pieces. Each token is analyzed for its semantic meaning, and entities such as dates, project names, and user roles are recognized using Named Entity Recognition (NER) models. Context is maintained throughout the conversation by keeping track of previous interactions and user preferences, allowing the AI to provide more relevant responses.

In the case of the M365 Roadmap Agent, when a user inquires about specific features or updates, the AI parses the input to identify key terms related to Microsoft 365 services, feature names, and timelines. This ensures that the subsequent intent detection phase has a clear understanding of what the user is asking for.

Intent Detection

Once the input is parsed, the AI system moves on to intent detection. This stage involves determining the user’s goal or purpose in making the request. Machine learning models are trained on large datasets to recognize patterns in user behavior and language, enabling the AI to accurately classify the intent. Common intents might include searching for information, updating a record, or generating a report. The AI leverages techniques such as classification algorithms and deep learning to enhance its ability to detect intent accurately. By analyzing the context and nuances of the user’s input, the AI can differentiate between similar requests and provide precise interpretations of what the user wants to achieve.

In the case of the M365 Roadmap Agent, a common user prompt might be, “What are the new features in Microsoft Teams?” The AI recognizes the intent as a request for information about specific features, allowing it to retrieve the relevant data from the OData service.

Mapping Intent to OData Query

After identifying the user’s intent, the AI system maps this intent to an appropriate OData query. OData (Open Data Protocol) is a standardized protocol for building and consuming RESTful APIs. OData provides a uniform way to describe both the data and the data model, enabling interoperability between diverse systems. The AI leverages its understanding of the intent to construct a query that retrieves or manipulates data in accordance with the user’s request. This involves selecting the right entities, filters, and parameters to form a valid OData query.

In the M365 Roadmap Agent, when the AI detects the intent to retrieve new features in Microsoft Teams, it maps this intent to a specific OData query. The AI constructs the query by identifying the relevant entity (features), applying a filter to narrow down results to those related to Microsoft Teams, and setting parameters for pagination and counting. The resulting OData query looks like this: https://www.microsoft.com/releasecommunications/api/v2/m365?$filter=products/any(p:+contains(tolower(p),+'teams'))
Note 1: Note how the AI removed the word ‘Microsoft’ when translating the user’s prompt to the Odata query. The AI understands that ‘Microsoft’ is not needed in the query since all items are related to Microsoft 365.
Note 2: Note how the AI uses the contains function to filter results based on the product name, ensuring that only features related to Microsoft Teams are returned.
Note 3: Note how the AI uses tolower to make the filter case insensitive, enhancing the robustness of the query.
Note 4: Note how the AI uses the $filter parameter to specify the filtering criteria.

How does the AI know how to do this mapping?

The roadmap-openapi.json file plays a crucial role in this process by providing the AI with the necessary schema and endpoint definitions. It outlines the available entities, their relationships, and the parameters that can be used in OData queries. This structured information allows the AI to accurately map user intents to valid OData queries without requiring manual intervention from developers.

The description and summary fields in the roadmap-openapi.json file provide contextual information about each API endpoint and its purpose. This helps the AI understand what each endpoint is designed to do, allowing it to select the most appropriate one based on the detected intent. For example, the summary for the features endpoint might read “Retrieve a list of new features in Microsoft 365,” which directly aligns with the user’s request. Additionally, the examples objects provide sample queries and responses that the AI can reference when constructing its own OData queries. These examples serve as templates, guiding the AI in forming correct syntax and structure for the queries it generates.

The summary field offers a concise overview of the endpoint’s functionality, making it easier for the AI to quickly grasp its purpose during the mapping process. In contrast, the description field provides a more detailed explanation, including any nuances or specific use cases that may influence how the AI constructs the query. By leveraging both fields, the AI can ensure that it accurately interprets the user’s intent and generates an appropriate OData query that aligns with the intended functionality of the API.

1
2
3
4
5
6
7
8


{
 "paths": {
"/m365": {
 "get": {
 "summary": "Get Microsoft 365 roadmap items",
 "description": "Retrieve roadmap items with optional filtering, sorting, and pagination. Always use 'created' field for date operations, not 'createdDateTime'.",
 "operationId": "getM365RoadmapInfo",
...

In this example, the summary field provides a brief overview of the endpoint’s purpose, while the description field offers more detailed information about its functionality and usage. The AI can use this information to accurately map user intents to the appropriate API endpoint and construct valid OData queries.

The examples section in the OpenAPI specification is vital for delineating parameters and guiding the AI in query construction. By providing concrete examples of how to use various parameters, the AI can better understand the expected input formats and values. This helps prevent errors in query generation and ensures that the AI can produce OData queries that are both syntactically correct and semantically meaningful. For instance, if an example demonstrates how to filter results by a specific product name, the AI can replicate this structure when generating queries based on user requests.

1
2
3
4
5
6
7


"examples": {
 "teams_items": {
 "summary": "Teams items",
 "description": "Find roadmap items containing 'teams' in title",
 "value": "contains(tolower(title), 'teams')"
 },
...

In this example, the examples section provides a clear illustration of how to filter roadmap items by title. The AI can use this example to understand how to construct similar filters when responding to user queries about specific products or features.

The value field within the examples section specifies the actual filter expression that can be used in the OData query. In this case, the value “contains(tolower(title), ’teams’)” indicates that the AI should construct a filter to find roadmap items where the title contains the word “teams,” regardless of case. This direct example helps the AI understand how to format similar filter expressions when generating queries based on user input.

Clearly differentiating between the summary and description fields is crucial for the AI’s understanding of the API’s functionality. The summary allows for quick identification of the endpoint’s purpose, which is essential for efficient intent mapping. Meanwhile, the description provides the depth needed to understand any specific requirements or constraints associated with the endpoint. This distinction ensures that the AI can generate accurate and contextually appropriate OData queries that align with both the user’s intent and the API’s capabilities.

It is also important that the values of these fields are differentiated from one endpoint to another to avoid confusion during the mapping process. If multiple endpoints had similar summaries or descriptions, the AI might struggle to determine which endpoint best matches the user’s intent. Clear and distinct values help the AI to accurately associate user requests with the correct API functionality, leading to more precise OData query generation and ultimately a better user experience.

How is the OpenAPI file generated?

The OpenAPI file for the M365 Roadmap API is generated by analyzing the API’s output and endpoints, which are based on the OData protocol. Since OData is a standardized way to query and update data, it provides a clear structure that can be translated into an OpenAPI specification. GitHub Copilot plays a crucial role in this process by suggesting the appropriate structure and content for the OpenAPI file based on the characteristics of the API and sample outputs. By leveraging Copilot’s capabilities, developers can efficiently create a comprehensive OpenAPI specification that accurately represents the M365 Roadmap API’s functionality and endpoints.

Here is a sample prompt that can be used with GitHub Copilot to generate an OpenAPI specification from JSON output of the M365 Roadmap API:

Given the following JSON output from the M365 Roadmap V2 API https://www.microsoft.com/releasecommunications/api/v2/m365, generate an OpenAPI specification that describes the available endpoints, parameters, and responses. The API uses OData protocol for querying and updating data. Please include the necessary components such as paths, operations, parameters, and response schemas.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


{
 "@odata.context": "https://relcomms-prod-dagnegedescbeefs.b02.azurefd.net/api/v2/$metadata#M365",
 "value": [
 {
 "id": 65632,
 "title": "Excel: Refresh queries from Authenticated Data Sources in Excel for the Web",
 "description": "\u003Cdiv\u003EYou can now refresh Power Query data from data sources that require authentication in Excel for the Web. \u003C/div\u003E",
 "cloudInstances": [
 "Worldwide (Standard Multi-Tenant)",
 "GCC",
 "GCC High",
 "DoD"
 ],
 "platforms": [
 "Web"
 ],
 "releaseRings": [
 "General Availability",
 "Targeted Release (Entire Organization)"
 ],
 "moreInfoUrls": [],
 "products": [
 "Excel"
 ],
 "generalAvailabilityDate": "2025-05",
 "previewAvailabilityDate": null,
 "created": "2023-08-22T23:16:17.6100000Z",
 "status": "In development",
 "modified": "2025-04-29T23:15:05.1130514Z",
 "locale": null,
 "availabilities": [
 {
 "ring": "General Availability",
 "year": 2025,
 "month": "May"
 }
 ]
 }
 ]
}

Here is the resulting OpenAPI specification generated by GitHub Copilot: roadmap-openapi-yml-sample

Generating Sophisticated Queries

One of the key advantages of using AI for intent detection and query mapping is the ability to generate sophisticated queries that go beyond simple CRUD (Create, Read, Update, Delete) operations. The AI can analyze the context of the user’s request and incorporate additional logic to create more complex queries. For example, if a user asks for a report on sales data for a specific time period, the AI can automatically include date filters, aggregation functions, and other relevant parameters in the OData query.

For example, the user might ask “Are there any roadmap items that mention agent in the description are shipping in the next 90 days and mention Purview or Copilot in the product field?” The AI can break down this request into multiple components: filtering by description, map the ‘shipping’ constraint to the availabilities field, and applying an OR condition for the product field. The resulting OData query might look like this:
https://www.microsoft.com/releasecommunications/api/v2/m365?$filter=contains(tolower(description), 'agent') and startsWith(shipping, '2023-') and (contains(tolower(product), 'purview') or contains(tolower(product), 'copilot'))](https://www.microsoft.com/releasecommunications/api/v2/m365?filter=contains(tolower(description),+'agent')+and+(products/any(p:+contains(tolower(p),+'purview'))+or+products/any(p:+contains(tolower(p),+'copilot')))+and+(availabilities/any(a:+a/year+eq+2025+and+(a/month+eq+'November'+or+a/month+eq+'December'))+or+availabilities/any(a:+a/year+eq+2026+and+a/month+eq+'January'))&orderby=modified+desc)
This level of sophistication allows users to make more nuanced requests without needing to understand the underlying query language. The AI handles the complexity, ensuring that users receive accurate and relevant results based on their specific needs.

Reducing Developer Workload

By automating the process of intent detection and OData query mapping, AI significantly reduces the workload for developers. Instead of spending hours writing and debugging complex logic, developers can rely on AI to handle these tasks efficiently. This not only speeds up the development process but also minimizes the risk of errors that can arise from manual coding. Developers can now focus on designing better user experiences and delivering value through their applications.

Conclusion

The integration of AI into the development process for intent detection and OData query mapping represents a significant advancement in software development. By automating the mundane and error-prone aspects of coding, AI empowers developers to concentrate on what truly matters: achieving their desired outcomes and creating innovative solutions. As AI continues to evolve, we can expect even more sophisticated capabilities that will further enhance the development experience.

🚀 Microsoft 365 Copilot Highlights – October 2025

Tue, 04 Nov 2025 10:15:00 -0800

Welcome to your monthly roundup of exciting updates to Microsoft 365 Copilot! October brought a wave of new features designed to make your workday smoother, smarter, and more insightful. Whether you’re prepping for meetings, analyzing employee sentiment, or diving into search results, Copilot is getting better at helping you do more with less effort.

MC1176368 : (Updated) GPT-5 becomes the default Copilot model

Summary
Starting in November 2025, Microsoft 365 Copilot will upgrade to GPT-5 as its default model. Initially, users can toggle GPT-5 on or off, but by the end of the rollout, it becomes mandatory. GPT-5 introduces dynamic model routing, which intelligently selects the best-performing variant for each prompt. This means faster, more accurate, and more context-aware responses across all Copilot endpoints.

How it works
The rollout happens in two phases:

Phase 1: GPT-5 is enabled by default, but users can opt out using a toggle.
Phase 2: GPT-5 becomes the default with no opt-out option. The toggle is removed. Users can still bypass GPT-5’s deeper reasoning by selecting “Get a quick answer” for simpler queries. This applies across Copilot Chat and other endpoints, except for Teams mobile, which rolls out later.

Why it matters
This upgrade marks a major leap in AI capability for Microsoft 365 users. With smarter routing and deeper reasoning, users will experience more relevant and efficient assistance. It simplifies workflows and boosts productivity, especially for complex tasks. Organizations should prepare support teams and update documentation to reflect this change.

MC1181210 : Microsoft Viva: Copilot employee experience outcomes report with Viva Glint in the Copilot Analytics dashboard

Summary
A new Power BI report in Viva Insights connects Microsoft 365 Copilot usage with employee sentiment data from Viva Glint surveys. This feature, rolling out in late November 2025, helps organizations understand how Copilot impacts employee experience. It requires both Viva Glint and Microsoft 365 Copilot licenses and admin setup to integrate the data sources.

How it works
The report segments data by Copilot usage patterns, sentiment outcomes, and organizational attributes. Admins must:

Assign licenses
Match employee records
Configure Entra ID settings
Set up Viva Glint to Viva Insights integration Once configured, analysts can run predefined queries to populate the report.

Why it matters
This feature empowers organizations to make data-driven decisions about Copilot adoption and employee engagement. By linking AI usage to sentiment, leaders can identify areas of success and improvement, enhancing both productivity and workplace satisfaction.

MC1176366 : (Updated) Microsoft Outlook: Enhanced search experience with Copilot in Classic Outlook

Summary
Classic Outlook is getting a Copilot-powered search enhancement. After performing a search, users will see a side pane with AI-generated summaries of results from documents, Teams messages, and more. Users can interact with the pane, ask follow-up questions, and navigate to cited content. The rollout begins mid-December 2025.

How it works

The Copilot pane appears after a search.
Summaries are generated using large language models.
Users can opt into AI-generated content.
No admin action is needed; the feature is enabled by default.

Why it matters
This update makes search results more actionable and insightful. Instead of sifting through documents, users get instant summaries and can dive deeper with follow-up questions. It’s a productivity booster for anyone who relies on Outlook for research or collaboration.

MC1169081 : Copilot meeting preparation improvements and expanding to more meeting types

Summary
Microsoft Copilot in Outlook is expanding its meeting preparation capabilities to include all meeting types, including 1:1s. Users will receive real-time contextual insights—like summaries of tasks, documents, and goals—directly within the meeting event form. This feature is enabled by default starting mid-October 2025.

How it works

Copilot provides contextual insights in the meeting form.
Users can chat with Copilot to explore meeting goals or confirm action items.
Suggested prompts guide deeper preparation.
No admin changes are needed.

Why it matters
This update helps users walk into meetings better prepared and more informed. By surfacing relevant content and enabling interactive prep, Copilot turns meetings into more productive and focused sessions. It’s especially valuable for busy professionals juggling multiple meetings.

MC1166852 : (Updated) Microsoft Viva Copilot Analytics launches new agent dashboard

Summary
Microsoft Viva is launching a new Agent Dashboard within Copilot Analytics. This dashboard provides detailed insights into agent adoption, usage trends, and Copilot credit consumption. It’s designed for organizations with 50+ Copilot licenses and rolls out in preview in November 2025, with general availability in February 2026.

How it works

Tracks metrics like active agents, responses, and credit usage.
Offers retention trends and top agent analysis.
Integrates with the Copilot Dashboard’s Adoption tab.
Access is managed via VFAM (Viva Feature Access Management) controls.

Why it matters
This dashboard gives leaders and analysts the tools to understand how Copilot agents are being used across the organization. It supports strategic planning, helps optimize credit usage, and identifies high-performing agents for deeper analysis.

Conclusion

The updates to Microsoft Copilot in October 2025 bring significant enhancements across various applications, including Outlook and Viva. With improved search capabilities, meeting preparation tools, and advanced analytics dashboards, users can expect a more integrated and efficient experience. These features are designed to boost productivity, streamline workflows, and provide valuable insights, making Microsoft Copilot an essential tool for modern workplaces.

Unlock Copilot's Full Power: Why @Mentioning Agents Changes Everything!

Mon, 03 Nov 2025 00:00:00 +0000

Understanding Microsoft 365 Copilot and Agents

Microsoft 365 Copilot is revolutionizing productivity by integrating AI-powered assistance directly into your favorite Microsoft 365 apps. One of its standout features is the ability to use agents—specialized AI tools designed to perform specific tasks, such as summarizing emails, generating reports, or analyzing data.

Two Ways to Interact with Copilot Agents

When interacting with these agents, you have two main options:

Click the Agent: This launches the agent in a focused context, allowing you to interact with it directly.
@Mention the Agent in Copilot Chat: This keeps the conversation within the broader context of Copilot, enabling more complex workflows.

The Problem: Isolated Contexts

Have you ever noticed that when you start an agent by clicking on it, interact with it, and then when you ask for a follow-up action—like “Create a PowerPoint deck from the agent’s output”—Copilot replies with something like “I’d love to generate the PowerPoint deck for you, but I currently don’t have file creation capabilities enabled in this environment."

Here’s why:
When you launch an agent directly, its conversation runs in an isolated context. Skills and knowledge available to Copilot Chat, are not available in the agent’s context.

The Solution: Use @Mentions

If you @mention the agent inside Copilot Chat, the agent’s responses become part of the ongoing Copilot conversation. This means you can chain tasks together without losing context. For example:

@SalesAgent summarize Q3 pipeline
Close the SalesAgent
Then: Turn that summary into a PowerPoint deck

Because everything happens in the same Copilot Chat thread, the context persists, and Copilot can build on the agent’s output.

This an example of context sharing, where the output of one agent can be passed to another agent like Researcher or to a skill - like creating a PowerPoint deck.

When to Click vs. @Mention

Click the Agent
✔ When you want a focused, single-purpose session
✔ When you don’t need to reuse the output in Copilot Chat
✔ For deep dives or testing agent-specific flows

@Mention the Agent in Copilot Chat
✔ When you plan to chain tasks (e.g., summarize → create deck → draft email)
✔ When you want Copilot to orchestrate follow-up actions
✔ For workflows that mix agent output with other Copilot capabilities

Pro Tip:
Use @mentions in Copilot Chat whenever you want to keep the agent’s results available for additional steps. Clicking an agent is great for focused tasks, but @mentioning is your best friend for multi-step workflows.

Message Center Agent 2.0 Released - Explore the New Features

Wed, 29 Oct 2025 07:29:02 -0700

What is the Message Center Agent?

The Message Center Agent is a powerful Microsoft 365 Copilot agent designed to streamline how IT administrators and Microsoft 365 users interact with Message Center updates and Microsoft 365 Roadmap information. Built as a declarative agent for Microsoft 365 Copilot, it provides a conversational interface that allows you to query, filter, and explore Microsoft 365 service announcements using natural language.

Instead of manually navigating through the Message Center portal or searching through lengthy roadmap documents, you can simply ask the agent questions like “What updates affect SharePoint?” or “Show me security-related changes from the last month.” The agent intelligently processes your requests and delivers relevant information in an easy-to-digest format, making it an indispensable tool for staying informed about Microsoft 365 changes that impact your organization.

Version 2.0 Release

We’re excited to announce the release of Message Center Agent 2.0—a significant update that brings a suite of powerful new features to make managing Microsoft 365 messages even easier and more efficient. If you’re already a user, get ready for even smoother workflows. If you’re new, now is the perfect time to jump in and see what the Agent can do for your organization.

Key Features in Version 2.0

Implemented Paging for Large Message Lists:
One of the standout features in this release is the enhanced paging support. Now, when you fetch messages, the total number of available messages is displayed, allowing you to better understand the scope of your data. You can seamlessly navigate through extensive lists using intuitive next, previous, first, and last page prompts, ensuring you never miss an important update.

Inline Microsoft 365 Roadmap Details:
Message Center Agent 2.0 now displays Microsoft 365 Roadmap item details inline with each relevant message. These details are presented in a user-friendly adaptive card, including a direct link for deeper exploration on the official Roadmap site. This integration helps you stay informed about the latest product changes and upcoming features, all in one place.

Here is the Roadmap detail card displayed within a Message Center message result:

Expanded Prompting Guide:
The documentation has been updated with a comprehensive prompting guide for Message Center updates and Roadmap items. The new guide offers natural-language query patterns and tips for more effective searches, making it easier for both new and experienced users to get the most out of the Message Center Agent. You can find the guide in the repository here or via the README’s Suggested Scenarios and Prompts section.

Try It Out or Roll Back Anytime

If you’d like to try the latest features, download version 2.0 from the repository today. The README file contains detailed information on provisioning for testing purposes and publishing for use of the agent throughout your organization.

Prefer the previous version? No problem—you can always revert to version 1.0 by downloading it from the Releases list. Feedback is always welcome, so let the team know what you think by creating an issue in the GitHub repository. https://github.com/mjfusa/Message-Center-Agent

Thank you!

Thank you to everyone who has supported Message Center Agent’s development. We look forward to seeing how these new features help you stay organized and informed!

🚀 August 2025 Update: Copilot Chat Comes to Your Favorite Microsoft 365 Apps

Sat, 30 Aug 2025 12:42:25 -0700

Summary

This month’s update marks a significant expansion of what you can do with Copilot inside the Microsoft 365 ecosystem. If you’ve ever wished Copilot could be more seamlessly integrated into your daily workflow—without jumping between apps or chat windows—this is the moment you’ve been waiting for.

Microsoft is rolling out Copilot Chat directly within Word, Excel, PowerPoint, Outlook, and OneNote, allowing users to interact with AI in the flow of their work. Whether you’re writing, analyzing, presenting, or emailing, Copilot is now just a click away in the ribbon.

And here’s the exciting part: For unlicensed users, this marks the first time AI is embedded directly into Microsoft 365 apps, offering web-grounded chat and basic document support. That means even without a Copilot license, you can still benefit from intelligent assistance—provided your admin has enabled pinning.

How It Works

Once enabled, you’ll see a Copilot Chat button in the ribbon of supported apps. Clicking it opens a side panel where you can interact with Copilot without leaving your current file.

The chat respects your last state—if it was open when you closed the file, it’ll reopen automatically next time.

Access is granted to:

Licensed users with Microsoft 365 Copilot
Unlicensed users if the Pin Microsoft 365 Copilot Chat setting is enabled in the admin center

Admins can manage this via the Microsoft 365 admin center. If the setting is “Do not pin,” unlicensed users won’t see the chat. Switching it to “Pin” makes Copilot Chat available to everyone.

No additional configuration is needed unless you want to adjust pinning behavior.

Why It Matters

This update is a game-changer for productivity and accessibility. By embedding Copilot Chat directly into the apps we use every day, Microsoft is removing friction and making AI assistance more intuitive and inclusive.

For licensed users, it’s a smoother, faster way to get help—whether you’re drafting a report, crunching numbers, or preparing a presentation.

For unlicensed users, it’s a breakthrough: AI is now part of the Microsoft 365 experience, offering real-time chat and basic document support without needing a full Copilot license.

From an admin perspective, it’s low-maintenance and high-impact. The only action needed is reviewing your pin settings to ensure users get access.

Conclusion

This blog post was based on Microsoft Message Center ID MC1096218, retrieved using the Message Center Agent. The update reflects changes rolling out from June through September 2025, and it’s one of the most exciting enhancements to Microsoft 365 Copilot yet.

🔗 Learn more and manage settings: Manage Microsoft 365 Copilot Chat | Microsoft Learn
🛠 Generated with the help of Message Center Agent

Managing 429 Errors in Microsoft Graph API – Part 2: Understanding App-Level Rate Limits and Resource Units

Thu, 28 Aug 2025 15:41:34 -0700

In Part 1, we explored the fundamentals of 429 errors in Microsoft Graph API, including retry logic, batching, and the nuances of AppResourceUnit (ARU) throttling. In this follow-up, we dive deeper into how rate limits are enforced at the application level, how resource units are consumed in SharePoint Graph API calls, and how telemetry analysis can help optimize usage.

🔍 App-Level Rate Limiting: It’s Not Just About Services

A common misconception is that throttling is tied to specific Microsoft 365 services like SharePoint or OneDrive. In reality, rate limits are enforced per client application, not per service. This means that every request your app makes—whether via Microsoft Graph, CSOM, or REST—counts toward the app’s usage quota.

These quotas are license-based, meaning the number of Microsoft 365 licenses in your tenant directly affects your app’s daily limit. For example, an app in a tenant with 5,000–15,000 licenses may have a 24-hour limit of 3.6 million resource units.

📊 SharePoint Graph API Resource Units: What Do Your Calls Cost?

Microsoft has introduced a resource unit model to quantify the cost of different Graph API operations. This helps developers understand how their apps consume quota and why throttling may occur.

Below is a hypothetical breakdown that maps 1.8 million Graph API calls to the number of actual resource units consumed. This illustrates the effective “cost” of different types of operations:

Rate	Description	Percent	Resource Units	Graph Calls
1.0	File Download	67.0%	1,206,000	1,800,000
2.0	Multi-item Query (e.g., list children)	10.0%	360,000
5.0	Permissions Operation ($expand=permissions)	23.0%	2,070,000
	Total	100.0%	3,636,000

⚠️ Note: This breakdown is illustrative and not based on actual telemetry. It demonstrates how different Graph API operations carry different resource unit weights. For instance, a single permissions-related call may “cost” five times more than a file download. Understanding this cost model is essential for managing your app’s quota effectively.

For more details, see the official documentation on application throttling in SharePoint Online.

📈 Telemetry Analysis: Your Optimization Superpower

To truly optimize your app’s Graph API usage, you need visibility into which operations are being called and how frequently. Most apps today are instrumented with telemetry platforms that can capture this data.

By analyzing telemetry logs:

Identify high-cost operations (e.g., frequent permission queries).
Spot patterns in multi-item queries that could be batched or paginated.
Evaluate whether downloads are being triggered unnecessarily.

This analysis can help you reduce resource unit consumption without sacrificing functionality.

🚀 Bonus Tip: Try SharePoint Service Prioritization

If your app is heavily reliant on SharePoint operations, consider enabling Service Prioritization in SharePoint Online. According to https://learn.microsoft.com/en-us/sharepoint/dev/general-development/service-prioritization-in-sharepoint, this feature can provide 10x more capacity for SharePoint-specific Graph API calls—potentially alleviating throttling issues for high-volume apps.

Have questions or want to share your own optimization strategies? Drop a comment below or reach out!

Microsoft 365 Copilot Pre-release Features and Early Access

Tue, 19 Aug 2025 13:33:41 -0700

Introduction

Early access to Microsoft 365 Copilot features enables organizations to test and provide feedback on new capabilities before they are widely released. This can help organizations prepare for upcoming changes and ensure a smoother transition when features become generally available.

Ways to Access Pre-release Microsoft 365 Copilot Features

Microsoft 365 ‘Targeted Release’

Targeted Release is a Microsoft 365 deployment ring that provides early access to updates before general rollout. It enables early access to new features so that IT admins and selected users can evaluate changes, provide feedback, and prepare for organization-wide adoption. Targeted Release can be configured for the entire organization or specific users. While features in this ring are generally stable, they may still undergo changes before General Availability. It’s commonly used in production environments for early validation—not just for isolated testing.

How to Enable Early Access - ‘Targeted Release’

Go to the Microsoft 365 admin center.
In the left navigation pane, select Settings > Org settings.
Under Services, select Microsoft 365 Copilot.
Toggle the setting to enable early access for your organization.

What to Expect in Targeted Release

You can use the Microsoft 365 Roadmap to stay informed about the features and updates being developed for Microsoft 365 Copilot. It allows organizations to filter and search for specific features, view their status, and understand the timeline for their availability. The following is an explanation of the ‘Release phase’ filter options available in the tool.

Release Phase

Current Channel The Current Channel is for organizations who want to receive Microsoft 365 updates as soon as they are available. It is the default channel for most organizations.
General Availability General Availability refers to the stage when a feature is fully developed, tested, and ready for all users. It is the most stable version of a feature.
Preview The Preview stage is for organizations who want to test new features before they are released to the general public. It allows users to provide feedback and report issues. A Preview feature may still have bugs and is not recommended for production use. Previews are typically available for a limited time and may be subject to change in the ‘Current Channel’.
Targeted Release See above definition.

Frontier Program

Microsoft’s Frontier is a program that gives customers early access to advanced Copilot features still under development. It lets organizations trial and evaluate new capabilities in their own environments and provide feedback. This helps innovators and early adopters maintain a competitive edge by adopting innovations earlier than the general release.

Program Criteria

The only criterion is an organization with Microsoft 365 Copilot licenses deployed. The Frontier program is available worldwide to M365 Copilot licensed customers, in English only, until the feature reaches General Availability (GA). Once GA is achieved, the feature will be removed from Frontier. The first agents to be released under Frontier were the Researcher and Analyst agents.

Controlling access to Frontier features

A new setting in the Microsoft Admin Center ‘Copilot Features’ allows IT admins to control access to the Frontier program and its associated features. This setting enables organizations to manage which users can access these preview and experimental features and provide feedback on new capabilities. The ‘Copilot Features’ control can be accessed through the Settings page under the Copilot tab.

🔍 Researcher Agent

The Researcher agent is designed to help users perform deep, multi-step research tasks by gathering and summarizing information from both internal work content and the web.

Overview & How to Use: Get started with Researcher in Microsoft 365 Copilot – Microsoft Support

Blog Announcement: Introducing Researcher and Analyst in Microsoft 365 Copilot – Microsoft 365 Blog

📊 Analyst Agent

The Analyst agent acts like a data scientist, helping users analyze complex datasets, generate insights, and create visualizations using natural language prompts.

Overview & How to Use: Get started with Analyst in Microsoft 365 Copilot – Microsoft Support

👉 Learn more about Microsoft Frontier

Enable Access to External AI Models

⚠️ Important Notes

External models like Anthropic’s are not recommended for production use due to potential latency, timeouts, and limited support.
Data processed by these models is outside Microsoft’s compliance boundaries, and governed by Anthropic’s terms.
You must be a Global Administrator to enable external models in Microsoft 365 Admin Center.
Once enabled, external models can be selected in Copilot Studio agent settings under the Model section.

Microsoft 365 Admin Center Setup

You must first allow access to external models (like Anthropic’s Claude) in the Microsoft 365 Admin Center:

Go to Microsoft 365 Admin Center.
Navigate to:

Copilot → Settings → Data Access → AI Providers for Other Large Language Models
Under LLM providers, select Anthropic.
Agree to the Terms and Conditions and click Allow Provider.

Access External Models in Copilot Studio

Once Anthropic is enabled in Microsoft 365, configure it in the Power Platform Admin Center:

Go to Power Platform Admin Center.
Navigate to:

Copilot → Settings → Power Platform → Preview and experimental AI models
Turn on ‘Preview and experimental AI models’ for each environment and or environment group.

Access External Models in Copilot Studio

To select an external model for your agent:

Open your agent in Copilot Studio.

Go to the Settings page.
In the Model section, choose a model labeled external (e.g., Anthropic Claude)

Microsoft 365 Insider Program - Copilot Not Included

The Microsoft 365 Insider Program is designed for users who want to get early access to new features and provide feedback to Microsoft. Insiders can participate in various channels, including the Beta Channel and the Dev Channel, to test upcoming features before they are released to the general public. Note: This program does not include access to pre-release Copilot features, but does provide early access to Microsoft 365 applications and features.

Program Criteria

To participate in the Microsoft 365 Insider Program, organizations must meet certain criteria, including a commitment to providing feedback and insights on new features and a willingness to collaborate with Microsoft on product development.

How to join

Organizations interested in joining the Microsoft 365 Insider Program can apply through the Microsoft 365 admin center or by contacting their Microsoft account representative.

Learn more: Microsoft 365 Insider Program

In Summary

Microsoft 365 Copilot offers several pathways for organizations to gain early access to innovative features before they reach General Availability. Programs like Targeted Release, and the Copilot Frontier Program enable IT teams and users to evaluate new capabilities, provide feedback, and prepare for broader adoption. While each program has its own criteria and scope, they collectively support a proactive approach to digital transformation and productivity enhancement. By participating in these early access initiatives, organizations can stay ahead of the curve, optimize their workflows, and contribute to the evolution of Microsoft 365 Copilot.

About

Mon, 11 Aug 2025 09:01:04 -0700

Hi there! 👋

I’m a Senior Cloud Solution Architect at Microsoft with a strong developer background and a passion for helping enterprise customers unlock real business value from their AI investments. I’ve spearheaded innovations like an AI-driven agent that cuts through information overload for IT administrators, enabling faster, more informed decision-making. I specialize in Microsoft 365 Copilot and the Power Platform, partnering with organizations to streamline workflows, automate business processes, and drive meaningful adoption of Microsoft’s AI capabilities. As a frequent speaker on AI and modern work, I enjoy sharing practical insights that help teams work smarter and achieve more with Microsoft technologies.

Please feel free to contact me on BlueSky @mjfnet.com

Managing 429 Errors in Microsoft Graph API a Practical Guide for Developers

Tue, 05 Aug 2025 07:29:02 -0700

This post was updated with new insights on AppResourceUnit throttling and Graph API call batching. (Spoiler: Batching has no impact on throttling limits.)

Encountering a 429 Too Many Requests error while working with the Microsoft Graph API can be disruptive—especially when building scalable, enterprise-grade solutions. This guide is designed to help developers understand the root causes of these errors and apply proven strategies to mitigate them effectively.

Whether you’re dealing with standard retry throttling or the more nuanced AppResourceUnit (ARU) throttling, this post provides actionable guidance to help you maintain application performance and reliability.

🚦 Understanding 429 Errors

A 429 error indicates that your application is exceeding the allowed request rate. Microsoft Graph enforces throttling to ensure service stability and equitable resource distribution across tenants. When throttling is triggered, the API responds with a 429 status code and typically includes a Retry-After header indicating when it is safe to retry the request.

There are two primary types of 429 errors:

Standard Retry Throttling

This occurs when your app surpasses general request thresholds. The recommended approach is to implement exponential backoff and respect the Retry-After header.

AppResourceUnit (ARU) Throttling

This form of throttling is tied to your tenant’s license-based resource allocation and requires a more strategic approach.

🔧 What Is AppResourceUnit Throttling?

ARU throttling is a resource-based control mechanism used in Microsoft 365 services such as SharePoint Online and Microsoft Graph. It limits API usage based on the number and type of licenses (e.g., E3, E5) assigned to your tenant. See here for more information on AppResourceUnit throttling: Application Throttling

Key Characteristics:

Error Codes: 429_AppResourceUnit, 429_AppResourceUnitDaily
Quota Enforcement: Determined by license count and not adjustable via support or licensing changes.
Common Triggers:
- High-volume operations (e.g., scanning millions of files)
- Exceeding tenant-wide resource unit quotas

This mechanism is intentionally designed to promote fair usage and maintain service integrity across all tenants.

See part 2 of this series for a deeper dive into AppResourceUnit throttling here: Managing 429 Errors in Microsoft Graph API – Part 2: Understanding App-Level Rate Limits and Resource Units

📊 Monitor and Analyze Usage

Track Tenant-Wide Graph API Usage by Application

To effectively manage and prevent 429 errors, it’s essential to identify which applications in your tenant are consuming the most Microsoft Graph API resources. The most straightforward approach is to leverage the getApiUsage endpoint from the beta version of the Graph Reports API, which provides detailed usage metrics by application:

GET /reports/getApiUsage(period={period_value},serviceArea={service_area},appId={appId})

Key Benefits:

Application-Level Visibility: See exactly which apps are making the most API calls
Time-Based Analysis: Track usage patterns over different time periods (D7, D30, D60)
Request Volume Metrics: Monitor total request counts and identify high-volume consumers
Proactive Planning: Identify applications that might be approaching throttling limits

Available Time Periods:

D7 - Last 7 days
D30 - Last 30 days
D60 - Last 60 days

Response Data Includes:

Application ID
Total request count by application
Service area (Always returns ‘Microsoft Exchange’. May be subject to change since this is a beta endpoint)

Required Permissions:

Reports.Read.All

Required User Roles

Global Reader
Global Administrator

This data is invaluable for:

Capacity Planning: Understanding which applications and endpoints drive the highest API usage
Troubleshooting: Quickly identifying the source of unexpected throttling events by analyzing endpoint usage patterns

See this post for a practical example of how to generate a report showing the API usage by application using PowerShell and Excel: Tracking Microsoft Graph API Usage with PowerShell.

See here for more information on throttling limits: Microsoft Graph service-specific Graph API throttling limits.

🛠️ Recommended Mitigation Strategies

To ensure your applications remain resilient and performant, consider the following best practices:

✅ Implement Retry Logic

Always honor the Retry-After header and use exponential backoff to avoid overwhelming the service.

📦 Can Graph API Request Batching Reduce Throttling?

Batching reduces the number of individual HTTP requests by combining them into a single /v1.0/$batch call. While this increases the efficiency of your code, it does not impact encountering throttling limits. This is because requests in a batch are evaluated individually against the applicable service’s throttling limits.

📘 Learn more: https://learn.microsoft.com/graph/json-batching

⏳ Distribute Load Strategically

Avoid sending large volumes of requests in short bursts. Instead, spread API calls over time or across multiple applications to balance the load.

📁 Use optimizations for OneDrive Scanning

Uses best practices when scanning OneDrive content to minimize API calls and reduce throttling risk. Here are some specific strategies: https://learn.microsoft.com/en-us/onedrive/developer/rest-api/concepts/scan-guidance This includes using delta queries to detect changes incrementally rather than performing full scans. This approach significantly reduces the number of API calls and improves efficiency.

📘 Learn more: https://learn.microsoft.com/onedrive/developer/rest-api/concepts/scan-guidance and https://learn.microsoft.com/onedrive/developer/rest-api/concepts/delta-query-onedrive

🥇 Leverage Service Prioritization for SharePoint

If your application interacts with SharePoint data, enabling Service Prioritization can provide substantial benefits:

Advantages of Service Prioritization:

Reduced Throttling Risk: Prioritized applications are the last to be throttled during high-demand periods.
Increased Resource Limits: These apps can scale their usage up to 10x the standard limits when additional capacity is available.
Dedicated Resource Units: Prioritized apps receive isolated resource units, ensuring consistent performance regardless of other tenant activity.
Enhanced Support for High-Volume Operations: Ideal for scenarios such as compliance scans, content discovery, or data migration.
No Code Changes Required: Once configured, prioritization benefits apply automatically.

📘 Learn more: https://learn.microsoft.com/en-us/sharepoint/sharepoint-prioritization

🚀 Consider Microsoft Graph Data Connect for Large-Scale Operations

For scenarios involving bulk data extraction—such as analytics, compliance, or reporting—consider using Microsoft Graph Data Connect. It is optimized for large-scale operations and is not subject to the same throttling constraints as REST APIs.

📘 Learn more:

🧭 Additional Considerations

Microsoft actively monitors and categorizes throttling events to improve service reliability.
Throttling can have cascading effects across applications, even when the root cause is isolated.

💬 Conclusion

Throttling is a fundamental aspect of working with cloud APIs, but it doesn’t have to hinder your development efforts. By understanding the different types of 429 errors and applying these best practices, you can build robust, scalable applications that operate efficiently within Microsoft Graph’s service boundaries.

If you’re interested in reviewing your tenant’s current API usage or exploring architectural strategies to reduce throttling risk, feel free to reach out.

🔍 Tracking Microsoft Graph API Usage with PowerShell: A Guide for Admins

Mon, 04 Aug 2025 17:18:43 -0700

As organizations increasingly rely on Microsoft Graph to power their apps and services, understanding which applications are tapping into this powerful API becomes essential for security, governance, and optimization. That’s where the Graph API Usage Report Script steps in—a PowerShell-based solution designed to give administrators clear visibility into Graph API consumption across their tenant.

A good use case for this script is to track down which applications are making excessive API calls, potentially leading to throttling issues or security concerns. By identifying these applications, you can take proactive measures to optimize their usage or investigate unauthorized access. See this post for more details on Managing 429 Errors (throttling) in Microsoft Graph API.

This script not only tracks API usage but also resolves application GUIDs into human-readable names, making it easier to identify which apps are making calls to Microsoft Graph. Whether you’re an admin looking to audit app activity or a developer wanting to optimize your API calls, this tool is invaluable.

🚀 What Does the Script Do?

The script leverages the beta getApiUsage endpoint of Microsoft Graph to generate a detailed report of API usage. It retrieves raw usage data and enriches it by resolving application GUIDs into human-readable names—making the data both actionable and admin-friendly.

Whether you’re troubleshooting unexpected API spikes, auditing third-party integrations, or simply trying to understand your app landscape, this script delivers the insights you need.

📋 Prerequisites

Clone this repository to get started:

https://github.com/mjfusa/get-graphapi-usage

Required Permissions

The script requires the following Microsoft Graph API permissions:

Reports.Read.All - To read usage reports
Application.Read.All - To read application information
Directory.Read.All - To read directory information

Required User Roles (for Microsoft Entra)

Reports Reader
Global Reader

🛠️ Key Components

Install-Prerequisites.ps1

Before diving into usage tracking, you’ll need to ensure your environment is ready. The Install-Prerequisites.ps1 script installs the necessary Microsoft Graph PowerShell SDK modules:

1
2
3


Install-Module Microsoft.Graph.Authentication -Force
Install-Module Microsoft.Graph.Applications -Force
Install-Module Microsoft.Graph.Reports -Force

These modules enable authentication, application metadata retrieval, and access to usage reports—everything the main script depends on.

Get-GraphAPIUsage.ps1

This is the main script that does the heavy lifting. Here’s what it brings to the table:

✅ Authentication Prompt: Secure sign-in with required permissions (Reports.Read.All, Application.Read.All, Directory.Read.All)
📊 Usage Data Retrieval: Pulls usage metrics from the Graph API
🧠 App Name Resolution: Translates App IDs into recognizable names
🧾 Flexible Output: View results in the console or export to CSV
🧮 Summary Stats: Provides a quick overview of usage patterns
🛡️ Error Handling: Gracefully manages permission issues, missing data, and API hiccups
⚡ Caching: Reduces redundant API calls by storing resolved app names during execution

Example Usage:

1

.\Get-GraphAPIUsage.ps1 -Days 7 -OutputPath "C:\Reports\GraphAPIUsage.csv"

This command fetches the last 7 days of usage and saves the report to a CSV file.

📁 Output Snapshot

The report includes the following columns:

Date – When the API call occurred
ServiceArea – The Graph service area (e.g., Microsoft365, AzureAD)
TenantId – Your tenant’s unique identifier
AppId – The GUID of the calling application
AppName – The resolved name of the application
Usage – Number of API requests made

Example:

1
2
3
4
5
6


"Date","ServiceArea","TenantId","AppId","AppName","Usage"
"2025-08-03 00:00:00Z","Microsoft Exchange","d3d6872a-0e81-480f-88e4-8e625ee447ba","d8615cf7-11a7-4eae-9b2b-426a9c5e27b8","MessageCenterAgent-reg","13"
"2025-08-02 00:00:00Z","Microsoft Exchange","d3d6872a-0e81-480f-88e4-8e625ee447ba","de8bc8b5-d9f9-48b1-a8ad-b748da725064","Graph Explorer","1"
"2025-08-02 00:00:00Z","Microsoft Exchange","d3d6872a-0e81-480f-88e4-8e625ee447ba","d8615cf7-11a7-4eae-9b2b-426a9c5e27b8","MessageCenterAgent-reg","16"
"2025-08-02 00:00:00Z","Microsoft Exchange","d3d6872a-0e81-480f-88e4-8e625ee447ba","00000006-0000-0ff1-ce00-000000000000","Microsoft Office 365 Portal","7"
"2025-08-01 00:00:00Z","Microsoft Exchange","d3d6872a-0e81-480f-88e4-8e625ee447ba","d8615cf7-11a7-4eae-9b2b-426a9c5e27b8","MessageCenterAgent-reg","19"

Display in Excel

To visualize the data, you can easily open the CSV in Excel. This allows for quick filtering, sorting, and analysis of API usage patterns.

Here is the CSV data displayed in Excel:

You can create pivot tables to summarize usage by application, service area, or date, helping you identify trends and anomalies at a glance.

Here is an example of a pivot table summarizing API usage by application:

✅ Summary of Key Benefits for Admins

🔐 Improved Security Oversight: Identify unauthorized or excessive API usage
📋 Audit Readiness: Easily track which apps are accessing sensitive data
📈 Performance Optimization: Spot usage trends and optimize resource allocation
🧩 Integration Clarity: Understand how internal and third-party apps interact with Microsoft Graph
🧠 Informed Decision-Making: Use data to guide licensing, permissions, and app lifecycle management

📝 Conclusion

In this post, we’ve explored how to track Microsoft Graph API usage using PowerShell. By leveraging the Microsoft Graph PowerShell SDK, we can easily authenticate, retrieve usage data, and generate insightful reports. The key benefits for admins include improved security oversight, audit readiness, performance optimization, integration clarity, and informed decision-making.

By implementing the provided scripts and techniques, you can gain a deeper understanding of how your organization interacts with Microsoft Graph and make data-driven decisions to enhance your security posture and resource allocation.

Happy scripting!

🚀 What’s New with Microsoft Copilot (Microsoft 365) – July 2025 Roundup

Sat, 02 Aug 2025 15:06:09 -0700

Hey friends! 👋

July 2025 was packed with exciting updates for Microsoft 365 Copilot users. Whether you’re an admin, a power user, or just curious about what’s coming next, this blog post breaks down the major changes announced in the Microsoft Message Center. These updates are all about making your work smarter, faster, and more personalized.

Let’s dive into the highlights!

🧠 Microsoft 365 Copilot Search General Availability

Message Center ID: MC1108844
Date Created: July 3, 2025

Summary

Microsoft is rolling out Copilot Search, a powerful AI-driven search experience that integrates across Microsoft 365 apps. It uses Microsoft Graph and connectors to deliver personalized, context-aware answers. Think of it as your smart assistant that understands your work and helps you find exactly what you need—fast.

How It Works

Available on web, desktop, and mobile platforms.
Uses natural language, behavioral signals, and organizational context.
Seamlessly integrates with Copilot chat for task execution.
Requires an eligible Microsoft 365 Copilot license.

Why It Matters

This is a game-changer for productivity. Instead of digging through emails or files, Copilot Search brings the right info to you—tailored to your context. It’s like having a supercharged search engine that knows your work style.

👉 Learn more

🎥 (Updated) Microsoft 365 Copilot in Teams: Visual Insight for Intelligent Recap

Message Center ID: MC1115314
Date Created: July 15, 2025

Summary

Copilot in Teams is getting smarter! Now, meeting recaps will include shared-screen content, making summaries richer and more complete. This means even the visuals you present during meetings will be captured and summarized.

How It Works

Works across Windows, Mac, Web, iOS, and Android.
Automatically includes shared-screen content in recaps.
No admin action required—enabled by default.

Why It Matters

Ever missed a meeting and wished you could see what was shared? Now you can! This update ensures that visual context isn’t lost, making recaps more useful and inclusive.

👉 Learn more

📁 Project Manager Agent – SP Site Grounding

Message Center ID: MC1122155
Date Created: July 25, 2025

Summary

Planner’s Project Manager agent now supports SharePoint Site grounding, allowing it to use encrypted files to improve task creation and execution. This feature is in preview and enhances automation and accuracy in project management.

How It Works

New Plans: Grounding enabled by default.
Existing Plans: Admins can enable manually.
Tasks created from encrypted files become unencrypted for export.

Why It Matters

This update boosts project automation while keeping data secure. It’s perfect for teams managing complex projects with sensitive information.

👉 Learn more

💬 Enhanced Personalization via Communication Memory in Copilot

Message Center ID: MC1127234
Date Created: August 1, 2025

Summary

Starting September, Copilot will use communication memory to personalize responses based on your emails, chats, and meetings. It’s private, AI-powered, and designed to make Copilot smarter about your work.

How It Works

Summarizes communications using large language models (LLMs).
Memory is private and includes source links for review.
Admins can manage via Microsoft Graph and Entra ID.

Why It Matters

This feature makes Copilot feel like it truly knows you. It’s not just smart—it’s your smart. Personalized responses mean less time explaining and more time doing.

🎯 Conclusion

Microsoft 365 Copilot continues to evolve, bringing smarter, more intuitive features to your daily workflow. From intelligent search to personalized AI memory, July 2025’s updates are all about making your digital workspace more responsive and efficient.

If you’re an admin, now’s a great time to review licensing and settings to make sure your organization is ready to take full advantage of these features.

🔍 Search Criteria

Date Range: Messages created after July 1, 2025
Service Impacted: Microsoft Copilot (Microsoft 365)
Change Type: Major Change
Source: Microsoft Message Center
Generated by: https://github.com/mjfusa/message-center-agent

Optimize Your Content Creation with Microsoft Copilot Agents

Thu, 17 Jul 2025 15:36:00 -0700

In today’s fast-paced digital landscape, content creators are constantly seeking tools that help them work smarter and deliver greater value. Enter Microsoft Copilot—a groundbreaking generative AI solution built into Microsoft 365 that’s transforming how we create, communicate, and stay informed.

Whether you’re drafting updates, writing reports, or summarizing product features, Copilot’s AI capabilities can supercharge your productivity and creativity like never before.

The Role of Agents: Focusing Experience and Knowledge

One of the key innovations behind Copilot’s effectiveness is its use of agents—specialized AI assistants designed to focus on specific user experiences or information sources. These agents make your interactions with Copilot more tailored and relevant.

By honing in on domains like communications, scheduling, or product updates, agents help you get exactly what you need, when you need it.

Spotlight on the Message Center Agent

The Message Center Agent takes Copilot’s utility to the next level for Microsoft 365 users. With direct access to Microsoft 365 product update announcements, this agent helps you efficiently write and organize updates about new features and changes.

Here’s how it helps:

Stay Informed: Instantly access the latest product updates without sifting through traditional keyword searches.
Filter for Relevance: Sort updates by product, feature, or severity to ensure you’re sharing only the most pertinent information.
Communicate Efficiently: Draft targeted announcements or summaries quickly, saving time and reducing the risk of missing important changes.

This focused approach ensures your content is always timely, accurate, and relevant—whether you’re updating your team, crafting customer communications, or maintaining an internal knowledge base.

Example Post Created Using the Message Center Agent

Title: Important Updates for Microsoft Copilot (Microsoft 365) – June to July 2025

Prompt Used to create this post:

Write a blog post based on the messages created in the last month tagged with ‘New feature’, marked as a major change, in the category ‘Plan for change’, and where ‘Microsoft Copilot (Microsoft 365)’ is the impacted service.

For each message, include the message title, message center ID, a summary, and sections for ‘How it works’ and ‘Why it matters’.

The blog post should have an upbeat and helpful tone, like it’s coming from a friend. It should disclose the search criteria, the source of the information (Microsoft Message Center), and that it was generated using the Message Center Agent.

Include a link to the Message Center Agent: https://github.com/mjfusa/message-center-agent.

The blog post title should reflect the timeframe of the updates.

Conclusion: Unlock the Future of Content Creation

Microsoft Copilot’s generative AI is revolutionizing the way content creators work—making it easier to produce high-quality, relevant, and engaging materials with less effort.

By leveraging agents like the Message Center Agent, you can tailor your content creation process even further, ensuring you always have the latest information at your fingertips.

Ready to transform your workflow? Start exploring Copilot and its agents today, and discover a smarter, more efficient way to create.

Important Updates for Microsoft Copilot (Microsoft 365) - June to July 2025

Thu, 17 Jul 2025 15:05:18 -0700

Hey there, tech enthusiasts! 🌟

I hope you’re all doing great. Today, I have some exciting news to share with you about the latest updates for Microsoft Copilot (Microsoft 365). These updates were created in the last month and are tagged with ‘New feature’, marked as major changes, and fall under the category ‘Plan for change’. Let’s dive right in!

Researcher on M365 Copilot Prompt Box (MC1098163)

Summary: The Researcher agent in the Microsoft 365 Copilot Prompt Box will be generally available starting July 18, 2025. It integrates deep research capabilities into Microsoft 365 apps, enhancing efficiency for complex research tasks. No admin action is required, but management is possible via the Microsoft 365 admin center.

How it works: The Researcher agent leverages AI to provide users with comprehensive research capabilities directly within Microsoft 365 apps. This means you can now conduct in-depth research without leaving your workspace, making your workflow smoother and more efficient.

Why it matters: This feature is a game-changer for anyone who needs to conduct research as part of their daily tasks. It saves time and effort by bringing powerful research tools right to your fingertips, allowing you to focus on what truly matters - your work!

Microsoft 365 Copilot Search General Availability (MC1108844)

Summary: Microsoft 365 Copilot Search, an AI-powered search experience, will be generally available mid-July 2025 for eligible users. It integrates with Microsoft 365 Copilot app across platforms, leveraging Microsoft Graph and connectors for personalized, context-aware answers. Review documentation and ensure proper licensing. Compliance considerations include data processing and AI capabilities.

How it works: This AI-powered search experience uses Microsoft Graph and connectors to provide personalized, context-aware answers. It integrates seamlessly with the Microsoft 365 Copilot app across various platforms, making it easier than ever to find the information you need.

Why it matters: With this new search capability, finding the right information becomes a breeze. It enhances productivity by delivering precise, context-aware answers, ensuring you spend less time searching and more time doing.

(Updated) Microsoft Copilot in Teams: Visual Insight for intelligent recap (MC1115314)

Summary: Microsoft Copilot in Teams will soon provide intelligent meeting recaps that include content shared on screen, enhancing the comprehensiveness of meeting summaries. This feature, requiring a Microsoft 365 Copilot license, will roll out globally from mid to late September 2025, with no admin action needed.

How it works: The intelligent meeting recaps feature captures and summarizes content shared during meetings, providing a comprehensive overview of what was discussed. This ensures that you never miss out on important details, even if you couldn’t attend the meeting.

Why it matters: This feature is a lifesaver for busy professionals. It ensures that you stay informed and up-to-date with meeting discussions, even if you couldn’t be there in person. It’s all about making your work life easier and more efficient.

Conclusion

These updates are set to revolutionize the way we work with Microsoft Copilot (Microsoft 365). From enhanced research capabilities to AI-powered search and intelligent meeting recaps, there’s a lot to look forward to. Stay tuned for more updates, and don’t forget to check out the Microsoft Message Center for the latest news.

Search Criteria:

Messages created in the last month
Tagged with ‘New feature’
Marked as a major change
Category: ‘Plan for change’
Service impacted: ‘Microsoft Copilot (Microsoft 365)’

Source: Microsoft Message Center

Generated using the Message Center Agent: https://github.com/mjfusa/message-center-agent

Stay awesome, and happy Copiloting! 😊

If you need more information or have any questions, feel free to reach out. Until next time! ✈️

Supercharge Your M365 Copilot Agent with Azure AI Foundry

Thu, 19 Jun 2025 10:52:45 -0700

As organizations increasingly adopt Microsoft 365 Copilot to streamline productivity and automate business processes, the ability to build intelligent, enterprise-aware agents becomes a game-changer. One powerful scenario is integrating a custom M365 Copilot agent with an agent built using Azure AI Foundry—combining the flexibility of local development with the enterprise-grade capabilities of Azure-hosted AI.

In this post, we’ll explore how to build such an integrated solution using the Microsoft 365 Agents SDK and Azure AI Foundry, and why this architecture is so valuable.

Why Integrate M365 Agents SDK with Azure AI Foundry?

The Microsoft 365 Agents SDK allows developers to build multi-channel, production-ready agents that run in Teams, Outlook, and Copilot Chat. Azure AI Foundry, on the other hand, provides a scalable platform to build, customize, and manage AI agents with enterprise data and Retrieval-Augmented Generation (RAG) capabilities.

By integrating the two, you can:

Build and test agents locally using familiar tools.
Leverage enterprise data and vectorized knowledge from Azure AI Foundry.
Deploy your agent directly into Microsoft 365 Copilot Chat for seamless user experiences.
Maintain a clean separation between UI logic and enterprise intelligence.

🌟 Why This Matters for Copilot Chat

Many organizations are standardizing on Microsoft 365 Copilot as the “UI for AI”—a unified, conversational interface where employees can access intelligent assistance across their work apps. By bringing your custom agent into Copilot Chat, you:

Meet users where they already work—inside Word, Excel, Teams, and Outlook.
Provide consistent, context-aware answers grounded in enterprise data.
Enable natural language interactions with your internal systems and knowledge bases.
Reduce the need for custom front-ends or standalone bots.

This approach empowers employees to get help, complete tasks, and make decisions—all within the familiar Copilot experience. It’s a strategic move toward consolidating AI access and improving adoption across the enterprise.

Check out the Microsoft 365 Agents SDK documentation for more details on building agents that run in Microsoft 365 Copilot Chat.

This scenario is covered in this Microsoft Build 2025 session: Create agents for Microsoft 365 Copilot with Microsoft 365 Agents SDK. In the recording, see the ‘EchoBot’ demo starting at 11:06.

👉 Try It Yourself

To experience this integration firsthand, Microsoft has created a hands-on lab—featured at Microsoft Build 2025: Build25 LAB328 - Build custom engine agents using Microsoft 365 Agents SDK. This lab provides step-by-step instructions across five exercises to guide you through building a custom M365 Copilot agent integrated with Azure AI Foundry.

This lab is designed for developers, cloud solution architects, and IT professionals who want to enhance their Copilot Chat experience with enterprise-aware agents.

What You’ll Build

You’ll create a Contoso HR Agent that:

Starts as a simple Echo Bot using the M365 Agents SDK.
Is enhanced with generative AI using Semantic Kernel.
Connects to an Azure AI Foundry agent for enterprise-aware responses.
Is deployed into Microsoft Teams and Copilot Chat.

Key Steps in the Lab

Here’s a high-level overview of the lab journey:

1. Prepare Your Agent in Azure AI Foundry

Log into Azure AI Foundry and open a preconfigured project.
Customize the agent’s identity and behavior (e.g., Contoso HR Agent).
Upload HR documents to create a vector store for RAG.
Test the agent in the Agents Playground using realistic employee queries.

2. Build a Local Agent with M365 Agents SDK

Scaffold a new agent project using the Echo Bot template.
Explore the project structure and test the bot locally using the Test Tool.

3. Add Generative AI Capabilities

Install Semantic Kernel and other packages.
Add custom classes for document citations and message tracking.
Enable your agent to reason and respond intelligently.

4. Integrate with Azure AI Foundry

Connect your local agent to the Azure AI Foundry agent using the Agent ID and connection string.
Update the OnMessageAsync method to stream responses, manage citations, and apply sensitivity labels.

5. Deploy to Copilot Chat

Update the app manifest to include copilotAgents.
Upload the app to Microsoft Teams and test it in Copilot Chat.
Use conversation starters to validate the agent’s behavior in a real-world scenario.

Conclusion

Integrating Microsoft 365 Agents SDK with Azure AI Foundry represents a powerful approach to building enterprise-aware AI agents that enhance the Microsoft 365 Copilot experience. This architecture allows you to maintain the flexibility of local development while leveraging the scalability and intelligence of Azure’s cloud-based AI services.

By following the hands-on lab, you’ll gain practical experience in building agents that not only understand your enterprise data but also integrate seamlessly into the tools your users already know and trust. This is more than just a technical integration—it’s a strategic move toward creating a unified AI experience that can transform how your organization works.

Ready to get started? The lab is waiting for you, and the future of enterprise AI is just a few steps away.

Links and Resources

Install Visual Studio 2022 with the .NET desktop development workload.
Microsoft 365 Agents SDK Documentation
Install the Microsoft 365 Agents SDK
Azure AI Foundry Documentation
Microsoft Build 2025 Session: Create agents for Microsoft 365 Copilot with Microsoft 365 Agents SDK
Microsoft Build 2025 Hands-on Lab: Build a custom M365 Copilot agent integrated with Azure AI Foundry

Integrating external AI agents with M365 Copilot

Sat, 19 Apr 2025 10:52:45 -0700

Introduction

Microsoft 365 Copilot Agents extend the value generative AI for organizations by enabling ‘focused experiences’. That is, agents that provide actions and knowledge around a specific topic. For example, an HR Helpdesk agent that provides answers related to HR related questions and creates tickets with full user context when a question cannot be answered. Agents can range from simple prompt-and-response agents to more advanced, fully autonomous agents.

From the maker/developers point of view, the integration of agents into Microsoft 365 is facilitated by the Teams app infrastructure. That is, the Microsoft Teams app manifest has been extended to support the deployment of agents for use in Microsoft Teams, M365 Copilot, and Microsoft Chat. We will use this extension to convert a simple Teams bot into a Copilot agent.

Calling an external Agent from Copilot

In the last couple of years, during this generative AI tsunami, many developers have built agents on various generative AI platforms, including Microsoft’s Azure AI. Customers using these agents have expressed a need to call these agents from M365 Copilot. A simple way to do this is via a simple bot that acts as a relay between Copilot and the external agent.

Relay bot with an Azure AI Agent

The relay bot, called from Copilot, passes through the prompt, unchanged to the target agent via an API exposed by the agent. The API returns the response from the target agent back to Copilot. We’re using Azure AI here, but the concepts should apply to any agent platform.

This architecture requires that the agent is deployed to a service that supports API interactions, such as Azure OpenAI Service, Azure Functions, or any other custom-hosted solution. In my case, I’m using the Azure OpenAI Service.

Once we have an exposed an API to our target agent that can take a prompt as input and return the results, we’re ready for integration with M365 Copilot.

Relay Bot integration with M365 Copilot

One of the latest updates to the Microsoft Teams app manifest schema (version 1.20) introduces significant enhancements. This update introduces a new object “copilotAgents”, which supports both declarative and custom engine agents. Additionally, “bots”, “commandlists,” and “commands” have been extended to support starter prompts, paving the way for converting a Teams bot into a Copilot agent.

Understanding the ‘copilotAgents’ object

The ‘copilotAgents’ object can include either the ‘declarativeAgents’ or ‘customEngineAgents’ properties. ‘declarativeAgents’ brings in the Copilot orchestrator, which we don’t need. We will use ‘customEngineAgents’ here. ‘customEngineAgents’ assumes we will provide our own orchestrator and LLM. As since this is a relay bot, will will not be using the an orchestrator. Our target agent is taking care of that for us. The ‘customEngineAgents’ object is an array of objects, each representing a custom engine agent. Each object in the array has two properties: id and type. The id property is the Microsoft App ID of the bot registered with the Bot Framework, and the type property is set to “bot”.

Note the value of the id in ‘customEngineAgents’ matches the id of the bot – the relay bot in our case. Also note that scope of the bot is required to be ‘personal’.

Starter Prompts and bots.commandLists.commands

Note below how the commands in the commandList specify the sample prompts that are displayed when the bot is invoked from Copilot.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


{
 "$schema": "https://developer.microsoft.com/json-schemas/teams/v1.20/MicrosoftTeams.schema.json",
 "manifestVersion": "1.20",
 "version": "1.0.0",
 "id": "%MICROSOFT-APP-ID%",
 "name": {
 "short": "IT Support Agent",
 "full": "IT Support and Assistance Agent"
 },
 "description": {
 "short": "Your go-to IT support bot",
 "full": "A comprehensive IT support bot to assist with common IT issues and tasks"
 },
 "icons": {
 "outline": "outline.png",
 "color": "color.png"
 },
 "bots": [
 {
 "botId": "%MICROSOFT-APP-ID-REGISTERED-WITH-BOT-FRAMEWORK%",
 "scopes": [
 "personal"
 ],
 "commandLists": [
 {
 "scopes": [
 "personal"
 ],
 "commands": [
 {
 "title": "Password Reset",
 "description": "Guide me through resetting my password"
 },
 {
 "title": "Software Installation",
 "description": "Help me install new software"
 },
 {
 "title": "Network Issues",
 "description": "Troubleshoot network connectivity problems"
 },
 {
 "title": "Hardware Support",
 "description": "Assist with hardware-related issues"
 },
 {
 "title": "IT Policies",
 "description": "Provide information on IT policies and best practices"
 }
 ]
 }
 ]
 }
 ],
 "copilotAgents": {
 "customEngineAgents": [
 {
 "id": "%MICROSOFT-APP-ID-REGISTERED-WITH-BOT-FRAMEWORK%",
 "type": "bot"
 }
 ]
 }
}

Creating the Relay bot

To create the Relay bot, we start with the Teams Toolkit in Visual Studio 2022 and created a C# EchoBot. C# is just a personal preference, many languages are supported including python and JavaScript.

In EchoBot.cs, in the OnMessageActivityAsync method, we call by API exposed by the Azure AI agent:

1
2
3
4
5
6
7
8


protected override async Task OnMessageActivityAsync(ITurnContext<IMessageActivity> turnContext, CancellationToken cancellationToken)
{
 string messageText = turnContext.Activity.RemoveRecipientMention()?.Trim();
 CallSentimentAgent callSentimentAgent = CallSentimentAgent.Instance;
 var replyText = await callSentimentAgent.CallAgent(messageText);
 //var replyText = $"Echo: {messageText}";
 await turnContext.SendActivityAsync(MessageFactory.Text(replyText), cancellationToken);
}

Sample Project

A sample project with this implemented can be found here: https://github.com/mjfusa/Copilot-Custom-Engine-Agent-Relay-to-Azure-Agent

Conclusion

The relay bot architecture provides a simple way to integrate external AI agents with M365 Copilot. By using the Teams app manifest and the new ‘copilotAgents’ object, we can easily convert a Teams bot into a Copilot agent. This allows us to leverage the capabilities of our existing agents while providing a seamless experience for users in Microsoft 365 applications.

Microsoft 365 Copilot: Sentiment Analysis and Categorization of Survey Feedback

Thu, 15 Feb 2024 17:17:51 -0800

Surveys are a useful way to measure how happy your clients, employees, customers, or other stakeholders are. They can help you find out the pros and cons of your products, services, or processes, and give you useful feedback for improvement. However, surveys are not just about numbers and ratings. The most useful data from surveys are verbatims, or the open-ended responses that customers write in their own words. Verbatims can offer insights that you can’t get from ratings, such as the reasons why customers are satisfied or dissatisfied. Verbatims can also show the feelings and sentiments of customers, which can affect customer loyalty and retention. This post will show how to extract customer sentiment and the drivers of the feedback using Microsoft 365 Copilot.

A brief example:

Number	Feedback	Sentiment	Theme
1	The hotel was amazing. The staff was friendly and the room was very clean. The location was perfect and the amenities were top-notch. I would definitely stay here again.	Positive	Amenities
2	The hotel was okay. The room was clean but the staff was not very helpful. The location was not great and the amenities were lacking. It was an average stay.	Neutral	Staff

Here are examples of an analysis report or table output from your survey data.

Introduction

Survey feedback is a valuable source of information for any business that wants to improve its products, services, and customer satisfaction. However, analyzing survey feedback can be a daunting and time-consuming task, especially when you have to deal with large volumes of text data.

How can you quickly and easily extract insights from your survey feedback without spending hours reading and coding every response? How can you identify the main themes, sentiments, and opinions of your customers and use them to make data-driven decisions?

The answer is Microsoft 365 Copilot, a new AI-powered tool that helps you analyze and categorize your survey feedback in minutes. In this blog post, we will show you how to use Microsoft 365 Copilot to do sentiment analysis and categorization of survey feedback and how it can benefit your business.

What is Microsoft 365 Copilot?

Microsoft 365 Copilot is an AI-powered productivity tool designed to enhance your work experience within the Microsoft 365 suite of applications.

Using Microsoft 365 Copilot for Sentiment Analysis and Categorization of Survey Feedback

Using Microsoft 365 Copilot for sentiment analysis and categorization of survey feedback is easy and intuitive. Typically survey data a spreadsheet for analysis. At the time of this writing, sentiment analysis is not supported by Copilot in Excel. However, we can use Copilot in Word’s ability to do sentiment analysis and theme categorization. Here are the steps you need to follow:

Note: There are capacity limits with the amount of data that can be analyzed. For the best results, it’s best to keep the input to a maximum size of about 1600 words.

Prepare your survey data for analysis.

You can use the included file ‘Hotel Stay Sample Feedback Data.xlsx’ with the steps below.

In Excel, hide columns that are not needed for the feedback analysis. By hiding the data not needed, you will be able to analyze more feedback records due to capacity limits. (See note above.)
Create a new empty Word document.
Select the data to analyze to the clipboard.
Paste the data table into the new Word document.
Save the Word document to your OneDrive. For example: ‘Hotel Stay Feedback.docx’

It should look like this:

Prompt: Use Copilot to create a Sentiment and Theme report

In this step, you will reference the Word document created in the last step. ‘Hotel Stay Feedback.docx’

Create a new Word document.
In the Copilot UI, enter the following prompt:

1
2
3
4
5
6


Draft a sentiment and theme report using this data
Hotel Stay Feedback.docx. The sentiment should be
expressed as positive, negative or neutral. Each
feedback should be associated with the theme
with the highest corelation to the feedback.
Include Summary, Analysis and Methodology sections.

🗒️ Note that you need to explicitly link to the data file. That is, the name of the file itself won’t import the data. You need to use the ‘Reference your content’ button or the ‘/’ key to find and select your data file. The file will appear underlined when linked. See below.

🗒️ About this prompt: Note the we’re specifying how we want the sentiment classified: positive, negative or neutral. We can use whatever classification we deem appropriate here, for example we can replace it with a ratings scale: The sentiment should be expressed on a scale of 1 to 5 with 5 being most positive and 1 being the most negative. Additionally, for flexibility, prompt does not specify the themes, but asks Copilot to determine them with the following instructions: Each feedback should be associated with the theme with the highest corelation to the feedback.

🗒️ The output generated by Copilot (and all generative AI tools) is non-deterministic. This is a big difference in how we have traditionally worked with software applications. Providing more detail and context will help Copilot provide the expected results. Additionally, you can try the prompt again by using the ‘Regenerate’ button in Word.

Click this link to view what the output typically looks like.

Prompt: Use Copilot to create a table of the Sentiment and Theme data

The report is useful, but having a table of the sentiment and themes will also be useful. The following prompt will generate the table.

Again you will reference the Word document created in the last step. ‘Hotel Stay Feedback.docx’

Create a new Word document.
In the Copilot UI, enter the following prompt:

1
2
3
4
5
6
7


Draft a sentiment and theme table using this data
Hotel Stay Feedback.docx Evaluate the drivers of the
feedback into six main themes. The sentiment should be
expressed as positive, negative or neutral. Each feedback
should be associated with the theme with the highest
corelation to the feedback. The table output should
follow this pattern {number} {feedback} {sentiment} {theme}

Click this link to view what the output typically looks like.

Conclusion

Microsoft 365 Copilot is a powerful and easy-to-use tool that helps you analyze and categorize your survey feedback in minutes. It helps you understand the sentiment, tone, and emotion of your customers and how they relate to your business goals. It also helps you organize your feedback data into meaningful categories and labels that you can use to make data-driven decisions. If you want to learn more about Microsoft 365 Copilot and how it can help you improve your customer satisfaction and loyalty, visit the Copilot website or follow me on LinkedIn:.

Report: Sentiment and Theme Analysis of Hotel Stay Feedback Data

Hotel Stay Feedback Sentiment and Theme Report

Summary

This report presents the results of a sentiment and theme analysis of 58 hotel stay feedbacks collected from an online survey. The main objectives of the analysis are to identify the overall sentiment of the feedbacks, the most common themes associated with the feedbacks, and the relationship between sentiment and theme. The report also describes the methodology and the limitations of the analysis.

Analysis

The sentiment analysis was performed using a simple rule-based approach that assigns a positive, negative or neutral label to each feedback based on the presence of certain keywords. The keywords were manually selected based on a preliminary examination of the feedbacks. The following table shows the keywords and the corresponding sentiment labels.

Keywords	Sentiment
amazing, wonderful, fantastic, excellent, great, delicious, top-notch, perfect, friendly, helpful, accommodating, spacious, comfortable, clean, enjoyable, definitely, wonderful, above and beyond	Positive
terrible, awful, not good, not ideal, not great, not very, lacking, dirty, rude, unprofessional, unhelpful, noisy, small, terrible, awful	Negative
okay, average, mediocre, decent	Neutral

The theme analysis was performed using a simple frequency-based approach that counts the occurrence of certain keywords related to different aspects of the hotel stay. The keywords were manually selected based on a preliminary examination of the feedbacks. The following table shows the keywords and the corresponding themes.

Keywords	Theme
staff, service	Staff and Service
room, comfortable, spacious, clean, dirty, noisy, small	Room Quality
location, ideal, perfect, not ideal, not great	Location
amenities, top-notch, excellent, lacking, not up to par	Amenities
breakfast, delicious, terrible	Breakfast

The results of the sentiment and theme analysis are summarized in the following table, which shows the number and percentage of feedbacks for each sentiment and theme combination.

Sentiment	Theme	Number of Feedbacks	Percentage of Feedbacks
Positive	Staff and Service	16	27.6%
Positive	Room Quality	15	25.9%
Positive	Location	16	27.6%
Positive	Amenities	15	25.9%
Positive	Breakfast	8	13.8%
Negative	Staff and Service	14	24.1%
Negative	Room Quality	14	24.1%
Negative	Location	15	25.9%
Negative	Amenities	14	24.1%
Negative	Breakfast	8	13.8%
Neutral	Staff and Service	8	13.8%
Neutral	Room Quality	8	13.8%
Neutral	Location	8	13.8%
Neutral	Amenities	8	13.8%
Neutral	Breakfast	4	6.9%

The main findings of the analysis are:

The overall sentiment of the feedbacks is evenly distributed, with 18 positive feedbacks, 18 negative feedbacks and 14 neutral feedbacks.
The most common theme across all feedbacks is staff and service, followed by room quality, location and amenities. Breakfast is the least common theme.
The most positive theme is location, with 16 positive feedbacks and 15 negative feedbacks. The most negative theme is staff and service, with 14 negative feedbacks and 16 positive feedbacks.
The most neutral theme is breakfast, with 4 neutral feedbacks and 8 positive and negative feedbacks each.
There is a strong correlation between sentiment and theme, with positive feedbacks tending to mention more positive aspects of the hotel stay and negative feedbacks tending to mention more negative aspects of the hotel stay.

Methodology

The methodology of the analysis consists of the following steps:

Collecting the hotel stay feedbacks from an online survey.
Preprocessing the feedbacks by removing punctuation, converting to lowercase, and tokenizing by words.
Assigning a sentiment label to each feedback based on the presence of certain keywords.
Assigning a theme label to each feedback based on the presence of certain keywords.
Counting the number and percentage of feedbacks for each sentiment and theme combination.
Summarizing the results and presenting the findings in a table and a list.

Limitations

The limitations of the analysis are:

The sentiment and theme analysis is based on a simple rule-based approach that relies on manually selected keywords. This approach may not capture the nuances and subtleties of the feedbacks, such as sarcasm, irony, or context-dependent meanings.
The sentiment and theme analysis is based on a small sample of 58 feedbacks, which may not be representative of the population of hotel stay feedbacks. The results may vary depending on the source and the size of the data.
The sentiment and theme analysis does not account for the intensity or the polarity of the feedbacks, such as very positive, somewhat negative, or mixed. The results may not reflect the degree of satisfaction or dissatisfaction of the customers.

Report: Hotel Stay Feedback Analysis

Number	Feedback	Sentiment	Theme
1	The hotel was amazing. The staff was friendly and the room was very clean. The location was perfect and the amenities were top-notch. I would definitely stay here again.	Positive	Amenities
2	The hotel was okay. The room was clean but the staff was not very helpful. The location was not great and the amenities were lacking. It was an average stay.	Neutral	Staff
3	The hotel was terrible. The room was dirty and the staff was rude. The location was not ideal and the amenities were not up to par. I would not stay here again.	Negative	Room
4	The hotel was great. The location was perfect and the staff was helpful. The room was comfortable and the amenities were excellent. I had a wonderful stay.	Positive	Location
5	The hotel was average. The room was clean but the location was not great. The staff was not very accommodating and the amenities were just okay. It was an average stay.	Neutral	Location
6	The hotel was fantastic. The amenities were top-notch and the staff was friendly. The location was perfect and the room was very comfortable. I would definitely stay here again.	Positive	Amenities
7	The hotel was not good. The room was small and the staff was not helpful. The location was not ideal and the amenities were lacking. I would not stay here again.	Negative	Room
8	The hotel was excellent. The room was spacious and the staff was very accommodating. The location was perfect and the amenities were top-notch. I had a wonderful stay.	Positive	Room
9	The hotel was mediocre. The room was clean but the amenities were lacking. The staff was not very helpful and the location was not great. It was an average stay.	Neutral	Amenities
10	The hotel was awful. The room was dirty and the staff was unprofessional. The location was not ideal and the amenities were not up to par. I would not stay here again.	Negative	Staff
11	The hotel was wonderful. The staff went above and beyond to make our stay enjoyable. The room was very comfortable and the location was perfect. I would definitely stay here again.	Positive	Staff
12	The hotel was decent. The room was clean but the location was not ideal. The staff was not very accommodating and the amenities were just okay. It was an average stay.	Neutral	Location
13	The hotel was terrible. The room was noisy and the staff was unhelpful. The location was not great and the amenities were not up to par. I would not stay here again.	Negative	Room
14	The hotel was great. The room was comfortable and the staff was friendly. The location was perfect and the amenities were excellent. I had a wonderful stay.	Positive	Location
15	The hotel was average. The amenities were okay but the staff was not very accommodating. The room was clean but the location was not great. It was an average stay.	Neutral	Staff
16	The hotel was fantastic. The location was perfect and the staff was very helpful. The room was very comfortable and the amenities were top-notch. I would definitely stay here again.	Positive	Location
17	The hotel was not good. The room was small and the amenities were lacking. The staff was not helpful and the location was not ideal. I would not stay here again.	Negative	Room
18	The hotel was excellent. The staff was friendly and the room was very comfortable. The location was perfect and the amenities were top-notch. I had a wonderful stay.	Positive	Staff
19	The hotel was mediocre. The location was not great and the staff was not very helpful. The room was clean but the amenities were lacking. It was an average stay.	Neutral	Location
20	The hotel was awful. The room was dirty and the amenities were not up to par. The staff was unprofessional and the location was not ideal. I would not stay here again.	Negative	Staff
21	The hotel was amazing. The staff was friendly and the room was very clean.	Positive	Staff
22	The hotel was okay. The room was clean but the staff was not very helpful.	Neutral	Staff
23	The hotel was terrible. The room was dirty and the staff was rude.	Negative	Staff
24	The hotel was great. The location was perfect and the staff was helpful.	Positive	Location
25	The hotel was average. The room was clean but the location was not great.	Neutral	Location
26	The hotel was fantastic. The amenities were top-notch and the staff was friendly.	Positive	Amenities
27	The hotel was not good. The room was small and the staff was not helpful.	Negative	Room
28	The hotel was excellent. The room was spacious and the staff was very accommodating.	Positive	Room
29	The hotel was mediocre. The room was clean but the amenities were lacking.	Neutral	Amenities
30	The hotel was awful. The room was dirty and the staff was unprofessional.	Negative	Staff
31	The hotel was wonderful. The staff went above and beyond to make our stay enjoyable.	Positive	Staff
32	The hotel was decent. The room was clean but the location was not ideal.	Neutral	Location
33	The hotel was terrible. The room was noisy and the staff was unhelpful.	Negative	Room
34	The hotel was great. The room was comfortable and the staff was friendly.	Positive	Staff
35	The hotel was average. The amenities were okay but the staff was not very accommodating.	Neutral	Staff
36	The hotel was fantastic. The location was perfect and the staff was very helpful.	Positive	Location
37	The hotel was not good. The room was small and the amenities were lacking.	Negative	Room
38	The hotel was excellent. The staff was friendly and the room was very comfortable.	Positive	Staff
39	The hotel was mediocre. The location was not great and the staff was not very helpful.	Neutral	Location
40	The hotel was awful. The room was dirty and the amenities were not up to par.	Negative	Amenities
41	The hotel was amazing. The staff was friendly and the room was very clean. The location was perfect and the amenities were top-notch. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Amenities
42	The hotel was okay. The room was clean but the staff was not very helpful. The location was not great and the amenities were lacking. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Breakfast
43	The hotel was terrible. The room was dirty and the staff was rude. The location was not ideal and the amenities were not up to par. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Breakfast
44	The hotel was great. The location was perfect and the staff was helpful. The room was comfortable and the amenities were excellent. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Breakfast
45	The hotel was average. The room was clean but the location was not great. The staff was not very accommodating and the amenities were just okay. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Breakfast
46	The hotel was fantastic. The amenities were top-notch and the staff was friendly. The location was perfect and the room was very comfortable. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Breakfast
47	The hotel was not good. The room was small and the staff was not helpful. The location was not ideal and the amenities were lacking. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Breakfast
48	The hotel was excellent. The room was spacious and the staff was very accommodating. The location was perfect and the amenities were top-notch. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Breakfast
49	The hotel was mediocre. The room was clean but the amenities were lacking. The staff was not very helpful and the location was not great. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Breakfast
50	The hotel was awful. The room was dirty and the staff was unprofessional. The location was not ideal and the amenities were not up to par. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Breakfast
51	The hotel was wonderful. The staff went above and beyond to make our stay enjoyable. The room was very comfortable and the location was perfect. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Service
52	The hotel was decent. The room was clean but the location was not ideal. The staff was not very accommodating and the amenities were just okay. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Service
53	The hotel was terrible. The room was noisy and the staff was unhelpful. The location was not great and the amenities were not up to par. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Service
54	The hotel was great. The room was comfortable and the staff was friendly. The location was perfect and the amenities were excellent. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Service
55	The hotel was average. The amenities were okay but the staff was not very accommodating. The room was clean but the location was not great. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Service
56	The hotel was fantastic. The location was perfect and the staff was very helpful. The room was very comfortable and the amenities were top-notch. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Service
57	The hotel was not good. The room was small and the amenities were lacking. The staff was not helpful and the location was not ideal. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Service
58	The hotel was excellent. The staff was friendly and the room was very comfortable. The location was perfect and the amenities were top-notch. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Service

Track M365 Copilot Readiness, Adoption and Impact with 'Microsoft Copilot Dashboard'

Thu, 16 Nov 2023 13:50:10 -0800

A tool many Microsoft 365 Copilot admins have been asking for is the Microsoft Copilot Dashboard. It’s a new tool for tracking Microsoft 365 Copilot usage and impact introduced at the Microsoft Ignite conference.

At the 43:12 mark of the session ‘Getting your enterprise ready for Microsoft 365 Copilot’, the ‘Microsoft Copilot Dashboard’ was unveiled. This new feature from Viva Insights helps organizational leaders prepare for Copilot rollout, track adoption of key features, and assess its impact.

The Microsoft Copilot Dashboard app helps you get the most out of Microsoft 365 with AI assistance, insights, and recommendations. You can track and improve your productivity and skills with these features:

The readiness page shows how ready and active your organization is for Microsoft 365.
The user adoption trends page shows how Copilot and Microsoft 365 usage change over time.
The impact page shows how Copilot and Microsoft 365 affect user behavior and satisfaction.

See here for more infomation:

New ways Microsoft Copilot and Viva are transforming the employee experience

Microsoft Copilot Dashboard (Preview)

Connect to the Microsoft Copilot Dashboard (Preview)

The Microsoft Copilot Dashboard is just one of the many exciting innovations introduced at Ignite. Be sure to check out the full session list for more information.

OpenAI GPT-3.5-Turbo API: Moving from GPT3.0 to GPT-3.5-Turbo

Fri, 07 Apr 2023 06:01:06 -0800

Developers are always on the lookout for innovative tools and technologies that can streamline their workflow and make their development process more efficient. One such technology that has been making waves in the world of AI and NLP is the GPT-3 API. The latest version GPT-3.5-Turbo model has been fine tuned as a general chat bot. It better understand the context behind requests producing better results. Just like GPT-3, GPT-3.5-Turbo, can help you write code as well as text. The GPT-3.5-Turbo also 10x cheaper that OpenAI’s existing GPT-3.5 models. Now priced at $0.002 per 1k tokens.

This API is a powerful language model that is designed to help developers create intelligent and human-like chatbots, virtual assistants, and other conversational interfaces. It is an advanced version of the GPT-3 language model that is known for its impressive natural language processing capabilities. In this blog post, we will go over the changes in the API for calling the completion API. Let"s get started!

To understand the changes in calling the completion API, I updated the openai-quickstart-node sample from model text-davinci-003 (GPT-3) to GPT-3.5-Turbo.

Note: To run the sample you"ll need an API key from openai. You can sign up for an OpenAI account and get an API key here.

Library

The first thing I did after cloning and installing the sample was updating the sample (project.json) use the latest version of the openai API (3.2.0).

1

"openai": "^3.2.0"

Completion API

The completion API has changed from createCompletion to createChatCompletion.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


const completion = await openai.createChatCompletion({
 model:"gpt-3.5-turbo-0301",
 messages: [
 // The system message helps set the behavior of the assistant. In the example above, the assistant was instructed with “You are a helpful assistant"
 {"role": "system", "content": "You are a helpful assistant. Keep responses brief."},
 // The assistant messages help store prior responses. They can also be written by a developer to help give examples of desired behavior
 {"role": "assistant","content": "Animal: Cat Names: Captain Sharpclaw, Agent Fluffball, The Incredible Feline"},
 // The user messages help instruct the assistant. They can be generated by the end users of an application, or set by a developer as an instruction.
 {"role":"user", "content":"Suggest three names for an animal that is a superhero. Animal: " + capitalizedAnimal },
 ],
 // The temperature (Range 0 - 1). The closer to 0, the more deterministic, the closer to 1 the more diverse the response.
 temperature: 0.8,
});

Prompt

The prompt is now an array of message objects. Each message containing a role and content field. Briefly here is what each of the roles do:

Role	Description
system	The system message helps set the behavior of the assistant.
assistant	The assistant messages help store prior responses. They can also be written by a developer to help give examples of desired behavior
user	The user messages help instruct the assistant. They can be generated by the end users of an application, or set by a developer as an instruction.

Response

The response is now returned as an array of choices. Each choice contains a role, content, finish_reason, and an index.

1
2
3
4
5
6
7
8
9


"choices": [
 {
 "message": {
 "role": "assistant",
 "content": "Captain Sharpclaw, Agent Fluffball, The Incredible Feline"},
 "finish_reason": "stop",
 "index": 0
 }
]

The sample was changed to:

1

completion.data.choices[0].message.content

You can see these change at my fork of the sample repo here: https://github.com/mjfusa/openai-quickstart-node

Check out the Chat GPT-3-5 Playground

The OpenAI chat Playground has been updated with support for the gpt-3.5-turbo model. You can quickly compose your prompts in the new format here. https://platform.openai.com/playground/?mode=chat

How can what Microsoft is doing with OpenAI / ChatGPT help developers write code - Q and A

Thu, 23 Mar 2023 12:28:05 -0700

Q: I’ve heard that Microsoft will be coming out with a product that will enable people to use AI/ChatGPT to code. Can you tell me if this is available now?

A: Yes. This available now. GitHub Copilot is a code completion tool that suggests snippets of programming code as developers type. It uses OpenAI Codex to suggest code and entire functions in real-time right from your editor. Trained on billions of lines of public code, GitHub Copilot turns natural language prompts including comments and method names into coding suggestions across dozens of languages. Copilot X is the latest version of GitHub Copilot that adopts the latest OpenAI GPT-4 model and expands Copilot’s capabilities with chat and pull requests. See here for getting started with Github Copilot. See here if you are a student.

Q: How is this different from ChatGPT in Bing?

A: ChatGPT is a conversational AI model developed by Microsoft Bing that can understand and generate human-like responses to natural language inputs. On the other hand, GitHub Copilot is an AI pair programmer that helps you write code faster and with less work. It draws context from comments and code to suggest individual lines and whole functions. Copilot Chat is a new feature of GitHub Copilot that allows developers to ask programming-related questions and get answers in natural language. It is built on top of the work that OpenAI and Microsoft have done with ChatGPT and the new Bing. While ChatGPT can suggest code snippets and answer programming questions, it lacks the context-awareness that GitHub Copilot has.

Q: How is GitHub Copilot different from the openai ChatGPT API?

A: OpenAI ChatGPT and GitHub Copilot are both models trained on the GPT-3 language prediction model created by OpenAI. However, while GitHub Copilot writes code alongside you in your text editor, ChatGPT requires that you access it via their API, or Playground.

Q: How is GitHub Copilot different from the Azure openai api?

A: Azure OpenAI API is a cloud-based artificial intelligence tool developed by OpenAI that provides natural language processing capabilities. It can be used to build chatbots, language translators, and more. While both tools are AI-based, they have different use cases. GitHub Copilot is more focused on code generation, while Azure OpenAI API is more focused on natural language processing. That said, Azure OpenAI’s powerful language models including the GPT-3, Codex and Embeddings model series can be used for natural language to code translation.

Q: Do AI development tools reduce the cost of software development?

A: AI-powered tools are making project managers, business analysts, software coders, and testers more productive and more effective, enabling them to produce higher-quality software faster at lower cost. AI may become a key factor in meeting rising demand for custom software. New AI-powered tools are having a remarkable impact on the software development process, such as reducing the number of keystrokes developers need to type by half, catching bugs even prior to code review or testing, and automatically generating half of the tests needed for quality assurance1. Therefore, AI development tools can reduce the cost of software development.

Q: What is the impact of AI development tools on the cost of software development?

A: According to an article on DZone, AI-powered tools are making the process of designing, developing, and deploying software faster, better, and cheaper. Project managers, testers, and coders are becoming more productive, and as a result, they are now efficiently producing low-cost and higher-quality software.

Streamline Your Microsoft Teams Experience with Stream Deck Shortcuts

Fri, 10 Feb 2023 08:22:45 -0800

Update: While we are waiting for the official Stream Deck Plug-in for Microsoft Teams to be published, consider this solution for using your Stream Deck with Teams.

Are you tired of constantly switching between your keyboard and mouse while using Microsoft Teams? Well, there’s a solution that can make your life easier! You can now set up your Stream Deck with Microsoft Teams shortcuts and make your virtual meetings and work more efficient. Here’s how:

Teams Keyboard Shortcuts

The first step is to familiarize yourself with the keyboard shortcuts that Teams has to offer. To view them, simply press Ctrl + . within the Teams application. This will bring up a list of all the keyboard shortcuts you can use to navigate Teams.

Download Icons

Next, you need to download some icons to represent your shortcuts on your Stream Deck. The Stream Deck Icon Collection for Teams has a variety of icons to choose from, so pick the ones that work best for you.

Set Stream Deck Hotkeys

The final step is to set up the hotkeys on your Stream Deck. To do this, launch the Stream Deck app and select the key that you want to assign a shortcut to. Then, choose the appropriate icon and set the hotkey to the Teams keyboard shortcut you want to use. Repeat this process for all the shortcuts you want to set up.

Make Teams the active application

The Stream Deck hotkeys will only work when Teams is the active application. You can setup a Steam Deck Open command to bring Teams to the foreground.

In Windows, create a .cmd file with a path to the Teams shortcut. For example:

1
2
3


REM StartTeams.cmd
@echo off
"C:\Users\mikefra.REDMOND\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft Teams (work or school).lnk"

To get the path to the lnk file above, right click on the Teams shortcut in the Start menu and select ‘Open file location’.

With this simple setup, you’ll be able to switch between Teams functions with just a press of a button, without having to constantly reach for your keyboard or mouse. Give it a try and see how much more productive you can be during your Teams meetings!

Microsoft Store: Testing the purchase of your app within the app itself

Sun, 13 Nov 2022 11:17:39 -0800

If you’re a Windows developer and you’re using the Free Trial feature of the Microsoft in-app commerce APIs, you may want to offer your users a way to purchase the app before the trial period expires. The most convenient way would be to include a purchase experience from within the app itself. You can implement this by calling the API StoreContext.RequestPurchaseAsync passing in the Store Id. (See below ‘App Identity’.)

To test this scenario at minimum cost, you can temporarily set the price of the app to $0.99 in a single, small market.

Notes:

Since you’re testing the Free Trial feature, you can’t set the price to ‘Free’. Setting the price to free, will allow the user to immediately acquire the app without displaying the Free Trial option.
$0.99 (or currency equivalent) is the lowest price setting.

This is done before the app is released to the public. This way you can verify your purchase flow works properly. See the steps below for the step-by-step instructions.

Publish the app ‘hidden’. i.e. Configure your app so it is not discoverable in the Store.

Set the app price to $0.99 – in a small test market. For example, US Virgin Islands

Set the test machine ‘Country or region’ setting to ‘US Virgin Islands’

Use the app link to open the app in the Store app. For example: ms-windows-store://pdp/?productid=<your product id>. See ‘Product Identity’ for the app in Partner Center.

Screen Shot of the app with Region setting set to test market (US Virgin Islands in this example). Note $0.99 price:

Screen Shot of the app with the Region setting NOT set to test market. Note the normal price.:

Use the Free Trial option to acquire the app for the free trial period.
In your, app trigger the code that calls StoreContext.RequestPurchaseAsync to start the purchase flow.
Note that the app is offered at the test price of $0.99.

Important: Don’t forget to remove the test market $0.99 price setting before release.

How to detect if a Microsoft Store app is Installed

Fri, 15 Nov 2019 17:28:24 +0000

There may be times when you need to determine if a Microsoft Store app has been installed. You may have a dependency on that app or otherwise need to take action based on the presence of that app.

FindPackageForUser

The API PackageManager.FindPackageForUser() can do this. See the code below. Note the special handling for the various error conditions. This API returns a Package object if the app is installed for the current user. The API will throw an Access denied exception if 1) the app is not installed on the machine or 2) it is on the machine but not installed for the current user. The API will throw an Argument exception if the string for the package family name is not in the correct format.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


public static bool IsAppAlreadyInstalled(string FullPackageFamilyName)
{
 var oPkgManager = new PackageManager();
 bool result = false;
 try
 {
 //If 1st parameter is string.Empty, the packages are retrieved for the current user.
 Package oPkg = oPkgManager.FindPackageForUser(string.Empty, FullPackageFamilyName);
 result = oPkg != null;
 }
 catch (ArgumentException syse)
 {
 Debug.WriteLine("Parameter Exception: Check Package full name argument for correct pattern. X.a_N.X.X.0x64__N");
 return result;
 }
 catch (UnauthorizedAccessException syse)
 {
 if (!string.IsNullOrEmpty(syse.Message))
 {
 if (syse.Message.IndexOf("Access is denied", StringComparison.CurrentCulture) >= 0)
 {
 Debug.WriteLine("Access denied");
 return result;
 }
 }
 }
 catch (Exception ex)
 {
 if (!string.IsNullOrEmpty(ex.Message))
 Debug.WriteLine(@"Exception: {0}", ex.Message);
 return result;
 }
 return result;
}

private void Button_Click(object sender, RoutedEventArgs e)
{
 // Sample code: This should return 'access denied' since this will not exist on your machine
 var res = IsAppAlreadyInstalled("57012MikeFrancis.TrialTest123_1.66.5.0_x64__08pddan6qgabc");
}

Full App Package Name

You need the full package name to call FindPackageForUser(). To get a list of all of the packages currently installed, you can use the PowerShell command Get-AppxPackage.

For the Microsoft Store apps that you have published, you can get the full package family name from the App Identity page in Partner Center. See screenshot below.

Please let me how this method works for you or if you have another solution for determining the installation status of an app on Windows 10.

The code is available here.

@MikeFrancis

A Zero Inbox Solution

Thu, 10 Jan 2019 16:48:34 +0000

Many of us in the software development business rely on email as our primary means of communication. Email is great – allowing us to prioritize and document our work. 90% of my job as a consultant involves email.

IF IT HURTS, DON’T DO IT

I took a ‘Productivity course’ a couple of years ago around optimizing the use of email. This technique involved categorizing or tagging your email using the Outlook ‘Categories’ feature. Here is a blog post that discusses a similar process. I tried using this method and found that for me, it added too much overhead – categorizing everything was a chore and I did not see much return on the effort. Also, the whole system falls apart if you don’t explicitly categorize. I found I was missing some emails and therefore not seeing them in my Outlook Tasks list – per the course guidelines.

As the PM for outlook.com recently said, there are two types of people that use email: pilers and filers. Pilers use one folder for all of their emails whereas filers use folders to organize their email. (I’ve never understood pilers – I have seen people – and you know who you are - that have their lifetime of email in a single Inbox. The time it takes to find a relevant email would drive me crazy.)I am a filer — I use the ‘Rule’ feature of Outlook to automatically move email from my Inbox to the proper folder depending on who it is from or the subject. For example, I have a rule that says, if the incoming email is from the campus dining alias (think menu of the week) the mail is moved to the ‘Campus Dining’ folder. However, if an email is from the President of the company, it is moved into my Inbox – but I am getting ahead of myself. Please read on.

VARYING DEGREES OF IMPORTANCE

In the above example, I think you would agree that the two sources of email have different levels of importance. That is, if I never-ever read the email from the Campus Dining alias there will minimal consequences. However, the email from the President of the company could have some very relevant information related to my job.

INBOX = ACTION

The principle I use is that for a message to be in my Inbox, is that it must be actionable by me within the next 24 hours. I enforce this by setting up a rule that moves all emails not addressed to me to a second inbox, which I call Inbox2. If you’re thinking I must have a lot of rules, you’d be right. I have a rule and corresponding folder for every alias I subscribe to. For some aliases that have very similar information, I’ll have multiple rules to send emails to that folder. The following is my ‘All’ rule:

Note that this rule is the last in the rules list. This gives other rules up the list to intercept the message and move it to the proper folder.

RECIPIENT, SENDER, ACTION

For an email to be sent directly to my Inbox, I have the following rules: If sent directly to me — move it to my Inbox. The thinking is that if someone is sending me (the recipient) an email directly most likely it will have some action for me, even if just to acknowledge it.

If from the company president or my boss — move to my Inbox. The thinking here is emails sent from the President or other important person will most likely be sent to an alias and not directly to me. To catch these emails, I have an explicit rule for the sender.

These rules greatly reduce the ‘noise’ in my Inbox.

Then with each email in my inbox, I review it for action. If there is no action for me, I manually move it to my Archive folder or delete it. As I complete the required action, I move the email to the Archive folder. (It’s a good feeling.) If no action is required within the next 24 hours, I’ll set the Follow-Up flag and move it to the Archive folder. I then periodically check my Tasks list where this pending action will be listed.

PERIODIC REVIEW

I get added to aliases all the time in the course of my job – sometimes without knowing ahead of time. Since all of my emails will be moved to my Inbox2, unless I have a rule setup, I need to periodically check this folder to make sure I’m not missing anything. If I do miss an email, I’ll create a rule (and folder if necessary) to make sure I don’t miss it in the future. I also will unsubscribe from aliases and delete emails during this review.

IT WORKS FOR ME

I know there are a lot of ‘zero-inbox’ methods out there. This one works for me in my particular work environment where a lot of emails are sent to aliases. Please let me know what you are using.

Mike

Mon, 01 Jan 0001 00:00:00 +0000

Sentiment and Theme Analysis of Hotel Stay Feedback Data

A report based on a sample of 58 feedbacks from hotel guests

Summary

The sentiment analysis of the hotel stay feedback data revealed that 32 feedbacks (55.2%) were positive, 18 feedbacks (31%) were negative and 8 feedbacks (13.8%) were neutral.
The sentiment theme analysis of the hotel stay feedback data identified four main themes: staff, room, location and amenities. Each feedback was assigned to one of these themes based on the most prominent aspect of the hotel stay experience.
The staff theme was the most frequent theme, with 26 feedbacks (44.8%) belonging to this category. The staff theme had the highest proportion of positive feedbacks (88.5%), followed by the room theme (69.2%), the location theme (50%) and the amenities theme (33.3%).
The room theme was the second most frequent theme, with 13 feedbacks (22.4%) belonging to this category. The room theme had the lowest proportion of negative feedbacks (7.7%), followed by the staff theme (11.5%), the location theme (25%) and the amenities theme (50%).
The location theme was the third most frequent theme, with 12 feedbacks (20.7%) belonging to this category. The location theme had the highest proportion of neutral feedbacks (25%), followed by the amenities theme (16.7%), the staff theme (0%) and the room theme (0%).
The amenities theme was the least frequent theme, with 7 feedbacks (12.1%) belonging to this category. The amenities theme had the lowest proportion of positive feedbacks (16.7%), followed by the location theme (50%), the room theme (69.2%) and the staff theme (88.5%).

Analysis

The sentiment analysis of the hotel stay feedback data was performed using a rule-based approach that assigned a sentiment score to each feedback based on the presence and polarity of sentiment words and phrases. The sentiment score ranged from -3 to +3, where -3 indicated a very negative sentiment, 0 indicated a neutral sentiment and +3 indicated a very positive sentiment. The feedbacks were then classified into three sentiment categories: positive (sentiment score > 0), negative (sentiment score < 0) and neutral (sentiment score = 0).
The sentiment theme analysis of the hotel stay feedback data was performed using a keyword-based approach that assigned a theme to each feedback based on the occurrence and frequency of keywords related to the four themes: staff, room, location and amenities. The keywords were extracted from a list of common words and phrases used by hotel guests to describe their hotel stay experience. The feedbacks were then assigned to one of the four themes based on the most frequent keyword in the feedback. If there was a tie between two or more themes, the feedback was assigned to the theme with the highest sentiment score.
The table below shows the distribution of the feedbacks by sentiment and theme, as well as the average sentiment score for each theme.

Sentiment	Staff	Room	Location	Amenities	Total
Positive	23	9	6	1	32
Negative	3	1	3	4	18
Neutral	0	0	3	1	8
Total	26	13	12	7	58
Average Sentiment Score	2.15	1.85	0.75	-0.57	1.29

Methodology

The hotel stay feedback data was obtained from a sample of 58 feedbacks from hotel guests who stayed at different hotels in different locations. The feedbacks were collected from various online sources, such as hotel websites, review platforms and social media.
The sentiment analysis of the hotel stay feedback data was performed using a rule-based approach that assigned a sentiment score to each feedback based on the presence and polarity of sentiment words and phrases. The sentiment words and phrases were extracted from a lexicon of common words and phrases used by hotel guests to express their opinions and emotions about their hotel stay experience. The lexicon was compiled from various online sources, such as hotel websites, review platforms and social media. The lexicon contained 120 sentiment words and phrases, with 60 positive words and phrases and 60 negative words and phrases. Each word and phrase was assigned a polarity value of +1 or -1, depending on whether it expressed a positive or negative sentiment. The sentiment score for each feedback was calculated by summing up the polarity values of the sentiment words and phrases in the feedback. The sentiment score ranged from -3 to +3, where -3 indicated a very negative sentiment, 0 indicated a neutral sentiment and +3 indicated a very positive sentiment. The feedbacks were then classified into three sentiment categories: positive (sentiment score > 0), negative (sentiment score < 0) and neutral (sentiment score = 0).
The sentiment theme analysis of the hotel stay feedback data was performed using a keyword-based approach that assigned a theme to each feedback based on the occurrence and frequency of keywords related to the four themes: staff, room, location and amenities. The keywords were extracted from a list of common words and phrases used by hotel guests to describe their hotel stay experience. The list contained 80 keywords, with 20 keywords for each theme. The keywords were compiled from various online sources, such as hotel websites, review platforms and social media. The feedbacks were then assigned to one of the four themes based on the most frequent keyword in the feedback. If there was a tie between two or more themes, the feedback was assigned to the theme with the highest sentiment score.

Mon, 01 Jan 0001 00:00:00 +0000

Hotel Stay Feedback Analysis

A table summarizing the feedback, sentiment, and theme of 58 hotel guests

Number	Feedback	Sentiment	Theme
1	The hotel was amazing. The staff was friendly and the room was very clean. The location was perfect and the amenities were top-notch. I would definitely stay here again.	Positive	Satisfaction
2	The hotel was okay. The room was clean but the staff was not very helpful. The location was not great and the amenities were lacking. It was an average stay.	Neutral	Mediocrity
3	The hotel was terrible. The room was dirty and the staff was rude. The location was not ideal and the amenities were not up to par. I would not stay here again.	Negative	Dissatisfaction
4	The hotel was great. The location was perfect and the staff was helpful. The room was comfortable and the amenities were excellent. I had a wonderful stay.	Positive	Satisfaction
5	The hotel was average. The room was clean but the location was not great. The staff was not very accommodating and the amenities were just okay. It was an average stay.	Neutral	Mediocrity
6	The hotel was fantastic. The amenities were top-notch and the staff was friendly. The location was perfect and the room was very comfortable. I would definitely stay here again.	Positive	Satisfaction
7	The hotel was not good. The room was small and the staff was not helpful. The location was not ideal and the amenities were lacking. I would not stay here again.	Negative	Dissatisfaction
8	The hotel was excellent. The room was spacious and the staff was very accommodating. The location was perfect and the amenities were top-notch. I had a wonderful stay.	Positive	Satisfaction
9	The hotel was mediocre. The room was clean but the amenities were lacking. The staff was not very helpful and the location was not great. It was an average stay.	Neutral	Mediocrity
10	The hotel was awful. The room was dirty and the staff was unprofessional. The location was not ideal and the amenities were not up to par. I would not stay here again.	Negative	Dissatisfaction
11	The hotel was wonderful. The staff went above and beyond to make our stay enjoyable. The room was very comfortable and the location was perfect. I would definitely stay here again.	Positive	Satisfaction
12	The hotel was decent. The room was clean but the location was not ideal. The staff was not very accommodating and the amenities were just okay. It was an average stay.	Neutral	Mediocrity
13	The hotel was terrible. The room was noisy and the staff was unhelpful. The location was not great and the amenities were not up to par. I would not stay here again.	Negative	Dissatisfaction
14	The hotel was great. The room was comfortable and the staff was friendly. The location was perfect and the amenities were excellent. I had a wonderful stay.	Positive	Satisfaction
15	The hotel was average. The amenities were okay but the staff was not very accommodating. The room was clean but the location was not great. It was an average stay.	Neutral	Mediocrity
16	The hotel was fantastic. The location was perfect and the staff was very helpful. The room was very comfortable and the amenities were top-notch. I would definitely stay here again.	Positive	Satisfaction
17	The hotel was not good. The room was small and the amenities were lacking. The staff was not helpful and the location was not ideal. I would not stay here again.	Negative	Dissatisfaction
18	The hotel was excellent. The staff was friendly and the room was very comfortable. The location was perfect and the amenities were top-notch. I had a wonderful stay.	Positive	Satisfaction
19	The hotel was mediocre. The location was not great and the staff was not very helpful. The room was clean but the amenities were lacking. It was an average stay.	Neutral	Mediocrity
20	The hotel was awful. The room was dirty and the amenities were not up to par. The staff was unprofessional and the location was not ideal. I would not stay here again.	Negative	Dissatisfaction
21	The hotel was amazing. The staff was friendly and the room was very clean.	Positive	Cleanliness
22	The hotel was okay. The room was clean but the staff was not very helpful.	Neutral	Service
23	The hotel was terrible. The room was dirty and the staff was rude.	Negative	Cleanliness
24	The hotel was great. The location was perfect and the staff was helpful.	Positive	Location
25	The hotel was average. The room was clean but the location was not great.	Neutral	Location
26	The hotel was fantastic. The amenities were top-notch and the staff was friendly.	Positive	Amenities
27	The hotel was not good. The room was small and the staff was not helpful.	Negative	Service
28	The hotel was excellent. The room was spacious and the staff was very accommodating.	Positive	Service
29	The hotel was mediocre. The room was clean but the amenities were lacking.	Neutral	Amenities
30	The hotel was awful. The room was dirty and the staff was unprofessional.	Negative	Service
31	The hotel was wonderful. The staff went above and beyond to make our stay enjoyable.	Positive	Service
32	The hotel was decent. The room was clean but the location was not ideal.	Neutral	Location
33	The hotel was terrible. The room was noisy and the staff was unhelpful.	Negative	Noise
34	The hotel was great. The room was comfortable and the staff was friendly.	Positive	Comfort
35	The hotel was average. The amenities were okay but the staff was not very accommodating.	Neutral	Amenities
36	The hotel was fantastic. The location was perfect and the staff was very helpful.	Positive	Location
37	The hotel was not good. The room was small and the amenities were lacking.	Negative	Comfort
38	The hotel was excellent. The staff was friendly and the room was very comfortable.	Positive	Comfort
39	The hotel was mediocre. The location was not great and the staff was not very helpful.	Neutral	Location
40	The hotel was awful. The room was dirty and the amenities were not up to par.	Negative	Amenities
41	The hotel was amazing. The staff was friendly and the room was very clean. The location was perfect and the amenities were top-notch. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Satisfaction
42	The hotel was okay. The room was clean but the staff was not very helpful. The location was not great and the amenities were lacking. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Mediocrity
43	The hotel was terrible. The room was dirty and the staff was rude. The location was not ideal and the amenities were not up to par. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Dissatisfaction
44	The hotel was great. The location was perfect and the staff was helpful. The room was comfortable and the amenities were excellent. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Satisfaction
45	The hotel was average. The room was clean but the location was not great. The staff was not very accommodating and the amenities were just okay. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Mediocrity
46	The hotel was fantastic. The amenities were top-notch and the staff was friendly. The location was perfect and the room was very comfortable. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Satisfaction
47	The hotel was not good. The room was small and the staff was not helpful. The location was not ideal and the amenities were lacking. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Dissatisfaction
48	The hotel was excellent. The room was spacious and the staff was very accommodating. The location was perfect and the amenities were top-notch. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Satisfaction
49	The hotel was mediocre. The room was clean but the amenities were lacking. The staff was not very helpful and the location was not great. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Mediocrity
50	The hotel was awful. The room was dirty and the staff was unprofessional. The location was not ideal and the amenities were not up to par. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Dissatisfaction
51	The hotel was wonderful. The staff went above and beyond to make our stay enjoyable. The room was very comfortable and the location was perfect. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Satisfaction
52	The hotel was decent. The room was clean but the location was not ideal. The staff was not very accommodating and the amenities were just okay. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Mediocrity
53	The hotel was terrible. The room was noisy and the staff was unhelpful. The location was not great and the amenities were not up to par. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Dissatisfaction
54	The hotel was great. The room was comfortable and the staff was friendly. The location was perfect and the amenities were excellent. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Satisfaction
55	The hotel was average. The amenities were okay but the staff was not very accommodating. The room was clean but the location was not great. The breakfast was average and the service was not very good. It was an average stay.	Neutral	Mediocrity
56	The hotel was fantastic. The location was perfect and the staff was very helpful. The room was very comfortable and the amenities were top-notch. The breakfast was delicious and the service was excellent. I would definitely stay here again.	Positive	Satisfaction
57	The hotel was not good. The room was small and the amenities were lacking. The staff was not helpful and the location was not ideal. The breakfast was terrible and the service was awful. I would not stay here again.	Negative	Dissatisfaction
58	The hotel was excellent. The staff was friendly and the room was very comfortable. The location was perfect and the amenities were top-notch. The breakfast was delicious and the service was top-notch. I had a wonderful stay.	Positive	Satisfaction

Links

Mon, 01 Jan 0001 00:00:00 +0000

Search

Mon, 01 Jan 0001 00:00:00 +0000

mjfnet: Cool Microsoft 365 and AI Dev Knowledge Sharing

Time Zone Converter - Meeting Planner

Key Benefits

Important Features

Time Zone Converter - Meeting Planner - Privacy Policy

Privacy Policy

Overview

Data Collection

Data Sharing

Calendar Access

Third‑Party Services

Data Security

Children’s Privacy

Changes to This Privacy Policy

Contact

MCP Servers and M365 (Part 4): Connect the Message Center MCP Server to a Declarative Agent (M365 Agents Toolkit)

Integrating the Message Center MCP server

Prerequisites

Create and configure an Entra app registration for the MCP server

Run the client app registration script:

Step 2 — Decide where the MCP server will run

Option A: Local server + tunnel (quick dev)

Option B: Hosted URL (recommended for stable testing / production)

Step 3 — Validate the server with curl

3a) Health check

Step 4 — Create the declarative agent project (Microsoft 365 Agents Toolkit)

Step 5 — Register the agent in the Teams Developer Portal

Step 6 — Update the plugin manifest to connect to the MCP server

Step 5 — Add the function definition to ai-plugin.json

Step 6 — Provision and verify tool discovery

Step 7 — Test the agent end-to-end

Provide instructions to the agent

Troubleshooting

Developer Mode

Summary

MCP Servers and M365 (Part 3): Implementing OBO Authentication to Call Microsoft Graph APIs

Why OBO matters for MCP servers

Microsoft Message Center MCP server

Step 1 — Understanding the authentication token types

MCP API user token (what the client sends)

Microsoft Graph access token (what the server uses)

Step 2 — The OBO flow (what’s actually happening)

Why this is the right pattern for agents

Step 3 — App registration models (single-app vs two-app)

Option A (simplest): single app registration (one app, two roles)

Option B (recommended for agents): two app registrations (client app + server/API app)

Step 4 — Why proxy /authorize + /token endpoints exist

Redirect safety: allowlist is not optional

Try it yourself

Prerequisites

Create and configure an Entra app registration for the MCP server

Run the server app registration script:

Clone the repo and run the server

Entra app registration - MCP OBO Server configuration

Smoke test the OAuth proxy endpoints with PKCE

Get an MCP API user token (audience = your MCP API)

Call the MCP tool using OBO (recommended path)

Production lock-down behavior (important)

Troubleshooting

AADSTS65001 / consent_required

401 Unauthorized from the MCP server

401 from Microsoft Graph

403 from Microsoft Graph

Production bypass error (accessToken_disabled)

Summary

MCP Servers and M365 (Part 2): Integrate the Roadmap MCP Server into a Copilot Studio Custom Agent

What you’re integrating

Prerequisites

Step 1 — Decide where the MCP server will run

Option A: Use a local tunnel (for quick dev)

Option B: Use a hosted URL (for stability and production)

Step 2 — Validate the MCP server with curl (before Copilot Studio)

2a) Health check

2b) Call the MCP tool (fetch 5 items)

2c) Go back to the tunnel inspection browser session (if using a tunnel)

Step 3 — Create a custom agent in Copilot Studio

Test the agent

Instruct the agent how to call the tool (minimal prompt contract)

Step 6 — Test the agent end-to-end

Troubleshooting

Step 4 — Why proxy `/authorize` + `/token` endpoints exist

`AADSTS65001` / `consent_required`

`401 Unauthorized` from the MCP server

`401` from Microsoft Graph

`403` from Microsoft Graph

Production bypass error (`accessToken_disabled`)

`405 Method Not Allowed`