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:
Connect-MicrosoftTeams 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.
Setting it to True before it is assessed whether it is ok for the company to have such recordings doesn’t seem right.
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…
Ok, i get it now. Thanks
Thank you very much for this. Really helpful!
How can we see how many call recordings have been made by users to evaluate its current usage?
Use the script in https://office365itpros.com/2020/05/29/tracking-video-uploads-stream/ to report who is uploading videos to Stream and you should be able to find out.
“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…?
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.
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?
I don’t know what you mean by school phone numbers…
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)?
1:1 calls over Teams.
I am getting this error:
Command: Set-CsTeamsCallingPolicy CorrelationId: b835916c-905f-4378-82a9-9b238a6c42d0. Exception while submit job to
Lros
+ CategoryInfo : OperationStopped: (:) [Set-CsTeamsCallingPolicy], LrosClientErrorException
+ FullyQualifiedErrorId : CmdletFinalizationFailure,Microsoft.Rtc.Management.Internal.SetTeamsCallingPolicyCmdlet
+ PSComputerName : api.interfaces.records.teams.microsoft.com
I’m not sure what it means..
What command did you run?
Did you upgrade to the latest version of the Teams PowerShell module?
All those mentioned in the article above, running 1.1.6
I just ran those commands using the Teams PowerShell module 2.0 and they worked just fine.
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!