Make Sure Users Can Continue Recording Teams (1:1) Calls

Microsoft Introduces New Control Effective Mid-April 2021

Message center notification MC227292 posted on 26 November (subsequently updated February 10 and March 9) advises of a change to how Teams controls the ability of individual users to record 1:1 calls. This feature, which allows people to make recordings of calls with other individuals, was introduced in April 2020.

Recordings are stored in Stream or OneDrive for Business, depending on whether the tenant has switched the storage location for Teams recordings (from March 1, commercial and GCC tenants store all new recordings in OneDrive). If OneDrive is used, the recording is stored in the account of the person who starts the recording. In Stream, the originator is the owner of the recording. OneDrive for Business is a better option for people who record calls with others outside the tenant because they can share the recording afterwards. Stream doesn’t allow its files to be shared outside the tenant.

Controlling Teams Recordings

Up to now, the AllowCloudRecording setting in the Teams meeting policy assigned to accounts has controlled if a user can initiate recording. If True, the user can record a call. If False, they can’t. However, the setting is really intended to control whether people can record meetings instead of personal calls, and the change introduces a new setting called AllowCloudRecordingForCalls to differentiate between the two types. In addition, the new setting is in the Teams calling policy applied to accounts rather than the Teams meeting policy (editorial comment: policies is one thing Teams is not short of).

What’s important to realize is that the default state of the setting is False, which means that once Microsoft switches the policies in mid-April 2021, users won’t be able to record their personal 1:1 calls unless action is taken to update calling policies. The quick fix is to update the setting in all calling policies to True until the organization assesses if it’s a good idea to allow people to make recordings of this nature. According to the notification, tenants should update their calling policies by April 12 if they want to be sure that users can continue to record 1:1 calls.

Updating the Calling Policy with PowerShell

The ability to update the setting in calling policies isn’t currently available in the Teams admin center. To make the change with PowerShell, connect to Microsoft Teams and then create a session with the endpoint used for managing policies. The cmdlets to do this are all in the Microsoft Teams PowerShell module. Connect to Teams and then Check the current situation by running the Get-CsTeamsCallingPolicy cmdlet:

Get-CsTeamsCallingPolicy | Format-Table Identity, AllowCloudRecordingForCalls

Identity                                 AllowCloudRecordingForCalls
--------                                 ---------------------------
Global                                                         False
Tag:AllowCalling                                               False
Tag:DisallowCalling                                            False
Tag:AllowCallingPreventTollBypass                              False
Tag:AllowCallingPreventForwardingtoPhone                       False

The policies prefixed with Tag: can’t be updated. These are special policies controlled by Microsoft. You can update the Global calling policy and any custom calling policies created by the tenant. For example:

Set-CsTeamsCallingPolicy -Identity Global -AllowCloudRecordingForCalls $True

Users not allowed to record Teams personal calls because the policy assigned to their account has AllowCloudRecordingForCalls set to False might be frustrated at the new development, but perhaps the question needs to be asked what business purpose justifies the recording of personal calls?

The Office 365 for IT Pros eBook contains lots of information about Teams calling and meetings. Subscribe to receive monthly updates about important changes like the one described here.

22 Replies to “Make Sure Users Can Continue Recording Teams (1:1) Calls”

  1. Setting it to True before it is assessed whether it is ok for the company to have such recordings doesn’t seem right.

    1. It just restores the functionality as it exists today when calls are recorded based on the meeting policy. But you have time to figure out what the policy should be in the future before December 18…

  2. “perhaps the question needs to be asked what business purpose justifies the recording of personal calls?”

    Who said it’s a personal call? Just because it’s 1:1 doesn’t make it a personal call. Do Microsoft employees never make 1:1 business calls…?

    1. That terminology comes from Teams personal chat. Of course the calls are probably business communications. I can’t see many of them being used to phone home.

  3. Just to clarify – this refers to calls using ol’ school phone numbers under the calls tab – not 1:1 conversations under the chat tab, right?

      1. Apologies, let me rephrase…
        Is this a setting which affects 1:1 ‘calls’ over Teams (i.e. under the Chat tab) or calls to phone numbers using a calling plan (under the calls tab)?

  4. I am getting this error:

    Command: Set-CsTeamsCallingPolicy CorrelationId: b835916c-905f-4378-82a9-9b238a6c42d0. Exception while submit job to
    + CategoryInfo : OperationStopped: (:) [Set-CsTeamsCallingPolicy], LrosClientErrorException
    + FullyQualifiedErrorId : CmdletFinalizationFailure,Microsoft.Rtc.Management.Internal.SetTeamsCallingPolicyCmdlet
    + PSComputerName :

    I’m not sure what it means..

    1. What command did you run?

      Did you upgrade to the latest version of the Teams PowerShell module?

      1. I just ran those commands using the Teams PowerShell module 2.0 and they worked just fine.

      2. Ok, I explicitly updated the teams module, it went from 1.1.6 to 2.0 .
        When running the GET- command I suddenly got an error (even after reconnect) where I didn’t got one before, after “Exit” and restart PS the GET- worked again but somehow the AllowCloudRecordingForCalls for global identity was already set to “true”, very odd! But this is what I wanted at the end, so it’s all good now I guess 🙂
        Thanks for the quick support!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.