What it does

The MicrosoftTeams module from the PowerShell Gallery — the one module for Teams policy, voice, team and tenant configuration since the old Skype for Business Online Connector was folded into it. Anything the Teams admin center can do it can usually do, plus a fair bit the admin center can't.

Key facts

• Supported hosts are Windows PowerShell 5.1 or PowerShell 7.2 and later. From module 6.3.0 onwards, those are the only supported versions. .NET Framework 4.7.2 or later is required on Windows.
• Install with Install-Module -Name MicrosoftTeams -Force -AllowClobber (update PowerShellGet first on older builds). Update with Update-Module MicrosoftTeams; remove old versions with Uninstall-Module MicrosoftTeams -AllVersions.
• Update-Module fails if the module is already imported in the session. Close it and open a fresh elevated session.
• Sign in with Connect-MicrosoftTeams. From 7.9.0 (July 2026) it authenticates through Web Account Manager (WAM) on Windows; a -DisableWAM switch exists for hosts where that causes problems.
• Current release at time of writing is 8.0.0 (September 2026). Preview builds are published alongside GA builds with a -preview suffix.
• Breaking changes do happen between major versions: 7.9.0 removed the Teams Shifts Connection cmdlets entirely; 8.0.0 made RecordingEnabled, TranscriptionEnabled and AgentViewPermission mandatory on New-CsAutoRecordingTemplate; 7.0.0 onwards removed several deprecated federation and external access parameters.
• The Skype for Business Online Connector functionality was merged into the module back in 1.1.6 (September 2020). Any script still calling New-CsOnlineSession is long dead.
• Policy cmdlets follow a pattern: New-/Set-/Get-Cs<PolicyType> to manage a policy, Grant-Cs<PolicyType> to assign it to a user, group (-Group with -Rank) or the tenant (-Global).
• Bulk work goes through New-CsBatchPolicyAssignmentOperation (up to 5,000 users per batch) rather than looping Grant- cmdlets.
• Offline installation is supported via the manual download route from the PowerShell Gallery for locked-down admin hosts.

When to use / skip

You need it. Any Teams Phone deployment, any group policy assignment design with ranking, any bulk change, and any repeatable build — the admin center is fine for looking and for one-offs, but a tenant you can't rebuild from script is a tenant you can't audit. Voice config in particular (dial plans, voice routing, PSTN usages, resource accounts) is far quicker and less error-prone in PowerShell.

Where you can skip it: small tenants with a couple of policies and no Teams Phone. Equally, team and channel content operations (membership at scale, channel creation) are often better done through Microsoft Graph, which handles throttling and app-only auth more cleanly for automation.

Configuration decisions

• Where admin scripts run: admin workstations, a jump host, or an Azure Automation / Functions runbook. Unattended runs need app-based or managed-identity auth rather than an interactive admin sign-in.
• Which module version to pin. For production automation, pin a known-good GA version and upgrade deliberately; don't run -preview builds in scheduled jobs.
• Which admin roles the scripting account holds — Teams Administrator covers most things; Teams Communications Administrator is enough for voice-only work. Avoid running everything as Global Administrator.
• Whether config is held as code (policy definitions in source control, applied by script) or the admin center stays the source of truth with scripts for bulk only.
• How you'll capture a baseline export of all Get-Cs*Policy output before and after a project, for change evidence.

Gotchas

• Major version bumps break scripts. Read the release notes before letting Update-Module loose on a runbook host — the Shifts Connection removal in 7.9.0 broke anyone still calling those cmdlets.
• The WAM change in 7.9.0 altered the sign-in experience. If an interactive login suddenly behaves differently on a jump host or in a remote session, try -DisableWAM before chasing conditional access.
• Several versions installed side by side means you may not be importing the one you think. Check Get-Module MicrosoftTeams -ListAvailable and clean up old versions.
• The module talks to a back end that replicates; a Set- followed immediately by a Get- can show the old value. Allow for it in scripts that validate their own work.
• UPN versus SIP address: some cmdlets, notably batch assignment, need the identifier to match the SIP address. Mismatched UPN and SIP domains in hybrid or migrated tenants bite here.
• Parameter names occasionally change or get removed between versions (the 7.x federation clean-up is the obvious example). Scripts copied from old blog posts are a common source of errors.

Consultant notes

• Start every engagement with a full read-only export of the client's Teams policies and voice config. It costs ten minutes and saves arguments later about what was there before you touched it.
• Keep a module version note in every handover doc alongside the scripts.
• For tenant-to-tenant migrations, script the source tenant's policy configuration out first and rebuild it in the target from that export; there's no native policy copy between tenants, and policy GUIDs won't carry over.
• Use PowerShell 7 on new admin hosts — it's cross-platform and the version Microsoft is targeting going forward — but keep 5.1 available for any older modules the client still depends on.
• Wrap destructive bulk changes with -WhatIf where the cmdlet supports it, and always run a pilot batch first.

---

Worth revisiting at the next major module version, or if Microsoft changes the default sign-in flow again