When the Admin Center Becomes a Liability
A financial services client we support had a compliance audit scheduled for Q3. Their Teams environment had grown from a pandemic-era rollout of 200 users to a production-critical platform for 1,800 employees across three countries. The auditors wanted evidence of retention policies, communication monitoring, and a defensible audit trail for every file shared over the past 24 months. The admin center had given them Teams, but nobody had governed it. That gap is exactly what this article addresses.
Microsoft Teams administration sits at the intersection of IT management, legal compliance, and security operations. Getting the deployment running is the easy part. What most organizations underestimate is the operational layer — the policies, audit configurations, and PowerShell automation — that determines whether Teams works for the business or against it when regulators come knocking.
The Split Between Admin Center and PowerShell
The Microsoft 365 Admin Center gives you a capable interface for day-to-day Teams management: user licenses, group memberships, service configurations, and basic security settings. For a 50-person organization, that is often enough. For anything larger, or for environments with compliance obligations, you will eventually hit the ceiling of what the GUI can express.
PowerShell fills that gap. The Microsoft Teams PowerShell module and the Security and Compliance Center cmdlets give you programmatic control over configurations that the admin center either exposes poorly or does not expose at all. If you are managing Teams at scale — multiple regions, regulated industries, or complex permission structures — PowerShell is not optional. It is the actual control plane. Analyst guidance from Gartner consistently positions automation and policy-as-code as critical capabilities for managing collaboration platforms at enterprise scale, and Teams is no exception.
The migration from Skype for Business Online to Teams also changed the administration model significantly. Many organizations that inherited their Teams deployment from that transition are still using governance patterns designed for a different product. Relearning the administration layer from first principles is worth the investment.
Understanding the Unified Audit Log
One of the most underutilized tools in Microsoft Teams administration is the Unified Audit Log, accessible through the Microsoft Purview compliance portal. The activity coverage is extensive: file and page activities, folder operations, SharePoint list changes, sharing and access requests, synchronization events, site permissions, site administration, Exchange mailbox actions, and a full category of Teams-specific activities. Each of those categories contains granular sub-activities with individual event records, giving you a detailed transaction history of your collaboration environment.
In practice, this means that when a user shares a file in a Teams channel, accesses a document from SharePoint, or adds a guest to a meeting, there is a log entry. The question is whether your organization has audit logging turned on and whether anyone is reading those logs. For the financial services client referenced earlier, audit logging had never been explicitly enabled post-migration. Enabling it revealed a 14-month gap in audit coverage — a material problem when auditors were requesting 24 months of evidence.
Audit logging is also a hard prerequisite for several downstream governance capabilities, including Information Barriers. If it is not active, you are operating without a safety net. Reference: Microsoft Learn — Enable audit log search.
Retention Policies: What Legal Actually Needs
Most Teams deployments have no retention policy. Messages accumulate indefinitely, chats pile up, and when Legal asks how long Teams communications are being kept, the answer is effectively: forever, by accident. That is not a policy — it is an absence of one, and absence creates exposure.
The Security and Compliance Center PowerShell module includes Teams-specific retention cmdlets that give you precise control over both channel messages and chat threads. No default policies are created when you provision a new Microsoft 365 tenant. You are starting from zero regardless of when the tenant was provisioned, which means someone has to make an explicit decision about retention scope and duration.
Building Teams Retention Policies with PowerShell
Creating a retention policy for Teams requires two objects: a policy and a rule. The policy defines scope — which teams and users are covered. The rule defines behavior — keep, delete, or keep-then-delete, and for how long.
Here is a regulation-aligned example targeting specific teams and individual chat participants:
New-TeamsRetentionCompliancePolicy `
-Name "Teams - Regulation 123 Compliance" `
-TeamsChannelLocation "Engineering Team", "UX Design Team" `
-TeamsChatLocation "[email protected]", "[email protected]"
Once the policy object exists, attach a rule that defines retention behavior. For a seven-year legal hold — common in financial services and healthcare — the command looks like this:
New-TeamsRetentionComplianceRule `
-Name "Seven Years All Teams / Channels" `
-Policy "All Teams / Channels Retention" `
-RetentionComplianceAction KeepAndDelete `
-RetentionDuration 2555
The RetentionDuration parameter is in days, so 2555 maps to seven years. For indefinite holds — active litigation, regulatory freeze, or compliance holds — use -RetentionDuration Unlimited paired with -RetentionComplianceAction Keep. One important caveat: Teams chat messages can take up to 24 hours to fully process under a newly applied policy. Never assume same-day retroactive coverage, and communicate that window explicitly to Legal and compliance stakeholders before policy go-live.
Information Barriers: Separating Teams That Shouldn’t Talk
Information Barriers address a specific governance problem: preventing communication between groups that must stay separated for regulatory, legal, or ethical reasons. Investment banking and research analysis teams are the textbook example. In an ungoverned Teams environment, nothing technically prevents a thread between those groups from forming — and that is a regulatory exposure, not just a policy violation.
Enabling Information Barriers has a documented prerequisite checklist, and skipping any item on it will cause the configuration to fail silently or behave unpredictably. The key requirements include:
- Active Directory attribute replication must be functioning correctly — any attribute used as a filter must be syncing cleanly to your tenant
- Scoped Directory Search must be configured in Teams
- Audit logging must be active (see above)
- Exchange Online Address Book Policies must be removed prior to enabling barriers — this is a hard dependency that many organizations miss because ABPs are often set during an on-premises migration and never revisited
- Both the Security and Compliance Center PowerShell module and Azure PowerShell must be installed
- Administrative consent must be granted following Microsoft’s documented process
The Address Book Policy requirement is the one that catches most environments off guard. ABPs have existed in Exchange for years and frequently survive tenant migrations intact. If your organization falls into that category, the pattern of inherited policy debt creating downstream compliance failures is one we have documented in other contexts — see the Windows Group Policy incident post-mortem for a detailed walkthrough of how unreviewed legacy policy objects surface as production incidents. Reference: Microsoft Learn — Information barriers in Teams.
Communication Compliance: Monitoring Without Overreach
What was previously called Supervision in the Security and Compliance Center has been rebranded and relocated to the Microsoft Purview Compliance Center as Communication Compliance. The scope has expanded — it now covers Teams chats, channel messages, and Exchange Online communications under a unified policy framework, with updated tooling for reviewer workflows and policy management.
We deployed Communication Compliance for a managed services client in the legal sector where external client communications over Teams needed to be reviewable by a designated compliance officer, without granting that officer access to individual mailboxes or IT-level permissions. The separation of duties that Communication Compliance enforces by design — where role assignments in the compliance portal are distinct from IT admin roles — is actually the right architecture for this problem.
One thing worth stating directly: access to the Communication Compliance section requires specific role assignments, not just global admin. This is deliberate. The person managing IT infrastructure should not automatically have visibility into monitored communications. Getting those role assignments configured before you need them — rather than scrambling during an incident — is the kind of access control discipline that the Zero Trust Architecture deployment walkthrough covers in detail.
Three Administration Patterns, One Decision Framework
After working across environments ranging from 50-seat professional services firms to multi-region enterprise deployments, Teams administration usually settles into one of three patterns:
| Pattern | Tooling | Best For | Governance Risk |
|---|---|---|---|
| Admin Center Only | GUI, manual | Sub-100 users, no compliance requirements | High — no auditability |
| Hybrid (GUI + PowerShell scripts) | Mix of both | Mid-market, some compliance exposure | Medium — depends on documentation quality |
| PowerShell-Driven | Scripts, pipelines, version-controlled configs | Regulated industries, multi-tenant | Low — when scripts are reviewed and stored in source control |
The direct opinion: organizations that rely entirely on the Admin Center are making an implicit decision to accept governance debt. That debt is invisible until an audit, a security event, or a legal discovery request makes it visible — usually at the worst possible time. The cost of moving to a scripted, auditable administration model is front-loaded but small compared to the cost of reconstructing governance evidence after the fact.
The Practical Takeaway
Start with audit logging. It costs nothing and it enables everything else downstream. If it is not already active in your tenant, enable it today and schedule a review of retention policy coverage within 30 days. From there, work backward from your organization’s actual retention requirements: ask Legal what they need before you configure what the technology can deliver. The PowerShell cmdlets exist to express whatever policy Legal defines — the gap is almost never the tooling.
For organizations in regulated industries — financial services, healthcare, legal — Information Barriers and Communication Compliance are not optional features. They are the difference between a defensible governance posture and a material exposure. Getting the prerequisites right before enabling them is always cheaper than unwinding a misconfigured deployment.
If you are managing a Teams environment that has outgrown its original governance model, or inheriting a tenant that was never properly governed, the Digital Forensics for Incident Response field guide covers the audit trail reconstruction techniques that often become necessary when governance gaps surface late. And if you would like help assessing your current Teams administration posture or designing a compliance-aligned configuration from scratch, reach out to the SSE team directly.


