Introduction Updating the default sharing link from the User Interface at both the site level and tenant level to Specific People (only the people the user specifies) might not work always as expected. This issue could be due to the outdated setting DefaultSharingLinkType being updated behind the scenes. I tested this on a Team site by updating the default sharing setting from the SharePoint Admin Centre to “People you choose”. However, the default sharing link for new sharing links did not reflect this setting.

In the Power Platform Admin Center, you may have added app users that you no longer need. To view the list of app users added to an environment, navigate to the following URL https://admin.powerplatform.microsoft.com/manage/environments/c1725b9e-0000-0000-0000-000d3ad0000/appusers, replacing c1725b9e-0000-0000-0000-000d3ad0000 with your environment ID: To delete an app user, click on the ellipsis (…) next to the app user and select the Delete button. However, you may encounter a misleading error message: ✖ Failed to delete app user: User with SystemUserId= is not disabled.

Client secrets have traditionally been the go-to method for deploying Power Platform solutions from Azure DevOps, utilizing app registrations from the Azure platform. However, my personal experience has shown that this approach can be problematic, especially when you are not an application admin. It often involves wasting time figuring out why deployments have failed due to expired or missing client secrets. Even when reaching out to someone with application admin rights, they might generate a new client secret but forget to update the service connections for each service connection within Azure Dev Ops or the application admin does not have access requiring to reach out to someone else who have access, causing further disruptions.

My Visual Studio subscription was deactivated, resulting in the loss of my Azure subscription and licenses to access Microsoft Teams within my M365 developer tenant. This post covers my attempts to recover access in vain. Access to Microsoft Teams I thought I could extend my access to Microsoft Teams by opting for a free trial for Microsoft 365 E5 (no Teams) and Teams Premium - Microsoft Teams Premium. However, this did not restore access to Microsoft Teams despite waiting multiple hours after I added the above licenses.

When you create an Agent within Copilot Studio, a corresponding App registration is automatically generated. These app registrations are named after the Agent, suffixed with “(Microsoft Copilot Studio)”. You can view these app registrations in the Azure Portal under App registrations > All applications. Agent Certificates and Federated Identity Each app registration associated with a Copilot Studio Agent includes three certificates and two federated credentials as of January 2025. These components enable secure communication between agents and your data sources and services.

Sharing is a great feature for collaboration. However, depending on how items, files, or folders are shared, a sharing link might be created or unique permissions on these items are created. It is possible to set an expiration date on sharing links in SharePoint and OneDrive. For more details, please refer to How to set an expiration date on sharing links in SharePoint and OneDrive. Microsoft introduced the capability to set an expiry date for all types of sharing links: “Anyone”, company-wide (aka.

Introduction Microsoft Teams offers private and shared channels as specialized collaboration spaces to cater to different organizational needs. While these channels provide enhanced security and collaboration features, they come with specific limitations and management challenges, particularly around the associated SharePoint sites. This post covers some limitations, and management tips for SharePoint sites associated with private and shared channels, including PowerShell hacks and governance practices to overcome these challenges. Managing SharePoint Sites for Private and Shared Channels SharePoint sites associated with private and shared channels are special types of sites with the limitations as identified by Gregory in his blog post Why you should never mess with Private and Shared Channel SharePoint Sites related to the inability to attach to a hub directly, being accessible from the Teams interface mainly, and inability to manage permissions at the site level, and with constrained external sharing.

Introduction There are situations where you might want to reuse the M365 Group principals to assign permissions to other sites without creating additional Entra ID groups. This can be useful for: Adding M365 group members to a SharePoint site, such as an intranet site for ‘Human Resources’ managed by the ‘Human Resources’ M365 Group/Teams or a hub site managed by a ‘Service Desk’ M365 Group/Teams. Adding M365 group members to custom or out-of-the-box SharePoint groups, such as adding particular M365 group owners or members to custom groups created for additional libraries within a different site.

Introduction By default, guest access for Microsoft 365 groups is enabled within the tenant. This can be controlled either to allow or block guest access at the tenant level or for individual Microsoft 365 groups / Teams. For more information, check out Manage guest access in Microsoft 365 groups. PowerShell Script to Prevent Guest Access Below is a PowerShell script that allows you to disable/enable guest access for specific Microsoft 365 groups.

Introduction As part of Microsoft 365 Copilot readiness, you may want to find where “Everyone and “Everyone except external users” claims are granted permissions which is a cause of oversharing. This blog post will guide you through using PowerShell to manage and audit the “Everyone” and “Everyone except external users” claims within your SharePoint site collection. For more insights on why the “Everyone except external users” group is riskier than “People in your organization,” refer to Copilot for Microsoft 365 Data Ready – Where “Everyone except external users” group is more risky than “People in your organization” links!

Introduction Understanding the sensitivity and retention labels applied to files in your SharePoint Online sites is essential for maintaining data security and compliance. These labels enable you to manage and protect your data by defining retention periods and handling sensitive information appropriately. This is particularly important for initiatives like the Microsoft 365 Copilot rollout, ensuring that the correct files are stored within the appropriate SharePoint sites. For example, if a SharePoint site is a public Team site, files labeled as confidential should be moved to a private Team site or existing Team site updated from public to private.

Ensuring the security and compliance of your SharePoint environment is crucial, especially when dealing with service principals, Entra ID apps, or federated identities. These entities often have elevated permissions that, if mismanaged, can lead to unauthorized access and potential data breaches. Regularly auditing these permissions is a best practice for maintaining a secure and compliant SharePoint environment. Application only or granular access to individual site instead of whole tenant, scope called “Sites.

Updating the expiration time and role for sharing links is still limited. Although it seems possible through the Graph API Update permission, I have been unable to pass the roles as body parameters. Graph Explorer Attempts Using the following script: Invoke-PnPGraphMethod -Url "v1.0/drives/$driveId/items/$driveItemId/permissions/$($ShareLink.Id)" -Method Patch -Content @{ roles = @("read") } threw the error message “Invalid input: No Information provided to update the specifed permission” From the UI Anyone link can’t be edited Organisation link can’t be edited Specific people links can be edited Using the network tab from the browser developer tools enables identifying the endpoint to update specific people links only.

The script checks the ‘SharePoint Online Web Client Extensibility’ Principal within Entra ID for the actual assigned permissions as the SPFx solutions requests are all be added to that single shared permission group. As hilghlighted by “Wes Hackett”: I’ve personally seen plenty of tenants with Mailbox permissions with no corresponding solutions live in the app catalogs. Early SPFx doc examples encouraged the use of MS Graph into Mailbox permissions in one of the how to learn samples, older tenants sometimes have this breadcrumb left behind.

Have you ever needed to gather detailed information about SPFx solutions installed in your SharePoint environment, such as API permissions, for auditing, inventory, or compliance purposes? The PowerShell script below helps you retrieve these details from both the tenant-level and site collection app catalogs for auditing with the aim to improve security posture by removing unneeded apps and access rights. To execute this script, you must have Global Administrator or SharePoint Administrator roles.

Effective oversight of sharing links and sharing information are paramount to ensuring data security, compliance, and optimal collaboration experiences. As organisations migrate to M365 environments, they inherit powerful collaboration tools that facilitate seamless sharing of documents and resources. However, without proper governance, these capabilities can lead to unintended consequences such as data breaches, compliance violations, and loss of intellectual property. Sharing is a powerful feature for collaboration. However depending on how items, files or folders are shared, a sharing link might be created or unique permissions on these items are created.

Query Unique Permissions in SharePoint using CSOM and PnP PowerShell Managing permissions in SharePoint is a critical aspect of maintaining data security and compliance within organisations. However, as SharePoint environments grow in complexity, manually auditing and managing permissions becomes increasingly challenging. To address this challenge, PowerShell scripts can be leveraged to automate the auditing process, providing administrators with valuable insights into permission structures across SharePoint sites and libraries. What do SharePoint permissions have to do with Copilot for Microsoft 365?

Recreating Deleted Owners Group for M365-Connected SharePoint Sites If out-of-the-box (OOB) groups such as owners, members, or visitors have been deleted accidentally from your SharePoint site, this article may assist you in recovering those vanished groups specifically for M365 linked Team site. I recently encountered a distress call from an end user facing data access issues on a SharePoint Team site. To my dismay, I discovered that the SharePoint Owners group had been accidentally deleted, prompting me to seek and implement a solution to restore access.