The Grief and Joys of New PowerShell Releases
A new version of the Microsoft Graph PowerShell SDK (V2.38) is available, as is a new version of the Exchange Online Management module. They don’t work well together. It’s annoying and beyond frustrating that two critical PowerShell modules in the Microsoft 365 ecosystem cannot work together. If anything, the situation is getting worse. On the upside, I found out about two cmdlets that I might never use – but who knows! https://office365itpros.com/2026/06/22/powershell-woes-and-cmdlets/Microsoft Blocks Graph Access to Non-IPM Folders
An app written to fetch details of Copilot interactions from the TeamsMessagesData folder suddenly stopped working when the Graph refused to return items. The 403 forbidden error can’t be argued with. Fortunately, the aiInteractionHistory API fills the gap, even if the API does not return the full text of Copilot responses. That information is available, but you’ll need to use eDiscovery to get it. https://office365itpros.com/2026/06/18/copilot-interaction-app/Microsoft Wants PowerShell Developers to Change How They Download Microsoft Modules
A Microsoft blog describes some changes for PowerShell developers in terms of installing modules and the role of the Microsoft Artifact Registry (MAR). In a nutshell, Microsoft intends the MAR to be the go-to place to download first-party PowerShell modules and other artifacts. This solves the problem of potentially compromised modules found in the PowerShell Gallery, but MAR can’t work if it doesn’t contain the modules people use. https://office365itpros.com/2026/06/05/microsoft-artifact-registry/Microsoft Cans Power BI App for Reporting Microsoft 365 Usage
Microsoft has announced that the Microsoft 365 Usage Analytics Power BI app will retire on August 1, 2026. The alternative is the usage reports in the Microsoft 365 admin center or to develop a custom Power BI dashboard based on data imported through the Graph usage reports API. The decision isn’t surprising, but I’m sure that some will mourn the passing of Microsoft’s first tool to report usage information. https://office365itpros.com/2026/05/29/microsoft-365-usage-analytics/Sending a Welcome Message to New Employees Part 2
Recently, I wrote about how to use PowerShell to send a welcome email to new employees together with attached ICS files for corporate events. Although new employees can add the ICS files to their calendars (so the solution works), simply inviting employees to attend those events by updating the participant list with PowerShell is an easier and better approach. This article explains how to find calendar events, update participant lists, and update events with the Microsoft Graph PowerShell SDK. https://office365itpros.com/2026/05/27/new-employee-email2/Why Graph-added People Skills Don’t Show Up on the User Profile Card
Microsoft’s People Skills service can use AI to attribute 16,000 different skills to users. Those skills show up on the user profile card. However, once a Microsoft 365 tenant enables People Skills, they lose the ability to add custom skills for user profiles via Graph APIs or People Connectors. It’s a curious situation where Microsoft blocks custom additions because its AI-powered service is active. Couldn’t both exist alongside each other? https://office365itpros.com/2026/05/14/people-skills-graph/Understanding How Graph Permissions for Groups Work
Understanding the set of Graph permissions required by apps can be challenging. In this article we discuss how the Group.Read.All and GroupMember.Real.All permissions work and why you should choose one permission over the other so that you respect the principle of least permission when it comes to assigning Graph permissions to your apps and PowerShell scripts. Experience of reviewing scripts shows that too many people use Group.Read.All without needing to. Don't over-permission your scripts! https://office365itpros.com/2026/05/13/graph-permissions-groups/The Microsoft Graph PowerShell SDK and the additionalProperties Property
The additionalProperties property is available for many Microsoft Graph PowerShell SDK cmdlets. In this article, we explain the function of the additionalProperties property and how it functions in holding output for Microsoft Graph PowerShell SDK cmdlets. It’s all because of the lack of strongly-typed properties, or so the AutoRest process would have us believe. https://office365itpros.com/2026/04/21/additionalproperties-property/Creating a Planner Weekly Notification Email for Incomplete Tasks
A reader wanted a weekly incomplete task report to send details of Planner tasks to people with outstanding work to do. We used PowerShell to scan for incomplete tasks for people who are members of a group, perform some analysis on the data, and create and send email. Despite some deficiencies in the Planner Graph API, the code is pretty straightforward. https://office365itpros.com/2026/04/15/weekly-incomplete-task-report/
Microsoft Graph: Private channel SharePoint site URL naming appears to have changed
📄 Question We are creating private channels using the Microsoft Graph API: POST https://graph.microsoft.com/v1.0/teams/{team-id}/channels With the following payload: { "@odata.type": "#microsoft.graph.channel", "displayName": "Project-Channel-001", "description": "Sample private channel for testing", "membershipType": "private", "members": [ { "@odata.type": "#microsoft.graph.aadUserConversationMember", "******@odata.bind": "https://graph.microsoft.com/v1.0/users/{user-id}", "roles": ["owner"] } ] } 🔍 Observed Behavior When the private channel is created, the associated SharePoint site is provisioned automatically (as expected). However, the URL format appears to have changed. Previously observed behavior: https://{tenant}.sharepoint.com/sites/ProjectTeamURL-Project-Channel-001 Current behavior: https://{tenant}.sharepoint.com/sites/ProjectTeamName-Project-Channel-001 ❗ Impact This change introduces several issues: Breaks deterministic URL generation logic Produces longer and less predictable URLs Introduces dependency on display name, which is mutable and may contain unexpected characters Impacts existing automation and integrations relying on the previous pattern ❓ Questions Has there been a recent change in how SharePoint site URLs are generated for private channels? Is this behavior intentional and documented, or a regression? Is there any way (via Graph or otherwise) to: Control the generated SharePoint site URL, or Retrieve the final site URL deterministically without relying on pattern assumptions? Is the previous {ParentTeamUrl}-{ChannelName} format still expected in some scenarios, or has it been deprecated? 🧪 Additional Notes This behavior is observed when creating channels via Microsoft Graph (v1.0) The issue is reproducible across multiple test scenarios 🙏 Any clarification from Microsoft or others encountering this would be appreciated.
