1:1 Call Recording Policy Controls Are (Almost!) Here

1:1 Call Recording Policy Controls Are (Almost!) Here

This article is contributed. See the original author and article here.

Hi Teams Community,


A long outstanding request from Teams Administrators is the ability to control 1:1 Call recording independently of Teams Meeting Recording.  We’re pleased to announce these controls are almost here.  


 


Today, any user allowed to record Teams meetings can also record 1:1 Calls.  This setting is currently governed by Teams Meeting Policy parameter AllowCloudRecording.  Very soon, 1:1 Call Recording will be governed by a new parameter in Teams Calling Policies, AllowCloudRecordingForCalls.  



For more information, be sure you’re logged into your M365 Admin Portal as a Tenant Admin account and review the following Message Center Post:  (Updated) 1:1 Call recording policy introduction


 

In fact, the AllowRecordingForCalls parameter is there now, and you should take immediate action to ensure your users have the desired experience once we begin enforcing this policy, current Plan of Record is to start the rollout April 12, 2021.

 

What this means for you as a Teams Administrator depends on what your business requirements are.  If you are fine with your users recording 1:1 Calls, you will need to take action to ensure they can continue to do so after the new Policy goes into effect.  Because of the policy requirements of a significant majority of Teams customers, 1:1 Call Recording will be disabled by default.  Further, the new policy is only manageable through PowerShell.  


So, if you would like your users to continue to have the ability to record 1:1 Calls after April 12, 2021 – you should take action now.  What action?  Set -AllowCloudRecordingForCalls to $True in the Calling Policy applied to the desired Users.  For many of you this will be the Global Default policy and for that, the change can be achieved with the following PowerShell cmdlet:

 

Set-CsTeamsCallingPolicy -Identity Global -AllowCloudRecordingForCalls $True


 

If however you want some users to be prevented from recording 1:1 Calls, you would modify the appropriate policy by setting -AllowCloudRecordingForCalls to $False.  Keep in mind, $False will be the default value for the Global and any out-of-the-box a.k.a. “OOB” Calling Policies when this change rolls out. 

 

OOB Calling Policies cannot be modified – so if you have users with OOB Calling Policies set you will need to move those users to a new policy if you want them to be able to record 1:1 Calls.  Based on customer feedback we expect this case to be somewhat rare – but just in case we’ve provided you an example PowerShell script that copies your existing Calling Policies and creates new policies with -AllowCloudRecordingForCalls set to $True.  We hope this eases the administrative burden of preparing for this change and also gives you a cool example of how to make a copy of a Teams Policy (yes, with appropriate modifications this script can make a copy of other Teams policies, not just Calling!).


You can find the script here: TeamsCallingPolicyUpdateIt was written by our good friend @Andy Thomson, thanks Andy!  

 

Side note – there are other very useful Sample Scripts there – take a moment and bookmark this shortcut: 

 

Be sure to read the ReadMe file there for important instructions (requires MicrosoftTeams ps module, 2.0.0 or higher, for example).  


From my test tenant, running the script example:

CallRecordingScriptRun.png

 

And, this is what it looks like in the Teams Admin Center after I’ve copied my Calling Policies with the script:

CallingPoliciesAfterScriptGUI.png

In my case, I had a ‘CustomCalls’ custom Calling Policy created as the only non-default (OOB) policy in my Tenant.  You may have others, and you can copy only select policies if you wish, the script will prompt you.

 

At this point I would use my preferred method of applying the new policies that allow 1:1 Call recording to my desired user set.  Remember, you do have to Grant these policies to users for the setting to take effect.  

 

TLDR: 1:1 Call Recording Policy controls are coming starting April 12, 2021.  Default will be disabled.  If you want your users to be able to continue recording 1:1 Calls in Teams – you need to make policy changes now to ensure they can continue to do so.  If you are OK with the default (disabled) – no action is required!

 

Final notes:

First, you may be wondering what constitutes a 1:1 Call vs a Meeting?  If you schedule a Meeting with 1 other person only, is that a 1:1 Call?  Nope.  That’s a Meeting, and will be governed by Meeting Policies.  So will a Meet Now.  If you call someone, then add video, or screensharing, and then decide to Record – that’s a 1:1 Call and will be governed by Calling Policies.

 

Second, this new Calling Policy Parameter does not apply to PSTN calls, yet.  That’s coming later.  For the moment you cannot record PSTN calls or calls with Skype for Business users in Teams.

 

And last but not least, this new policy setting relates to the Microsoft Teams Recording solution for 1:1 calls. This setting does not affect 1:1 Compliance Recording, which is still controlled via the Compliance Recording policy.

 

As always we hope this information is useful for you, please comment the blog with any questions or feedback.

Thanks!
Microsoft Teams Support


 

Timeout Issue Caused by Idle Time-Out Action

Timeout Issue Caused by Idle Time-Out Action

This article is contributed. See the original author and article here.

While navigating the pages in an application, the page was spinning for about a minute and giving a timeout error. This application utilizes a WCF service.


 


We collected a dump file from both the ASP.NET page and WCF service while the page was spinning. Here are the exceptions we saw in the dump files:


 


Exception Type : System.Net.Sockets.SocketExceptionMessage: An existing connection was forcibly closed by the remote hostSystem.ServiceModel.Channels.SocketConnection.Write(Byte[], Int32, Int32, Boolean, System.TimeSpan)Exception Type : System.ServiceModel.CommunicationExceptionMessage: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.System.Runtime.AsyncResult.End[[System.__Canon, mscorlib]](System.IAsyncResult)System.ServiceModel.Activation.WorkerProcess.EndDispatchSession(System.IAsyncResult)Exception Type : System.IO.PipeExceptionMessage: There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).System.ServiceModel.Channels.PipeConnection.OnAsyncReadComplete(Boolean, Int32, Int32)


 


Solution


For this website, Idle Time-out Action was set to “Suspend”. This option isn’t always helpful. I don’t recommend using it.


 


Setting Idle Time-out Action to Terminate solved the issue. Website started displaying pages.


Nedim_0-1616781621350.jpeg


 


If you like to find out who change the application pool settings, check this post out.

Keyset does not exist

Keyset does not exist

This article is contributed. See the original author and article here.

IIS may display “Keyset does not exist” error while trying to set application pool identity. In the the Event Viewer, I saw this message:


 


ERROR ( hresult:80090016, message:Failed to commit configuration changes. Keyset does not exist)


 


This issue occurs when there is a problem with the machine keys (C:ProgramDataMicrosoftCryptoRSAMachineKeys)


 


IIS uses the machine keys below for encryption. The first thing to check is if these files exist.


 


















6de9cb26d2b98c01ec4e9e8b34824aa2_GUID



iisConfigurationKey



d6d986f09a1ee04e24c949879fdb506c_GUID



NetFrameworkConfigurationKey



76944fb33636aeddb9590521c2e8815a_GUID



iisWasKey



 


If the files exist in MachineKeys folder, check their security permissions. In the server I worked on, these files didn’t have owners.


Nedim_0-1616781541387.jpeg


 


After taking the ownership, it displayed only IIS_IUSRS account in the permission list. I added DatabaseAdministrators group to the Security list. Other required permissions came back right away. Afterward, we were able to change application pool identity.


 


Note: If you see 0x8009000D error along with “Keyset does not exist” message, please check this post.

Application Request Routing is Missing in IIS Manager

Application Request Routing is Missing in IIS Manager

This article is contributed. See the original author and article here.

Even if you install Application Request Routing (ARR), it may not show up in IIS Manager. Here is how a server farm looks like when ARR settings are not displayed:


Nedim_0-1616781479566.jpeg


 


Solution


It’s possible that something went wrong during the ARR installation. Follow the steps below to fix the issue and make ARR settings available.



  1. Remove ARR (Using Add/Remove Programs)

  2. Remove the server farm

  3. Install ARR back

  4. Restart IIS

  5. Close and open IIS Manager


 


Note: If you remove ARR and install it back without removing the server farm, it won’t work.

401 Custom Error Page Breaks Windows Authentication

401 Custom Error Page Breaks Windows Authentication

This article is contributed. See the original author and article here.

IIS has an easy way to add custom error pages in IIS Manager. However, using IIS Manager for adding a custom page for 401 status code may cause issues with Windows Authentication. Your website may keep prompting credentials even though you enter the correct username and password.


 


It is expected for Windows Authentication to be unfunctional if there is a new custom error page for 401 status. As a workaround, I would recommend editing the IIS default error page located at %SystemDrive%inetpubcusterren-US401.htm


Nedim_0-1616781258247.jpeg


 


Open this file in notepad and make changes. Then save it as htm file and replace the existing one.