How to Retrieve Windows Edition (SKU) from managedDevices API
Hi everyone, I am working with the Microsoft Graph API endpoint /v1.0/deviceManagement/managedDevices to iterate through all devices in a tenant and collect operating system related information. For Windows devices, the operatingSystem field only returns "Windows". However, Windows has multiple editions such as Enterprise, Education, and Pro. For my use case, I need the specific Windows edition. Is it possible to retrieve this information using only the v1.0 endpoint, or is the beta endpoint /beta/deviceManagement/managedDevices/{managedDeviceId} required to get the SKU family? Thanks in advance for your help.General Availability of Graph Database Support in Azure Database for PostgreSQL
We are excited to announce the general availability of the Apache AGE extension for Azure Database for PostgreSQL! This marks a significant milestone in empowering developers and businesses to harness the potential of graph data directly within their PostgreSQL environments, offering fully managed graph database service. Unlocking Graph Data Capabilities Apache AGE (A Graph Extension) is a powerful PostgreSQL extension. It allows users to store and query graph data within Postgres seamlessly, enabling advanced insights through intuitive graph database queries via the openCypher query language. Graph data is instrumental in applications such as social networks, recommendation systems, fraud detection, network analysis, and knowledge graphs. By integrating Apache AGE into Azure Database for PostgreSQL, developers can now benefit from a unified platform that supports both relational and graph data models, unlocking deeper insights and streamlining data workflows. Benefits of Using Apache AGE in Azure Database for PostgreSQL The integration of Apache AGE (AGE) in Azure Database for PostgreSQL brings numerous benefits to developers and businesses looking to leverage graph processing capabilities: Enterprise-grade Managed Graph Database Service: AGE in Azure Database for PostgreSQL provides a fully managed graph database solution, eliminating infrastructure management while delivering built-in security, updates, and high availability. Simplified Data Management: AGE's ability to integrate graph and relational data simplifies data management tasks, reducing the need for separate graph database solutions. Enhanced Data Analysis: With AGE, you can perform complex graph analyses directly within your PostgreSQL database, gaining deeper insights into relationships and patterns in your data. Cost Efficiency: By utilizing AGE within Azure Database for PostgreSQL, you can consolidate your database infrastructure, lowering overall costs and reducing the complexity of your data architecture. Security and Compliance: Leverage Azure's industry-leading security and compliance features, ensuring your graph data is protected and meets regulatory requirements. Index Support: Index graph properties with BTREE and GIN indexes. Real-World Applications Apache AGE opens up a range of possibilities for graph-powered applications. Here are just a few examples: Social Networks: Model and analyze complex relationships, such as user connections and interactions. Fraud Detection: Identify suspicious patterns and connections in financial transactions. Recommendation Systems: Leverage graph data to deliver personalized product or content recommendations. Knowledge Graphs: Structure facts and concepts as nodes and relationships, enabling AI-driven search and data discovery. In the following example, we need to provide Procurement with an updated status of all statements of work (SOW) by vendor, including their invoice status. With AGE and Postgres, this once complex task becomes quite simple. We’ll start by creating the empty graph. SELECT ag_catalog.create_graph('vendor_graph'); Then, we’ll create all the ‘vendor’ nodes from the vendors table. SELECT * FROM ag_catalog.cypher( 'vendor_graph', $$ UNWIND $rows AS v CREATE (:vendor { id: v.id, name: v.name }) $$, ARRAY( SELECT jsonb_build_object('id', id, 'name', name) FROM vendors ) ); Next, we’ll create all the ‘sow’ nodes. SELECT * FROM ag_catalog.cypher( 'vendor_graph', $$ UNWIND $rows AS s CREATE (:sow { id: s.id, number: s.number }) $$, ARRAY( SELECT jsonb_build_object('id', id, 'number', number) FROM sows ) ); Then, we’ll create the ‘has_invoices’ relationships (edges). SELECT * FROM ag_catalog.cypher( 'vendor_graph', $$ UNWIND $rows AS r MATCH (v:vendor { id: r.vendor_id }) MATCH (s:sow { id: r.sow_id }) CREATE (v)-[:has_invoices { payment_status: r.payment_status, amount: r.invoice_amount }]->(s) $$, ARRAY( SELECT jsonb_build_object( 'vendor_id', vendor_id, 'sow_id', sow_id, 'payment_status', payment_status, 'invoice_amount', amount ) FROM invoices ) ); Now that we’ve completed these steps, we have a fully populated vendor_graph with vendor nodes, sow nodes, and has_invoices edges with the invoice attributes. We’re ready to query the graph to start our report for Procurement. SELECT * FROM ag_catalog.cypher('vendor_graph' , $$ MATCH (v:vendor)-[rel:has_invoices]->(s:sow) RETURN v.id AS vendor_id, v.name AS vendor_name, s.id AS sow_id, s.number AS sow_number, rel.payment_status AS payment_status, rel.amount AS invoice_amount $$) AS graph_query(vendor_id BIGINT, vendor_name TEXT, sow_id BIGINT, sow_number TEXT, payment_status TEXT, invoice_amount FLOAT); This statement invokes Apache AGE’s Cypher engine that treats our graph as a relational table: ag_catalog.cypher('vendor_graph', $$ … $$) executes the Cypher query against the graph named “vendor_graph.” The inner Cypher fragment, MATCH (v:vendor)-[rel:has_invoices]->(s:sow) RETURN v.id AS vendor_id, v.name AS vendor_name, s.id AS sow_id, s.number AS sow_number, rel.payment_status AS payment_status, rel.amount AS invoice_amount finds every vendor node with outgoing has_invoices edges to SOW nodes projects each vendor’s ID/name, the target sow’s ID/number, and invoice attributes. Wrapping that in … ) AS graph_query( vendor_id BIGINT, vendor_name TEXT, sow_id BIGINT, sow_number TEXT, payment_status TEXT, invoice_amount FLOAT ); tells PostgreSQL how to map each returned column into a regular SQL result set with proper types. The result? You get a standard table of rows—one per invoice edge—with those six columns populated and ready for further SQL joins, filters, aggregates, etc. Performance notes for this example: AGE will scan all “vendor–has_invoices–sow” paths in the graph. If the graph is large, consider an index on the vendor or sow label properties or filter by additional predicates. You can also push WHERE clauses into the Cypher fragment for more selective matching. Scaling to Large Graphs with AGE The Apache AGE extension in Azure Database for PostgreSQL enables seamless scaling to large graphs. Indexing plays a pivotal role in enhancing query performance, particularly for complex graph analyses. Effective Indexing Strategies To optimize graph queries, particularly those involving joins or range queries, implementing the following indexes is recommended: BTREE Index: Ideal for exact matches and range queries. For vertex tables, create an index on the unique identifier column (e.g., id). CREATE INDEX ON graph_name."VLABEL" USING BTREE (id); GIN Index: Designed for efficient searches within JSON fields, such as the properties column in vertex tables. CREATE INDEX ON graph_name."VLABEL" USING GIN (properties); Edge Table Indexes: For relationship traversal, use BTREE indexes on start_id and end_id columns. CREATE INDEX ON graph_name."ELABEL" USING BTREE (start_id); CREATE INDEX ON graph_name."ELABEL" USING BTREE (end_id); Example: Targeted Key-Value Indexing For targeted queries that focus on specific attributes within the JSON field, a smaller BTREE index can be created for precise filtering. CREATE INDEX ON graph_name.label_name USING BTREE (agtype_access_operator(VARIADIC ARRAY[properties, '"KeyName"'::agtype])); Using these indexing strategies ensures efficient query execution, even when scaling large graphs. Additionally, leveraging the EXPLAIN command helps validate index utilization and optimize query plans for production workloads. How to Get Started Enabling Apache AGE in Azure Database for PostgreSQL is simple: 1. Update Server Parameters Within the Azure Portal, navigate to the PostgreSQL Flexible Server instance and select the Server Parameters option. Adjust the following settings: azure.extensions: In the parameter filter, search for and enable AGE among the available extensions. shared_preload_libraries: In the parameter filter, search for and enable AGE. Click Save to apply these changes. The server will restart automatically to activate the AGE extension. Note: Failure to enable the shared_preload_libraries will result in the following error when you first attempt to use the AGE schema in a query. “ERROR: unhandled cypher(cstring) function call error on first cypher query” 2. Enable AGE Within PostgreSQL Once the server restart is complete, connect to the PostgreSQL instance using the psql interpreter. Execute the following command to enable AGE: CREATE EXTENSION IF NOT EXISTS AGE CASCADE; 3. Configure Schema Paths AGE adds a schema called ag_catalog, which is essential for handling graph data. Ensure this schema is included in the search path by executing: SET search_path=ag_catalog,"$user",public; That’s it! You’re ready to create your first graph within PostgreSQL on Azure. Ready to dive in? Experience the power of graph data with Apache AGE on Azure Database for PostgreSQL. Visit AGE on Azure Database for PostgreSQL Overview for more details, and explore how this extension can transform your data analysis and application development. Get started for free with an Azure free account
Cannot update Case number in Microsoft Purview eDiscovery
I can no longer update the Case number under case settings in the new eDiscovery UI. I used to be able to update it via the externalId Graph endpoint but that appears to be deprecated. The error simply reads "update failed" - there is no additional information. Is anyone else having this problem?Bug: Invoke-MgGraphRequest not respecting ErrorAction.
Hi folks, This is a brief callout that Invoke-MgGraphRequest is not currently respecting the ErrorAction parameter. Rather, it's hardwired to throwing an exception as if ErrorAction:Stop had been provided. If you're like me and typically use ErrorAction:Stop in a try/catch block then you won't be impacted, but if use another value like Continue (the default) or SilentlyContinue, you may find this breaks your automation. Example Hopefully this is addressed in a future version of the Microsoft.Graph.Authentication module. Cheers, Lain
403 Forbidden when sending mail with app-only token via Microsoft Graph
Hello, I am trying to send emails from my Outlook account using a registered enterprise application in Azure AD. We created an application registration in our tenant, assigned the relevant users, and granted admin consent for these Microsoft Graph application permissions: Mail.Send and Mail.ReadWrite and Mail.Send.Shared. I authenticate with application credentials (client_id, client_secret, tenant_id) and successfully retrieve an app-only access token using MSAL in Python: def get_access_token() -> str: load_dotenv() client_id = os.getenv("CLIENT_ID") client_secret = os.getenv("CLIENT_SECRET") tenant_id = os.getenv("TENANT_ID") authority = f"https://login.microsoftonline.com/{tenant_id}" scopes = ["https://graph.microsoft.com/.default"] # app-only token app = msal.ConfidentialClientApplication( client_id=client_id, client_credential=client_secret, authority=authority ) result = app.acquire_token_for_client(scopes=scopes) if "access_token" not in result: raise RuntimeError(f"Auth failed: {result.get('error_description') or result}") return result["access_token"] The token is retrieved successfully. However, when I try to send an email with: GRAPH_BASE = "https://graph.microsoft.com/v1.0" def send_email(access_token: str, from_user: str, to_address: str, subject: str, body_text: str, save_to_sent: bool = True) -> bool: """ Sends a plain-text email via POST /users/{from_user}/sendMail using an app-only token. Returns True on success; raises HTTPError on failure. """ payload = { "message": { "subject": subject, "body": {"contentType": "Text", "content": body_text}, "toRecipients": [{"emailAddress": {"address": to_address}}], }, "saveToSentItems": bool(save_to_sent), } r = requests.post( f"{GRAPH_BASE}/users/{from_user}/sendMail", headers={"Authorization": f"Bearer {access_token}"}, json=payload, timeout=20, ) r.raise_for_status() return True …I get this error: 403 Client Error: Forbidden for url: https://graph.microsoft.com/v1.0/users/{from_user}/sendMail File "C:\mail\src\mail.py", line 53, in send_email r.raise_for_status() ~~~~~~~~~~~~~~~~~~^^ File "C:\mail\src\mail.py", line 111, in <module> send_email(token, from_user, to, "Hello from Microsoft Graph", "Hello Human") ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://graph.microsoft.com/v1.0/users/{from_user}/sendMail where {from_user} is my actual mailbox address (e.g., email address removed for privacy reasons). Since the app has Mail.Send (Application) permission with admin consent, my understanding is that the app should be able to send mail on behalf of any user in the tenant using /users/{user}/sendMail. Is there another configuration step I am missing (e.g., Application Access Policy or mailbox-level Send As requirement)? Any guidance on why this 403 happens despite having Mail.Send application permissions with admin consent would be very helpful. Thank you!Introducing support for Graph data in Azure Database for PostgreSQL (Preview)
We are excited to announce the addition of Apache AGE extension in Azure Database for PostgreSQL, a significant advancement that provides graph processing capabilities within the PostgreSQL ecosystem. This new extension brings a powerful toolset for developers looking to leverage a graph database with the robust enterprise features of Azure Database for PostgreSQL.
Since Aug 22nd we can't save any Side Panel tabs
Hello! Yesterday (Aug 22nd 2025) we got an update in our Teams Links that we normally share to start meetings. They were modified from this format: https://teams.microsoft.com/l/meetup-join/19%3ameeting_XXXXXXXXXXXXXXX%40thread.v2/0?context=%7b%22Tid%22%3a%22xxxxxxxxxxxx%22%2c%22Oid%22%3a%22xxxxxxxxxxxxxx%22%7d to https://teams.microsoft.com/meet/00000000000?p=XXXXXXXXX Sensitive values and ids have been redacted above and inside all the snippets in this post. This looks like a planned rollout, as specified here: https://mc.merill.net/message/MC772556 After this change, none of our apps are able to save a side panel into any of the meetings with the new link format. We had a couple of older, still available meetings whose link had the previous format, and we are able to save the side panel there, but no matter what we tried, nothing allowed us to solve this situation on our end. My final resort is this post in hopes of a solution to what we see. Each save operation yields a 500 on this call https://teams.microsoft.com/api/chatsvc/amer/v1/threads/19%3Ameeting_XXXXXXXXXXXXXXXXXX%40thread.v2/properties?name=tab%3A%3Axxxxxxxxxxxxxxxx { "errorCode": 500, "message": "{\"subCode\":\"TabOperationFailed\",\"details\":\"Initiator 8:orgid:xxxxxxxxxxxxxx failed perform tab operation\",\"errorCode\":1500,\"errorSubCode\":null}", "standardizedError": { "errorCode": 1500, "errorSubCode": 1, "errorDescription": "TabOperationFailed-Initiator 8:orgid:xxxxxxxxxxxxxx failed perform tab operation" } } I ended up trying to manually install it with graph api calls, which didn't work either and gave me a 502 curl -s -X POST "https://graph.microsoft.com/v1.0/chats/$CHAT_ID/tabs" \ -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json" \ -d '{ "displayName": "DisplayName", "email address removed for privacy reasons": "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/'"$TEAMS_APP_ID"'", "configuration": { "entityId": "entity-random", "contentUrl": "https://<domain>/?theme={theme}&locale={locale}", "websiteUrl": "https://<domain>/" } }' | jq . { "error": { "code": "BadGateway", "message": "Failed to execute backend request.", "innerError": { "date": "2025-08-22T03:36:08", "request-id": "b4bbade7-1ea2-46df-a1d9-92cdda9e360b", "client-request-id": "b4bbade7-1ea2-46df-a1d9-92cdda9e360b" } } } Then, thinking there was something wrong with my app, I used a MS app, same result curl -s -X POST "https://graph.microsoft.com/v1.0/chats/$CHAT_ID/tabs" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "displayName": "Website - test", "email address removed for privacy reasons": "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/com.microsoft.teamspace.tab.web", "configuration": { "entityId": null, "contentUrl": "https://www.microsoft.com", "websiteUrl": "https://www.microsoft.com" } }' | jq . { "error": { "code": "BadGateway", "message": "Failed to execute backend request.", "innerError": { "date": "2025-08-22T04:02:36", "request-id": "ece5590e-f23f-4780-a4a6-20c1b2f0d0f3", "client-request-id": "ece5590e-f23f-4780-a4a6-20c1b2f0d0f3" } } } I then tested it against chats that do not belong to a meeting. Both apps succeeded curl -s -X POST "https://graph.microsoft.com/v1.0/chats/$REGULAR_CHAT_ID/tabs" \ -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json" \ -d '{ "displayName": "Website - test", "email address removed for privacy reasons": "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/com.microsoft.teamspace.tab.web", "configuration": { "entityId": null, "contentUrl": "https://www.microsoft.com", "websiteUrl": "https://www.microsoft.com" } }' | jq . { "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#chats('19%3xxxxxx_xxxxxxxxxxxx%40unq.gbl.spaces')/tabs/$entity", "id": "a0cca657-12d0-4df0-84d8-cc1f8fa7d3e6", "displayName": "Website - test", "webUrl": "https://teams.microsoft.com/l/chat/19%xxxxxxxxx_XXXXXXXXX%40unq.gbl.spaces/tab%3a%3xxxxxxxxxxxxxxxxxxxxxx?webUrl=https%3a%2f%2fwww.microsoft.com&label=Website+-+test&tenantId=xxxxxxxxxxxxxxxxxxx, "configuration": { "entityId": null, "contentUrl": "https://www.microsoft.com", "removeUrl": null, "websiteUrl": "https://www.microsoft.com" } } curl -s -X POST "https://graph.microsoft.com/v1.0/chats/$REGULAR_CHAT_ID/tabs" \ -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json" \ -d '{ "displayName": "redacted", "email address removed for privacy reasons": "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps/'"$TEAMS_APP_ID"'", "configuration": { "entityId": "redacted", "contentUrl": "https://<domain>/?theme={theme}&locale={locale}", "websiteUrl": "https://<domain>/" } }' | jq . { "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#chats('19%3xxxxxxxxxxxxx_xxxxxxxxxxxxx%40unq.gbl.spaces')/tabs/$entity", "id": "xxxxxxxxxxxxxxxxxxxxxx", "displayName": "redacted", "webUrl": "https://teams.microsoft.com/l/entity/<redacted>/_djb2_msteams_prefix_000000000?webUrl=https%3a%2f%2f<domain>%2f&label=redacted+label&context=%7b%0d%0a++%22context%22%3a+%22chat%22%2c%0d%0a++%22chatId%22%3a+%2219%3axxxxxxx_xxxxxxxxx%40unq.gbl.spaces%22%2c%0d%0a++%22subEntityId%22%3a+null%0d%0a%7d&tenantId=xxxxxxxxxxxxxxxx", "configuration": { "entityId": "redacted", "contentUrl": "https://<domain>/?theme={theme}&locale={locale}", "removeUrl": null, "websiteUrl": "https://<domain>/" } } At this point we don't know what else to do, seems like a meeting specific issue that we are unable to solve. It's affecting our tenants in all environments, since our primary business flow relies on this panel. All the snippets contain real dates and request-ids, here's hoping it helps somehow. Help, and thanks in advance. ~A. del Yerro
Graph API 1.0 - Listing lists doesn't return all lists (todoTaskList)
Hi, first time posting here, please let me know if I should be doing something differently! I've searched throughout the internet and couldn't find a reason for this. I've got a couple of users running into a problem where the https://learn.microsoft.com/en-us/graph/api/todo-list-lists?view=graph-rest-1.0&tabs=http endpoint only returns one list (Flagged Emails), though these users have and see many other lists in the To Do desktop (macOS) app. I've confirmed in both cases it's the same user that's identified in my app/integration and in the desktop app. They can see the tasks in that list without a problem. There are no errors requesting that list, and asking via `/users/{id|userPrincipalName}/todo/lists` also returns the same response (with that one list). Is there any known situation where this could be happening? Am I missing something obvious? Is there something else I should be trying? I've got many other customers using the To Do integration without a problem. I'm aware "My Day" and a few other special lists aren't returned. Thank you so much!"Insufficient privileges to complete the operation" when listing Planner tasks from Project
Hi, it's only my time posting here, please let me know if I should be doing something differently! I've searched throughout the internet and couldn't find a solution for this. I've got a user running into a problem where the `/me/planner/tasks`, `/planner/buckets/{bucketId}/tasks`, and `/planner/plans/{planId}/tasks` endpoints return a `Authorization_RequestDenied` error. Here's an example response: { "code": "Authorization_RequestDenied", "message": "Insufficient privileges to complete the operation.", "innerError": { "date": "2025-07-23T08:15:50", "request-id": "bd5f7056-a41d-439c-a0d7-d768cd82d1ea", "client-request-id": "362f376c-863e-0616-86f7-22c7c07c1352" } } While this happens for almost all of their groups and plans, it doesn't happen for one. The main difference between that which works and the other ones which don't is that all the ones that don't work were created in Microsoft Project (Platinum, I think?). The one that does was created in Planner. We can, however, list the proper plans and buckets, just not fetch the tasks. Is there any way around this? Is there some kind of special scope I should be asking for so the API calls work? Should I use the To Do API in some special way for this, instead? Thank you so much!"User content migrated" Error when Creating OneDrive Webhook Subscription
Dear Microsoft Community, Our application is encountering an undocumented error when attempting to set up a Webhook Subscription to a OneDrive app-root folder (/drive/special/approot). This issue began approximately one day after deployment, following an initial period where the subscription process worked correctly, and has now persisted for several weeks. Here's the full error message: { "error": { "code": "ExtensionError", "message": "Operation: Create; Exception: [Status Code: ServiceUnavailable; Reason: User content migrated. Cannot access disabled item.]", "innerError": { "date": "2025-06-10T10:58:15", "request-id": "edff6dc0-45b7-4e7c-8797-3134ebc6bae4", "client-request-id": "edff6dc0-45b7-4e7c-8797-3134ebc6bae4" } } } Could this error be related to: - The absence of an MPN ID? - The type of Microsoft account used for app registration (personal vs. work account)? Any insights or suggestions would be greatly appreciated!
