SharePoint Agents are changing what customers need to know for preparation
SharePoint Agents Are Changing: What Customers Need to Prepare for Now Microsoft is moving SharePoint Agents away from the legacy .agent file model and into the broader Microsoft 365 agent platform. The capability is not being retired but the way agents are created, governed, shared, and surfaced is changing. As of October 24, 2026, the first phase is scheduled to begin in mid-November, followed by the retirement of .agent based experiences after March 2027. Organizations using SharePoint Agents should treat this as a lifecycle and governance transition not simply a user interface update. The transition and its decision points are summarized below. Figure 1: The transition is not a simple file conversion: each legacy SharePoint Agent needs an owner, a target experience, and validation of permissions, licensing, and access points before support ends. New agents will move to Microsoft Copilot Agent Builder Beginning in mid-November 2026, creating an agent from SharePoint or OneDrive will open Microsoft Copilot Agent Builder instead of creating another .agent file. New agents will become Microsoft 365 declarative agents and appear through the Microsoft plugin ecosystem. The rollout is expected to complete by early December 2026. Users will still be able to start from SharePoint content. Selected sites, libraries, folders, or files become the agent’s initial knowledge scope, but the resulting agent is managed through Agent Builder rather than a file stored in a SharePoint library. Microsoft describes Agent Builder as the lightweight experience for creating declarative agents with dedicated SharePoint knowledge sources, instructions, and scenario specific behavior. Why this matters: SharePoint remains the governed knowledge source, while agent creation, sharing, discovery, and lifecycle management move into the Microsoft 365 agent platform. Figure 2: Microsoft Copilot Agent Builder provides the new agent creation experience, allowing users to define agent instructions and add skills to customize the agent for specific scenarios. Existing .agent files require a transition decision Existing .agent files will continue working through the end of March 2027. Microsoft plans to begin disabling those experiences in early April 2027, with completion expected by mid-April. The retirement affects .agent based experiences in SharePoint, OneDrive, Microsoft Teams, and the Copilot app. Figure 3: From the Edit agent page, select Upgrade to Microsoft 365 agent to transition an existing agent to the Microsoft 365 agent experience. Microsoft indicates that agents not upgraded by the end of March 2027 will no longer be accessible as agents. Microsoft identifies several transition paths: Use Copilot in SharePoint for general questions about content on the current site. Convert the agent to a skill when it supports a focused site-specific task or business outcome. Upgrade to a Microsoft 365 declarative agent when users need a named, content-grounded conversational experience across Microsoft 365. Review the publishing configuration of an existing Copilot Studio agent rather than rebuilding it solely because of this change. Retire or archive the agent if it no longer has a clear purpose or accountable owner. Copilot in SharePoint entered general availability rollout on September 30, 2026. Its everyday capabilities require an active Microsoft 365 Copilot license; advanced, large scale work uses Copilot Credits through usage based billing. The important customer decision is therefore not simply “How do we convert this file?” It is “Which experience best preserves the agent’s intended business outcome?” SharePoint page and Teams placements must be reviewed Agent access points do not necessarily remain unchanged after an upgrade. Microsoft says upgraded agents must be re-added to applicable Teams chats or channels, and legacy .agent placements in SharePoint will require review. To support the new model, Microsoft has announced the Agent Chat web part, which will allow modern SharePoint page editors to configure a page with any Microsoft 365 Copilot agent. Roadmap ID 575298 currently lists a November 2026 preview and January 2027 general availability, with the feature still marked in development. This differs from the existing Agent Link web part, which provides a link that opens an agent in a side pane. Organizations with agents embedded on high traffic intranet or business-process pages should inventory those placements early rather than waiting for the legacy agent deadline. Permissions and licensing remain two separate checks Upgrading an agent does not replace SharePoint permissions. Users still require access to the SharePoint content used as knowledge, while access to the agent itself is managed separately. Microsoft specifically notes that Agent Builder does not automatically grant broad access to source files and folders; permissions may need to be updated for the intended audience. Licensing also depends on the selected transition path: For users with a Microsoft 365 Copilot add-on license, access to declarative agents and SharePoint grounded extensibility does not create additional consumption charges. Eligible Microsoft 365 Copilot Chat users can access declarative agents, but agents using shared tenant data such as SharePoint may incur usage based charges through Copilot Credits. Copilot in SharePoint requires a Microsoft 365 Copilot license, while its advanced, at-scale capabilities additionally require usage based billing and available Copilot Credits. Admins should therefore validate both user eligibility and cost management configuration before communicating that an upgraded agent is ready for production. What organizations should do now Inventory existing agents. Use SharePoint search for *.agent, site usage information, Purview audit data, and the SharePoint Agent Insights reporting capabilities to identify agents and where they are being used. Need a way to start finding existing .agent files in your SharePoint environment? Mike Lee has shared two PowerShell scripts that can serve as useful resources for agent discovery and inventory: TenantWide_SP_Copilot_Agents_Insights.ps1 and TenantWide_SP_Copilot_Agents.ps1. The insights version has specifically been referenced as a script that can help identify .agent files, making it a helpful resource as organizations assess their existing SharePoint agents. Assign an accountable owner. Record the agent’s purpose, audience, knowledge sources, current sharing model, business criticality, and access points. Choose the destination by outcome. Use Copilot in SharePoint for site-level knowledge, a skill for a focused site task, Agent Builder for a named Microsoft 365 experience, or retirement where the agent no longer delivers measurable value. Validate access twice. Confirm that intended users can access both the replacement agent and every SharePoint knowledge source required for a complete response. Test the replacement. Run representative prompts, verify citations and knowledge scope, review licensing or Copilot Credit implications, and confirm SharePoint, Teams, and Copilot access paths. Complete the transition before March 2027. Leave time for page updates, Teams replacement, user communications, and remediation of permission or content quality issues. The central message is straightforward: SharePoint Agents are not going away, but .agent files are. Customers that begin with inventory, ownership, and scenario based decisions will be better positioned to move into the new Microsoft 365 agent model without disrupting trusted knowledge experiences. Resources: Agent Builder Agent Builder overview | Microsoft Learn Get Started with Copilot in SharePoint Get started with Copilot in SharePoint - SharePoint in Microsoft 365 | Microsoft LearnSharePoint Is Becoming the Knowledge Platform for Copilot
Why the next phase of enterprise AI will be determined not only by better models, but by better organizational knowledge Product and terminology status verified against Microsoft’s published guidance available on September 10, 2026. The most important question about enterprise AI is no longer, “How intelligent is the model?” It is, “What does the model know about our organization, and should it trust what it finds?” A powerful model grounded in outdated policies, duplicate documents, unclear ownership, or overly broad permissions can produce polished but unreliable answers. Grounded in current, authoritative, well-structured, and appropriately secured knowledge, AI can become a dependable participant in how an organization works. That is why SharePoint’s role in Microsoft 365 is changing. It remains a platform for documents, intranets, collaboration, publishing, and business solutions. Increasingly, those capabilities support a larger strategic function: creating, organizing, governing, and activating the knowledge Copilot and agents use to reason about the business. Microsoft describes SharePoint as the leading grounding source for Microsoft 365 Copilot, foundational to Work IQ, and “the knowledge platform for Copilot and agents.” My strategic interpretation is straightforward: SharePoint is evolving from a place where enterprise knowledge is stored into an operational knowledge layer through which AI discovers, interprets, protects, and activates that knowledge. From Passive Repository to Conversational Knowledge For much of its history, SharePoint helped people publish information and gave others places to browse or search for it. Agents change that interaction model. Instead of knowing which site, library, terminology, or document version contains the answer, an employee can begin with intent: What is our policy? What changed? What applies to my situation? What should I review next? This is more than an improved search box. Search returns candidate content. A knowledge grounded conversation can retrieve, synthesize, compare, explain, and cite that content in the context of the user’s request. The repository becomes the grounding environment behind a conversational interface. SharePoint Agents: Giving Knowledge a Conversational Boundary SharePoint agents ground conversations in selected sites, libraries, pages, folders, and files. This creates a deliberate knowledge boundary around a business purpose while continuing to respect each user’s permissions. Microsoft has announced an evolution to this model. Beginning in mid-November 2026, creating a new agent from SharePoint or OneDrive transitions from the .agent file model to Microsoft 365 Copilot Agent Builder. Users can still start where the knowledge lives, but the selected content becomes the agent’s initial knowledge scope in Agent Builder rather than a new .agent file. The architectural separation becomes clearer: SharePoint provides the governed knowledge foundation, Microsoft 365 provides the agent creation and lifecycle layer, and Copilot provides the interaction layer. Agent access determines who can use the agent; SharePoint permissions determine what knowledge each person can receive. Existing .agent files will not automatically migrate and are planned to remain supported through March 2027. Organizations should use the transition to decide which agents solve meaningful business problems, who owns them, and whether their sources are authoritative, current, and appropriately permissioned. Knowledge Agent Has Evolved into Copilot in SharePoint Microsoft’s terminology has evolved. In early 2026, Knowledge Agent in SharePoint was described as a public preview experience for improving AI answers, automating metadata and classification, supporting business processes, and identifying stale pages, broken links, and knowledge gaps. By September 2026, Microsoft documentation presents the broader user-facing capability as Copilot in SharePoint. Microsoft Learn notes that it was previously called AI in SharePoint, while PowerShell parameters such as KnowledgeAgentScope retain the earlier name for compatibility. These concepts should not be treated as interchangeable: Concept Primary role SharePoint Agents Scoped conversational assistants grounded in selected SharePoint knowledge. Copilot in SharePoint / earlier Knowledge Agent capabilities An AI experience for understanding, creating, organizing, enriching, maintaining, and acting on SharePoint content. SharePoint Admin Agent An administrative governance experience for assessing and remediating risks across SharePoint and OneDrive. As of September 10, 2026, Copilot in SharePoint remains documented as a public preview. Microsoft moved it toward an opt-out preview for licensed users beginning in mid-June 2026, with tenant- and site-level controls available through the SharePoint Online Management Shell. Its documented capabilities include asking questions, organizing content, creating sites and business artifacts, and supporting workflows through natural language. This is another sign of a knowledge platform: AI is moving upstream into knowledge stewardship. SharePoint Agents help people converse with knowledge; Copilot in SharePoint helps create, organize, improve, and operationalize the environment those conversations draw from. Metadata Is Becoming Context Infrastructure Metadata has often been treated as a SharePoint feature users avoid and administrators defend. In an AI-ready environment, it is better understood as context infrastructure. Content supplies the words. Metadata supplies structured context: document type, business process, owner, geography, review date, lifecycle status, and related product, customer, regulation, or department. SharePoint information architecture already combines navigation, search, hierarchy, taxonomy, security, metadata, and personalized experiences. Managed metadata creates reusable vocabulary, while content types provide consistent structures for policies, procedures, contracts, and other content classes. Microsoft also documents more direct links between metadata and Copilot retrieval. When a request is scoped to a SharePoint library or folder, grounding can use library column metadata with file content to constrain and rank results. Guidance for agent content recommends consistent metadata, content types, owners, effective dates, and regional classifications to reduce ambiguity. Metadata is not an accuracy switch. It cannot correct a bad policy or resolve conflicting sources. Its value is that it makes organizational distinctions machine-readable, supports retrieval and lifecycle controls, separates authoritative content from drafts, and gives people and AI a shared vocabulary. Copilot in SharePoint may also reduce the friction of structured knowledge management by suggesting schemas and autofill columns. People must still validate the vocabulary, schema, and resulting classifications. Permissions Are Part of the Answer Microsoft 365 Copilot does not grant access simply because a user asks a question. SharePoint Agents and SharePoint knowledge sources in Copilot Studio return only content the signed-in user is authorized to access. But permission aware AI can still surface sensitive information when the underlying access model is too broad. Copilot can amplify the consequences of oversharing without causing the original permission problem. “Copilot respects permissions” should begin the executive conversation, not end it. The real question is whether Copilot is respecting the permissions the organization intends. Microsoft recommends SharePoint Advanced Management and Microsoft Purview to identify overshared content, review permissions and sharing links, apply sensitivity protections, and right-size access. Restricted Access Control can limit a site to designated groups. Restricted Content Discovery can temporarily keep high-risk site content out of organization-wide search and Copilot during remediation without changing underlying permissions. Controls should remain proportionate. Microsoft cautions that overusing Restricted Content Discovery can reduce the completeness and relevance of search and AI responses. The goal is not to hide enterprise knowledge, but to make appropriate knowledge safely usable. Content Quality Is Now an Operational Discipline A perfectly permissioned content estate can still be a poor knowledge foundation. Duplicate procedures, unclear filenames, ownerless pages, missing review dates, broken links, drafts mixed with approved guidance, and years of inactive content can all weaken answers. Microsoft guidance emphasizes clear structure, focused pages, descriptive headings, concise summaries, consistent labels, versioning, retention, review policies, and archiving or deleting obsolete content. Governance tooling can also identify inactive or ownerless sites, request attestations, archive sites while preserving metadata and permissions, and assess content-management risk. Copilot in SharePoint points toward continuous content quality through documented capabilities for identifying stale pages, broken links, and gaps; suggesting improvements; enriching libraries with metadata; and helping owners organize or automate content. Technology cannot own knowledge quality by itself. AI may identify old or similar content, but it cannot always determine legal validity or business authority. Knowledge quality requires accountable owners, defined review cycles, and operational measures—not a one-time cleanup before Copilot deployment. The Architecture of an AI-Ready Knowledge Layer The emerging operating model can be understood as five connected layers: Content: SharePoint sites, pages, documents, lists, libraries, and business solutions. Context: metadata, taxonomy, content types, ownership, effective dates, relationships, and information architecture. Trust: permissions, least privilege, sensitivity, retention, lifecycle, authoritative-source designation, and discovery controls. Retrieval and reasoning: Microsoft Graph, semantic indexing, retrieval services, and Work IQ. Experiences: SharePoint Agents, Copilot in SharePoint, Copilot Search, Microsoft 365 Copilot, Copilot Studio agents, and custom applications. Microsoft describes Work IQ as a workplace intelligence layer spanning organizational data, context, tools, and workspaces. SharePoint Embedded can also provide persistent working storage for longer running agent workflows. SharePoint is not the exclusive source of Microsoft 365 intelligence. Copilot can also ground experiences in OneDrive, email, meetings, chats, people, and connected external data. Work IQ assembles context across organizational systems, and the Retrieval API supports SharePoint, OneDrive, and connector content. SharePoint is becoming a primary governed knowledge foundation within Microsoft 365’s broader AI and intelligence architecture. Its distinctive value is the combination of content management, publishing, information architecture, permissions, lifecycle, extensibility, and agent experiences inside the Microsoft 365 trust boundary. What Leaders Should Do Now For executives Treat enterprise AI readiness as a knowledge strategy, not merely a licensing or deployment program. Identify the business domains that depend most on authoritative knowledge, assign accountability, assess the cost of outdated or incorrectly shared answers, and prioritize scenarios that justify investment in stewardship. The strategic metric is not the number of agents created. It is whether people can make faster, better-supported decisions using trusted organizational knowledge. For IT, security, and governance leaders Move from periodic cleanup to continuous knowledge-risk management. Priorities include identifying high risk sites, validating ownership, reviewing sharing defaults and legacy links, establishing lifecycle and attestation policies, distinguishing official sources, and using temporary discovery restrictions selectively during remediation. Microsoft’s Content Management Assessment, data access governance reporting, authoritative site designation, and SharePoint Admin Agent all reflect this shift toward ongoing governance. For SharePoint and Microsoft 365 practitioners Design for both human and AI consumption: clear titles and headings, intentional content types, meaningful metadata, manageable document scope, identifiable owners, review and effective dates, explicit current or superseded status, accessible page structure, and agent scopes aligned to real business questions. Build agents around curated knowledge domains and measurable user needs not every library that happens to exist. The Knowledge Layer Is a Leadership Choice SharePoint will not become an effective AI knowledge platform simply because Copilot is enabled. It becomes one when organizations give knowledge ownership, structure, maintenance, and protection. Many organizations will have access to comparable models. Differentiation will come from what those models can know, how effectively they retrieve it, how confidently users can verify it, and how deliberately the underlying knowledge is governed. SharePoint is well positioned because it already sits where content, collaboration, publishing, security, metadata, and lifecycle intersect. Agents make that knowledge conversational. Copilot in SharePoint helps manage it more intelligently. Microsoft Graph, semantic retrieval, and Work IQ make it available across the broader flow of work. The foundation remains human. People determine what is authoritative, define appropriate access, resolve contradictions, retire obsolete knowledge, and decide which business rules AI should follow. AI may activate enterprise knowledge, but organizations must first make that knowledge worthy of activation. The opportunity for SharePoint leaders is not simply to prepare SharePoint for Copilot, but to use Copilot as the catalyst to treat organizational knowledge as the strategic asset it has always been. Resources Topic Microsoft resource The knowledge platform for Copilot SharePoint at 25: Global enterprise knowledge in the AI era Semantic Indexing Semantic indexing for Microsoft Copilot Copilot Retrieval API Microsoft 365 Copilot Retrieval API Overview SharePoint Advanced Management Get ready for Microsoft Copilot with SharePoint Advanced Management Secure and governed foundation for Copilot Configure a secure and governed foundation for Microsoft Copilot SharePoint sites in Copilot Search SharePoint Authoritative Sites in Copilot Search Work IQ Work IQ overview Restricted Content Discovery Restrict discovery of SharePoint sites and content Adding SharePoint as a knowledge source Add SharePoint as a knowledge source in Microsoft Copilot Studio
OneDrive Username Enumeration: What Security Teams Should Know
From time to time, we receive questions about a reconnaissance technique that enumerates usernames, or user principal names (UPNs), by probing OneDrive and SharePoint URLs. The technique can reveal account names that attackers may use in targeted phishing, credential-stuffing, or brute-force attempts. These URL probes do not appear in Microsoft Entra sign-in logs or Microsoft Purview, which limits direct visibility into the reconnaissance activity. Key risks Attacker reconnaissance: UPNs discovered → targeted phishing, credential stuffing, social engineering. No direct alerting is currently available to notify organizations when users are identified through this reconnaissance technique. OneDrive enumeration is a reconnaissance technique that can support targeted phishing and credential attacks. It is currently classified as low risk because it is passive and does not bypass authentication. Organizations can reduce the risk of downstream attacks by using identity protections such as multifactor authentication and Conditional Access policies. Microsoft may also throttle clients that make excessive requests to OneDrive site collections that do not exist: "When a client makes excessive attempts to access many OneDrive site collections that do not exist, we may throttle requests from that client's IP address. The client will receive an HTTP 429 response when accessing any OneDrive site collection during the throttling period." - Throttled or blocked in SharePoint Online From a threat-model perspective, OneDrive enumeration is reconnaissance vector worth monitoring and implementing defenses. Please see the table below that provides the techniques and the associated defense that can be used: Technique Defense UPN discovery via OneDrive Enumeration Rate-limited by throttling Targeted phishing User education Targeted phishing MDO phishing prevention Credential stuffing Entra MFA Social engineering Entra Conditional access Social engineering Entra sign-in risk policies The key takeaway: OneDrive username enumeration is a low-risk reconnaissance technique, but the account names it reveals can support higher-impact attacks. Organizations should reduce that downstream risk through strong identity controls, phishing protection, and user awareness.MC1387573 Explained What Microsoft Teams Administrators Need to Know About Built-In Agent Governance
Microsoft has separated governance for built-in Teams agents from the controls traditionally used for Microsoft Teams apps. Following MC1387573 and Microsoft 365 Roadmap ID 564766, administrators now manage built-in experiences such as Channel Agent, Facilitator, and Copilot Agent in Teams from the Teams admin center > Teams apps > Built-in Teams agents. The org-wide Microsoft apps setting no longer governs those agents. Instead, administrators can set each built-in agent’s availability to Everyone, Specific users or groups, or No one. Existing explicit agent-level configurations are preserved, but an agent that previously inherited availability only from the org-wide Microsoft apps setting may now be allowed by default for licensed users. That transition behavior is the most important part of this change. Current status and scope MC1387573 was published on June 11, 2026, updated on July 20, and last modified on July 21. It was scheduled General Availability for Worldwide and GCC from early June through mid-July 2026. The latest publicly indexed Roadmap ID 564766 snapshot was updated on July 28, 2026, lists the feature as Launched, and identifies July 2026 as the GA date. The Message Center item subsequently expired on August 25, but the management experience is documented in the current Teams administrator's guidance. The announcement identifies the administrative platform as the Teams admin center. Roadmap metadata lists Android, desktop, iOS, and Mac because the governed agents surface inside the Teams experiences on those clients; administrators do not perform the governance task from those clients. The published rollout scope explicitly names Worldwide and GCC. It does not explicitly document this rollout for GCC High, DoD, 21Vianet, or air-gapped environments, so administrators should not extrapolate availability to those environments without checking their own service documentation and tenant UI. Microsoft Learn and Support content has continued to evolve: the central Teams app-management article now documents the dedicated Built-in Teams agents page, while current Facilitator and Copilot documentation provides more detailed licensing, data access, and compliance behavior. The table reflects the current Message Center copy, roadmap snapshot, and Microsoft Learn description. What changed administratively Before MC1387573 Traditional Teams app governance combines several concepts: app status, org-wide defaults, and user-level availability. With app-centric management, administrators assign an app or Copilot agent to Everyone, Specific users or groups, or No one. Org-wide settings continue to provide defaults for conventional apps that administrators have not explicitly managed. Built-in Teams agents are different. They are embedded in the core Teams experiences rather than installed from the Teams store. Before the dedicated governance experience, a built-in agent without an explicit assignment could derive its effective availability from the org-wide Microsoft apps setting. After MC1387573 Built-in agents now have their own management page. Administrators select one or more agents, choose Edit availability, and make them available to everyone, selected users or groups, or no one. The general Microsoft apps toggle on the Manage apps page expressly states that it no longer controls built-in Teams agents. The following diagram illustrates the control-plane change. Figure 1: MC1387573 separates built-in Teams agent governance from org-wide Microsoft app settings and places availability control for Channel Agent, Facilitator, and Copilot Agent in Teams in a dedicated Teams admin center surface. The transition rule that can surprise administrators There are two materially different cases: The administrator explicitly configured the agent. Existing agent-level configurations will remain unchanged after rollout The administrator never configured the agent individually and relied on the org-wide Microsoft apps setting. Prior to this change, the organization was not managing the built-in Teams agent directly. Instead, the agent's availability was inherited from the tenant's broader Microsoft app settings. With the introduction of dedicated built-in agent governance in Teams, those org-wide app settings no longer apply to built-in agents, and administrators now manage them through the new Built-in Teams Agents experience. This does not mean that a blocked explicit assignment was intentionally overwritten. It means that inherited default behavior and explicit configuration are treated differently. Administrators who used an org-wide block as a broad AI-governance control should therefore review the new page rather than infer current state from the old setting. Microsoft preserved access for users who were already using these built-in agents. With the new governance model, administrators no longer install these agents as apps. Instead, they control whether the agents are available to specific users or groups, making availability the primary management mechanism. The built-in agents named in MC1387573 Channel Agent Channel Agent creates an agent associated with a Teams channel and can draw on channel conversations, channel SharePoint files, and relevant meeting information. Microsoft currently documents Channel Agent as public preview, requiring an eligible Microsoft 365 base license, a Teams license, a Microsoft Copilot license, Teams Public Preview participation, and enabled Loop experiences. Its data access behavior is permission aware. Microsoft states that it does not use file content to answer a user who lacks access to that file. If the requesting user has access but other conversation members may not, the agent asks the requester to review and approve sharing the response. Its documented knowledge sources include channel messages, channel SharePoint files, meetings, transcripts, and optional web search; files shared outside the channel’s SharePoint location are not automatically part of its knowledge. Channel Agent deserves a focused data governance review because its knowledge can span channel and meeting contexts. Microsoft’s documentation notes that meeting summaries accepted into the agent’s knowledge may subsequently help channel members who did not attend the meeting, and that generated responses do not automatically inherit all controls of a source sensitivity label. These are documented product behaviors not evidence of unauthorized access, but they reinforce the need to validate channel membership, SharePoint permissions, meeting practices, information barriers, and sensitivity-label design during a pilot. Facilitator Facilitator is a collaborative meeting agent. Unlike an individual Copilot interaction, prompts Facilitator and its responses are visible within the meeting conversation. Generally available capabilities include collaborative notes, meeting Q&A, timeline markers, document creation, Teams Rooms integration, and mobile capture; Planner task tracking remains documented as preview. Facilitator requires eligible Microsoft 365 and Teams licensing plus a Microsoft Copilot license, with Loop experiences enabled for meeting notes. Facilitator meeting data is documented as being stored in the initiating user’s OneDrive Meetings folder and treated as meeting transcript data. Microsoft also documents several control limitations: generated notes do not automatically inherit the meeting sensitivity label, meeting prevent copy and watermark settings do not apply to Facilitator responses or notes, and retention labels are not supported for cloud attachments in AI-generated notes. Administrators should incorporate these documented differences into meeting classification and records management guidance. Microsoft Purview supports auditing, data classification, communication compliance, eDiscovery, retention, DSPM, and Compliance Manager scenarios for Facilitator interactions. Prompts and responses can be captured in the unified audit log; Microsoft recommends Teams chats as the retention location for Facilitator interactions and OneDrive accounts for generated notes. The same documentation currently marks direct sensitivity-label and DLP support for Facilitator AI interactions as unsupported, so administrators should not assume that every Purview control applies uniformly to every artifact. Copilot Agent in Teams group chats While the Message Center announcement refers to Copilot Agent in Teams, current Microsoft documentation describes this experience as Copilot in Teams group chats (Teams Mode). Currently available in Public Preview, the experience allows licensed users to add Copilot to group chats and interact with it using @mentions to ask questions, locate relevant information, summarize discussions, and create collaborative content directly within the conversation. Copilot grounds its responses in the content available to the person asking the question. If all chat participants have access to the same source content, or if the response is based on web data, the response can be displayed directly in the chat. If Copilot uses information not available to every participant, the requester receives a private preview and must approve or reject broader sharing. Users without a Copilot license cannot prompt the agent but can read responses that licensed users share in the conversation. More broadly, Microsoft states that Copilot surfaces organizational data based on the requesting user’s existing permissions, and that prompts, responses, and Microsoft Graph data are not used to train foundation models. Copilot interaction history is stored and can be managed through Microsoft Purview retention and eDiscovery capabilities. Governance and security implications Treat availability and data access as separate control planes Making an agent available lets an eligible user invoke it; it does not independently grant the user access to files, chats, or meetings. Microsoft Copilot and Channel Agent document permission-aware grounding. Nevertheless, existing oversharing remains relevant because AI can make information that a user is already authorized to access easier to discover and synthesize. Microsoft’s broader secure-governed Copilot guidance therefore emphasizes remediating oversharing, establishing guardrails, and meeting regulatory requirements. Use explicit assignments for controlled adoption For a tenant that has not completed risk review, assigning an agent to a pilot group is clearer and more auditable than relying on a broad default. The built-in agent page supports selected user or group availability, and Teams app-centric management describes per app assignments to align access with organizational compliance and risk posture. Microsoft does not currently provide a definitive list of built-in agents directly within the Built-in Teams Agents administration page. As a result, administrators should refer to current product documentation and announcements for the latest information on supported agents. Apply administrative least privilege Microsoft documents the Teams Administrator role as capable of managing Teams apps and recommends using the lowest privileged role available rather than Global Administrator. Teams Reader can support read-only validation where its documented limitations are acceptable. Separate operational duties configuration, compliance investigation, and helpdesk support rather than granting standing Global Administrator access to everyone involved in the rollout. Fit the page into a broader AI governance model The dedicated page is an availability control, not a complete AI-governance program. A defensible enterprise model also addresses licensing, data permissions, source hygiene, sharing boundaries, retention, eDiscovery, audit, user training, acceptable use, and lifecycle review. Microsoft’s secure-governed foundation organizes this work around remediating oversharing, setting guardrails, and meeting regulatory obligations, while the Microsoft 365 admin center provides broader agent settings and lifecycle controls for other agent classes. Monitor cautiously and document telemetry gaps Teams app usage reports provide per app usage, active user, active team, platform, and last used information for supported Teams apps. Purview provides more specific interaction level auditing for experiences such as Facilitator and Copilot. Microsoft’s public documentation does not explicitly guarantee that every built-in agent action appears in the generic Teams app usage report, so test each named agent and document which report, audit event, or DSPM view provides evidence in your tenant. Administrator readiness checklist Immediate configuration review Open Teams admin center > Teams apps > Built-in Teams agents. Record every listed agent and its current availability. Compare current state with your approved AI and Teams-app governance baseline. Identify agents that were never explicitly configured and were previously assumed to be controlled by the org-wide Microsoft apps setting. For any unapproved agent, set availability to No one or a defined pilot audience rather than relying on inheritance. Pilot and validation Create a representative pilot covering channel owners, meeting organizers, information workers, administrators, security/compliance teams, and support staff. Validate licensing and prerequisites for each agent separately. Test positive and negative access scenarios: permitted file, inaccessible file, mixed permission group chat, external participant, labeled content, retained meeting, and agent removal. Verify the actual propagation interval before announcing availability; Teams documentation notes that app availability changes can take time to appear. Capture screenshots or exports of approved settings as change evidence. Security and compliance Review SharePoint and Teams permissions for pilot workspaces. Confirm how sensitivity labels, encryption, DLP, information barriers, retention, eDiscovery, and audit apply to each agent’s inputs and outputs. For Facilitator, distinguish meeting-chat interactions from notes stored in OneDrive. For Channel Agent, validate how meeting summaries become part of the channel agent’s knowledge. Confirm whether public web search is approved and controlled for the pilot audience. Change management and operations Update runbooks that direct administrators only to Manage apps or org-wide Microsoft app settings. Brief the helpdesk on the difference between availability, license eligibility, preview enrollment, Loop prerequisites, and underlying data permission. Provide users with acceptable-use guidance and remind them to verify generated content. Define an escalation path for unexpected availability, missing controls, or inconsistent documentation. Establish a recurring owner, review cadence, and evidence-retention process for built-in agent decisions. Documentation ambiguity administrators should know about At publication, Microsoft's official Teams management guidance pointed administrators to the dedicated Built-in Teams agents page for configuration and management tasks. However, some product specific setup articles for Channel Agent and Facilitator still show workflows through Teams apps > Manage apps and refer to app policies or app-centric management. Administrators should treat the newer dedicated management article and the actual UI in their tenant as the operational source of truth, while using product-specific pages for licensing, prerequisites, data behavior, and feature limitations. There is also no single public page that exhaustively enumerates every current and future built-in Teams agent, every agent-specific setting, or the telemetry coverage for every action. MC1387573 names Channel Agent, Facilitator, and Copilot Agent in Teams, while the Learn article refers more generally to “other built-in agents.” Maintain a tenant inventory and validate newly appearing entries rather than treating the three named experiences as a permanent closed list. Takeaway MC1387573 changes the governance boundary, not merely the Teams admin center navigation. Built-in Teams agents no longer inherit policy intent from the org-wide Microsoft apps setting. Explicit agent-level configurations survive, but default inherited agents may become allowed for licensed users. Administrators should therefore inventory the dedicated page, set explicit availability, pilot each agent according to its distinct permissions and data behavior, and connect those controls to Microsoft 365 permissions, Purview, records management, and change management processes. Area Current documented position Administrative surface Teams admin center > Teams apps > Built-in Teams agents Built-in examples named Channel Agent, Facilitator, Copilot Agent in Teams Availability controls Everyone, Specific users or groups, or No one Previous org-wide Microsoft apps setting No longer controls built-in Teams agents Existing explicit configuration Preserved after transition No explicit agent-level configuration May become allowed for licensed users rather than inheriting the old org-wide setting Installation model Built into core Teams experiences; no separate app-store installation required Roadmap status Launched; GA July 2026 for Worldwide and GCC Resources and further reading Manage Apps Manage your apps in the Microsoft Teams admin center - Microsoft Teams | Microsoft Learn App centric management App centric management to manage user access to Teams apps - Microsoft Teams | Microsoft Learn Set up Facilitator Set up Facilitator in Microsoft Teams - Microsoft Teams | Microsoft Learn Manage Facilitator Use Microsoft Purview to manage data security & compliance for Microsoft Facilitator | Microsoft Learn Copilot privacy Data, Privacy, and Security for Microsoft Copilot | Microsoft Learn Setup Channel Agents Set up a Channel Agent for Microsoft Teams - Microsoft Teams | Microsoft Learn FAQ’s about Agents in Teams Frequently asked questions about agents in Microsoft Teams | Microsoft Support How to use Microsoft Copilot In Teams group chats How to use Microsoft Copilot in Teams group chats | Microsoft Support Using Admin Roles Use Microsoft Teams administrator roles to manage Teams - Microsoft Teams | Microsoft Learn App usage report Microsoft Teams app usage report - Microsoft Teams | Microsoft LearnMicrosoft 365 Copilot Brand Kits: Making On-Brand Content Easier to Create
Creating a presentation should begin with the message, not with searching for the latest logo, confirming the correct font, or finding a slide deck that looks close enough to the corporate standard. AI can accelerate content creation, but speed alone does not solve brand consistency. Without the right assets and guidance, the result can still require significant cleanup before it is ready to share. Microsoft 365 Copilot Brand Kits bring approved brand assets and guidance into the content creation experience. Employees gain a clearer starting point, while brand managers and IT can control which organizational branding is available and who can manage it. The opportunity is straightforward: make approved branding easier to use, reduce avoidable rework, and help people focus on what they want to communicate. This article explains what Brand Kits include, how personal, shared, and official kits differ, how templates and organizational asset libraries affect PowerPoint results, and what administrators should configure before a pilot. Readers who are evaluating the experience can begin with the PowerPoint and template sections; administrators can start with setup, governance, and storage. What is a Copilot Brand Kit? A Brand Kit is a managed collection of approved brand assets and guidance—such as logos, colors, fonts, imagery, templates, and tone—that helps people create content aligned with an organization’s identity. In Microsoft 365 Copilot, Brand Kits provide a consistent starting point for branded content while allowing organizations to control how those assets are created, shared, and published. A Brand Kit brings together the elements that define an organization’s visual and verbal identity. Depending on how it is configured, that can include: Logos: Primary, secondary, and approved variations. Colors and fonts: Brand palettes and typography. Images and icons: Approved photography, illustrations, and visual assets. Templates and layouts: Reusable structures for creating content. Brand voice: Guidance on tone, terminology, and communication style. Usage guidelines: Rules for how brand elements should—and should not—be used. These elements help connect content creation to the organization’s standards rather than leaving each employee to assemble their own interpretation. For organizations with multiple brands, business units, or product identities, separate kits can help keep the right assets associated with the right content. Think of a Brand Kit as a managed starting point, not a guarantee that every generated result will be publication-ready. Personal, shared, and official: Understanding the three kit types Brand Kits support three different scopes of use. Personal Brand Kits: Personal kits are available only to their creator. They support individual work without exposing those assets across the organization. Creation rights still depend on organizational policy. “Personal” describes the kit’s audience—not an exemption from administrative controls. Shared Brand Kits: Shared kits make assets available to selected people based on the permissions assigned by the creator. They can support a department, project, or other defined group. Giving someone edit permission on a shared kit does not bypass the organization’s restrictions on who may create or edit kits. Official Brand Kits: Official kits are managed by designated brand managers and made available across the tenant. They provide an organization-wide option for approved corporate branding. This distinction matters: a kit shared with a team is not automatically an official organizational kit. How Brand Kits help in PowerPoint For PowerPoint, a Brand Kit provides access to approved assets and presentation templates that help guide generated content. Users can select an available Brand Kit when creating content and ask Copilot to incorporate relevant brand imagery. They can also start from an approved presentation or template. A practical approach is to: Choose the appropriate published Brand Kit. Use an approved template suited to the presentation. Describe the audience, purpose, and desired structure. Generate the content. Review the result for accuracy, readability, accessibility, and brand alignment. Selecting a Brand Kit does not automatically restyle existing slides. If the goal is to update an existing presentation, explicitly request or apply the branding changes. Copilot supports PowerPoint on Windows, Mac, and the web; availability also depends on licensing and organizational settings. Your template is as important as your assets A complete logo library cannot compensate for a weak PowerPoint template. Templates must show how the organization presents information, not merely define a color palette. Representative slides demonstrate how titles, text, images, charts, and other objects work together in realistic layouts. Include representative sample slides You do not need one sample slide for every possible layout. Instead, provide examples that reflect common and specialized presentation needs. A practical collection might include: A title slide and section divider. A straightforward content slide. An image-led slide. A chart or table. A process or timeline. A summary and next-steps slide. Choose examples that reflect how people actually communicate in your organization. A sales presentation and a technical briefing may need different patterns. Make placeholders intentional Copilot uses placeholder type, position, and size to understand the layout. Placeholder text is not a hidden instruction channel. Writing “Insert an executive summary here” inside a placeholder does not make that wording a semantic instruction to Copilot. Use the prompt to explain the communication goal. Use the template to demonstrate the presentation structure. Prepare for varying amounts of content Copilot does not resize the font or placeholder when generated text needs more space. Instead, it may add design elements to accommodate the content. That makes review important. Check for overcrowded slides, awkward text flow, and content that would be clearer if split across multiple slides. Keep instructions separate where possible Instructional slides can remain when they use reusable layouts, but mixing template guidance with normal presentation content can produce unintended results. A better practice is to keep reusable sample slides focused on the desired output and maintain detailed authoring instructions separately. Both .pptx and .potx files are supported as Brand Kit templates. Administrative setup Microsoft’s setup guidance directs administrators to configure the brand manager policy in the Microsoft 365 Apps admin center (config.office.com) using a tenant-wide policy and the designated security group. The setting appears as Elevated role for Brand Managers. Allow up to 24 hours for policy changes to take effect before treating a missing capability as a configuration failure. Restricting kit creation does not prevent users from accessing and using published official kits. Group membership matters Official editing and publishing rights are granted to members of the configured mail-enabled security group. Being a group owner is not enough. If an owner also needs to manage official Brand Kits, ensure that person is a member as well. Governance: Two permission checks, not one One of the most important administrative details is the relationship between two controls: Restrict brand kit creation governs who can create and edit kits. Enterprise Brand Manager governs publishing and management of official kits. When creation restrictions are enabled, a user needs the appropriate permissions under both controls to create and publish an official kit. For example, a person with Enterprise Brand Manager rights who is not in the permitted creation group cannot create or edit kits under that restriction. Conversely, someone allowed to create kits does not automatically have permission to publish an official kit. Storage and organizational asset libraries The implementation guidance supplied with this article describes Brand Kit data as stored in SharePoint Embedded containers: Personal and shared kits use user-based containers. Official kits use the official Brand Kit container. Organizations should verify which governance, labeling, retention, and access controls apply to their SharePoint Embedded containers and configuration. SharePoint Embedded storage does not by itself establish that every policy used for a conventional SharePoint site applies in the same way. An organizational asset library, or OAL, has a related but different role. An OAL can hold approved assets that a Brand Kit references. This lets organizations reuse an established asset collection rather than treating every kit as a separate collection of uploaded files. For PowerPoint, the important distinction is: In PowerPoint, users select the published Brand Kit, while the organizational asset library can supply assets referenced by that kit. Referencing assets also makes source accessibility important. If an asset cannot be found, check that the referenced OAL content remains accessible. Uploading the asset into the kit may be an alternative where appropriate. A practical way to get started Start with a focused pilot rather than loading every brand asset your organization owns into the first kit. Choose one presentation scenario Select a common use case, such as customer updates, internal briefings, or project reviews. This gives the team a concrete way to assess whether generated content meets real needs. Agree on ownership Identify who approves the assets, who maintains the template, who publishes the kit, and who manages the supporting permissions. A clear owner makes it easier to keep the kit current after launch. Prepare the template Review sample slides, placeholders, theme colors, fonts, and reusable layouts. Remove outdated examples and separate instructional material from production-ready samples where possible. Assemble the assets and guidance Include the approved logos, imagery, colors, fonts, and brand guidance needed for the pilot. Use compatible asset formats and sensibly sized images. Avoid unnecessarily large files—particularly images over 10 MB—as a performance precaution, not as a stated product upload limit. Configure permissions and publish Confirm both creation/editing permissions and official publishing rights. Check actual group membership rather than assuming that ownership or another administrative role provides access. Test with realistic prompts Evaluate more than whether the logo appears. Check layout selection, content density, imagery, readability, tone, and factual accuracy. Use the results to improve the kit and template before expanding adoption. An example prompt After selecting the appropriate Brand Kit, try a prompt such as: Create a presentation introducing our proposed customer onboarding approach to business stakeholders. Use the selected Brand Kit and its approved presentation template. Include the business problem, proposed approach, implementation stages, responsibilities, and next steps. Keep each slide focused on one main idea, use approved brand imagery where relevant, and add speaker notes. Do not invent metrics or customer examples; identify any missing information. The prompt explains the audience, purpose, and structure. The selected kit supplies the approved brand context. Four reliable ways to apply branding Choose the method that matches the task: use the organization theme for standard defaults, begin with a seed file when the presentation needs established structure, apply a named theme when that theme is available, or select a brand directly in PowerPoint. Frequently asked questions Do we need a sample slide for every layout? No. Prioritize representative examples across the slide types and specialized scenarios your organization actually uses. Can placeholder text tell Copilot what to generate? Not as semantic guidance. Placeholder type, position, and size inform layout; placeholder wording can influence styling but is not treated as an instruction. What happens when text does not fit? Copilot does not change the font size or placeholder size. It may add design elements. Review the result and simplify or split content where needed. Which template formats are supported? Both .pptx and .potx. Can instructional slides stay in the template? They can, when they use reusable layouts. However, keeping instructions separate reduces the risk of guidance appearing as presentation content. Can existing OAL assets be used? Yes. A Brand Kit can reference approved OAL assets. For PowerPoint Brand Kit selection, publish the kit rather than relying on the OAL alone. Why can a brand manager not create or publish an official kit? Check both permission controls. When creation restrictions are enabled, Enterprise Brand Manager rights alone are insufficient if the person is outside the permitted creation group. Also confirm that the person is a member, not only an owner, of the relevant group. Does selecting a kit update an existing presentation? No. Explicitly request or apply branding to existing slides. What should we check when assets are missing? Confirm that the kit is published, the expected assets are included, and referenced OAL content is accessible. Where appropriate, upload the assets directly into the kit. What most affects the quality of the output? The completeness of the kit and the quality of its template—especially representative sample slides, usable placeholders, and consistent theme settings. The bottom Line Microsoft 365 Copilot Brand Kits can make approved branding easier to use in everyday content creation. The strongest approach combines three things: a well-prepared kit, a well-designed template, and clear ownership. Start with a focused scenario, test realistic output, and refine the underlying assets and guidance. Human review remains essential, but a stronger starting point lets people spend less time correcting formatting and more time communicating clearly. References Create and manage official Brand kits in the Microsoft Copilot app | Microsoft Support Edit with Copilot in PowerPoint | Microsoft Support Use branded templates in the Microsoft Copilot app | Microsoft Support Enterprise brand manager policy setup | Microsoft Learn Set Up the Restrict Brand Kit Creation Policy in Microsoft Copilot | Microsoft Learn Keep your presentation on-brand with Copilot | Microsoft Support
From Teams Admin Center to Pro Management Portal: The Readiness Checks That Actually Matter
If you've managed Teams Rooms, Teams Phones, or Teams Panels for any length of time, you've probably noticed the steady shift towards the Teams Rooms Pro Management Portal (PMP). The deadline for this move from Teams Admin Center (TAC) to PMP is currently this month. October 2026. We're just waiting on the Android background for feature parity between the two portals. What started as a roadmap item earlier this year is now becoming reality. Android device management is moving out of Teams Admin Center (TAC) and into PMP, making PMP the primary management experience for Teams Rooms on Android, Teams Phones, Teams Panels, and SIP devices. At first glance, this looks like a portal migration, but I think that's the wrong way to think about it. The biggest risk isn't learning where Microsoft moved a button. The biggest risk is assuming a device is manageable because it can still join a meeting. Over the last few months I've spoken with customers managing hundreds, and sometimes thousands, of Teams devices. Very few were worried about the portal itself. Most were asking much more practical questions: Are all our devices actually ready? What happens to devices that have been offline for months? Do we need firewall changes? How do we know PMP is really working? What breaks if we miss something? Those are the questions worth focusing on. What Is Actually Changing? Microsoft is consolidating Teams Android device management into a single administration experience. For organisations today, that means inventory, health monitoring, update management, configuration management, and remote actions are increasingly moving into PMP. The affected devices include: Teams Rooms on Android Teams Phones Teams Panels SIP Phones For end users, very little changes (a recurring theme!). For the teams supporting hundreds or thousands of devices, quite a lot changes. Three things to check now 1. Check Admin Agent Versions Microsoft has introduced Admin Agent requirements as part of the PMP transition and unsupported versions may prevent devices from onboarding or communicating correctly with PMP. My recommendation is simple: don't plan around the minimum supported version. Plan around the latest supported version available for your platform. Also remember to check: Spare devices Devices in storage Rooms under refurbishment Recently factory-reset devices Those are usually the ones that cause surprises later. 2. Validate Network Connectivity The migration succeeds or fails based on connectivity. Review: Teams device networking requirements PMP connectivity requirements Microsoft 365 endpoints Firewall policies Proxy configuration TLS inspection policies One lesson I've learned repeatedly is that "reachable" doesn't necessarily mean "manageable". A device can happily join meetings while management traffic is being blocked somewhere else in the network path. Oh, and don't cherry pick the the IPs/URLs that you allow - this can cause pain later. Follow the recommendations. 3. Validate Permissions Before making PMP your primary management portal, make sure the right people can actually manage the estate. Validate that: Operations teams can manage devices Regional teams can see their assigned rooms Escalation teams have the access they need Don't wait until TAC functionality disappears to discover a permissions issue. The Gotchas We've Seen in the Field Most of the issues I've seen aren't portal issues. They're networking and operational issues that become visible once devices start relying on PMP. WebSocket Inspection One common mistake is validating HTTPS connectivity and assuming everything is ready. PMP relies on long-lived management connectivity. Devices can still sign in and join meetings while management communications are being disrupted elsewhere. Typical symptoms include: Devices repeatedly going online and offline Delayed health reporting Failed remote actions Stale inventory information If you're using TLS inspection, secure web gateways, or deep packet inspection technologies, test actual PMP functionality, not just connectivity. Proxy Authentication This continues to catch organisations out. Teams Rooms have limited support for proxy authentication. If your environment uses authenticated proxies, make sure Teams devices are appropriately exempted. NAT and PAT Pool Exhaustion This one surprises people. Nobody worries about NAT when they have ten devices. The conversation changes when they have a thousand. Large Teams estates create lots of long-lived outbound connections. When Teams Rooms, Teams Phones, VDI environments, and user devices all share centralised internet egress, source-port exhaustion can become a genuine operational issue. Warning signs include: Random onboarding failures Different behaviour across sites Intermittent disconnects Unexplained connectivity issues during busy periods Offline Devices Every migration looks healthy until somebody opens a cupboard. The devices most likely to cause problems are often: Spare phones Unused rooms Devices awaiting deployment Recently factory-reset systems Before declaring success, actively look for devices that aren't currently reporting. These are usually the last blockers discovered. What Good Looks Like Before declaring the migration complete, I'd want confidence that: Every supported Android device appears in PMP Health telemetry updates consistently Remote actions execute successfully Devices are running supported Admin Agent releases Required Microsoft endpoints are accessible WebSocket traffic is functioning correctly Proxy and firewall policies have been validated NAT/PAT capacity has been reviewed Administrators have the right permissions Operational runbooks reference PMP rather than TAC If you're there, you're probably ready. If you're only checking whether rooms can still join meetings, you're validating the user experience, you're not validating the management plane. Remember, they're not the same thing. Final Thoughts My advice is simple: stop thinking about this as a portal migration, treat it as an entire management-plane migration. For most organisations, the experience inside the room won't noticeably change. The experience for the people supporting hundreds or thousands of devices absolutely will. The customers that have the smoothest transition won't be the ones who learned PMP first. They'll be the ones who validated Admin Agent versions, networking, WebSocket behaviour, permissions, monitoring, and operational processes long before the final TAC management capabilities disappear. That's what readiness looks like. And that's where the real fun starts! Useful links PG Blog: https://learn.microsoft.com/en-us/microsoftteams/rooms/aboutunifieddevicemanagement-pmp1 M365 Roadmap: https://www.microsoft.com/en-gb/microsoft-365/roadmap?searchterms=555235 Teams Devices Network Security Requirements: https://learn.microsoft.com/en-us/microsoftteams/rooms/security?tabs=Android Our old friend Microsoft 365 URLs and IP Address Ranges: https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwideManaging SharePoint Online Version History at Scale to Recover Storage
Summay SharePoint Online version history is one of those features that users love, but admins eventually have to govern. Versioning protects users from accidental edits, bad changes, and overwritten content. It gives people a way to restore previous versions of documents without opening a ticket. That is a good thing. But at tenant scale, version history can also consume a surprising amount of storage. Highly active libraries, large Office files, frequent edits, migrations, sync activity, and years of retained versions can quietly add up. Eventually, admins need to answer a few practical questions: How many file versions do we have? How much storage are those versions consuming? Which sites would benefit most from cleanup? What policy should we apply going forward? How much space could we recover before making changes? How do we clean up versions safely across many sites? That is why I built this tool: SPOVersions-ApplicationTools The main script is: Apply-SPOVersions-Tool.ps1 Why version history planning matters Microsoft's official guidance for SharePoint version storage makes an important point: version limits should support your organization's recovery objectives while also controlling storage consumption. Microsoft documents this here: Plan version storage for document libraries in SharePoint The key idea is balance. If you keep too many versions for too long, storage consumption can grow quickly. If you trim too aggressively, users may lose the ability to recover from accidental or unwanted changes. A good version history strategy needs to consider both: Goal Why it matters Recovery Users need enough version history to restore useful prior versions. Storage control Admins need to prevent version history from consuming excessive quota. Consistency Tenant defaults and site-level policies should be understandable and repeatable. Exceptions Some business areas may need different version retention behavior. Safe cleanup Existing versions should be analyzed before deletion jobs are created. The goal is not simply to delete versions. The goal is to understand version storage, set the right policy, and clean up intentionally. What Microsoft recommends admins consider Microsoft's documentation calls out three major planning questions: Determine the default version history limits for new document libraries. Identify exceptions needed from organization default limits. Decide whether existing content should be updated to align with the organization limits. That third point is where many admins need tooling. It is one thing to configure a tenant default for new libraries. It is another thing to understand what already exists across hundreds or thousands of sites. Existing content is often where the storage opportunity is. Automatic vs. manual version limits SharePoint provides different ways to manage version history. Mode What it does Best fit Automatic SharePoint uses intelligent trimming based on version age. Recent versions are preserved more densely, while older versions are thinned over time. Recommended default for many organizations that want Microsoft-managed optimization. Manual with count and expiration Admins specify how many major versions to keep and how long versions should remain. Useful when you want more direct control and predictable cleanup. Manual with count only Admins keep a configured number of versions without age-based expiration. Useful when a fixed restore count matters, but it can consume more storage. Microsoft's guidance highlights that automatic trimming is designed to preserve high-value versions while optimizing storage. Manual policies can be useful, but they require careful planning because low limits or short expiration windows can affect restore scenarios. That is why I wanted this tool to include reporting and What-If analysis before cleanup. What the tool does Apply-SPOVersions-Tool.ps1 is an interactive PowerShell tool built with PnP PowerShell to help admins manage SharePoint Online version policies across multiple site collections. At a high level, the tool helps admins: Audit current version policies across sites. Apply automatic or manual version limits. Review version policy status. Generate version history reports. Run What-If analysis to estimate storage recovery. Create batch delete jobs for cleanup. Monitor cleanup job status. Set tenant-level defaults for new sites. This makes it useful for both planning and implementation. Why I built it as an admin workflow Version cleanup should not start with deletion. The safer workflow is: Discover current settings. Generate version history reports. Estimate storage recovery. Decide the right policy. Apply policy to selected sites. Queue cleanup jobs. Monitor job status. Repeat as part of governance. That is how the tool is structured. It is not just a cleanup script. It is a planning and execution tool. Site discovery options The tool can work from a defined list of site URLs or discover sites automatically. For larger tenants, I usually prefer a site list because it gives admins better control over rollout scope. You can start with a pilot group, validate results, then expand. For smaller tenants or discovery scenarios, auto-discovery can be useful. The tool supports: SharePoint sites OneDrive for Business sites Exclusion of common system sites Confirmation before processing discovered sites That confirmation step matters. When a script can operate across many sites, admins should have a checkpoint before changes are made. Key operations: Get current version policies Before changing anything, admins can retrieve current version policy settings for all selected sites. This helps answer: Which sites already use automatic trimming? Which sites use manual limits? Which sites have inconsistent settings? Which sites may need exceptions? This is useful for building a baseline. Set version policies across sites After planning, admins can apply version policies across site collections. The tool supports: Automatic version trimming Manual major version limits Optional expiration after a specified number of days Automatic trimming is useful when you want SharePoint to optimize storage intelligently. Manual limits are useful when the organization has a defined policy, such as keeping a specific number of major versions or expiring versions after a specific period. Check version policy status Policy changes may take time to apply. The tool can check propagation status, so admins can verify whether pending changes are completed successfully. This is important during staged rollouts because you want to confirm policy state before moving on to cleanup. Generate version history reports This is one of the most important parts of the workflow. The tool can submit version history report jobs for each site. Those reports are written to a dedicated document library created by the tool: Admin_SiteCollection_VersionReport_DONOTDELETE Using a dedicated library avoids some of the issues that can happen when report files are written into normal user-facing document libraries. The reports provide the raw data needed to understand version storage usage. Run What-If analysis This is the feature I think most admins should start with. The What-If analysis downloads completed version history reports and simulates a version policy without making changes. That means admins can estimate: Total versions analyzed Versions that would be deleted Total version storage Storage that could be recovered Percent of version storage that could be freed Per-site savings This gives admins data before they commit to a cleanup policy. For example, a What-If analysis might show that one site can recover a large amount of storage while another site has very little benefit. That helps prioritize action. Create batchdeletejobs Once the admin understands the impact and chooses a policy, the tool can create batch delete jobs to remove excess versions. This is the destructive part of the workflow, so it should come after reporting and What-If analysis. Admins can use automatic or manual cleanup criteria depending on the desired policy. Important reminder: deleted versions are not recovered from the Recycle Bin. Treat batch delete jobs as permanent cleanup operations. Monitor batchdeletejob status After cleanup jobs are created, admins need to know whether they completed and how much storage was released. The tool can check batch delete job status across sites, including completion state and storage released where available. This closes the loop from planning to execution. Tenant-level defaults vs. existing content One important distinction in SharePoint version management is the difference between tenant-level defaults and existing content. Tenant-level settings affect new sites or new libraries going forward. Existing sites and existing file versions may need additional steps. Microsoft's guidance describes multiple approaches: Scenario What it means Apply defaults to new libraries only Least disruptive; existing settings and versions remain unchanged. Update existing library settings without trimming versions Future versions follow the new policy, but existing versions are not deleted. Update settings and trim existing versions Aligns current and future behavior but requires careful planning and cleanup jobs. This tool helps with the third scenario, where admins need to understand and manage existing version storage across sites. A practical rollout approach For most tenants, I would not recommend starting with the entire environment. A safer rollout looks like this: Phase Action Phase 1: Baseline Get current version policies across a small set of sites. Phase 2: Report Generate version history reports for pilot sites. Phase 3: What-If Estimate storage recovery under automatic or manual policies. Phase 4: Decide Choose default policy and identify exceptions. Phase 5: Apply Apply policy to selected pilot sites. Phase 6: Cleanup Queue batch delete jobs only after review. Phase 7: Monitor Check job status and storage released. Phase 8: Expand Repeat across additional sites or workloads. This creates a defensible admin process instead of a one-time cleanup event. Where this helps most This tool is especially useful in tenants with: Large document libraries Heavy collaboration sites Long-running project sites Migration history Large Office files with frequent edits Storage pressure Inconsistent site-level version policies Need for tenant-wide governance reporting It can also help organizations that want to move toward automatic trimming but need to understand the impact first. Permissions and prerequisites The tool uses PnP PowerShell and interactive authentication. Typical prerequisites include: PowerShell 5.1 or later PnP.PowerShell 3.1.0 or later SharePoint Administrator role Entra ID app registration Delegated SharePoint permissions required for version policy and report operations Important: Ensure that the account running this tool has site collection admin rights on all sites If you need to add your Admin account to all OneDrive and SPO sites, check out this scripts: Add-GroupToSPOSites.ps1 Add-GroupToOneDriveSites.ps1 The repository README includes setup details and permission guidance: Apply-SPOVersions-Tool README As always, review permissions carefully before using any tenant-wide admin automation. Safety notes Version cleanup can permanently remove version history. Before creating cleanup jobs: Run reports first. Run What-If analysis. Start with pilot sites. Review business requirements. Identify exceptions. Communicate expected behavior to site owners. Keep exported results for audit and planning. Avoid opening or modifying report CSV files while report jobs are still running. The tool is designed to support safe planning, but admins still need to make policy decisions carefully. Why this belongs in your governance toolkit SharePoint storage management is not just about quota. Version history touches: User recovery expectations Records and retention requirements Collaboration patterns Site lifecycle Migration cleanup Storage forecasting Governance consistency If version history is unmanaged, storage growth can feel mysterious. Once you report on it, it becomes something you can plan and control. That is the point of this tool: help admins move from guessing to measuring, then from measuring to controlled action. Final thoughts SharePoint version history is valuable, but it needs governance at scale. Microsoft provides flexible version storage options, including automatic trimming and manual limits. The challenge for admins is understanding what exists today and how much storage could be recovered before applying changes. Apply-SPOVersions-Tool.ps1 helps with that process by combining policy discovery, report generation, What-If analysis, policy application, cleanup jobs, and job monitoring into a single admin workflow. More Information You can find the tool here: SPOVersions-ApplicationTools Microsoft's official planning guidance is here: Plan version storage for document libraries in SharePoint Suggested Reading for More Information: SharePoint Automatic Version History Cleanup (Intelligent Versioning)The new sharing experience is coming to SharePoint Online: What admins need to know
Microsoft 365 is introducing a simpler sharing experience centered around a reusable hero link. Here’s what SharePoint Online and Microsoft 365 admins should know about the new interface, key behavior changes, rollout preparation, and end-user communications.VDI, Teams, and what’s changing in 2026: VBSS becomes VMSS, and eCDN lands in the core license
Audience: Mission Critical customers running Microsoft Teams on virtualized desktop platforms (Citrix, AVD, Windows 365, VMware/Omnissa Horizon). TL;DR: Two Teams-on-VDI changes are converging: VMSS is already in Public Preview today as the successor to VBSS in the new VDI solution for Teams (Microsoft Learn - Screen sharing), and Microsoft eCDN is now included in Teams core license. This post previews the guidance our Support for Mission Critical (SfMC) Cloud Solution Architects (CSAs) are already walking customers through - because the cost of finding these issues in production is always higher than finding them in a pilot. Why we’re flagging this now SfMC exists to get ahead of changes like these. The SfMC CSA role is built on a simple principle: be a trusted advisor embedded alongside the customer team, not a reactive support line. SfMC CSAs work hand-in-hand with platform, network, security and service-ownership teams to build a deep “know-me” picture of the customer - their gold-image strategy, their VDI vendors, their peering topology, their CAB cadence, the history of what was tried and what didn’t stick. That context is the reason a readiness review lands in weeks, not months: your SfMC CSA isn’t starting from zero, they’re starting from knowing the estate. Goodbye VBSS, hello VMSS - and it’s here now Teams on VDI has used Video Based Screen Sharing (VBSS) for years - an efficient, encoded video stream for screen shares. That approach is being replaced by Virtual Machine Screen Sharing (VMSS) as part of Microsoft’s New VDI solution for Teams. This isn’t a future roadmap item - VMSS is available in Public Preview today across Azure Virtual Desktop, Windows 365, Citrix and Amazon WorkSpaces, with Omnissa following. Microsoft’s guidance and support matrix is live on Microsoft Learn: New VDI solution for Teams - Screen sharing. If you have users on a pilot ring on VDI, you can light this up now, simply by activating Public Preview for them. Support depends on three things moving together: the Teams client on the session host, the virtualization vendor’s optimization component (Citrix HDX / AVD Multimedia Redirection / VMware-Omnissa Media Optimization), and the endpoint client (Windows App, Citrix Workspace App, Horizon Client). Where any one of those lags, screen share quietly falls back to a lesser modality - users don’t raise tickets, they just tolerate worse quality. Because VMSS is already in preview, there’s a real window to get this right before it becomes the default path. On Mission Critical engagements, SfMC CSAs are already sitting with customer teams on VMSS readiness reviews: confirming client and plugin versions across the gold-image estate, rebuilding CQD dashboards so the baseline survives the cutover, and flagging any inline network appliance that still assumes the old VBSS flow. The “know-me” picture the SfMC CSA has built up makes that work fast - they already know which plugin versions the desktop team is running and which CAB window the next image refresh lands in. Microsoft eCDN is now in the core Teams license Microsoft eCDN - previously a paid add-on - is now included in the Microsoft Teams core license. It’s a WebRTC-based peer-to-peer mesh that offloads large-scale town halls and live events from the corporate WAN by peering video between clients on the same site. If the business case for the add-on never cleared, that objection is gone. But “included” doesn’t mean “working”. The failure mode we see is consistent: customers enable eCDN because “it’s free now”, but the peering never works - because the client-to-client path is blocked by security controls nobody remembers adding. The town hall runs, the WAN still saturates, the CIO asks why the thing that was supposed to fix it didn’t. The VDI infrastructure question Both changes elevate something that has always mattered but rarely been tested: VDI-to-VDI network reachability. The new Teams client needs to talk to Microsoft 365 media endpoints (usually already open) and to other VDI instances on the same site for eCDN peering. That second requirement is where customers are consistently caught out. Most VDI builds treat each session host as an island - east-west traffic between session hosts is blocked by NSG, hypervisor firewall, or micro-segmentation policy, because it was never needed. With eCDN in the box, it is now needed - and the blocks are often in places the virtualization team doesn’t own. This is where working hand-in-hand with the customer team pays off. The SfMC CSA convenes the platform, network, and security owners, translates the platform change into each team’s language, and makes sure nothing falls through the gaps between them. The specific hostnames, IP ranges, UDP/TCP port requirements, and peering-group configuration are all on Microsoft Learn (links below) - the hard work is operationalizing them against your estate, and that’s the work your SfMC CSA is built to drive. If two or more of these apply to your estate, book the conversation with your SfMC CSA now: Client version sprawl - multiple Teams versions in flight across gold images, or a long tail of unpatched Citrix Workspace App / Windows App / Horizon Client. Missing or partial CQD data - gaps in building/subnet mapping, “unknown” network location for a meaningful share of streams, dashboards still filtered on legacy VBSS modality tags. Recent east-west firewall changes - new micro-segmentation rollout, zero-trust project, or NSG rule consolidation in the last 12 months. Recent live-event pain - WAN saturation, buffering, or join failures on the last town hall. No eCDN subnet map, or a map that predates your current site/subnet topology. Proxy or TLS-inspection changes forcing Teams media through an inspection device rather than bypassing it. VPN full-tunnel without eCDN VPN exclusion. Upcoming large broadcast in the next 90 days. Closing thought VMSS is in Public Preview today and eCDN is already in your Teams license. The window to pilot, validate and harden is open right now - and it closes the moment either of these becomes the default path for your users. That’s what Support for Mission Critical is built for: Cloud Solution Architects working shoulder-to-shoulder with your team as trusted advisors, investing the time to genuinely know your estate - your platforms, your people, your change windows, your risks - so that when a shift like VMSS or eCDN arrives, the remediation plan is already half-written. Not a ticket-shop. A partnership. If you’re running Teams on VDI at scale and you haven’t had the VMSS + eCDN conversation with your SfMC CSA yet - that’s the next call to book. References New VDI solution for Teams - Screen sharing (VMSS, Public Preview) - https://learn.microsoft.com/en-us/microsoftteams/vdi-2#screen-sharing New VDI solution for Teams (overview) - https://learn.microsoft.com/en-us/microsoftteams/vdi-2 Microsoft Teams for VDI - install requirements - https://learn.microsoft.com/en-us/microsoftteams/teams-client-vdi-requirements-deploy Microsoft eCDN networking requirements - https://learn.microsoft.com/en-us/ecdn/technical-documentation/network-requirements eCDN peering groups and restrictions - https://learn.microsoft.com/en-us/ecdn/how-to/set-up-peering-groups Microsoft 365 URLs and IP address ranges - https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-rangesEnterprise Security Assessment: A Strategic Lens for Mission Critical Environments
Understanding Enterprise Security at Scale Understanding security posture at scale requires more than isolated control reviews or point‑in‑time assessments. The Enterprise Security Assessment (ESA) helps organizations understand their security posture across Azure, Microsoft 365, and hybrid environments from a true enterprise perspective. Instead of assessing individual services or workloads in isolation, ESA provides a single, enterprise‑wide view of security. By examining identity, data security, endpoints, threat protection, and cloud infrastructure together, ESA helps uncover gaps that often span multiple teams and platforms. This broader perspective enables clearer prioritization, stronger alignment across security teams, and a more resilient foundation for long‑term security improvement. ESA complements other Microsoft assessments, such as workload‑specific reviews, by connecting the bigger picture - to align security priorities across teams and platforms, fostering a more cohesive and resilient security approach. From Standard Engagement to Strategic Partnership An Enterprise Security Assessment is typically delivered as a focused engagement designed to establish an enterprise‑wide view of security posture. At Microsoft, we begin by reviewing Secure Score insights, analyzing a defined set of core security datasets, and correlating those signals across Azure and Microsoft 365. For many organizations, this approach works well. Collecting and evaluating these datasets provides a high‑level understanding of security posture, highlights common gaps, and identifies priority improvement areas. In standard enterprise environments, ESA delivers actionable insights with minimal disruption and sets a solid foundation for security improvements. How ESA Evolves in Mission‑Critical Environments In large or mission‑critical environments, security is often distributed across multiple teams and tools. Operational constraints, regulatory requirements, and business dependencies introduce complexity that standard assessments cannot fully capture. For mission‑critical customers, ESA goes beyond a baseline review and becomes more consultative. This typically includes: 📝 Structured discovery sessions across multiple security domains 🤝 Deep‑dive workshops with specialized teams 🎯 Validation of findings against real‑world operating models 🔄 Iterative analysis to validate findings against real operational conditions This ensures recommendations reflect how security is actually managed, not just how it is documented. Why Going Deeper Matters to Customers For organizations operating at scale, this consultative ESA approach delivers significantly more than a standard readout: A realistic, enterprise‑wide understanding of security posture, grounded in actual configurations and operating models Clear visibility into cross‑team dependencies and systemic risks Prioritized recommendations aligned to existing licenses, third‑party tools, and regulatory requirements A realistic, phased security roadmap focused on adoption, not theory The result is a clear starting point for security improvements that teams can execute with confidence. A Continuous Improvement Model ESA is not a one‑time exercise. For most customers, it becomes the foundation for ongoing security maturity. Once a baseline is established, future ESAs are faster and more efficient, allowing organizations to track progress, validate improvements, and maintain alignment as environments evolve. Over time, ESA functions as an annual enterprise security health check, supported by follow‑up reviews and continuous improvement. In mission‑critical environments, this means: The first ESA requires deeper engagement investment Building cross-team alignment takes time Future assessments become smoother and more efficient once a baseline is established Over time, ESA functions as an enterprise security health check that supports continuous improvement. It works best when treated as a starting point for continuous improvement, and Enterprise Security Alignment. What Customers Gain from an Enterprise Security Assessment A true enterprise view Visibility across identity, data, devices, cloud workloads, and threat signals - without losing sight of critical details. A customized security roadmap Recommendations aligned to existing licenses, third‑party tools, hybrid footprints, and regulatory requirements - making adoption realistic, not aspirational. Momentum and measurability Many organizations track progress using dashboards or scorecards to measure improvement and sustain focus over time. Repeatability Once a baseline is established, future ESAs become easier and more efficient - serving as a regular health check rather than a brand‑new effort. A consultative model ESA delivers far more value than a one‑time assessment by fostering collaboration, shared understanding, and long‑term alignment. A Foundation for Continuous Improvement Enterprise security is complex, especially at scale. In mission‑critical environments, security success depends on embracing complexity, aligning teams, and moving beyond a standard assessment playbook. An Enterprise Security Assessment is more than a snapshot. It’s an opportunity to build alignment, inform strategy, and create a resilient security foundation that evolves with the organization.
