Bulk Policy Assignment in Microsoft Teams

In a very large Microsoft Teams environment, assigning, removing, or updating a user policy assignment for a large user base can be a frustrating process due to session time-out and the tenant level throttling limits. The traditional approach has been to loop through all users to assign, remove, or update the policy assignment as required. With the release of the “New-CsBatchPolicyAssignmentOperation” cmdlet in Microsoft Teams, the traditional approach can be replaced for bulk assignment. This cmdlet allows you to submit a batch of the user to Microsoft for policy assignment, where the assignment is performed as an asynchronous operation by Microsoft. It means you are not required to loop through all users. 
At the moment, the batch policy assignment is limited to the following Microsoft Teams policy types: 
  • CallingLineIdentity
  • ExternalAccessPolicy
  • OnlineVoiceRoutingPolicy
  • TeamsAppSetupPolicy
  • TeamsAppPermissionPolicy
  • TeamsCallingPolicy
  • TeamsCallParkPoliy
  • TeamsChannelsPolicy
  • TeamsEducationAssignmentsAppPolicy
  • TeamsEmergencyCallingPolicy
  • TeamsMeetingBroadcastPolicy
  • TeamsEmergencyCallRoutingPolicy
  • TeamsMeetingPolicy
  • TeamsMessagingPolicy
  • TeamsUpdateManagementPolicy
  • TeamsUpgradePolicy
  • TeamsVerticalPackagePolicy
  • TeamsVideoInteropServicePolicy
  • TenantDialPlan
A batch may contain up to 5,000 users. For over 5,000 users, multiple batches can be submitted. The function below can be extended to split the list of users passed into a batch of 5000 users for policy assignment, where the policy type can be one from the above list. For each submitted batch an operation ID will be generated.

Function BulkPolicyAssignment
{
Param($UserList)
$startrow = 0 ;
$counter = 1 ;
while ($startrow -lt $UserList.count)
{
$BulkBatch = $UserList | select-object -skip $startrow -First 5000
$startrow += 5000
New-CsBatchPolicyAssignmentOperation -PolicyType TeamsUpgradePolicy -PolicyName UpgradeToTeams -Identity $BulkBatch.UserPrincipalname -OperationName "$counter-BulkBatch"
$counter++ ;
}
}
Once a batch is submitted, the status for each batch can be monitored through the “Get-CsBatchPolicyAssignmentOperation” cmdlet. 
Bulk Batch Operation - Get-CsBatchPolicyAssignmentOperation
The code below can be extended to fetch a list of submitted bulk assignment batches between a time and get the results.

$GetBulkBatch = Get-CsBatchPolicyAssignmentOperation | Where-Object {$_.CreatedTime -gt
$datetimeToString1 -and $_.CreatedTime -lt $datetimeToString2}
foreach ($batch in $GetBulkBatch)
{
Get-CsBatchPolicyAssignmentOperation -Identity $batch.OperationId | Select-Object -ExpandProperty UserState
}

The UserState property offers Result (Success or an Error message) and State (Completed, InProgress, or Not Started) parameters and can be used to filter users from batches for any further action. 

Bulk Batch Operation - Get-CsBatchPolicyAssignmentOperation
In the future, the policy types that are supported will be extended for sure. Also, having the same functionality for other Microsoft 365 PowerShell modules (Exchange Online, MSOL, AzureAD, and more) will be a great addition. 

Microsoft Teams & Stream Live Events with External Encoders to Stream

Teams live event offers support for integrating hardware of software-based external encoder to stream video to Microsoft Stream. The use of a media encoder in Microsoft Teams Live Events is tightly integrated with different settings in Microsoft Stream. To allow users to use an external media encoder for their Teams Live Events, users must be configured for the following setting:
  • Required users must be licensed for Teams and Stream with a valid license type such as a Microsoft or Office 365 Enterprise E1, E3, or E5 license or an Office 365 Education A3 or A5 license. Live events are not supported for the F3 license type.
  • Required users must be allowed to upload content to Microsoft Stream
  • Required users must be enabled to set up Live Events setup in Microsoft Stream.
  • Live Event policy in Microsoft Teams must be enabled
In many organisations, these features might not be enabled for all users due to security and compliance reasons.

The use of 3rd Party encoders is not supported for Public Live Events, therefore hosted Live events will be limited to an internal (licensed) audience only. While selecting the Live Event for public attendees, the option to select an external app or device for encoding will be disabled. 

Teams Live Event

Select 'People and groups' or 'Org-wide' and then 'An external app or device' to use an external encoder. 
Teams Live Event Permissions
Once the above pre-requisites are configured, enabled users will be able to use 3rd party encoders for their Live events hosted via Microsoft Teams or Microsoft Stream. In both cases, the recording will be stored in Microsoft Stream. The ingest URL can be used in supported encoders to stream video. 

Live Events external encoder

Similarly, while hosting a Live Event using the Stream portal.

Stream Live Event

As Microsoft has started the roll-out of the change from using Microsoft Stream to OneDrive for Business and Microsoft SharePoint for meeting recordings, the change can be applied as required. 

Teams Recording Location Policy

The change to store meeting recordings in OneDrive for Business and SharePoint Online is for the following meetings types (1:1 calls with internal or external parties, group calls, and adhoc/schedule meetings). Therefore, the experience and the licensing requirements for Live vents will remain the same and Live Events recording will be stored in Microsoft Stream.

Using Modern Authentication / Certificate based Authentication for Unattended Scripts in Exchange Online

Executing unattended scripts is one of the basic requirements for organisations of all scales for various reasons ranging from monitoring, reporting, auditing, scheduling changes, and running a customised portal. In general, these unattended scripts access Exchange Online PowerShell using a user name and a password (aka Basic Authentication), where credentials are stored in a local file or a secret vault. This is not considered a good security practice and Microsoft has decided to retire basic authentication and replace it with certificate-based modern authentication using Azure AD applications. 

The decision to retire basic authentication for Exchange Online Remote PowerShell is extended second half of 2021. It gives organisations, that are using basic authentication for Exchange Online Remote PowerShell to execute unattended scripts, time to switch and replace the basic authentication with certificate-based modern authentication. To use the modern authentication for unattended scripts requires: 
  • Exchange Online PowerShell V2 module (The EXO V2 module uses the Active Directory Authentication Library to fetch an app-only token using the application Id, tenant Id organization, and certificate thumbprint).
  • Azure Application Registration with required Application permissions. Please note, delegate permissions are not supported.
  • x.509 certificate  
  • Azure AD role assignment to the Application object
Step 1: Generate an x.509 certificate

This step is required if you want to use a self-signed certificate instead of a third-party certificate purchased for your domain. To generate a self-signed certificate, perform the steps below:
  • Open PowerShell as an Admin and run the cmdlets below to generate a self-signed certificate with .pfx and .cer format.

# Create certificate 

$EXOModernAuthCert = New-SelfSignedCertificate -DnsName "mydomain.com" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange 

The .pfx certificate format will be used while connecting to Exchange Online. 

# Export certificate to .pfx file 
$EXOModernAuthCert | Export-PfxCertificate -FilePath EXOModernAuthCert.pfx -Password $(ConvertTo-SecureString -String "MyStrongPassword" -Force -AsPlainText) 

The .cer format will be used to upload the certificate to Azure AD Application. 

# Export certificate to .cer file
$EXOModernAuthCert | Export-Certificate -FilePath EXOModernAuthCert
Self-Signed certificate for Unattended scripts in Exchange Online

Step 2: Register an Azure AD App

To delegate Identity and Access Management functionals to Azure AD, an application must be registered with an Azure AD tenant as it creates an identity configuration for the new application that allows it to integrate with Azure AD.
Azure App Registration for Exchange Online Unattended Scripts

 


Step 3: Assign Permissions

For the new application object to access Exchange Online resources, it needs to have the Application permission Exchange.ManageAsApp. To assign the required permissions, select Manifest, in the left-hand navigation under Manage, Locate requiredResourceAccess property in the manifest, and add the following inside the square brackets ([]): 

"resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
"resourceAccess": [
{
"id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
"type": "Role"
}
]

It should look, something like this:

Azure App manifest for unattended scripts in Exchange Online

Step 4: Consent Permissions

Once the Manifest is updated, go to API Permissions in the left-hand navigation under Manage to confirm Exchange.ManageAsApp application-level permissions are added. However, it is not yet consented. Because these are application permissions, not delegated permissions, an admin must grant consent to use the app roles assigned to the application. To consent, click on Grant admin consent for your tenant and confirm the consent.

Azure App consent



Azure App permissions for unattended script in Exchange Online

Step 5: Upload Certificate

Once the permissions are configured, the certificate generated as per step 1 can be uploaded. To upload the certificate, select Certificates and Secrets under Manage, click Upload Certificate

Certificate upload for unattended scripts in Exchange Online

Step 6: Assign Azure AD Admin Role

For app-only authentication in Exchange Online, currently following admin roles are supported. Depending on the requirement to execute unattended scripts, one or more roles can be assigned. 
  • Global administrator, Compliance administrator, Security reader, Security administrator, Helpdesk administrator, Exchange administrator, Global Reader
The custom RBAC roles (not available in Azure AD) are not supported.

In this example, the newly registered app is assigned an Exchange Online Admin role in Azure AD (Roles and Administrators):

Azure AD Exchange Admin role

Step 7: Sign-in to Exchange Online

After the completion of steps 1-6, the Exchange Online Remote PowerShell can be connected using Modern Auth to execute the unattended scripts.

Option 1: Connect to Exchange Online Remote Powershell using a local certificate:

Connect-ExchangeOnline -CertificateFilePath "C:\temp\EXOModernAuthCert.pfx" -CertificatePassword (ConvertTo-SecureString -String "MyStrongPassword" -AsPlainText -Force) -AppID "2803131c-bc1f-45b2-a5de-11aebb100000" -Organization "mydomain.onmicrosoft.com"

In the above command, the AppID is the GUID of the registered app and can be obtained from the overview option of the registered app. 

Azure AD App ID

Option 2:

Connect to Exchange Online using Certificate ThumbPrint. When using the CertificateThumbPrint parameter, the certificate needs to be installed on the computer where you are running the command. The certificate should be installed in the user certificate store.

Connect-ExchangeOnline -CertificateThumbPrint "9B25BB6343F0D63929AC88CB287D148026B50E2C" -AppID "2803131c-bc1f-45b2-a5de-11aebb100000" -Organization "mydomain.onmicrosoft.com" 

If the certificate is not installed, the following error will be generated "No certificate found for the given Certificate Thumbprint":

No certificate found for the given Certificate Thumbprint

Once the certificate is installed in the user certificate store, a successful session is established using the certificate thumbprint, App ID, and the Microsoft 365 domain. 

Exchange Online PS session using certificate based authentication

Option 3: using a certificate object
Connect to Exchange Online Remote PowerShell using the Certificate parameter. In this case, the certificate does not need to be installed on the computer where you are running the command. This parameter is applicable for scenarios where the certificate object is stored remotely and fetched at runtime during script execution. The remote server details can be passed in the command below to fetch the certificate details and use it for connection to Exchange Online Remote PowerShell.

Invoke-Command -ScriptBlock {Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -like "9B25BB6343F0D63929AC88CB287D148026B50E2C"}}


This easy to implement and adopt certificate-based modern authentication is a great feature to motivate organisations to move away from Basic Authentication and adopt a good security practices.

Routes available for this request but no available gateway at this point .. (PSTN Calls)

While making a PSTN call (internally or externally) via SIP trunk, calls failed to connect - with an error as below:

"Routes available for this request but no available gateway at this point"

12000; reason="Routes available for this request but no available gateway at this point"; source="FE01@mydomain.int"; appName="OutboundRouting"; OriginalPresenceState="0"; CurrentPresenceState="0"; MeInsideUser="Yes"; ConversationInitiatedBy="0"; SourceNetwork="0"; RemotePartyCanDoIM="No"

Looking at the error, one possibly can start to check to ensure that:
  • Topology is updated correctly with correct PSTN Gateways and Trunks
  • All required DNS records for PSTN Gateways are in place
  • Voice Policies, routes, and PSTN usage are configured correctly
Once the above was verified and confirmed, it required further investigation. As per Wireshark logs, the SIP trunk leg on Mediation Server is sending CANCEL REQUEST straight away. So surely, there is no issue with the supplier at Gateway end, and at this stage, it was not wise to raise it with them.


Logs in Snooper at client-side showing 503 Service Unavailable coming from Front End Server.


A similar post on this blog is suggesting to increase the FailoverTimeout value in Outbound Routing configuration on Front End Servers.

SfB Server 2015 Path: 
C:\Program Files\Skype for Business Server 2015/Server/Core/OutboundRouting.exe.config

Lync 2010 Path: 
C:\Program Files\Microsoft Lync Server 2010\Server\Core\OutboundRouting.exe.config

<configuration>
<appSettings>
<add key="FailOverTimeout" value="10000"/>
<add key="MinGwWaitingTime" value="1"/>
<add key="MaxGwWaitingTime" value="20"/>
<add key="FailuresForGatewayDown" value="10"/>
<add key="FailuresForGatewayLessPreferred" value="25"/>
<!-- Valid values are between 5 and 600 -->
<add key="HealthMonitoringInterval" value="300"/>
<!-- Valid values are between 60 and 3600 -->
<add key="GatewayStateReportingInterval" value="1800" />
</appSettings>
</configuration>
 

The above change seems to have resolved the CANCEL REQUEST issue but I didn't want to change the recommended FailoverTimeout value as there was something else causing this issue. 

As the calls we're getting failed internally as well, it was easier to assume that it cannot be due to a connectivity issue between Mediation and Edge servers. Well, it turned out to be due to connectivity issues between Mediation and Edge Servers. 

When Lync/Skype for Business Edge Servers is deployed in the environment, the Mediation Server service requires constant communication with the Edge Servers. The Mediation Server acts much like a Skype for Business client regarding Edge Server connectivity. When the Mediation Server is establishing any call, it will request Media Relay ports with the Edge Server to be ready if a remote user might be involved. Even when the call is made from an internal user, this process is still followed. If the Mediation Server cannot contact the Edge Server, the actual call might not fail but a delay in call setup time can occur. Depending on the FailoverTimeout, the call might fail to connect. 

An increase in FailoverTimeout value in OutboundRouting.exe.config might help to connect to call before FailoverTimeout (as confirmed here - Lync Mediation Server CANCEL problem). However, it may not be an ideal solution to experience delay for PSTN call connectivity. 

A common issue with call setup delays/failure is connectivity between Mediation Servers and Edge Servers. Ensure that the Mediation Server can communicate with the Edge Server on port 3478 UDP and 443 TCP for port allocation. If that network connection is not available or the Edge Servers are having issues, a delay of several seconds might be incurred at call setup time (fail to connect call). Additionally, if remote Skype for Business users are not able to make calls to the PSTN, Edge Server connectivity is a key component to analyze. 

Once the connectivity of Mediation servers with Edge servers on port TCP 443 and UDP 3478 is configured, PSTN call connectivity (internally and externally) started to work without any issue.

Abnormal Disconnect cause: 102 # GWAPP_RECOVERY_ON_TIMER_EXPIRY - AudioCodes Mediant 1000

While configuring the AudioCodes gateway Mediant 1000, we experienced an issue with outgoing calls - A timer was active somewhere (on PBX), which was disconnecting calls after few seconds (5 seconds) once a session is active. The logs via ACSyslog suggested it as "Abnormal Disconnect cause: 102 # GWAPP_RECOVERY_ON_TIMER_EXPIRY".

By changing the protocol type from "EI EURO ISDN" to "E1 QSIG" resolved the issue. This setting is under Configuration (Full Mode) -> VOIP -> PSTN -> Trunk Setting.


Unable to Put Call on HOLD or use Consult and Transfer

The external PSTN calls getting dropped or failing to retrieve while using the Hold or Consult and Transfer functionality seems to be a common issue, It can be resolved through different approaches such as Enabling/Disabling Refer Support on the Trunk side or Enabling/Disabling PRACK on Trunk side on SBC.
Recently one of the customers started to experience a similar issue but it was limited to one location. Therefore, Enabling/Disabling the Refer to Global Trunk configuration was not a feasible option.
Lync/SfB logs and WireShark traces reported - "Gateway responded with 491 Request Pending". It suggested the problem seems to be with SBC configuration.


Call Flow

On further investigation on the SBC side, it is identified that PRACK was enabled and causing the call to drop (Gateway call is not in the connected state) while using the Hold. Once the PRACK is disabled, the Hold and Consult and Transfer started to work fine.

PRACK - Unable to Put Call on HOLD or use Consult and Transfer

Skype for Business Edge Servers Not Showing Certificate After Import

While importing the External Certificate on Skype for Business Edge Servers via deployment wizard, it didn't appear in the list to assign the certificate. While opening the certificate, it didn't show the "You have a private key that corresponds to this certificate". The issue can be resolved by importing the certificate via MMC, repairing it, and then assigning it via Lync deployment wizard. 
Click on Run and type MMC
  • Select File and then Add Remove Snap-In
  • Select Certificates, Computer Account and Click on Finish
  • Click OK
  • Expand Certificates (Local Computer) and Import Certificate (Right Click -> All Tasks --> Import)
Open Command Prompt as Admin and run following cmd
certutil -repairstore my "11 11 11 11 11 11 11" 
Where "11 11 11 11 11 11 11" is the serial number of your certificate under the Details Tab.
Once the above cmd is successfully executed, in the Certificates snap-in, right-click Certificates, and then click Refresh. The certificate now should have an associated private key. 
  • Now Go back to Lync/SfB Deployment Wizard, select Request, Install or Assign Certificates
  • Select External Edge Certificate (If shown) and Select Assign
  • Select New Certificate and follow the wizard to complete the process
  • Restart Lync/SfB Services (It's good to reboot the server at this time to avoid any unexpected issue)
  • Check services, External Lync functionality, and Federation

Lync/SfB Federation - Certificate trust with another server could not be established

I came across this error while trying to communicate with one of the federated users. Knowing the fact that both parties are openly federated - we were not expecting any issue. But surprisingly, ended with the following error and were not able to communicate or see presence.

1010; reason="Certificate trust with another server could not be established"; ErrorType="The peer certificate is not chained off a trusted root"; TlsTarget="sip.teneo.net"; HRESULT="0x80090325"; source="edge.mydomain.com"; OriginalPresenceState="0"; CurrentPresenceState="0"; MeInsideUser="Yes"; ConversationInitiatedBy="1"; SourceNetwork="5"; RemotePartyCanDoIM="Yes

Logs suggested this as a TLS issue.

The issue is resolved by opening the SIP URL "https://sip.yourdomain.com" in IE on my Lync Servers. It allowed getting a federated partner root certificate from their providers via the automatic root certificate update mechanism.

You will get a page that could not be displayed. However, if your try to communicate with your federated partner, it will be successful.

"TargetRegistrarPool" with identity "12345678" assigned to "sip:user@mydomain.com" has been removed from configuration store.

It looks like the Registrar Pool associated with the user has been removed from Lync/SfB topology, but the user's attributes are not yet updated. To resolve this issue, follow the steps listed below:

Find the user in Active Directory OU
Go into that Active Directory OU
Open User's Properties
Select Attribute Editor
Find attributes as listed below and Set to "Not Set" or click on "Clear"
  • msRTCSIP-FederationEnabled
  • msRTCSIP-InternetAccessEnabled
  • msRTCSIP-OptionFlags
  • msRTCSIP-PrimaryHomeServer
  • msRTCSIP-PrimaryUserAddress
  • msRTCSIP-UserEnabled
Once done, check again Lync and there should be no more warnings.

Object XYZ contains other objects. Are you sure you want to delete object XYZ and all of the objects it contains.

This is just a warning for you to double-check if the objects associate with XYZ can be removed too.
 AD Subtree deletion

To view the associated objects, select
ADUC - View -- Users, Contacts, Groups, and Computers as Containers
Now expand the object and check all associated objects.

ADUC


Once confirmed, they can be removed, tick - Use Delete Subtree Server Control and then Yes to delete the objects.

An Error occurred during online meeting - Some sharing features are unavailable due to server connectivity issues ...

External users can join online meetings and can share desktop without any issue. But if they try to initiate whiteboard, presentation, or polls, Lync/SfB client shows:

An error occurred during an online meeting. Some sharing features are unavailable due to server connectivity issues.

The OCLogger on a Front End server shows:

Start-Line
: SIP/2.0 488 Not acceptable here
3041;reason="Participant is not connected to conference" ;source="FE01.domain.local"

Lync logs showing:

54001; reason="Connection to the Web Conferencing Server could be established, but the server terminated immediately"; ClientType=Lync; Build=4.0.7577.4456;
Branch=lcs_se_w14_main; ContentMCU="sip:user@domain.com; gruu;
opaque=app:conf:data-conf:id:G6C6JNHM";
ConferenceUri="sip:user@domain.com; gruu;
opaque=app:conf:focus:id:G6C6JNHM"; ServerFQDN="lyncwebconfedge.domain.com";
ServerPort="443"; ConnectionMethod="DataProxy";
ServerIPAddress="xxx.xxx.xxx.xxx"; ClientIPAddress="192.168.2.63";
ConnectionType="Wired"; SocketCode="10054 (WSAECONNRESET)"


The firewall Team confirmed, all the required ports are open - however, on testing it is identified that port 8057 between Edge Servers and Front End Servers is blocked. The port 8057 is used for Web conferencing traffic from Front End Server or each Front End Server if in a pool, to Edge Server internal interface. Once the port is configured correctly, the whiteboard, presentation, and polls started working without any issue.

SfB Client fail to Sign-in Over DA - Malformed SIP URI

SfB Client 2016 fail to sign-in over DA. It just spins for sign-in to connect to SfB servers but nothing happens.
Environment:
  • Back-end Server: Windows 2008 R2 + SfB 2015
  • Client Operating Server: Windows 7 - Service Pack 1 / Windows 10
  • Client: Skype for Business Client 2016 (Office 2016 Pro Plus)
  • Direct Access Servers: (Windows 2008 R2 + UAG 2010)
Error in Lync/SfB Client logs:
SIP/2.0 400 Malformed SIP URI
From: <sip:[2001:0:8a68:e317:38bb:374:ae22:7d11]:56825>
To: <sip:[2002:8a58:e417:8001::afd:215]:5061>

ms-diagnostics: 1018;reason="Parsing failure";source="LyncFE.mydomain.int"

On further investigation, it is identified that the SfB client over DA was trying to connect to the internal SfB pool instead of connecting via the Edge server.

The quick and easy fix was to include a new rule into the Name Resolution Policy Table (NRPT) table on DA servers to exclude SfB FE pools to restrict SfB clients to use the internal DNS server. Once a required rule is added to the NRPT table and published, the SfB client started to sign-in over DA without any problem. As shown below, SfB FE Pool is now part of the UAG DA rule without and Direct Access DNS server IP (to force it to route via the Internet).

Name Resolution Policy Table (NRPT) in Registry editor


Response Group Agents - Not able to receive calls .. RTCRGS - Current Active Calls = 18446740000000000000

With over 300 response groups, and nearly 70% of the agents were not able to receive calls. It appeared to happen for both FORMAL and INFORMAL Groups and so not a sign-in issue. While reviewing services and active calls, one of the Front End was showing "18446740000000000000" active calls for RTCRGS service !!!

active calls for RTCRGS service "18446740000000000000"

Nothing in event logs and surely no agent anonymity. Possibly, it's a bug (SfB 2015 with latest May 2017 CU). 

The only workaround seems to be to restart the service. After the restart of RTCRGS, active call sessions returned to normal and agents were able to entertain calls.

Skype for Business and Windows Fast User Switching resulting Lync Call Quality and Call Drops Issue

Some of the issues with Lync/Skype for Business call quality and call drop can be due to an integration issue between “Lync / SfB” and “Windows Fast User Switching” functionality. On a shared machine (desktop/laptop) especially at the front desk (reception), Fast User Switching is an easy way for users to allow others to log on to the machine without logging off or closing programs such as Lync. When a user is logged on to a computer and has locked the computer and a new user logs in to the same computer by using “Switch User” functionality, the new user is having problems using Skype for Business client for any type of Audio calls. User Switching without closing/exiting SfB session means that on a single machine two users are signed-in on SfB clients at the same time. Lync and SfB client doesn’t support fast user switching.

Some of the end-users comments based on this issue are:
  • I'm getting other people's calls; hear a dialing tone when answered but the call connects before deafening beeping noise.
  • Present of dialing tune while on call, and after a few seconds an alarm would go off - which hurts ear so much!
  • When making a call via Lync/SfB you can hear the person on the other end but also a dialing tone - as if two calls are happening at the same time
  • If the user tries to do a PSTN call there is a constant dial tone in the background and the call will eventually terminate.
  • If the user tries to join an A/V Conference, there is no audio and the conference call will end.
  • Resolution
  • If the first user logged on to the machine is not available to close Lync/SfB, ask the second user to restart the machine. The restart will kill all logged-in user sessions. After restart and sign-in, there will be only one Lync process on that machine.
It important that we inform/communicate to all users “especially users at front desk/ reception changing shifts” who are using a shared machine to log-out from the machine instead of using user switching functionality to avoid call quality and drop issue on reception response groups.

I think machines at the front desk/reception should be disabled for “switch user functionality” as fast user switching at the reception response group can result in a major incident.

Lync and Office 365 - Duplicate Contacts as Recipient Cache

User migrated to Office 365 and still using Lync 2010 client will see the duplicate contacts as Recipient cache in Lync search. Lync 2010 client is pulling duplicate contacts from recipient cache in outlook. The recipient cache seems to be a hidden folder and integrated with Lync search.

The solution to avoid duplicate entries (recipient cache) in the Lync search is to exclude the Recipient Cache contact folder from the Lync search. It can be implemented through the Lync client policy on Lync Server.

Set-CsClientPolicy -Identity Global -ExcludedContactFolders “Recipient Cache”

Change the client policy name as per your requirement.

If your organization is migrated to Office 365 and using Lync 2013 or SfB client, then there is no need to implement this change. As the issues seem to be resolved in the later version.

Voicemail not showing up on Lync / Skype for Business Client

The Voicemail to UM enabled users are not appearing under the voicemail option of Phone Tab in Lync /SfB Client. It forced users to listen to their voicemail via outlook. The issue was most probably due to corrupt a UM profile and Lync cached.
The issue has been resolved through the following steps:

  • Disable User UM on Exchange Server
  • Exit Lync
  • Delete Lync Cache
  • Access this path and delete all folders. 
This path will be different depending on your OS and the client.

  • “C:\Users\ABC12345\AppData\Local\Microsoft\Communicator\sip_UseremailID@mydomain.com”
  • Delete Tracing Contents
  • Access this path and delete all files “C:\Users\ABC12345\Tracing\”
  • Open Outlook and Select Voice Mail Folder under Search Folder and Delete
  • Disable Exchange Cached Mode from Outlook setting
  • Close Outlook
  • Enable User's UM on UM server
  • Open Outlook and allow some time to sync - A new Voice Mail will be created under Search Folders
  • Open Lync Client and allow some time to Sync
  • Check Voicemails under the voicemail option of Phone Tab in Lync/SfB Client.