Update May 25, 2011: The official Server Administration chapter including the CMS section has now been published - http://blogs.technet.com/b/drrez/archive/2011/05/24/microsoft-lync-server-2010-resource-kit-server-administration.aspx

The following information is an official preview of a single section of the Microsoft Lync Server 2010 Resource Kit, which will debut chapter-by-chapter in 2011 on the DrRez blog and then later be available in its entirety. This text is © 2010 Microsoft and published with permission.

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:

• Lync Server Master Replicator Agent (MASTER)
• Lync Server File Transfer Agent (FTA)
• Lync Server Replica Replicator Agent (REPLICA).

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.

What is stored in CMS?

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?

• Storing the information in different places made it difficult for the administrator to understand where the information was stored and which interfaces should be used to manipulate it
• When adding new features and functions to the product there was often a need to extend the Active Directory schema with new object classes and attributes. Extending the Active Directory schema is often a source for delay with customers
• The location for storing information in Active Directory have changed between product releases and has led to issues for customers with global deployments using the deprecated locations
• The Edge server role is typically deployed in the perimeter and therefore without access to the corporate Active Directory
• Active Directory does not include rich capabilities for validation of dependencies, data validation, guarantee data consistency between replicas and the data model is not structured

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.

How does CMS replicate?

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)

Resilience

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..

Managing CMS replication

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.

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.

Acknowledgements

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

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?

Background

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.

Checking trust

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:

• Any trusted domains (created by always trusting a server)
• The users SIP URI domain (via AD, the usual sign-in page or manually configured)
• The domain of the Lync server, which  Lync successfully connected to last

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.

Trust and Certificates

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.

Examples

It might be easier to understand this by way of a couple of examples. Let’s assume the following environment:

• The SIP URI of the user is jeff@fabrikam.com
• server.contoso.com is a Lync SE server in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target server.contoso.com on port 5061
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

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 SIP URI of the user is jeff@fabrikam.com
• server.contoso.com is the Lync director in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
• There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

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 SIP URI of the user is jeff@fabrikam.com
• Jeff has an Exchange 2010 mailbox and the primary SMTP address jeff@contoso.com
• There is a DNS A record for autodiscover.contoso.com with IP address 192.168.101.30
• There is a DNS A record for cas.contoso.com with IP address 192.168.101.30
• The Exchange 2010 Client Access Server is running on cas.contoso.com
• server.contoso.com is the Lync director in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
• There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

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.

Let’s now assume that the environment is changed to the following:

• The SIP URI of the user is jeff@fabrikam.com
• Jeff has an Exchange 2010 mailbox and the primary SMTP address jeff@contoso.com
• There is a DNS SRV record for _autodiscover._tcp.contoso.com with target autodiscover.fabrikam.com on port 443
• There is a DNS A record for autodiscover.fabrikam.com with IP address 192.168.101.30
• There is a DNS A record for cas.contoso.com with IP address 192.168.101.30
• The Exchange 2010 Client Access Server is running on cas.contoso.com
• server.contoso.com is the Lync director in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
• There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

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.

Best practices

When configuring DNS to support automatic discovery of Lync and Exchange servers for Lync please follow these best practices:

• Make sure that the target of any SRV record is in a domain, which will be automatically trusted by Lync per the rules above
• Make sure that the target of any SRV record is an A record. Using CNAME records as targets is not supported by Lync and is not allowed per RFC2782 – A DNS RR for specifying the location of services (DNS SRV)
• Make sure certificates used on Lync and Exchange servers includes all the FQDN’s used as targets for the SRV records. Otherwise Lync won’t be able to setup a TLS connection to the server

Thanks to Brian for background information and review.

When Lync 2013 shipped we did not provide the user interface to allow the user to configure his/her picture to be available on a web site (sometimes referred as photo url). With the November 7, 2013 update to Lync 2013 we have added this capability to Lync 2013. We have also changed the layout a little bit in the My Picture options page.

The ability to configure the picture from a web address is controlled by a new ClientPolicy entry called EnablePresencePhotoOptions. It can only be set via the Lync Server Management Shell (see below for an example on how to do it).

When the entry is set to True Lync 2013 will display a 3^rd radio button in the My Pictures options page, as shown below.

The user can then select the radio button and enter the Url to the picture. The maximum size of the picture is controlled by the ClientPolicy parameter MaxPhotoSizeKB. In the screenshot below I've set this value to 1000 and that is reflected in the user interface. The picture at the Url needs to be publically available without requiring a password for accessing it.

In the first screenshot you can also see the change in the layout of the page. We are no longer showing 2 different sizes of the picture in use, just one. We will show a 200x200 pixels version of the picture, either scaled up or down as needed.

Here is an example of how to set the policy entry using Lync Server Management Shell

• $pe=New-CsClientPolicyEntry -Name EnablePresencePhotoOptions -Value True
• $po=Get-CsClientPolicy
• $po.PolicyEntry.Add($pe)
• Set-CsClientPolicy -Instance $po

Introduction

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.

How is the sign in experience?

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:

• Authentication token issued by AD FS after the user has authenticated
• Web ticket. The web ticket is used by the mobile app to authenticate the communication with the UCWA component on Lync Server 2013 and is issued by the Lync server after the app has presented the AD FS authentication token. The web ticket has 8 hours expiration time
• Lync client certificate. The Lync client certificate is issued by the Lync Certificate Provisioning Service to the mobile app after it has obtained a web ticket. As an administrator you can see and revoke the certificates by using Get-CsClientCertificate and Revoke-CsClientCertificate. The default Lync client certificate has a 6 month expiration time. It can be changed by setting the MaxValidityPeriodHours value on the WebService configuration.

The Save Password setting is not used when using Passive Authentication. Table 1 lists the passive authentication sign in experience behavior in different scenarios.

Table 1 Sign in experience

Device Operating System versions

The following versions of the device operating systems are recommended for use with passive authentication

• Windows Phone 8: It is recommended to use version 8.0.10211.204 or later
• iOS: 6.1 or later

Topology Requirements

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.

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.

Functionality dependent on Microsoft Exchange

The Microsoft Lync 2013 for Mobile clients contains the following functionality dependent on Microsoft Exchange:

• Unified Contact Store (UCS)
• Meetings environment
• Voice Mail environment

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.

End-to-End configuration

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.

Table 3 Servers in the environment

All users on lync-int.contoso.dk will be configured to use passive authentication.

Reverse Proxy Configuration (ARR)

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.

Table 4 ARR Server Farms and Servers

DNS

Table 5 shows the DNS records in the internal and external DNS servers that has been configured in the environment.

Table 5 DNS records

Hair pinning

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.

Certificates

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.

AD FS Configuration

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.

1. Log in to sts2012r2-int.contoso.dk using a Domain Admin account
2. Launch Windows PowerShell
3. Make sure sts2012r2-ext.contoso.dk is set as the Federation Service Name
   1. Get-AdfsProperties | fl HostName
4. Establish a trust partnership with the Lync Server 2013 Pool that will be enabled for passive authentication. For pools add the trust for both internal and external Web Services FQDN. In this environment we need to add it for lync-int.contoso.dk and lync-ext.contoso.dk. Configure it by running the following command: 

$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

Lync 2013 Server configuration

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:

1. Log in to lync-int.contoso.dk using a Lync administrator account
2. Launch the Lync Server 2013 Management Shell
3. From the Lync Management Shell command-line interface, create a new Web Service configuration for lync-int.contoso.dk by running 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

User configuration

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>

Manual Discovery configuration

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:

• Internal Discovery Address: https://lync-int.contoso.dk/Autodiscover/autodiscoverservice.svc/Root
• External Discovery Address: https://lync-ext.contoso.dk/Autodiscover/autodiscoverservice.svc/Root

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

Troubleshooting

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:

• Is the client being re-directed to the AD FS in the sign in sequence via a 302 re-direct to the AD FS url? If this is not happening check the WsFedPassiveMetadataUri and that UseWsFedPassiveAuth has been set to true. The Lync server will report any errors in communicating with AD FS in the event log
• Does the returned MEX document contain the expected WsFedPassive_policy? If it lists the wrong combination check the enabled authentication methods on the WebServiceConfiguration for the pool
• Does AD FS return a reference back to the Lync pool on the virtual directory PassiveAuth/PassiveAuth.aspx after the user has signed into AD FS? If not, check the relaying party trust on AD FS
• Any 5xx errors coming back
• Are cookies disabled on the mobile device?

On the Lync server side the relevant trace component is WebInfrastructure.

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.

How it works

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:

• UserPhotoExpiration (in hours) specifies the minimum time that must elapse before SharePoint Server 2013 will check for a given user's photo again.
• UserPhotoErrorExpiration (in hours) specifies the minimum time that must elapse before SharePoint Server 2013 will check for a given user's photo when it received an error on the previous attempt.

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.

Configuration

Let me show how to configure the integration. I will use the following sample environment to illustrate the configuration:

• One Exchange 2013 Client Access server with FQDN e15fe.contoso.com
• One Exchange 2013 Mailbox server with FQDN e15be.contoso.com.
  • The test users have Exchange 2013 mailbox with the primary SMTP address test1@contoso.com and test2@contoso.com
  • High resolution photos have been uploaded to the mailboxes
• One SharePoint Server 2013 server with FQDN sps15.contoso.com
  • A Web Application available at https://sps15 and http://sps15. Alternate access mapping set for https://sps15.contoso.com
  • Appropriate SSL certificate set on the web site in IIS
  • A My Site site collection available at http://sps15/my
  • The test users have My sites available on http://sps15/my
• A DNS record for autodiscover.contoso.com points to e15fe.contoso.com

In the sample environment the programs have been installed on the C: drive.

Step 1: Exchange 2013 Autodiscover Service

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

Step 2: External Url's set

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

Step 3: Exchange Web Services Managed API V2.0

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

Step 4 SharePoint S2SOAuth configuration with Exchange

Now it is time to configure SharePoint to do S2SOAuth with Exchange.  Use the following SharePoint 2013 Management Shell commands:

• New-SPTrustedSecurityTokenIssuer -name "Exchange" -MetadataEndPoint "https://autodiscover.contoso.com/autodiscover/metadata/json/1"
• $sts=Get-SPSecurityTokenServiceConfig
• $sts.HybridStsSelectionEnabled = $true
• $sts.AllowMetadataOverHttp = $false
• $sts.AllowOAuthOverHttp = $false
• $sts.Update()
• $exchange=Get-SPTrustedSecurityTokenIssuer "Exchange"
• $app=Get-SPAppPrincipal -Site http://sps15 -NameIdentifier $exchange.NameId
• $site=Get-SPSite http://sps15
• Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.RootWeb -Scope sitesubscription -Right fullcontrol -EnableAppOnlyPolicy

Step 5 Exchange S2SOAuth configuration with SharePoint

We now need to configure the Exchange 2013 side of things. Use the following Exchange Management Shell commands:

• cd \Program Files\Microsoft\Exchange Server\V15\Scripts>
• .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl https://sps15/_layouts/15/metadata/json/1 -ApplicationType sharepoint

Make sure to restart IIS on both front-end and back-end by issuing the following commands in a command window:

• iisreset e15fe
• iisreset e15be

Step 6 Configure SharePoint 2013 Exchange photo sync

Use the following SharePoint 2013 Management Shell commands:

• $wa = Get-SPWebApplication http://sps15
• $wa.Properties["ExchangeAutodiscoverDomain"] = "autodiscover.contoso.com"
• $wa.UserPhotoImportEnabled = $true
• $wa.UserPhotoErrorExpiration = 1.0
• $wa.UserPhotoExpiration = 6.0
• $wa.Update()

How to try it out?

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.

Acknowledgements

Thanks to Ryan, Nathaniel and Sesha for their input to this post.

(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:

• ClsController.exe -start –scenario <scenario> –pools <pool fqdn>
• Repro issue
• ClsController.exe -stop –scenario <scenario> –pools <pool fqdn>
• ClsController.exe  -flush –pools <pool fqdn>
• ClsController.exe  -search –pools <pool fqdn> –components <component> –loglevel <loglevel>

For example to investigate an issue with UCS for a user on the lync.contoso.com pool:

• ClsController.exe -start –scenario lyssanducs –pools lync.contoso.com
• Repro issue
• ClsController.exe -stop –scenario lyssanducs –pools lync.contoso.com
• ClsController.exe -flush –pools lync.contoso.com
• ClsController.exe -search –pools lync.contoso.com –components lyss –loglevel verbose

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:

• PS C:\> $scenario=Get-CsClsScenario global/cps
• PS C:\> foreach ($sc in $scenario.provider) { $sc.name }
  CpsDiagnostics
  CpsHostingFramework
  CpsOrbit
  Collaboration
  S4
  Sipstack
  

This post describes how to configure Exchange 2013 OWA to have IM integration to Lync 2013. Here I would like to give some troubleshooting tips in case you can't get the integration to work.

Web.Config edits

• Make sure you edit the OWA web.config file on the MBX server(s)
• Make sure it has the right format, i.e. no space after the hex characters in the certificate thumbprint and ending /> brackets
  • <add key="IMCertificateThumbprint" value="EA5A332496CC05DA69B75B66111C0F78A110D22" />
  • <add key="IMServerName" value="atl-cs-001.litwareinc.com" />
• Make sure you add the two lines in the right section of the OWA web.config file (<appSettings>)
• Make sure to restart the MSExchangeOWAAppPool after the edit

Certificate

• Make sure that the certificate you use on the MBX server is trusted by the Lync 2013 server and vice versa. Typically this means using certificates from a mutually trusted CA, perhaps the enterprise CA
• Make sure the subject name of the certificate and one of the subject alternative names are the FQDN of the MBX server

OwaVirtualDirectory and OwaMailboxPolicy

• Make sure you have set InstantMessagingEnabled to $true and set InstantMessagingType to Ocs

User

• Make sure the user has a proxy address with SIP type (you can set it in EMS with the cmdlet set-Mailbox <alias> -EmailAddresses @{Add="SIP:<SIP URI, i.e. u@h.com>"})
• Make sure that the CASMailbox representing the user has the appropriate OwaMailboxPolicy

Signing in

• Look for event ID 112 from MSExchange OWA on the MBX server signaling that the Instant Messaging Endpoint Manager was initialized successfully. This happens at first IM sign-in after OWA App Pool restart
• If you get event 112, but the user is still not able to sign in, check certificates and that the user has the SIP proxy address

Lync 2013 Topology

• If the Exchange 2013 MBX server is also hosting a UM dial plan of URITYpe SipName do not add the Exchange 2013 MBX server as a Trusted Application Pool. The Exchange UM integration in Lync 2013 will automatically add the Exchange 2013 MBX server as a trusted server in Lync 2013

Logfile and tracing

• OWA IM Integration writes logfiles to the directory C:\Program Files\Microsoft\Exchange Server\V15\Logging\OWA\InstantMessaging on the MBX server. If there is no logfile in that directory or no InstantMessaging directory, OWA itself has not yet understood that it needs to support IM integration to Lync
• On the Lync 2013 server use SIPStack tracing (All Levels and All Flags) to get an idea of what might be wrong (Use LyncDebugTools.msi http://www.microsoft.com/en-us/download/details.aspx?id=35453)
• On Exchange 2013 MBX you can use OcsTracer.exe in C:\Program Files\Microsoft UCMA 4.0\Runtime\Tracing to see the SIP traffic generated by OWA IM
• To Start: OCSTracer.exe Start /Component:Collaboration,TL_noise,tf_component,tf_diag,tf_protocol,tf_connection /Component:S4,TL_VERBOSE,tf_component,tf_protocol /LogFileMode:NewFile,20
• To Stop and see traces: OCSTracer Stop /Component:Collaboration /component:s4 /OutputFile:traces.txt /View

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>

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.

CSeq: 1 SUBSCRIBE

<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.

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

Prerequisites

In order for this feature to work, the following needs to be in place:

• The scheduling user needs to be Lync enabled and homed on a Lync 2013 pool
• The mailbox of the scheduling user needs to be hosted on Exchange 2013 CU1
• Server to Server authentication (S2SOAuth) needs to be configured between Exchange 2013 and Lync 2013
• The Lync Autodiscover service needs to be configured (http://technet.microsoft.com/en-us/library/hh690030.aspx) with DNS records for lyncdiscover.<SIP domain> and lyncdiscoverinternal.<SIP domain>

How it works

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:

• PstnCallersBypassLobby
• LogoUrl¹
• LegalUrl²
• HelpUrl
• CustomFooterText

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

Configuration

Let me show how to configure the integration. I will use the following sample environment to illustrate the configuration:

• One Exchange 2013 CU1 Client Access server with FQDN e15fe.contoso.com
• One Exchange 2013 CU1 Mailbox server with FQDN e15be.contoso.com.
  • The test user has Exchange 2013 CU1 mailbox with the primary SMTP address test1@contoso.com
• One Lync Server 2013 Enterprise Edition pool with one Lync Server 2013 Front End Server lyncfe1.contoso.com
  • Pool FQDN is lync.contoso.com.
  • One test user is enabled with SIP URI test1@contoso.com
• A DNS record for autodiscover.contoso.com points to e15fe.contoso.com
• A DNS record for lyncdiscoverinternal.contoso.com points to lync.contoso.com
• The url pointing to legal text is https://web.contoso.com/legalurl.txt
• The url pointing to help text is https://web.contoso.com/helpurl.txt
• The custom Contoso logo is https://web.contoso.com/logo.jpg

Step 1: Exchange 2013 Autodiscover Service

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

Step 2 Exchange S2SOAuth configuration with Lync

We now need to configure the Exchange 2013 side of things. Use the following Exchange Management Shell commands:

• cd \Program Files\Microsoft\Exchange Server\V15\Scripts>
• .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl https://lync.contoso.com/metadata/json/1 -ApplicationType Lync

Step 3 Lync S2SOAuth configuration with Exchange

We now configure the Lync side of things. Use the following Lync Server Management Shell commands:

• New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.contoso.com/autodiscover/metadata/json/1
• Set-CsOAuthConfiguration -Realm contoso.com

Step 4 Lync Meeting Configuration

We now configure the Lync meeting configuration for the pool. Use the following Lync Server Management Shell commands:

• Set-CsMeetingConfiguration –LegalURL https://web.contoso.com/legalurl.txt
• Set-CsMeetingConfiguration –HelpURL https://web.contoso.com/Helpurl.txt
• Set-CsMeetingConfiguration –HelpURL https://web.contoso.com/Helpurl.txt
• Set-CsMeetingConfiguration –LogoURL https://web.contoso.com/logo.jpg
• Set-CsMeetingConfiguration –CustomerFooterText "This is the footer text"

Troubleshooting

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.

1. In Exchange 2013 CU1 the logo will only be shown, if the CustomFooterText has text in it
2. In Exchange 2013 CU1 the hyper link for the legal URL will always be empty no matter, if it is set or not

(Updated 15 April 2013)

In the Capacity Planning Guidance we describe that the disk requirements for a Lync 2013 front end server, given our usage model, is eight disks configured as two drives.

• One drive will use two disks in RAID 1 to store the Windows operating system and the Lync 2013 and SQL Express binaries
• One drive will use six disks in RAID1+0 to store databases and transaction logs from the two SQL Express instances (RTCLOCAL and LYSS)

If you have front end server with only two disk drives the Install-CsDatabase command run during installation of Lync Server 2013 will automatically place the databases and transaction logs on the non-system disk drive.

However if you have more than two disk drives you can use the following process to specify the disk drive used for database and transaction logs. In the example, the system drive is C:, there is E: drive and F:\CsData should be used for databases and transaction logs.

1. Start the Lync Server 2013 Deployment Wizard and accept the default location on the C: for the binaries
2. Under Deploy perform Step 1 – Install Local Configuration Store
3. When step 1 is done start Lync Server Management Shell and issue the following command:
   1. Install-CsDatabase -DatabasePaths F:\CsData -LocalDatabases
4. Continue with step 2 and the remaining steps in the Lync Server 2013 Deployment Wizard

This approach will give the location of databases and transaction logs as described in the table below.

Please also note that in Lync Server 2013 we create the rtc and rtcdyn databases and corresponding transaction logs with an initial size of 4 Gb. That mean in total 16 Gb. We are doing that to avoid any performance implication by extending the database and transaction log size during normal operations.

On a fresh Lync 2013 front end Step 3 in the above sequence will fail, because the LYNCLOCAL SQL Express instance has not been installed after step 1 in the deployment wizard. To work-around this problem you can do the following:

1. Continue with step 2 in the deployment wizard and let it install the databases on whatever drive it decides
2. After step 2, delete all databases in RTCLOCAL and LYNCLOCAL instances. You can do it via SQL Management Studio or by using the PS script below and replace Lync2013FE with the correct hostname
3. Issue Install-CsDatabase cmd from 3) above
4. Continue with step 3 in the deployment wizard

    $SqlServer = "Lync2013FE"    

    $connstring = "server=" + $SqlServer + "\rtclocal;trusted_connection=true;"

    $connection = new-object system.data.sqlclient.sqlconnection

    $connection.ConnectionString = $connstring

    $connection.Open()

    $command = new-object system.data.sqlclient.sqlcommand

    $command.Connection = $Connection

    $command.commandtext = "drop database rtc"

    $sqladapter = new-object system.data.sqlclient.sqldataadapter

    $sqladapter.selectcommand = $command

    $results = new-object system.data.dataset

    $reccount=$sqladapter.Fill($results) | Out-Null

    $command.commandtext = "drop database rtcdyn"

    $sqladapter.selectcommand = $command

    $results = new-object system.data.dataset

    $reccount=$sqladapter.Fill($results) | Out-Null

    $connection.Close()

    $connstring = "server=" + $SqlServer + "\lynclocal;trusted_connection=true;"

    $connection = new-object system.data.sqlclient.sqlconnection

    $connection.ConnectionString = $connstring

    $connection.Open()

    $command = new-object system.data.sqlclient.sqlcommand

    $command.Connection = $Connection

    $command.commandtext = "drop database lyss"

    $sqladapter = new-object system.data.sqlclient.sqldataadapter

    $sqladapter.selectcommand = $command

    $results = new-object system.data.dataset

    $reccount=$sqladapter.Fill($results) | Out-Null

    $connection.Close()

(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:

• $Site=Get-CsSite –Identity Søborg

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:

• New-CsTrustedApplicationPool –id jenstr31.inframss.dk –Registrar cs1.inframss.dk -site $Site.SiteId

After having create the trusted application pool you then need to create a trusted application representing SEFAutil. The PS cmdlet to do this is:

• New-CsTrustedApplication –ApplicationId sefautil –TrustedApplicationPoolFqdn jenstr31.inframss.dk –Port 7489

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:

• Install or Update Lync Server System
• Install Local Configuration Store
• Request, Install or Assign Certificates
• Start Services

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.

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:

1. New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn= Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -Services smtp
   1. Do not accept to replace the SMTP certificate when prompted
2. Note the thumbprint of the new certificate. Let us assume it is 7A39541F8DF58D4821967DD8F899B27410F7C081
3. $a=get-date
4. Set-AuthConfig -NewCertificateThumbprint 7A39541F8DF58D4821967DD8F899B27410F7C081 –NewCertificateEffectiveDate $a
   1. Accept to continue despite the fact that the certificate effective date is not 48 hours into the future
5. Set-AuthConfig –PublishCertificate
6. Make sure to remove any potential reference to the previous certificate (which might not exist anymore) by doing Set-AuthConfig -ClearPreviousCertificate.

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.

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:

• Determine language to use based on preferred language(s) in the browser and the language packs installed on the server. If no direct or indirect match (parent) can be found between preferred language(s) and the language packs installed on the server the server language will be used
• It will convert the SimpleUrl based URL to the real URI used to join the meeting. In the above example that URI will be sip:tu27@inframss.dk;gruu;opaque=app:conf:focus:id:7Q3DSSYV
• Determine if the web request came from the Internet or from the internal network by looking at which web site was used
• Determine which client to launch based on the installed client(s). It will check for Lync 2010, Lync 2010 Attendant and Lync 2010 Attendee. If it finds one of these client it will launch them. If both Lync 2010 and Lync 2010 Attendant are installed it will launch the last used client. If you are using Internet Explorer, we will close the resulting webpage for you after the client has launched, since there is no need for you to have it open.
• If none of the clients are installed it will check if Silverlight is installed. If it is not installed it will prompt the user to install Silverlight
• If Silverlight is installed it will continue and determine the value of two Boolean parameters ShowDownloadCommunicatorAttendeeLink and ShowJoinUsingLegacyClientLink in the appropriate CsWebServiceConfiguration. You can scope CsWebServiceConfiguration to Global, Site or Service level.
• If both these parameters are False it will launch Lync Web App directly. If one or both are True it will launch a web page allowing you to select Lync Web App by clicking on “Join the meeting using your web browser”. The page is shown below with both parameters being True.

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.

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:

• Two servers: wac1.contoso.dk and wac2.contoso.dk
• The internal fqdn of the farm should be wac.contoso.dk and the external fqdn should be wacext.contoso.dk
• Hardware load balancer configured for wac.contoso.dk

On wac1.contoso.dk

I did the following steps:

• Installed Office Web Apps Server 2013 and the March 12, 2013 update.
• Used the MMC certificate snap-in to create a certificate from my internal CA based on WebServer template with:
  • Subject name WacFarm
  • Friendly name WacFarm
  • Subject alternate names of wac1.contoso.dk, wac2.contoso.dk,wac.contoso.dk,wacext.contoso.dk, wac1 and wac2
  • Allow private key to be exported
• After the certificate was loaded in the personal local computer certificate store, I exported the certificate with the private key to a file
• Used PowerShell to create the Office Web Apps Farm with the cmd:
  • New-OfficeWebAppsFarm -InternalURL https://wac.contoso.dk -ExternalURL https://wacext.contoso.dk -CertificateName WacFarm -Verbose -AllowHttp:$true

On wac2.contoso.dk

I did the following steps:

• Installed Office Web Apps Server 2013 and the March 12, 2013 update
• Used the MMC certificate snap-in to import the certificate, I had exported on wac1.contoso.dk, into the personal local computer certificate store
• Used PowerShell to join wac2 to the Office Web Apps Farm, which has wac1.contoso.dk as the Master
  • New-OfficeWebAppsMachine -MachineToJoin wac1.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.

You might have wondered exactly which Active Directory permissions the Microsoft Lync Server 2010 PowerShell cmdlets Grant-CsSetupPermission and Grant-CsOuPermission grants which Active Directory group? If so, I hope the following post will stop your wondering.

At the end of this post is a table showing the content of each Active Directory property set referenced in the tables below.

Grant-CsSetupPermission will give the RTCUniversalServerAdmins group the following permission on an OU after having run Grant-CsSetupPermission on the OU.

Running Grant-CsOuPermission -ObjectType User on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission -ObjectType Contact or AppContact on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission -ObjectType Computer on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission –ObjectType Device on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission –ObjectType InetOrgPerson on an OU will grant the following groups the permissions shown in the table below.

Relevant PropertySets and their content are shown below.

Lync Server 2010 and Lync 2010 supports dialing emergency services using Enhanced 911 (E911) in North America. You configure the emergency dial string through the EmergencyDialString parameter to CsLocationPolicy and the value is sent to the Lync client through in-band provisioning. In the screenshot below you can see I have configured it to 911 and set the EmergencyDialMask to 112, which is the number used in Denmark.

When you dial the emergency number in Lync 2010 you will see that the client automatically employ an internal normalization rule, which prepends + in front of the number (see screenshot below). Don’t be alarmed, this is done on purpose to prevent other normalization rules kicking in and in that way potentially re-routing the call to another destination than the emergency service.

When the call is connect you’ll see a notification in the client that is an emergency call and that it is connected to the emergency number. See screenshot below

Depending on the way you are connected to the emergency service you might want to create an outbound translation rule on the trunk configuration to remove the + from the emergency number.

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:

• When changing between enabling Media Bypass Globally and enabling it based on sites and regions make sure to sign out and in again on the client after you’ve made the change. The reason is that the client receives its BypassId via in-band provisioning in the mediaConfiguration provisioningGroup

  <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>
  

• An easy way to determine, if a given call was using media bypass, is to look at the QoE report sent after the call. You can look at it via the Monitoring Server (User Activity Report –> <user you want to look for> –> Details –> Media Quality Report –> Call Information –> Mediation Server bypass call (true/false). You can also look at it in the uccapilog via Snooper. Find the SERVICE message being sent after the call was completed and look in the XML blob for the tag <v2:MediationServerBypassFlag>true</v2:MediationServerBypassFlag>
• As I wrote above the BypassId’s needs to match, but that is not enough to get media bypass. The other requirement is that the two end-points are able to communicate media directly between them. This includes network connectivity, but also that the media encryption level being used by both end-points matches. Out of laziness my PSTN gateway was configured to use TCP and RTP to communicate with the Mediation Server. That worked perfect without media bypass, but it didn’t enable media bypass. The client was configured to RequireEncryption (Set-CsMediaConfiguration –EncryptionLevel) and as such wanted to use SRTP for media. Since the PSTN gateway didn’t accept or offer that media bypass was not working. I had to re-configure my PSTN gateway to use TLS and SRTP to get media bypass working.

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.

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:

• New-CsKerberosAccount - creates a new computer account which can be used by IIS to authenticate against and hold the relevant SPN’s. It is done by using LDAP to access a domain controller in the domain you specify for the account
• New/Set-CsKerberosAccountAssignment – assigns the Kerberos account to the site in CMS
• Enable-CsTopology  - based on the Kerberos account assignments updates the SPN’s on the account as specified in the topology. It is done by using LDAP to access a domain controller in the domain you have specified for the account. The administrator running Enable-CsTopology needs to be 1) an RTCUniversalServerAdmin and 2) be granted setup permission for the AD container(s) in which the SPNs are located in order to add/remove them – this is done through setup delegation using Grant-CsSetupPermission.
• Set-CsKerberosAccountPassword– have two modes of operation depending on the parameters used:
  • 1) It configures IIS on every server running the WebServices^[1] service in every site associated with the account and resets the password for the computer account in AD
  • 2) It configures IIS on a specific server running the WebServices service using another server running the WebServices service as the source for the password.
  • The updating of IIS is done via DCOM to talk to ServerManager remotely. The reset of the password is done via LDAP
• Remove-CsKerberosAccountAssignment removes the Kerberos account assignment rom a site in CMS

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

• Whenever you add a site you need to decide, if you want to enable Kerberos and how you want to create/re-use the Kerberos account.
• Whenever you add a Kerberos account assignment to a site you need to enable the topology using the PS cmdlet Enable-CsTopology
• Whenever you add a server running the WebServices service into a site, which have assigned a Kerberos account, you need to configure IIS and set the password on the new server. This is done using the PS cmdlet Set-CsKerberosAccountPassword.

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

• Test-CsKerberosAccountAssignment tests that Kerberos account assignment is configured, the Kerberos account attributes are OK and that the IIS configuration is OK for all servers in the site running WebServices
• Test-CsTopology tests if Kerberos account assignment is configured on all sites and the attributes for all Kerberos account(s) used in the topology

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

In a previous post I discussed how the policies related to PSTN re-routing and bandwidth policy override worked. In this post I’ll use the same setup and describe how to configure voice routing to support PSTN re-rerouting. I will assume that the calling user is allowed PSTN re-routing by policy and that Alice has been configured with Line URI +4512345678 and Bob with Line URI +4587654321

PSTN re-routing is the ability of the Lync Server to re-route a Lync call via an external network in case bandwidth is restricted. The network is typically the PSTN, but could also be a private PBX infrastructure.

Lync re-routes the call to the Line URI of the called user. It bypass the normal Reverse Number Lookup (RNL), such that the call is not converted back to a Lync call.

The voice policy of the calling user and the normal voice routing configuration are also used for PSTN re-routing. Outbound Routing (OBR) will look to find a matching route (PSTN Usage and number pattern). In order to make sure PSTN re-routing can happen it is therefore necessary to ensure that voice routes are available for the DID range(s) used for Lync users and that PSTN gateways in all sites are listed in those voice routes.

For the setup above the following voice route would enable PSTN re-routing for users with PSTN usage “DK”:

OBR use the following logic when trying to route the call via PSTN re-routing:

• If it can’t find a matching route, i.e. the user is not allowed to call this number or there is no matching pattern, the call is routed to the called users voice mail
• If it finds a matching route it will send the call to one of the returned PSTN gateways
• If multiple PSTN gateways are returned it will try them one by one until the call is successful or there are no more PSTN gateways
• If it happens to try a PSTN gateway located in a remote site the call will fail due to bandwidth restrictions and OBR will try the next returned PSTN gateway.

Let’s try to summarize the different outcomes in the scenario where Alice calls Bob, bandwidth is restricted and Alice has been allowed PSTN re-routing:

In Lync 2013 we changed how we classify poor calls in QoE. The flag is called ClassifiedPoorCall and it is now available in the MediaLine table. It is moved here, because we now support classifying poor calls for audio, video and application sharing.

The conditions we use to classify poor calls are shown in the 3 tables below. The poor call flag is set if one or more the conditions are met. Please note that a record in the MediaLine table can cover multiple media streams. The flagging occurs on the MediaLine level, so if you want to understand specifically which stream was the reason for the classification you need to look at the individual streams and use the columns in the tables below.

Yesterday we made version 2.2 of the Networking Guide available and it now includes the Microsoft Call Quality Methodology Scorecard for Lync Server. The Scorecard is used to implement Call Quality Methodology (CQM) as discussed in Appendix C of the Networking Guide.

The new features in this version of CQM includes:

• PowerShell script to run the CQM queries against the QoE database
• The ability to use different conditions to flag an audio stream as poor
• The ability to remove off-work days from the results and thereby removing outliers skewing the poor stream ratios
• The Excel 2013 macro-enabled Scorecard which can load the CSV files generated by running the CQM queries, draw charts, show the Top 10 Issues for various categories and not least update the Scorecard with green/yellow/red status for the different CQM dimensions

You can read much more about the Scorecard and how to use it in the Microsoft Call Quality Methodology Scorecard for Lync Server document included in the ZIP file located here. Enjoy!

We have made an update available for the Office Web Apps Server 2013 (used by Lync 2013 for PowerPoint presentations). The update is from March 12, 2013, and is available at http://support.microsoft.com/kb/2760445. It is important that you follow our guidance on how to install the update. The guidance is available at http://technet.microsoft.com/en-us/library/jj966220.aspx.

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.

Enterprise Voice with Exchange 2007 SP1 Unified Messaging (UM)

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:

1. OCS 2007 rings all registered end-points for the user
2. After a user defined time-out the call is forwarded to Exchange 2007 SP1 UM
3. Exchange 2007 SP1 UM connects the call and plays the greeting and ask the user to leave a voice mail
4. The voice mail is recorded and sent

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.

You might have the situation that you are receiving Lync Meeting invites from federated partners using Exchange 2013 and Lync 2013, but when Outlook 2013 or OWA 2013 CU1 brings up the reminder dialog for the meeting, the Join button is missing. Outlook and OWA will show the Join button based on the existence of the MAPI property OnlineMeetingExternalLink on the calendar item representing the meeting in the attendee's mailbox.

It is the Lync Meeting Outlook add-in used by the organizer of the meeting, which sets the property on the meeting invite, before it is sent. However the MAPI property might be stripped from the message, when it is sent from the organizers Exchange 2013 environment to your, i.e. the meeting attendee, Exchange 2013 environment. You need to ensure that in the organizer's Exchange 2013 environment, the remote domain matching your Exchange 2013 environment, has the parameter TNEFEnabled set to True (http://technet.microsoft.com/en-us/library/bb232174.aspx#External). When TNEFEnabled is set to true Exchange 2013 does not strip MAPI properties including OnlineMeetingExternalLink and the Join button will be shown on the reminder.

Let us assume that the SMTP domain of the attendee is contoso.com. In the organizer's Exchange 2013 environment it is necessary to create a remote domain with TNEFEnabled = True representing contoso.com. One way of doing it is by using the following commands in Exchange Management Shell:

• New-RemoteDomain -Name contoso.com -DomainName contoso.com
• Set-RemoteDomain -Identity contoso.com -TNEFEnabled:$true