(Feb 27, 2013 - The Lync 2013 ResKit, which includes a new version of SefaUtil, is available here http://www.microsoft.com/en-us/download/details.aspx?id=36821)
(Updated with pointer to UCMA 3.0 documentation and also only describing using SEFAutil on a dedicated server. We recommend installing trusted applications on dedicated servers. However using Lync Server Management Shell cmdlets you can configure CsTrustedApplicationPool on a server already running EE/SE or Director)
SEFAUtil (secondary extension feature activation) enables Lync Server 2010 administrators and helpdesk agents to configure delegate-ringing and call-forwarding settings on behalf of a Lync Server user. This tool also allows administrators to query the call-routing settings that are published for a particular user. SEFAutil is a utility part of the Microsoft Lync Server 2010 Resource Kit Tools. It is a UCMA 3.0 application and in order for it to work you need to configure a trusted application. For more information about this look here.
The trusted application pool is related to a registrar and you need to find the SiteId of the site in which the registrar is located. You can use the PS cmdlet Get-CsSite to find the SiteId. In my case the site is called Søborg, so the cmdlet I used is the following:
You then need to create the trusted application pool. In my lab it is running on a dedicated server (jenstr31.inframss.dk) and the registrar is cs1.inframss.dk. The PS cmdlet to create the trusted application pool is:
After having create the trusted application pool you then need to create a trusted application representing SEFAutil. The PS cmdlet to do this is:
The ApplicationId needs to be sefautil, but the Port number can be whatever number you would like. After having added the trusted application pool and trusted application you need to enable the topology by issuing the PS cmdlet Enable-CsTopology.
When you run SEFAutil on a dedicated server you then need to install Lync Server 2010 on the server. The setup steps you need to perform are the following:
Now the infrastructure is ready and you can continue with installing the Lync Server 2010 Resource Kit Tools. When it is installed start a command prompt and run SEFAutil. The Word document describing the Microsoft Lync Server 2010 Resource Kit Tools has a good description on how to run SEFAutil.
(1 Aug 2012: Updated with information about the AlwaysOn scenario provided by Natasha the PM for CLS)
Centralized Logging Service (CLS) is a new feature in Lync Server 2013 Preview. It provides a mechanism to enable/disable logging across all Lync servers in a deployment from a single interface and to search the resulting logs from the same interface.
You specify what should be logged based on the scenario you want to investigate. The scenarios supported are AlwaysOn, MediaConnectivity, ApplicationSharing, AudioVideoConferencingIssue, HybridVoice, IncomingAndOutgoingCall, VoiceMail, IMAndPresence, AddressBook, DeviceUpdate, LYSSAndUCS, CLS, SP, WAC, UserReplicator, HostedMigration, MonitoringAndArchiving, LILRLegacy, LILRLYSS, MeetingJoin, RGS, CPS, XMPP and CAA.
The AlwaysOn scenario is special. CLS is designed to have that scenario running by default. This way, when you have an issue you do not have to turn on logging, repro the issues and then get your logs. The hope is that there is enough logging occurring with AlwaysOn that when you have an issue you will already have the logs available. If AlwaysOn does not provide you with enough logs, then you can turn on a particular scenario to get a more verbose set of logs.
CLS is implemented by agents and a controller used by the Lync administrator to interact with CLS.
The Lync Server Centralized Logging Service Agent service (also known as ClsAgent) is running on all Lync 2013 Preview servers in the deployment. The purpose of the agent is to respond to requests to enable/disable logging and to respond to search requests.
The Lync administrator controls the agents via the ClsController interface. ClsController is a program default installed into C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent. You can specify different parameters to ClsController. You can see detailed usage information about parameters and their values by just running ClsController without parameters.
The typical sequence of commands you want to run are:
For example to investigate an issue with UCS for a user on the lync.contoso.com pool:
The last invocation of ClsController will write the resulting log entries to standard output, so you might want to re-direct it to a file by using >.
You can get an understanding of which components are included in which CLS scenarios by the Lync Management Shell command Get-CsClsScenario. Below I’m showing how to find the components or providers in the CPS scenario:
In most environments you won’t see this, but depending on your infrastructure you might get a prompt when signing in to Lync similar to the one in the picture below. You might be asking yourself why do I get this prompt?
Microsoft Lync 2010 adds enhanced trust checking when connecting to automatically discovered servers Lync servers or Exchange servers. The additional trust checking has been implemented to enhance the protection against DNS spoofing attacks. Automatically discovered servers are servers found by looking up SRV or A records in DNS based on the SIP URI or primary SMTP address domains as well as DHCP Option 120. Servers specified manually in the Lync client are assumed trusted by the fact that you manually specified them. The same is true for any servers Lync is re-directed to by trusted servers in another domain.
When Lync has discovered a server in DNS it checks it against the list of trusted domains. If the check is successful the server is trusted and the connection is established. If the check is not successful, the above trust prompt is shown, and the user gets the ability to see the certificate being presented by the server and decide if he/she should trust the server. The user can chose to trust the server and connect to it, always trust the server or try to connect to another server. Always trusting a server adds the domain of the server to the list of trusted domains.
The list of trusted domains are compiled using the follow rules:
When Lync checks a server against the list of trusted domains it loops through the saved domains and test if the server is a member of the domain, either directly or as sub-domains. For example say the list of trusted domains contains d.e and h.i.j. A check for server s1.b.c.d.e will be successful, because b.c.d.e is a sub-domain of d.e. A check for server s2.i.j will not be successful, since i.j is not equal to or a sub-domain of either d.e or h.i.j.
The check of trust is not directly connected to certificates and their subjects or subject alternate name (SAN) entries. It is a pure test against the list of trusted domains. However it is clear that the FQDN of any server Lync connects to needs to be presented in that servers certificate subject and/or SAN. Otherwise the TLS connection can’t be made.
It might be easier to understand this by way of a couple of examples. Let’s assume the following environment:
In the above environment the list of trusted domains will contain fabrikam.com. When Jeff signs in Lync will find the DNS SRV record _sipinternaltls._tcp.fabrikam.com and it will attempt to connect to server.contoso.com on port 5061. However before it does that it will check if the server is trusted against the list of trusted domains. In this case the check fails and a trust prompt will be shown for server.contoso.com
Let’s now assume that the environment is changed to the following:
The list of trusted domains is still fabrikam.com. When Jeff signs in Lync will find the DNS SRV record _sipinternaltls._tcp.fabrikam.com and it will attempt to connect to sip.fabrikam.com on port 5061. First Lync checks it against the list of trusted domains. The test is successful and the trust prompt is NOT shown. The certificate of the Lync director server.contoso.com is checked to verify that it covers sip.fabrikam.com.
Let’s add automatic discovery for Exchange servers to the mix and assume that the environment is changed to the following:
The list of trusted domains is still fabrikam.com. When Jeff signs in Lync connect as before. However Lync will also try to access Exchange Autodiscover service to get information about how and where it can access Jeff’s mailbox. Lync will use the primary SMTP address domain and try to access the autodiscover service by using the URL’s https://contoso.com/autodiscover/autodiscover.xml and https://autodiscover.contoso.com/autodiscover/autodiscover.xml. In our case it will find the DNS A record for autodiscover.contoso.com and Lync checks it against the list of trusted domains. The check fails and a trust prompt will be shown for autodiscover.contoso.com.
The list of trusted domains is still fabrikam.com. When Jeff signs in Lync connect as before. Lync will try to access Exchange Autodiscover service as above, but will fail since there is no A record for autodiscover.contoso.com. Lync will then try to find a SRV record for _autodiscover._tcp.contoso.com and it will get the target autodiscover.fabrikam.com returned. Lync will check autodiscover.fabrikam.com against the list of trusted domains and it will find a match. This means the server is trusted and the prompt above is NOT shown.
When configuring DNS to support automatic discovery of Lync and Exchange servers for Lync please follow these best practices:
Thanks to Brian for background information and review.
Central Management Store (CMS) is a repository to store management data in the form of topology, configurations and policies. The repository is implemented as an SQL database (xds[1]). The configuration information is stored as XML documents in the database. CMS services are built around this repository to replicate the management data to required machines.
The access to the repository is provided through and limited to a Microsoft Lync Server 2010 Dynamic Link Library (DLL) called Microsoft.Rtc.Management.Core.dll. The DLL also enforces validations and scope resolutions etc. All consumers of the repository and its data, including service components and Lync Server Management Shell, uses this dll to interact with the CMS store.
The way to modify information in CMS is by using one of the tools: Topology Builder (TB), Lync Server Management Shell (PS) and Lync Server Control Panel (LsCP). It is described in Figure 1.
Figure 1 Interacting with CMS
CMS includes the key functionality of validating any information being written to it before it commits to the database. CMS implements and checks many rules for dependencies and inter-dependencies between components and server roles. In this way we make sure that the topology is valid and does not contain any un-supported configurations[2]. The validation logic is also available and used by the tools mentioned above.
CMS operates in a single master/multiple replica system. In every Lync Server 2010 deployment there is only a single master CMS and all servers running Lync Server 2010 have a local replica of CMS. All updates to information in CMS takes place at the master. The information is then replicated to all replicas. We will discuss how the replication works in the section How does CMS replicate.
It is recommended to install CMS on an Enterprise Edition (EE) pool so that it benefits from the high availability built into the Enterprise Edition. In such a configuration the master xds database is located in the same SQL Server instance as the backend databases, typically RTC. Each Front-End in the pool will have the replica xds database in a local SQL Express instance called RTCLOCAL. See Figure 2 showing a pool with 2 front-ends FE1 and FE2 and a SQL back-end BE.
Figure 2 CMS database placement in an EE pool
If CMS is installed on a Standard Edition (SE) pool the master xds database will be located in the normal SQL Express instance called RTC. Mirroring the front-end servers in an Enterprise Edition pool the Standard Edition pool will also create a replica xds database located in the SQL Express instance called RTCLOCAL. See Figure 3 showing an SE pool SE.
Figure 3 CMS database placement in an SE pool
The location of the master is found by looking up a Service Connection Point (SCP) for the master CMS. The SCP is an object in Active Directory created under the path of the following Distinguish Name (DN), CN=Topology Settings, CN=RTC Service,DC=<domain>, of type msRTCSIP-GlobalTopologySetting. This object contains the msRTCSIP-BackEndServer attribute, which specifies the FQDN of the master and the instance name of the SQL Instance. All tools use the SCP to locate and connect to the CMS master.
The SCP is typically created by Topology Builder when it initially publishes the topology based on information in the topology, and this is the recommended method for creating the SCP[3].
If you want to move the CMS store to a new pool the PowerShell cmdlet Move-CsManagementServer has to be used and it will also update the SCP to point to the new location.
In PowerShell the cmdlet Get-CsManagementConnection will show the connection information used when communicating with the CMS master. TB and LsCP will always read and write to CMS master. In PowerShell many of the Get-Cs* cmdlets accepts the switch –LocalStore, which will display the information found in the local replica of CMS.
The consumers, i.e. local Lync Server 2010 services running on the server, will always read from the local replica. This ensures resilience in case the master or the network connection to the master is not available. Resilience of CMS is discussed in more details in section Resilience.
CMS is implemented using three Windows services:
All three services run on the CMS master; however, only REPLICA runs on the replica (that is every Lync Server). We will describe what the services do in the section on replication.
As described above CMS stores configuration information. In previous versions that kind of information was stored in Active Directory, SQL and WMI. So why was the choice taken to move it to CMS?
The above reasons justified the need to create the central configuration information repository based on SQL. Lync Server 2010 still stores user type information in the user objects in Active Directory and maintains backward compatibility with system level settings stored in Active Directory for interoperability with Office Communications Server 2007 and Office Communications Server 2007 R2.
CMS stores information as XML documents. CMS stores three types of information: Topology, Policy and Configuration and these three types of information can be stored in four different scope levels: Global, Site, Service and Tag. The topology document contains the topology information generated by TB. The policy type contains all the different policies configurable in Lync Server 2010 (i.e. dial plan, client, conferencing etc.). The configuration type contains all the different settings, which can be configured in Lync Server 2010 (i.e. certificates, call park orbit number range, dial-in conferencing access numbers etc.).
There is only one XML document per information type and scope (i.e. one XML document will contain all dial plans with Site scope while another XML document will contain all dial plans with Global scope).
The tools will write to the XML documents through internal programmatic interfaces provided by CMS, i.e. Microsoft.Rtc.Management.Core.Dll. It is not supported to manipulate the XML documents directly.
As described above all writes are done to the CMS master and all Lync Server 2010 servers have a local replica of CMS. It is therefore necessary to update the replicas from the master. This process of transferring information updates from master to replica is called replication. The replication process consists of copying information between directories from the master to the replicas, applying the changes received to the replica and report status back to the master.
The CMS master uses a directory structure shared with other Lync Server components in network share defined in the topology document. The name of the top level directory is the Service Id of the CMS master. The tree structure is the following: <Lync Server FileStore>\<CMS Service Id>\CMSFileStore\xds-master, where <Lync Server FileStore> is the name of the directory selected to be the FileStore used by the CentralMgmt service in the topology document and CMS Service Id is the Service Id of the CentralMgmt service in the topology document . The directory, xds-master, contains two sub-directories replicas and working. The replicas directory contains a sub-directory for each of the replicas. Each sub-directory is named after the server’s FQDN. Within each replica direction are two sub-directories: from-replica and to-replica, (See Figure 4).
Figure 4 CMS xds-master directory structure
Each replica uses a directory structure in the file share, xds-replica (\\<replica>\xds-replica), to synchronize with the CMS master, where <replica> is the FQDN of the replica. The xds-replica contains three sub-directories: from-master, to-master and working (see Figure 5).
Figure 5 Replica directory structure
Each 60 seconds a task is run to determine if a change has been made to the CMS master and needs to be replicated. The unit of replication is the changed XML document, i.e. if a dial plan with global scope has been added, the full XML document containing dial plans with global scope will be replicated. All changes made since the last time the task was run are batched together into a data package – data.zip (see Figure 6). The data package also contains meta-data. (See Figure 7).
Figure 6 Data package
The size of the data package is small, typically less than 100 Kb, which makes for fast replication across the network without any substantial impact to the bandwidth.
Figure 7 The content of a data package
The MASTER generates the data package containing new changes to CMS and stores a copy in each to-replica directory for every replica.
The data package must be copied to all replicas. All Lync Server 2010 servers, except the Edge Server, uses the Windows file copy SMB[4] protocol mechanism to push the data package from the CMS master to the replica.
For Edge servers the file copy is performed over an HTTPS channel. The Edge Server runs a Web Service (https://<edgeserverfqdn>:Port/ReplicationWebService) on the port specified for the ManagementServices in the topology document. The default port is 4443. The Web Service, ReplicationWebService, does not require IIS to be installed on the Edge Server. It is implemented as part of the REPLICA service. The certificate used for the HTTPS channel is the internal or default certificate created for the Edge Server.
It is the responsibility of the FTA service running on the CMS master to copy the data packages from the master to the replicas. The FTA service has change notifications[5] on all the to-replica directories. It is alerted when the MASTER service places data packages in those directories and starts the file copy process to the replicas.
On a replica the REPLICA service has change notification on the from-master directory. It gets alerted when the FTA service has copied the data package to the replica. It then extracts the data package and applies the changes to the local CMS replica. After applying the CMS changes the REPLICA generates a status package – status.zip. The status package contains information for the CMS master about the status of the application of the CMS changes.
The REPLICA service will place the status package in the to-master directory. The FTA service running on the CMS Master has change notifications on the to-master directory on all replicas (except on Edge Servers). It is alerted about the new status package. On Edge Servers the FTA regularly polls the to-master directory to see if a status.zip package is placed there. Then polling frequency is increased when the FTA is expecting a status.zip package, i.e. after it has just transferred a data.zip package to the Edge Server. It then copies the status package from the replica to the from-replica directory on the CMS Master for the given replica.
The MASTER has change notifications on all from-replica directories. It will process the status package and update the CMS Master.
When a Lync Server starts up the REPLICA generates a status.zip package to report the current status to the CMS Master.
On the replica the Lync Server 2010 services (consumers) have registered for changes to the different types of XML documents in the replica. They will poll the local replica each 60 seconds to discover any changes to the XML document(s) they are interested in.
The two 60 second intervals means that it can take around 2 minutes from changes to be visible to the consumers (60 seconds poll on master + replication delay + 60 seconds poll on replica)
Microsoft recommends installing CMS on an Enterprise Edition pool for resiliency of the CMS services. One of the front-end servers in the pool is designated as the active master. All front-end servers in a pool run the MASTER and FTA services, but only on the front-end server designated as the active Master are CMS tasks performed.
To ensure high availability, a heartbeat mechanism is used to failover the active master to another front-end server if the current designated front-end server is not responsive. To determine which front-end server is designated as the active master use the PowerShell command:
Get-CsManagementStoreReplicationStatus –CentralManagementStoreStatus
In addition to the high availability of the CMS services built-in to the front-end servers architecture of an Enterprise pool, the CMS database can be made resilient by using SQL Server Clustering. To protect the data stored in the CMS database, SQL Server backup procedures can be leveraged using the cmdlet Export-CsConfiguration –Filename <file.zip> on a regular basis.
As previously mentioned the services from Lync Server 2010 server will always communicate with the local CMS replica and not the CMS master. If communication between the CMS master and the replica is disconnected, then the replica fails to receive any CMS updates. Nevertheless, the Lync services are able to continue functioning even without the latest CMS updates. When communication is re-established the local replica updates and the Lync services obtain the latest CMS information. If the replica has been without contact with the CMS master for an extended time the CMS master will gradually bring it up-to-date. It might take up to 1 hour to get the replica fully updated.
If the CMS master is not accessible from PowerShell or Lync Server Control Panel, updates (add or remove information) in CMS is not possible..
Item
Explanation
UpToDate
The replica is up-to-date with the CMS master
ReplicaFqdn
The full qualified domain name of the replica
LastStatusReport
latest date and time when the MASTER received a status package from the replica
LastUpdateCreation
latest date and time when the MASTER generated a data package to the replica
ProductVersion
version of Lync Server
Table 1 Output from Get-CsManagementStoreReplicationStatus
If Get-CsManagementStoreReplicationStatus is run with the parameter –CentralManagementStoreStatus it will display information about the active master. The information listed with this parameter is shown in Table 2.
LastUpdatedOn
The last time the master CMS database was changed
ActiveMasterFqdn
The full qualified domain name of the Lync Server designated as the active CMS master
ActiveMasterLastHeartBeat
latest date and time when the active master sent a heartbeat
ActiveFileTransferAgentFqdn
The full qualified domain name of the Lync Server designated as the active File Transfer Agent
ActiveFileTransferAgentLastHeartBeat
latest date and time when the active File Transfer Agent sent a heartbeat
ActiveReplicas
The list of active (not deleted) replicas
DeletedReplicas
The list of deleted replicas (servers no longer active in the topology)
Table 2 Output from Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus
To force replication you can use the PowerShell command Invoke-CsManagementStoreReplication. The command clears the last status report field from the CMS, which triggers replication. This command should be used with caution as is generates unnecessary traffic on the network due to the replication of all configuration to all machines.
Both Get-CsManagementStoreReplicationStatus and Invoke-CsManagementStoreReplication have the parameter –ReplicaFqdn, which will scope the action to only the specified replica.
I would like to express my gratitude to Erdinc Basci, Serkan Kutan and Santhosh Misro who designed and implemented CMS and tirelessly explained CMS to me. Thanks to Rui for his multiple reviews of the text and his help in making it more English However all mistakes are my own.
[1] Xds is an abbreviation for XML Document Store.
[2] The OCS Best Practice Analyzer (BPA) provide configurations checks to flag such issues post deployment.
[3] It can be changed using the PowerShell cmdlet Set-CsConfigurationStoreLocation –SQLServerFqdn -SqlInstanceName
[4] http://msdn.microsoft.com/en-us/library/cc246231(v=PROT.13).aspx
[5] http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx
Imagine you desperately want to get Microsoft Lync Server 2010 up and running. You quickly run Setup.exe, Prepare first Standard Edition server, install Topology Builder, use Topology Builder to create the topology and then perform steps 1 and 2 of the four steps for Installing or Updating Lync Server System:
However after step 2 you realize you need to make a change to the topology. You startup Topology Builder, make the change and Publish Topology. You then re-run step 2, but it is not picking up the changes you made to the topology, even if Publish Topology succeeded. Why?? Let me explain.
Step 1 performs, among other things, installation & creation of the SQL Express instance rtclocal hosting the local replica of CMS (for a discussion about this see here) and loading of the configuration (including the topology) from the CMS master. When you ran this it loaded the initial copy of the topology you published the first time you ran Topology Builder.
When you ran Topology Builder the second time and did the second Publish you updated the CMS master. However you haven’t updated the local replica created in Step 1. After the first run of this step the Run button in the Setup UI is disabled and you can’t re-run it. Step 2 of the installation always reads from the local replica of CMS and it is therefore not picking up the changes you made to the topology. On an operational Lync Server the local replica is updated via CMS replication, but the server you are working on is not operational yet. So what can you do?
The easiest option is to start up Lync Server Management Shell on the server and issue the following two cmdlets:
Export-CsConfiguration will read the configuration (including the updated topology) from the CMS master and store it in a ZIP file. The Import-CsConfiguration with the –LocalStore switch will import the configuration in the local replica of CMS (in reality doing a manual CMS replication). After performing the two cmdlets you should be able to re-run step 2 above and it will pick up your topology changes.
(Updated Oct 15 to fix misunderstanding around how EnableBWPolicyOverride works)
In this post I will show you how to configure CAC or bandwidth management and describe how the user experience will be when making calls where no bandwidth is available.
Imagine the setup below. Two network segments (10.164.28.0 and 10.164.25.0) with a router between. Two sites in the topology – Copenhagen and Odense. One user, a Lync Server 2010 SE box and a PSTN Gateway on both segments and the the user is signed in to the local SE box. Both users are UM enabled in a dial plan hosted on the Exchange 2010 SP1 server in Copenhagen.
I want to configure CAC to disable all audio and video between Copenhagen and Odense. In order to do that I use the PS script below:
# Bandwidth PolicyProfile New-CsNetworkBandwidthPolicyProfile -Identity AllBlocked -AudioBWLimit 0 -AudioBWSessionLimit 200 -VideoBWLimit 0 -VideoBWSessionLimit 3000
# Network Regions New-CsNetworkRegion -NetworkRegionID DK1 –CentralSite site:cph1 -Description "Copenhagen" New-CsNetworkRegion -NetworkRegionID DK2 –CentralSite site:od1 -Description "Odense"
# Network Region Links $a=New-CsNetworkRegionLink -NetworkRegionLinkID rl1 -NetworkRegionID1 DK1 -NetworkRegionID2 DK2 -BWPolicyProfileId AllBlocked
# Network InterRegion Routes New-CsNetworkInterRegionRoute -InterNetworkRegionRouteID nr1 -NetworkRegionLinks $a.identity -NetworkRegionID1 DK1 -NetworkRegionID2 DK2
# Creates a new CsNetworkSite and assigns that the bandwidth policy we just created New-CsNetworkSite -NetworkSiteID Cph -Description "Copenhagen" -NetworkRegionID DK1 New-CsNetworkSite -NetworkSiteID Od -Description "Odense" -NetworkRegionID DK2
# Create new CsNetworkSubnets New-CsNetworkSubnet -SubnetID 10.164.28.0 -MaskBits 24 -Description "Copenhagen" -NetworkSiteId Cph New-CsNetworkSubnet -SubnetID 10.164.25.0 -MaskBits 24 -Description "Odense" -NetworkSiteId Od
# Setup bandwidth management Set-CsNetworkConfiguration –EnableBandwidthPolicyCheck $true
Let’s assume that the above configuration is in effect and that Alice would like to call Bob. There is not enough bandwidth available to setup the call and the call experience of Alice and Bob is therefore controlled by two parameters (EnableBWPolicyOverride and AllowPSTNReRouting) in the voice policy, they have been granted.
If a user has EnableBWPolicyOverride = True calls to the person will not be subject to bandwidth restrictions. If a user has AllowPSTNRerouting calls he/she makes are allowed to be re-routed via PSTN. In the table below I’ve described what the call experience will be given different values for the two parameters.
Scenario
Alice voice policy
Bob voice policy
Experience
Alice calls Bob
AllowPSTNReRerouting = False
EnableBWPolicyOverride = False
Since Alice has AllowPSTNReRouting = False and Bob has EnableBWPolicyOverride = False the call is being sent directly to Exchange UM and Alice can leave a voice mail for Bob
EnableBWPolicyOverride = True
Since Alice has AllowPSTNReRouting = False and Bob has EnableBWPolicyOverride = True the call is going directly to Bob
AllowPSTNReRerouting = True
Since Alice has AllowPSTNReRouting = True and Bob has EnableBWPolicyOverride = False the call is being routed out the PSTN gateway in Copenhagen and in to the PSTN gateway in Odense
Since Alice has AllowPSTNReRouting = True and Bob has EnableBWPolicyOverride = True the call is going directly to Bob
Microsoft Lync Server 2010 continues to support Kerberos and NTLM authentication, when accessing web services hosted on Lync Server 2010, in fact it is the recommend deployment option. There are number of advantages to using Kerberos including faster authentication, mutual authentication and more features available compared to NTLM.
To use Kerberos authentication against a service it is necessary to have an AD object holding the Service Principal Name (SPN) of the service and to act as the authentication principal for the application pool running the service. In OCS 2007/OCS 2007 R2 the AD objects were the user accounts used to run the services, typically RTCService and RTCComponentService. In Lync Server 2010 all services and application pools are running as Network Service so there are no objects to hold the SPN’s and authenticate against.
Using normal user accounts in OCS 2007/OCS 2007 R2 had the added complexities that they typically fell under password expiration policies leading to expired passwords and potential service down-time. Additional being user accounts they held certain privileges in the AD forest.
Design
To solve the problem of missing AD object to hold the SPN(s), missing authentication principal and the issues around using normal user accounts Lync Server 2010 introduces the use of computer account objects for this purpose. They can hold the SPN’s, can be used as authentication principals and is not subject to password expiration policies.
Configuration and how it works
To make it easy to configure the use of Kerberos authentication a number of PS cmdlets have been implemented:
Deployment Considerations
You can use the same Kerberos account for one or more sites. Depending on your site structure, network infrastructure and administration model it might be recommendable to use one Kerberos account per site. For instance if you use only one Kerberos account and have a global deployment with central administration updating the Kerberos account password will mean that the machine, on which you run the PS cmdlet, needs to contact all servers running the WebServices service in all sites using DCOM. Depending on your network infrastructure this might take long time.
Operations
Troubleshooting
One problem you might see due to faulty Kerberos configuration is that access to Web Services or Lync Server Control Panel keeps prompting for username and password, even if the correct information is given.
The following PS cmdlets are very helpful in diagnosing what could be wrong in an environment
You can also use the Windows 2008 command setspn –L <Kerberos account> to list the SPN’s registered on the Kerberos account. The SPN’s are stored in the servicePrincipalName attribute on the computer account object in AD.
Acknowledgements
Thanks to Jason, Adit, Weimin and Peter for background information
[1] To see the servers in the topology running the WebServices service use the PS cmdlet Get-CsService -WebServer
I’m not talking about having too many friends on Facebook, too many connections on LinkedIn or too many followers on Twitter. I’m talking about the real deal – too many watchers – that is too many people watching or subscribing to your presence information.
If you are very popular other Microsoft Lync 2010 users might see the message Maximum Followers Reached in the contact card, when they want to see your presence (shown below).
It all starts by a user subscribing to another users presence. In my case it is tu26 subscribing to tu27’s presence. The relevant parts of the outgoing SUBSCRIBE is shown below with the 5 different categories being asked for.
CSeq: 1 SUBSCRIBE <batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe" uri="sip:tu26@inframss.dk" name=""> <action name="subscribe" id="94941760"><adhocList><resource uri="sip:tu27@inframss.dk"/></adhocList> <categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist"> <category name="state"/> <category name="services"/> <category name="contactCard"/> <category name="note"/> <category name="calendarData"/> </categoryList></action></batchSub>
CSeq: 1 SUBSCRIBE
<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe" uri="sip:tu26@inframss.dk" name=""> <action name="subscribe" id="94941760"><adhocList><resource uri="sip:tu27@inframss.dk"/></adhocList> <categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist"> <category name="state"/> <category name="services"/> <category name="contactCard"/> <category name="note"/> <category name="calendarData"/> </categoryList></action></batchSub>
On the Microsoft Lync 2010 Server the User Services component realize tu27 has reached the maximum and it returns the message below as a response to the SUBSCRIBE above.
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:tu26@inframss.dk" version="0" fullState="false"> <resource uri="sip:tu27@inframss.dk"> <instance id="0" state="terminated" reason="quotaExceeded" statusCode="413" cid=tu27@inframss.dk msDiagCode="2012"/> </resource> </list>
The msDiagCode = 2012 and statusCode = 413 are translated by the Microsoft Lync 2010 client into the message Maximum Followers Reached. At the same time the User Services component logs a warning with event id 32078 describing that the user has reached the limit (see below).
The net effect is that the user tu26 will not be able to see the presence of tu27 before one of the other watchers removes his subscription by signing out or removing tu27 from the contact list.
How can you as an administrator change the limit for these popular users?
In Lync Server 2010 the CsPresencePolicy controls the limit. It has two parameters MaxPromptedSubscriber and MaxCategorySubscription. The meaning of Prompted and Category Subscriptions are explained here. The default value for MaxPromptedSubscriber is 200 and the default value for MaxCategorySubscription is 1000 (the relationship 1:5 make sense since, as you can see above, presence subscription asks for 5 categories).
You can change the Global CsPresencePolicy, create one with Site scope or define one with user scope (tag) and grant the policy to the popular user.
Lync Web App is a new Silverlight based web browser client that allows participants to join meetings hosted on Microsoft Lync Server 2010. It is primarily used by users that do not have Lync 2010 installed.
A user initiates the meeting join process by clicking the Join Online Meeting link in the meeting invite or calendar item, clicking the Join Online button in the Microsoft Outlook reminder window or by copying the meeting URL into the browser and activating it. The meeting URL is based on SimpleUrl defined on the sever and could be on the form https://meet.inframss.dk/tu27/7Q3DSSYV, where meet.inframss.dk is the SimpleUrl, inframss.dk is the SIP domain, tu27 is the organizer and 7Q3DSSYV is the meeting id.
When the meeting URL has been activated the Lync Server runs the join launcher. The main steps performed by the join launcher are:
As can be seen from above it is not possible to use Lync Web App, if you already have one of the other clients installed. Fear not – there is a trick If you append ?sl= to the meeting URL, i.e. like https://meet.inframss.dk/tu27/7Q3DSSYV?sl=, the join launcher will launch the above web page and enable you to select Lync Web App no matter which clients you have installed.
Thanks to Annika for information for and review of this post.
One of the steps in creating OAuth integration between Lync Server 2013 and Exchange Server 2013 is to create a New-CsPartnerApplication on Lync 2013 referencing the OAuth metadata document from Exchange 2013 (http://technet.microsoft.com/en-us/library/jj688151.aspx):
New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl "https://autodiscover.litwareinc.com/autodiscover/metadata/json/1"
When running this cmdlet you might get the error "New-CsPartnerApplication: Cannot bind parameter 'MetadataUrl' to the target. Exception setting "MetadataUrl": "The metadata document could not be downloaded from the URL in the MetadataUrl parameter or downloaded data is not a valid metadata document, error: The remote server returned an error: (500) Internal Server Error."
When you look in the IIS log on the CAS server you will see a corresponding entry similar to this "2012-11-20 14:03:57 192.168.200.40 GET /autodiscover/metadata/json/1 - 443 - 192.168.200.35 - 500 0 0 265".
I have seen this in a couple of cases and the common root cause has been that the "Microsoft Exchange Server Auth Certificate" has been missing from Local Computer\Personal certificate store.
The "Microsoft Exchange Server Auth Certificate" certificate is used by the OAuth implementation on Exchange 2013. You can see it referenced in the output of Get-AuthConfig:
Get-AuthConfig
RunspaceId : b7de8683-bd90-4e24-a78f-d6933871cd48
CurrentCertificateThumbprint : A33E4C629AE9553E186F93474E796D598B1F7424
PreviousCertificateThumbprint :
NextCertificateThumbprint :
NextCertificateEffectiveDate :
ServiceName : 00000002-0000-0ff1-ce00-000000000000
Realm :
Name : Auth Configuration
The certificate with CurrentcertificateThumbprint needs to be listed, when you do Get-ExchangeCertificate on the Exchange 2013 servers. If it is not, there you will see the problem with Internal Server Error.
The fix is to create a new "Microsoft Exchange Server Auth Certificate" by using the following sequence of cmdlets In EMS on the MBX server:
Remember to do iisreset on both CAS and MBX servers. Then finally, you can try to re-issue the New-CsPartnerApplication cmdlet.
Update: Jan 15. 2013: Matt reported that he had to add a step, 6) Set-AuthConfig –clearpreviouscertificate, to get it to work in his lab.
Media Bypass is a new feature in Lync 2010 enabling media to flow directly between clients and PSTN gateways. The basic concept is that the client and the Mediation Server exchanges BypassId’s and if the Id’s match each other media bypass is possible, but not guaranteed (as I’ll discuss later). The BypassId’s are assigned either globally, in which case all servers and clients use the same Id, or per network site, in which case the Id is assigned per subnet membership of the servers and clients. You can control if media bypass is used per PSTN Gateway using Set-CsTrunkConfiguration –EnableBypass.
As I wrote above it is the Mediation Server responsible for the PSTN gateway, which will decide if media bypass can be established. It happens during the signaling in the call setup phase. The PSTN gateway is not necessarily involved.
I’ve set it up in my lab and wanted to share some learning's:
<provisionGroup name="mediaConfiguration" > <propertyEntryList > <property name="bypassEnabled" >true</property> <property name="internalBypassMode" >Any</property> <property name="externalBypassMode" >Off</property> <property name="bypassId" >c61755ed-402f-4b3b-86e2-2bd96252a23c</property> </propertyEntryList> </provisionGroup>
Ilse has a great post on how she configured the integration between Exchange 2010 SP1 OWA and Microsoft Lync Server 2010. Her lab configuration had the Exchange 2010 SP1 CAS server role co-located with HUB and MBX, but not co-located with the UM role.
If you have a slightly different configuration (like me), where the CAS and UM roles are co-located there is a small catch to following the steps Ilse outlines (in fact it is having the roles co-located on the same server and having created integration between Exchange UM and Lync Server using a SIP UM dial plan hosted by the UM server) .
The catch is that you’ll see an Error event being logged by LS Protocol Stack (event ID 14563) upon RTCSRV start, where it is basically complaining about having two entries in the known server table with different version numbers. You’ll see one entry with the role 'Application Server' and version 5 and another entry with role 'Authorized Host' and version 0. The entry with role ‘Application Server’ comes from the outcome of running New-CsTrustedApplicationPool & New-CsTrustedApplication. The entry with role ‘Authorized Host’ comes from the ExUMRouting component in Lync Server, which creates these entries for all Exchange UM Servers it finds in Active Directory hosting SIP UM dial plans.
You can safely ignore the error event, since shortly after the error event you’ll see an information event (ID 14493 from LS Protocol Stack) adding the entry with role ‘Application Server’ to the known servers table.
If you want to get rid of the error event you can remove the CsTrustedApplication representing Exchange OWA. However remember to add it back again, if you one day separate the CAS and UM role or move the SIP UM dial plan(s) to be hosted by another UM server.
As a user of OCS 2007 you have the ability to receive Missed Call Notifications. How the Missed Call Notification is generated depends on the configuration of the user in question. Let's examine the different options.
As an Enterprise Voice enabled user with voice mail coming from Exchange 2007 SP1 UM you can receive Missed Call Notifications and Voice Mails in your Exchange 2007 mailbox, when someone has tried to call you from either Office Communicator 2007 (OC), Office Communicator 2007 Phone Edition (OCPE) or from the PSTN/PBX. The Missed Call Notifications and Voice Messages are generated by Exchange 2007 SP1 UM.
The Missed Call Notifications can be generated in two ways depending on the state of the call when the caller hangs up. The states, for a user online with OCS 2007 and without call forwarding active, are:
If the caller hangs up in state 1 or 2 the call is still under control by OCS 2007. OCS 2007 will process the hang up and send a SIP INFO message to Exchange 2007 SP1 UM and instruct it to send a Missed Call Notification message to the called user. The SIP INFO message contains information about who is calling and who is called. Exchange 2007 SP1 UM will do reverse number lookup in AD and the called user's Outlook Contacts and will generate the Missed Call Notification message.
If the caller hangs up in state 3 the call is under control by Exchange 2007 SP1 UM and Exchange 2007 SP1 UM will do reverse number lookup in AD and the called user's Outlook Contacts and will generate the Missed Call Notification message.
If the call is in state 4 the called user will only a receive a Voice Mail message and no Missed Called Notification.
If the user is offline or with call forwarding set directly to Voice Mail the call will be routed directly to Exchange 2007 SP1 UM and go to state 3 in the above list.
Enterprise Voice without Exchange 2007 SP1 UM or Remote Call Control
As an Enterprise Voice enabled user without voice mail or a Remote Call Control user you can receive Missed Call Notifications in your Exchange mailbox. The Missed Call Notification is generated by OC 2007 via MAPI. The Missed Call Notification is only generated when OC 2007 is running. Microsoft Outlook does not need to be running.
Enterprise Voice with PBX Integration
As an Enterprise Voice with PBX Integration enabled user the generation of Missed Called Notification is the responsibility of the PBX system. OCS 2007 and OC 2007 will not generate Missed Call Notifications.
In this post I described how Lync 2013 Preview can use high-resolution photos available in Exchange 2013 Preview mailboxes. SharePoint Server 2013 is also able to use the same high-resolution photos. The SharePoint-Exchange photo sync feature implements this.
SharePoint Server 2013 maintains a library of User Photos, just like in SharePoint Server 2010. When SharePoint-Exchange photo sync is enabled, SharePoint's local photo store becomes a cache, and SharePoint Server 2013 treats Exchange 2013 as the master photo store. SharePoint-Exchange photo sync is not a regular sync job that runs on a recurring cycle. Instead, SharePoint Server 2013 requests photos from Exchange 2013 automatically when a user performs an operation that causes a request for their own photo (for example, browsing to their own user profile page). That means that the user needs to have requested his/her own photo, before other users will be able to see it.
When a user with a valid Exchange 2013 mailbox attempts to change their profile photo, SharePoint Server 2013 will launch the Outlook 2013 Web App photo upload dialog.
Two variables (which can be set per web-application) help govern the syncing behavior:
SharePoint Server 2013 is using the Exchange Web Services Managed API V2.0 and Server to Server authentication (S2SOAuth) to be able to read data from Exchange 2013.
Let me show how to configure the integration. I will use the following sample environment to illustrate the configuration:
In the sample environment the programs have been installed on the C: drive.
Configure the Exchange 2013 Autodiscover service to be available on the FQDN autodiscover.contoso.com. Use the following Exchange Management Shell command on e15fe.contoso.com.
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml
SharePoint Server 2013 use the external Url variants for EWS and ECP when accessing the photos on Exchange 2013. In the sample environment I'll use the internal FQDN's also for external use. Use the following Exchange Management Shell command on e15fe.contoso.com.
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –InternalUrl https://e15fe.contoso.com/ews/exchange.asmx –ExternalUrl https://e15fe.contoso.com/ews/exchange.asmx
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory –InternalUrl https://e15fe.contoso.com/ecp –ExternalUrl https://e15fe.contoso.com/ecp
Install the EWS Managed API from the link above on sps15.contoso.com. Make sure that the Microsoft.Exchange.WebServices.dll is loaded into the GAC by using GacUtil. Make sure to use the .NET 4 version of GacUtil (C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools after you have installed .NET 4.0 SDK)
GacUtil /i C:\Program Files\Microsoft\Exchange\Web Services\2.0\Microsoft.Exchange.WebServices.dll
Now it is time to configure SharePoint to do S2SOAuth with Exchange. Use the following SharePoint 2013 Management Shell commands:
We now need to configure the Exchange 2013 side of things. Use the following Exchange Management Shell commands:
Make sure to restart IIS on both front-end and back-end by issuing the following commands in a command window:
Use the following SharePoint 2013 Management Shell commands:
Sign in to Windows as test1 and use IE to access his My site at http://sps15/my. You should now see the high-resolution photo being shown as the profile photo.
If some reason, the photo is not showing you might be able to diagnose the issue by examining the ULS logs available at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS.
Thanks to Ryan, Nathaniel and Sesha for their input to this post.
This post describes how to configure Exchange 2013 OWA IM Integration to Lync 2013. It mentions that you need to create a trusted application pool and trusted application in the Lync 2013 topology representing the Exchange 2013 MBX server and OWA. Let me try to explain why this is so and when you have to do it.
Internally OCS and Lync uses the concept of Known Servers and it maintain a list of them, the so-called Known Servers Table (KST). A server needs to be in the KST, before Lync will communicate with it. The KST is created from information found in the Lync topology. You can also add to the table by creating Trusted Application Pools from Lync Server Management Shell or from adding Trusted application servers in Lync Server 2013 Topology Builder. A Known Server has a version number attached to it. The version number is related to the Lync version used when creating the known server: 6 is Lync 2013, 5 is Lync 2010 and 0 is any.
When RTCSRV starts, it will log event 14492 from LS Protocol Stack listing all the known servers. It will also log event 14493 from LS Protocol Stack, when a server is added to the KST, and event 14495, when a server is removed from the KST.
When the Exchange UM Integration was introduced with OCS 2007, we wanted to automate the creation of known servers for Exchange UM servers. Consequently, the Exchange UM Routing component adds the Exchange servers it finds to the KST. The servers it finds are the Exchange servers hosting SipName UM Dial Plans. It logs event 44024 from LS Exchange Unified Messaging Routing at startup listing the servers it found. It will also log events while running; indicating added or removed Exchange servers. When adding Exchange servers to the KST it sets the version to 0.
That was the background. Let us look at what happens.
We will assume an environment with Lync 2013 and an Exchange 2013 server called ex1.contoso.com. It is running all Exchange 2013 server roles, is hosting a SipName UM dial plan and Exchange OWA IM Integration has been configured.
When the Exchange UM Routing component starts it will add the entry {fqdn=ex1.contoso.com, version=0} to the KST. At this point Exchange UM integration and Exchange OWA IM Integration to Lync 2013 both works.
The Lync 2013 administrator then adds Trusted Application Pool and Application representing the Exchange server and OWA to the Lync topology. This means adding the entry {fqdn=ex1.contoso.com, version=6} to the KST. However, it is not legal to have two entries for the same server with different versions. The event 14563 from LS Protocol Stack is logged and both entries are removed from the KST.
This has the effect that Exchange UM and OWA IM Integration stops working, since there is no entry for ex1.contoso.com in the KST.
How to get Exchange UM and OWA IM integration working again?
Option 1
Remove the Trusted Application Pool and Application representing the Exchange server and the integration will start working again shortly.
Note: The caveat with using this option is that you have to remember to add the Trusted Application Pool and Application back to Lync 2013, if the Exchange server stop hosting a SipName UM dial plan.
Option 2
Restart RTCSRV on the Lync 2013 server. The restart will still produce the error event 14563 and a warning event 44030, but afterwards you will see an Information event 14493 from LS Protocol Stack adding the Exchange 2013 server to the KST. At this point, the integration works again.
Office Web Apps Server 2013 provides the ability to create a farm with one or more machines in it. Recently I had to create a farm with two machines, and it took a little bit to get my head around how to do it. Here is how I ended up doing it
I had the following environment:
On wac1.contoso.dk
I did the following steps:
On wac2.contoso.dk
The tricky part to get right was the last command. You have to run it on the machine you wish to join to the farm, and you have to reference an existing machine in the farm. It needs the reference to be able to read the farm settings.
One of the new features in Exchange 2013 CU1 is support for creation of Online Meetings in Outlook Web App (OWA). When you create a new event in OWA you can click on Online meeting, and the meeting is created as an Online meeting. You can also update an existing event to be an Online meeting. See Figure 1 for a screenshot showing the Online meeting button.
Figure 1 Creating an Online Meeting
In order for this feature to work, the following needs to be in place:
OWA use the Unified Communications Web API (UCWA) interface to create the Online Meeting. When OWA boots, and whenever you create a new event in Calendar tab, OWA checks, if UCWA is enabled for the user. OWA uses the Lync Autodiscover service to find the user's pool and the UCWA Url. If UCWA is enabled (happens automatically if the user is homed on a Lync 2013 pool) OWA shows the Online meeting button.
The communication between OWA and Lync happens via Server to Server OAuth (S2SOAuth).
When the Online meeting button is clicked, OWA is creating the Online Meeting. It sets the parameters used for the meeting based on the relevant CsMeetingConfiguration setting (Global, Site or Service scope) in Lync 2013. The parameters used are:
In addition to these parameters, it creates the meeting with the options that all company employees joins as presenters and bypass the lobby.
You are able to join the Online Meeting from the OWA calendar peek via the Join button (see Figure 2). You can also join from the Calendar read form (see Figure 3).
Figure 2 Calendar peek with Join button
Figure 3 Calendar read form with the Join button
We now configure the Lync side of things. Use the following Lync Server Management Shell commands:
We now configure the Lync meeting configuration for the pool. Use the following Lync Server Management Shell commands:
In situations, where the Online meeting button does not appear or the creation of the Online meeting fails, the administrator will have to enable logging in OWA to get diagnostic information about the potential issues. Logging is enabled by editing the web.config file in C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa on the Exchange 2013 CU1 mailbox server and changing the line <add key="OWAIsLoggingEnabled" value="false" /> to <add key="OWAIsLoggingEnabled" value="true" />. After saving the changed web.config, recycle the MSEXchangeOWAAppPool in IIS Manager for OWA to pick up the change. OWA will now log information to log files in the directory C:\Program Files\Microsoft\Exchange Server\V15\Logging\OWA\server\.
Ask the user to repro the problem and examine the log file in the directory above. Look for lines with the keywords GetUcwaUserConfiguration and CreateOnlineMeeting and timestamps matching the repro. Hopefully he information in the log file can point to the root cause of the issue.
In this post we announced the Skype-Lync connectivity. One of the screenshots in the post shows adding the Skype contact in the Lync 2013 client using Add a Contact Not in My Organization .
In the fly-out Skype is listed with the Skype logo. The Lync client get the list via in-band provisioning from the server based on the enabled public providers. To add Skype to the list issue the following commands on the Lync server in Lync 2013 Lync Server Management Shell:
Wait for CMS replication and sign out and in again in the Lync client. Skype should now be in the list.
Update 9-AUG-2013: Lync 2013 clients connecting to Lync 2010 servers will not show Skype in the add contact drop-down list. This is caused by Lync 2010 server not supporting the in-band provisioning group sending the list of public providers to the client.
In Microsoft Lync 2013 for Mobile release 5.2 we are introducing support for passive authentication via Active Directory Federation Services (AD FS). It enables customers to sign in using other authentication methods than Active Directory including support for users, who don't know their Active Directory password. Kaushal gives a great overview about the feature in his post here. In this post I will describe the sign-in experience for passive authentication user on Microsoft Lync 2013 for Mobile and how to configure your environment to support passive authentication.
Kaushal shows the sign experience on the mobile device using AD FS forms based authentication in his Figure 3. In this section I'll describe when the user has to sign in using passive authentication and when it is not necessary based on different scenarios.
There are 3 elements relevant for the sign in experience:
The Save Password setting is not used when using Passive Authentication. Table 1 lists the passive authentication sign in experience behavior in different scenarios.
Passive Authentication needed
Initial sign in
Yes
Sign in after previous sign out
User is signed out by server failure or other event
Administrator revokes the Lync client certificate or it expires, while the user is signed out of the mobile app
Administrator revokes the Lync client certificate or it expires, while the user is signed in on the mobile app. Web ticket is still valid
No
Administrator revokes the Lync client certificate or it expires, while the user is signed in on the mobile app. Web ticket is expired or not valid
Yes. This is needed to authenticate to get a new valid web ticket
The user is signed in to the mobile app and the web ticket expires. Lync client certificate is valid
No. The web ticket is renewed by using the Lync client certificate without the user having to do passive authentication
WP8: The user is signed in to the mobile app, press Home button and selects the mobile app in the jump list or starts it from the program list. Web ticket is valid
WP8: The user is signed in to the mobile app, press Back button and starts the app again from the program list. Web ticket is valid
WP8: The user is signed in to the mobile app and reboots the device. Mobile app is auto-started
iOS: The user is signed in to the mobile app, press Home button and selects the mobile app in the multi-tasking list or starts it from the program list
iOS: The user is signed in to the mobile app, press Home button and remove the mobile app from the multi-tasking list and starts it from the program list
iOS: The user is signed in to the mobile app and reboots the device. Mobile app is auto-started
WP8 and iOS: The user is signed in to the mobile app and it is in the foreground, the device goes to lock screen and the user unlocks the device
Table 1 Sign in experience
The following versions of the device operating systems are recommended for use with passive authentication
In order to implement passive authentication for Microsoft Lync 2013 for Mobile users it is necessary to disable some of the other authentication methods supported by Lync 2013 Server. Lync 2013 Server offers a list of authentication methods to clients, and others methods take precedence over passive authentication. If you are not disabling these other methods they will be used to authenticate instead of passive authentication.
Table 2 shows the service type, server role and the authentication methods, which needs to be enabled and disabled for passive authentication for mobile users. Please note that these settings are NOT on a per user basis, but rather on a per pool basis. That means all users homed on a specific pool will use the settings.
Service Type
Server Role
Disabled Authentication Methods
Enabled Authentication Methods
Configuration cmdlet
WebServer
Lync Autodiscover
Kerberos and NTLM
Certificate and Passive Auth
Set-CsWebServiceConfiguration -Identity WebServer:<FQDN> -UseWindowsAuth None -UseCertificateAuth $true -UseWsFedPassiveAuth $true
Front End
Registrar
Certificate
Set-ProxyConfiguration -Identity Registrar:<FQDN> -UseKerberosForClientToProxyAuth $false -UseNtlmForClientToProxyAuth $false -UseCertificateForClientToProxyAuth $true
Table 2 Authentication Methods
Note1: The pool running the Lync Autodiscover service, i.e. the pool pointed to by lyncdiscover.<SIP domain> and lyncdiscoverinternal.<SIP domain>, authenticates the users based on its own authentication settings and not those of the users home pool. If there is a discrepancy between the authentication methods supported on the Lync Autodiscover pool and the user home pool, the sign in experience might be non-optimal and might not work. In such scenarios it is recommended to use manual discovery configuration for either the passive authentication users or for the default authentication users.
Note2: Table 2 does not list configuration of Registrar for Edge servers. This needed for passive authentication for Microsoft Lync 2013 desktop clients, but Edge is not used by the Microsoft Lync 2013 for Mobile clients.
The Microsoft Lync 2013 for Mobile clients contains the following functionality dependent on Microsoft Exchange:
The Microsoft Lync 2013 for Mobile clients does not support passive authentication against Microsoft Exchange, and therefore the device is not able to use Exchange Web Services (EWS) to connect to Microsoft Exchange and get information about meetings and voice mails. Unified Contact Store (UCS) continues to work, since the connection to Microsoft Exchange is happening via the Lync server.
It is recommend to set the AllowExchangeConnectivity parameter to $false in the CsMobilityPolicy for the passive authentication users. This will make sure that the meetings and voice mail environments are not shown on the device and that errors related to the failed communication to Microsoft Exchange are not shown on the device.
Haven discussed the sign in experience, topology requirements and Microsoft Exchange related features it is now time to explain how to configure passive authentication end-to-end. To illustrate this I will use a fictitious environment and in it I am using AD FS as the passive authentication provider.
For the purpose of explaining the configuration of passive authentication assume the lab configuration shown in Table 3.
Role
Internal FQDN
External FQDN
Reverse Proxy using ARR
rp-int.contoso.dk
rp-ext.contoso.dk
AD FS
sts2012r2-int.contoso.dk
sts2012r2-ext.contoso.dk (same IP address as rp-ext.contoso.dk)
Lync 2013 July 2013 or later CU pool
lync-int.contoso.dk
lync-ext.contoso.dk (Web Services FQDN – same IP address as rp-ext.contoso.dk)
Lync Discover running on Lync 2013 July 2013 or later CU pool
lync2-int.contoso.dk
lyncdiscover.contoso.dk (same IP address as rp-ext.contoso.dk)
Table 3 Servers in the environment
All users on lync-int.contoso.dk will be configured to use passive authentication.
For configuration of ARR as a reverse proxy for Lync Server 2013 please see this http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx. Remember to change port numbers before you click Add for the server.
Table 4 shows the Server Farms and Servers defined in ARR.
Server Farm
Servers
sts2012r2-ext.contoso.dk
lync-ext.contoso.dk
lyncdiscover.contoso.dk
Table 4 ARR Server Farms and Servers
Table 5 shows the DNS records in the internal and external DNS servers that has been configured in the environment.
FQDN
Internal DNS
External DNS
Contains the external IP address of Reverse Proxy
Contains the internal IP address of Reverse Proxy
N/A
Contains the internal IP address of lync-int.contoso.dk
lyncdiscoverinternal.contoso.dk
Contains the internal IP address of lync2-int.contoso.dk
Table 5 DNS records
The environment supports hair pinning, that is the ability of internal computers to access external available resources via the reverse proxy. As an example internal Lync servers can connect to the AD FS server using its external DNS record.
The environment has been configured with mutually trusted certificates containing the appropriate FQDN's as subject alternate names (SAN). The certificate used on the reverse proxy is from a public trusted root CA.
The AD FS server has been configured for base functionality and forms based authentication has been enabled. We need to configure AD FS to have a trust relationship with Lync Server 2013. This is done by creating a Relaying Party Trust and appropriate Issuance Authorization and Transform rules. Information about the trust partner is contained in the federation metadata document.
The trust relationship means that Lync will trust credentials coming from AD FS. AD FS could have obtained them from a number of authentication providers, but in this environment we use Active Directory as authentication provider via the AD FS forms authentication.
The following section describes how to configure Active Directory Federation Services to support passive authentication with Lync Server 2013.
$IssuanceAuthorizationRules = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'
$IssuanceTransformRules = '@RuleTemplate = "PassThroughClaims" @RuleName = "Sid" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]=> issue(claim = c);'
Add-ADFSRelyingPartyTrust -Name Lync-PassiveAuth -MetadataURL https://lync-int.contoso.dk/passiveauth/federationmetadata/2007-06/federationmetadata.xml
Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules
Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules
Add-ADFSRelyingPartyTrust -Name Lync-Ext-PassiveAuth -MetadataURL https://lync-ext.contoso.dk/passiveauth/federationmetadata/2007-06/federationmetadata.xml
Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules
Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules
The trust between AD FS and Lync has been created on the AD FS side. We now need to create it on the Lync side. This is done by using the following command:
New-CsWebServiceConfiguration -Identity webserver:lync-int.contoso.dk -WsFedPassiveMetadataUri https://sts2012r2-ext.contoso.dk/federationmetadata/2007-06/federationmetadata.xml
After the trust now has been established from both sides we need to set the required authentication methods as shown in Table 2. From the Lync Management Shell command-line interface issue the following commands:
Set-CsWebServiceConfiguration -Identity webserver:lync-int.contoso.dk -UseWsFedPassiveAuth $true -UseWindowsAuth none –UseCertificateAuth $true
New-CsProxyConfiguration -Identity registrar:lync-int.contoso.dk -UseKerberosForClientToProxyAuth $false -UseNtlmForClientToProxyAuth $false
Final server configuration element is to create the Mobility Policy disabling Exchange connectivity. From the Lync Management Shell command-line interface issue the following command:
New-CsMobilityPolicy -Identity PassiveAuthUsers -AllowExchangeConnectivity $false
Make sure your users are homed on lync-int.contoso.dk and then grant them the PassiveAuthUsers mobility policy. From the Lync Management Shell command-line interface issue the following command for all the relevant users:
Grant-CsMobilityPolicy -PolicyName PassiveAuthUsers -Identity <user>
The environment is now setup to support passive authentication. However since Lync Autodiscover points to a Lync pool, which has not been configured to support passive authentication, the users on lync-int.contoso.dk needs to manual configure the discovery address on the mobile device. The settings will be:
These addresses needs to be set in the Microsoft Lync 2013 for Mobile clients by clicking on more details on the home screen, setting auto-detect server to Off and entering the relevant addresses. The relevant fields are in Figure 1.
Figure 1 Manual Discovery configuration
In order to troubleshoot the passive authentication between Microsoft Lync 2013 for Mobile, AD FS and Lync Server 2013 the best starting point is looking at the https communication between the client and the servers.
You can use the Fiddler tool for this. The tool does not run on the mobile device, but by running it on a desktop or laptop in the network, you can look at the communication. You can use similar steps as the ones here for Windows Phone 7 to do it. Please understand that the only way to remove that certificate on Windows Phone 8 is to reset the mobile device.
You can also use the Lync 2013 desktop client and Fiddler on a desktop/laptop. You start Fiddler and the Lync client, enter the SIP URI of a passive authentication user and make sure to click 'Delete my sign-in info' before clicking 'Sign in'. Based on your environment you might need to manually configure the internal and external server names (to overcome the Lync Autodiscover issue mentioned earlier).
Some things to look at in the Fiddler trace related to sign in:
On the Lync server side the relevant trace component is WebInfrastructure.
I was planning to write a post on how Exchange 2010 SP1 UM is able to send Message Waiting Indicator (MWI) to Lync 2010, but then I discovered that this is already covered in great detail in the Exchange 2010 SP1 documentation.
What I will add to the description is a little more how it works on the Lync side. The UM server sends a SIP NOTIFY to the Lync Server, when a new voice message is received for a user. On the Lync side the user needs to be Enterprise Voice enabled. An excerpt of such a NOTIFY is shown below:
NOTIFY sip:tu64@contoso.com:5061 SIP/2.0
From: <sip:tu64@contoso.com:5061>;epid=EDDFA7F3EE;tag=f03dc3ff8
To: <sip:tu64@contoso.com:5061>
CONTACT: <sip:tu64@contoso.com:5061>
EVENT: message-summary
SUBSCRIPTION-STATE: terminated
USER-AGENT: RTCC/3.5.0.0 MSExchangeUM/14.01.0218.012
CONTENT-TYPE: application/simple-message-summary
Messages-Waiting: yes
Message-Account: sip:tu64@contoso.com:5061
Voice-Message: 8/3
The Lync Server will transform this into a BENOTIFY to the user containing the MWI category. An excerpt of such a BENOTIFY is shown below:
BENOTIFY sip:10.164.25.133:52667;transport=tls;ms-opaque=a98bb6354a;ms-received-cid=7C7300;grid SIP/2.0
To: <sip:tu64@contoso.com>;tag=fd7ce0df4d;epid=e0bc6cec3d
From: <sip:tu64@contoso.com>;tag=23480080
CSeq: 126 BENOTIFY
Require: eventlist
Content-Type: application/vnd-microsoft-roaming-self+xml
Event: vnd-microsoft-roaming-self
subscription-state: active;expires=6978
<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self" xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories">
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:tu64@contoso.com">
<category name="mwi" instance="0" publishTime="2010-10-26T07:42:42.387" container="1" version="32" expireType="static">
<mwi xmlns="http://schemas.microsoft.com/2006/09/sip/mwi" messageWaiting="true" unreadVoiceMailCount="8" readVoiceMailCount="3"/>
</category></categories></roamingData>
Some time after reception of the BENOTIFY the client will connect to Exchange 2010 SP1 through EWS and fetch the details of the voice messages and display them. The MWI is used on Lync 2010 Phone Edition running on devices like Polycom CX600 and Astra 6725ip.
In Microsoft Lync Server you can configure bandwidth management such that media can use an alternate path, if adequate bandwidth is not available in primary path. It is done using the Set-CsNetworkRegion cmdlet and the boolean parameters AudioAlternatePath and VideoAlternatePath. The alternate path is via any deployed A/V Edges and the Internet.
In a topology as the above allowing AudioAlternatePath and VideoAlternatePath would enable Alice and Bob to communicate with media via the Internet in case bandwidth on the direct link between Odense and Copenhagen is unavailable.
Another way of looking at AudioAlternatePath and VideoAlternatePath is as parameters controlling, if media is allowed to flow via the Internet when bandwidth management is enabled. In a scenario as below with Alice being remote on the Internet she will not be able to establish a media session with Bob, if AudioAlternatePath and VideoAlternatePath are not True in the network region incorporating the A/V Edge used by Alice.
My colleague Keith pointed out that I’m not talking about PSTN re-routing in this post. The reason is that alternate path is only related to Internet. I covered PSTN re-routing in this post.
You might have seen the event with id 32113 from LS User Services informing that “Pas with FQDN: x.y.z has been detected up” and wondered what Pas is?
Pas or PAS stands for Presence Agent Server and is the component of the Lync Server handling presence logic and traffic. Some of the tasks performed by PAS are:
PAS is running in the RTCSRV process and is active on EE front-ends and SE servers, but it is not running on Directors and SBAs.
In Microsoft Lync Server 2010 the Mediation Server is now able to control multiple PSTN gateways. How does this impact outbound routing of calls?
Imagine a scenario as in the figure below.
We have two sites A and B each with a SE server, a co-located MS and a PSTN gateway. In the topology the PSTN gateways depends on their local MS, i.e. have them as the next hop. We have a route describing that calls to Denmark (+45) should be sent to PSTNGateway1.
Alice wants to call a number in Denmark. Since the Mediation Server can control multiple PSTN gateways will the call go via MS1 or MS2? The outbound routing component on SE2 will send the call to the MS on which the PSTN gateway depends. In this case MS1.
Imagine we change the scenario slightly as in the figure below.
We now add PSTNGateway2 to the route for Denmark. What will happen when Alice wants to call a number in Denmark? The outbound routing component on SE2 will round-robin over the two PSTN gateways, so the call will either go via MS1 or MS2.
Microsoft Lync 2010 is able to use the Wireless Access Point, a laptop is connected to, as the key to show your location. The client sends the so called Basic Service Set Identifier (BSSID), which can be seen as an identifier for the wireless access point, to the Location Information Service (LIS) and it will return the location information for that wireless access point as it is defined in LIS.
However today I ran into the following situation. I used my Windows 7 laptop and was connected to wireless access point A. Lync was showing the correct location LocationA. I then put the laptop to sleep and went to another building far away from wireless access point A. I resumed the laptop and Lync was still showing my location as LocationA. This puzzled me, since there was no way that my laptop could still be connected to wireless access point A. Something was wrong.
I looked at the wireless configuration on the laptop using netsh wlan show interface and netsh wlan show networks mode=bssid. The interface command showed my laptop being connected to a BSSID, which didn’t appear in the list of BSSID’s my laptop could see (as listed by netsh wlan show networks mode=bssid). Strange.
Turns out there is an issue in Windows 7 where it will report the wrong BSSID to applications after the laptop has been resumed. The issue is described in http://support.microsoft.com/kb/2385405 and there is a hotfix available. So Lync was being given the old BSSID and used that to get my location from LIS. It was doing the right thing, but it was based on stale information. I installed the hotfix and couldn’t repro the issue afterwards.
In W12/W13 ExUMRouting will route a call to voice mail to all the UM servers that support a given UM dial plan in a round robin fashion. When upgrading from Exchange 2007 SP2 UM to Exchange 2010 this is an issue, because an Exchange 2007 SP2 UM Server can’t communicate with an Exchange 2010 mailbox store. This has forced customers to create new UM dial plans specifically for Exchange 2010 and only have those dial plans supported by Exchange 2010 UM servers. This results in end-user and administrative pains, since moving to a new dial plan requires a new PIN and creating new um dial plans requires new pilot numbers.
In Lync Server 2010 ExUMRouting has been enhanced to also use the version of the UM Server supporting a dial plan, when routing the call. The way it works in a high-level is the following:
FOR all UM Servers supporting UM dial plans of type SIP
THEN get the majorVersion of the UM Server, where majorVersion = (<ExchangeAD Server Object>.versionNumber >> 22) & 0x3F
WHEN a call comes in destined to Exchange UM
THEN
Create a list of all UM servers of the highest version supporting the dial plan
Send the call to those UM servers in a round robin fashion
If none of these UM servers replies drop the call
The majorVersion is 8 for Exchange 2007 and 14 for Exchange 2010.