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/Automating Microsoft 365 with PowerShell Second Edition
The Office 365 for IT Pros team are thrilled to announce the availability of Automating Microsoft 365 with PowerShell (2nd edition). This completely revised 350-page book delivers the most comprehensive coverage of how to use Microsoft Graph APIs and the Microsoft Graph PowerShell SDK with Microsoft 365 workloads (Entra ID, Exchange Online, SharePoint Online, Teams, Planner, and more). Existing subscribers can download the second edition now free of charge. https://office365itpros.com/2025/06/30/automating-microsoft-365-with-powershell2/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.Restricting App Creation of SharePoint Online Sites
This article discusses the use of restricted site creation for third-party Entra ID apps. The feature has an allow or deny list to identify apps that can create new SharePoint Online sites. Controlling the set of apps that can create new sites contributes to limiting site sprawl and makes sure that every site has a real function. First-party apps like Teams are unaffected. https://office365itpros.com/2026/04/02/restricted-site-creation-apps/
