What it does

The Teams update policy (TeamsUpdateManagementPolicy) decides which users see Teams preview features ahead of general release, and suppresses some in-product messaging. Client updates themselves are Microsoft-managed: the new Teams client updates itself on a twice-monthly cadence, and admins mostly control who gets early features, not when the build installs.

Key facts

• Teams client updates ship roughly twice a month after internal and TAP validation, with critical fixes outside that schedule. Rollout is gradual across the world.
• The client checks for updates on start-up and every few hours, downloads deltas, and needs a restart to apply. On Windows it relies on Delivery Optimization (not set to mode 100) and a signed-in user; on Mac it uses Microsoft AutoUpdate (MAU).
• Clients 1–3 months old get an in-app prompt to update. Beyond three months, users hit a blocking page offering update now, contact IT, or continue in Teams on the web.
• The update policy's "Show Teams preview features" setting has four values: On for users in Current Channel (Preview) — the default; Users can opt in; Off; and On for everyone.
• In PowerShell that's Set-CsTeamsUpdateManagementPolicy -AllowPublicPreview with FollowOfficePreview, Enabled, Disabled or Forced. -AllowPrivatePreview takes Disabled, Enabled or Forced for tenants in a private preview programme.
• With opt-in allowed, users turn it on under Settings > About Teams > Early access > Public preview.
• Microsoft 365 Targeted Release isn't affected by this policy. Targeted Release controls Microsoft 365 feature rollout separately; Teams preview is its own switch.
• Public preview isn't supported in GCC, and preview features are unsupported and subject to change.
• Teams Rooms on Windows has preview off by default; it's turned on per device through the XML config (<EnablePublicPreview>True</EnablePublicPreview>), and Microsoft suggests limiting it to 5–10 devices.
• -DisabledInProductMessages can switch off specific in-product message categories, such as What's New. -BlockLegacyAuthorization forces clients to enforce session revocation for messaging, calling and meetings.
• The UseNewTeamsClient parameter is left over from the classic-to-new migration. Teams classic is retired, so it no longer plays a role in rollout planning.

When to use / skip

Every client should have a small, deliberate preview ring: IT, the Teams champions and a few business volunteers on "On for everyone" or opt-in through a dedicated update policy, with everyone else on Off. That gives you a few weeks' warning of UI changes and new defaults before the service desk gets the calls. The default — tying preview to Office Current Channel (Preview) — only makes sense if the client already runs an Office preview ring with the same people; often they don't, and the default then either does nothing or catches a random group.

What you can't do is hold the Teams build back. There's no deferral in the new client the way there is for Microsoft 365 Apps channels, so change management has to rely on the preview ring, Message center, and the roadmap — not on delaying updates.

Configuration decisions

• Global update policy setting: usually Off, unless the client is happy for preview to follow Office Current Channel (Preview).
• A named preview policy (for example "Teams Early Adopters") set to On for everyone or Users can opt in, assigned by group to the pilot population.
• Whether pilot users can opt out (opt in) or are forced into preview (On for everyone) — forced gives you consistent feedback, opt-in is kinder.
• Which Teams Rooms devices, if any, run public preview. One or two test rooms is plenty.
• Whether to suppress in-product What's New messaging when the client runs its own adoption comms.
• How Message center posts for Teams are triaged and fed into the preview group's testing.

Gotchas

• Targeted Release in the Microsoft 365 admin center doesn't give users Teams preview features. Clients assume it does; it's a separate setting.
• The default policy value follows Office Current Channel (Preview), so users on that Office channel are silently in Teams preview with no opt-out. Check this before a support team wonders why a few users have different menus.
• SSL inspection on Microsoft 365 endpoints and disabled Delivery Optimization are the usual reasons the client falls behind. Fix the network path rather than repackaging Teams.
• Modifying files in the Teams MSIX package corrupts the install and breaks updates. Customise through policy, not by editing the package.
• Mac update failures are almost always MAU — not installed, blocked, or misconfigured preferences.
• VDI follows its own install and update guidance. Don't apply the desktop update assumptions to a VDI estate without checking the VDI docs.

Consultant notes

• Create the preview update policy and group in week one of any Teams engagement; it's cheap and pays back the first time Microsoft changes the UI.
• Pair the preview ring with a channel or form where pilot users report changes, otherwise preview just means early confusion.
• Add "client version older than X" to the client's device reporting so stale clients show up before users hit the three-month blocking page.
• For Teams Rooms, keep production rooms off preview — a preview build failing in the boardroom does more harm than any feature is worth.
• Revisit the policy after Microsoft retires parameters; the cmdlet carries several legacy switches that are easy to misread in an existing tenant.

---

Worth revisiting if Microsoft adds an update deferral option to the new Teams client or changes the preview defaults