• Certificate Expiration Alerting

    Microsoft Lync Server and Microsoft Exchange Server utilize certificates to manage encryption and authentication. When certificates expire unexpectedly, network administrators are under pressure to resolve the problem quickly. Fortunately, most trusted Certificate Providers inform customers by email before certificates expire. But what happens when certificates are issued by an internal Microsoft Windows Certification Authority? If customers do not have a monitoring solution, such as Microsoft System Center Operations Manager, to provide status updates on certificate expirations, it is a real challenge to keep track of scheduled certificate expirations. The Certificate Expiration Alerter is a free tool that helps prevent unplanned certificate expirations.

    Author: Fabian Kunz

    Publication date: November 17, 2011

    Product version: Windows Server 2003 CA, Windows Server 2008 CA, Windows Server 2008 R2 CA

    Introduction

    The Certificate Expiration Alerter helps IT departments monitor the expiration status of all certificates issued by an internal Windows Server Certificate Authority (CA). When a certificate is about to expire, the Certificate Expiration Alerter sends an email notification with information about the certificate.

    This allows the IT administrator to proactively take action and renew the certificates before they expire and prevent possible service downtimes. This article explains how to use this tool.

    Description

    The Certificate Expiration Alerter is a command-line tool based on .NET Framework 2.0. The tool connects to a Windows Certification Authority (CA) specified as a command-line parameter. It detects which certificates are scheduled to expire on a specified day defined by a command-line parameter. After running the tool the administrator receives email notifications that identify which certificates are set to expire on the specified day. There is an optional regex parameter to filter certificates with specific Common Names. The administrator must create a Scheduled Task to run the tool once per day.

    Purpose

    This tool monitors internally issued certificates that are scheduled to expire. Armed with this information, the administrator can proactively take action to renew certificates before they expire.

    Requirements

    This tool runs on Windows Server 2003, Windows Server 2008 or Windows Server 2008 R2. The Windows version is supported only in English and German. The minimum requirement to run the tool is .NET Framework 2.0.

    Examples

    CertExpAlerter is a command-line tool that supports the following parameters. The parameters are:

    -m = SMTP server name or ip address to relay the notification message.
    -s = sender’s email address in the format sender@company.com.
    -r = recipient’s email address in the format recipient@company.com. To supply multiple email addresses, use the delimiter ";".
    -d = number of days to check when a certificate expires.
    -c = CA server path in form of “CAServerName\Common Name of the CA certificate”
    -f = regular expression to filter based on the certificate’s Common Name.

    The common use case is Scenario 4. Before you create a Scheduled Task for this tool, first run Scenarios 1 and Scenario 2. Scenario 1 (Test Email Receipt) validates that the tool can successfully send emails. Scenario 2 ensures that the user account, used by the Scheduled Task, has sufficient privileges to connect to the Windows CA. If both tests are successful, you can create the Scheduled Task.

    Scenario 1: Test email receipt.
    This command-line sends an immediate test email. This allows the administrator to verify that the tool sends certification expiration notifications.

    CertExpAlerter.exe -m SMTPServerName -s sender@company.com -r recipient@company.com

    Scenario 2: List all issued certificates.
    This command-line argument lists all certificates issued by the CA and includes their expiration information.

    CertExpAlerter.exe -c "CAServer\Root CA"

    Scenario 3: List all issued certificates scheduled to expire in x days.
    This command lists all certificates scheduled to expire in exactly 15 days.

    CertExpAlerter.exe -c "CAServer\Root CA" -d 15

    Scenario 4: Send email notification that identifies certificates scheduled to expire in x days.
    The administrator must create a Scheduled Task and run the tool on a daily basis. An email is sent to recipient@company.com if a certificate will expire in exactly 30 days.

    CertExpAlerter.exe -m SMTPServerName -s sender@free-fsolutions.com -r recipient@company.com -d 30 -c "CAServer\Root CA"

    Scenario 5: Filter based on certificate Common Name.
    To query certificates that match a specific regular expression in the Common Name, use the parameter: -f. This parameter uses regular expressions (regex). This parameter is not case sensitive. This parameter can be used in any of the previous listed scenarios, except in scenario Test email receipt.

    This command returns all certificates with a Common Name that starts with the string PC.

    CertExpAlerter.exe -c "CAServer\Root CA" -f "^PC"

    This command returns all certificates with Common Name that does NOT start with the string PC.

    CertExpAlerter.exe -c "CAServer\Root CA" -f "^(?!PC)"

    Output

    Figure 1 illustrates listing of all certificates with their expiration date information’s (Scenario 2).

    Figure 1. Quering certificates

     
    Figure 2 illustrates querying certificates where the Common Name begins with “test” (Scenario 5).

    Figure 2. Quering certificates with the optional filter parameter

     
    Figure 3 illustrates querying certificates about to expire in exactly 707 days (Scenario 3).

    Figure 3. Quering certificates with the optional filter parameter

    The email notification contains information about the certificate that matches the optional filter and the specified day criteria scheduled to expire (Scenario 4). This is illustrated in Figure 4.

    Figure 4. Email notification

    Summary

    Monitoring solutions, such as System Center Operations Manager, provide administrators with advanced notification of scheduled certificate expirations. If you do not have an installed monitoring solution, however, CertExpAlerter offers an easy and free solution to monitor your certificates. Download the tool here: Certificate Expiration Alerter. Please reach out to me if you have further questions.

    Lync Server Resources

    We Want to Hear from You

    Keywords: Certificate, Expiration, Alerter, Expired, Expire, CA, Lync Server

  • Enabling Lync Media to Bypass a VPN Tunnel

    Many organizations utilize Virtual Private Networks (VPNs) to secure traffic when users are outside the corporate network. VPNs have numerous security benefits, but they can actually degrade the call experience for Microsoft Lync users. This occurs because Lync traffic is already secured. This article explores this common Lync Server 2010 deployment issue, and demonstrates how to utilize the existing infrastructure to redirect media traffic to bypass the corporate client VPN Solution. This solution maintains a secure environment and improves the Lync 2010 user experience.

    Authors: Kevin Peters, Randy Wintle

    Publication date: November 15, 2011

    Product version: Lync Server 2010

    Many organizations that deploy Lync Server 2010 encounter voice quality issues associated with the usage of a client VPN solution in combination with Lync 2010. When users connect to the corporate network using a VPN client, Lync media traffic is sent through the VPN tunnel. This configuration can create additional latency and jitter because media traffic must pass through an additional layer of encryption and decryption. The issue is compounded when the VPN concentrator is busy. Real time media traffic is not prioritized. This means that other network activity, such as a large file transfer, can potentially degrade the call experience of users.

    To provide users with the best possible media quality, organizations should deploy a solution that prevents time sensitive real time media (voice/video) from traversing the VPN and simultaneously allows standard corporate network traffic to traverse the VPN. When considering this solution organizations should know the following:

    • All Lync 2010 traffic is encrypted by default. SIP signaling traffic is encrypted using TLS, and all media traffic (audio, video and application sharing) is encrypted using SRTP. Because of this, Lync traffic does not need to be routed through encryption tunnels unless your organization specifically requires dual layer encryption.
    • The Edge Server was designed to provide superb media quality to internet based users. Because of this, media that relays through the Edge Server is typically more reliable and of higher quality than media that traverses the corporate client VPN Solution.

    Because end users typically require continuous VPN connectivity, it is not feasible for users to disconnect from the VPN before making or receiving Lync calls. The solution is to force Lync traffic around the client VPN, while allowing users to connect to other internal corporate resources. The solution encompasses the following areas:

    • Create a split tunnel VPN configuration.
    • Revise the Windows Firewall policy or corporate VPN firewall rules.
    • Configure specialized DNS entries.

    The Problem

    Lync Server 2010 utilizes the Interactive Connectivity Establishment (ICE) protocol to establish media sessions between all Lync 2010 endpoints and servers. ICE attempts to establish media sessions between clients using all available ICE candidates on the client at the time of the call. Candidates are a combination of available IPv4 addresses and randomly allocated media ports on the machine with Lync 2010 installed. When a client VPN is connected, it often registers an IP address on a remote access interface on the client PC. Because of this, it is considered a valid IPv4 address; a candidate will be allocated for media connectivity to other clients. This is important because ICE tries candidates in the order shown below. When a media path is validated, the connectivity checks stop and the media is established.

    1. UDP Direct- Physical (or virtual RAS) interfaces with IPv4 addresses assigned.

    2. UDP NAT- Applies only when two users, who are outside the corporate firewall, are connected to the Lync infrastructure through the Edge Server. This scenario involves trying connectivity through the reflexive IP addresses for each home user. The reflexive IP address is the public IP address of the home router.

    3. UDP Relay- Between two external users or an external user and an internal user. This connectivity is relayed through the public IP address of the Audio/Video Edge service.

    4. TCP Relay- The relay address (Audio/Video Edge Server public interface) when connectivity is not available on UDP. TCP Relay is a last resort.

    When a Lync 2010 user is connected through VPN and attempts to call an internal Lync 2010 client, or tries to establish a media session with a Lync 2010 Server (Mediation Server, A/V Conferencing Server), the traffic attempts to pass through the VPN interface and is considered a UDP Direct candidate. If this connectivity check succeeds, the media traverses the client VPN solution.

    Figure 1. Lync 2010 Call Process through VPN - The Problem

     

    This scenario is a common default configuration issue. The requirements below define a solution that forces Lync client traffic through the Lync Edge Server (UDP Relay candidates).

    For more details on how ICE works for all Lync 2010 scenarios, see the Lync 2010 Resource Kit External User Access Chapter.

    Solution Configuration

    The solution to force VPN traffic through the Edge Servers must allow external Lync clients connected through VPN to do the following:

    1. Connect to corporate and external resources (split-tunnel).

    2. Resolve external DNS entries for the Lync Edge services, Lync Web services and Exchange Web Services.

    3. Register through the Lync Access Edge service.

    4. Block connectivity from VPN connected Lync 2010 clients to all Lync Servers and all internal client subnets through the VPN tunnel. In our example we used Windows Firewall to block this traffic. You can achieve similar results, however, if your VPN appliance has detailed rules to firewall client VPN traffic.

    5. Allow VPN connected clients to establish media through the A/V Edge Server public interface.

    Split-Tunnel VPN Policy

    To allow Lync traffic to reach the public IPs of all services, the VPN appliance must be configured to allow a split-tunnel. A split-tunnel is a VPN connection that allows connections intended for internal resources to traverse the VPN. All other user requests are sent through the internet connection and bypass the corporate network. For more information on spilt-tunnel VPNs read Split tunneling.

    In most split-tunnel VPN scenarios, DNS is provided by an internal DNS server. The server needs to be configured as described later in this article in the section Specialized DNS entries.

    It is critical that all public IP addresses used for the Lync and Exchange environments are excluded from entering the VPN tunnel. A tunnel-all VPN policy does not allow traffic to bypass the tunnel and does not work with this solution.

    Configuration of the VPN appliance is considered out of scope for this document; please consult your VPN appliance vendors’ documentation for more information on configuration recommendations.

    Windows Firewall Policy

    Administrators can create a custom Windows Firewall rule set to prevent Lync client traffic from entering the VPN. There are multiple options to push this policy, but this article will use the Windows Firewall snap-in to create the rules. Using group policy, administrators can follow the same configuration tasks. Deploying rules through group policy scales well in larger environments. For the scenario described below, we assume the following:

    • Corporate subnets all fall within the 10.0.0.0/8 range.
    • VPN subnet is 172.16.1.0/8.
    • A Connection type of Remote Access is shown in windows when VPN is connected.
    • A Network type of Domain is shown in windows when connected to the VPN.

    Note: If you are not using Windows Firewall, but want to deploy firewall rules through your VPN appliance, consider the following rules:

    Table 1. Firewall Rules to Block Lync Traffic over VPN

    Source

    Destination

    Port

    Description

    Client VPN Subnets

    Corporate VPN network

    1024-65535 TCP/UDP (this is by default; however these port ranges are configurable. See the QoS Deployment Guide for more details.

    Lync 2010 client media traffic to all other internal clients.

    Client VPN Subnets

    All Lync Servers, including the Edge Server internal interface

    All Ports TCP/UDP

    Lync 2010 client traffic to Lync Servers, all should be blocked.

    The above rules, used in conjunction with the remaining configurations, allow you to force Lync 2010 traffic to relay through the Edge Server.

    As mentioned above, all Windows Firewall configurations shown here are created using the local Windows Firewall Snap-In.

    Windows Firewall Policy Configuration Steps

    To begin, create a new inbound rule for the Lync application (Communicator.exe). This rule needs to be a Custom rule. See Figure 2 below.

    Figure 2. New Inbound Rule Type Custom

     

    Next, specify the executable for Lync or Communicator (Communicator.exe) as shown in Figure 3. Although this article only covers the Lync client, the same principles can be applied to other applications such as Microsoft Office Live Meeting 2007 or the Microsoft Lync 2010 Attendee.

    Figure 3. Communicator.exe specified as the program path

     

    For protocols and ports, leave the default settings as shown in Figure 4. This blocks all ports and all protocols.

    Figure 4. Default Configuration for Protocol and Ports

     

    To scope, define the VPN subnet in the Which local IP addresses does this rule apply to box, and the corporate and VPN subnets in the Which remote IP addresses does this rule apply to box. See Figure 5. Defining the VPN subnet in the remote IP address field prevents hair-pinning. Hair-pinning occurs when traffic enters and leaves the same interface on a network device, such as a VPN concentrator. Blocking hair-pinning prevents two VPN based users, from sending their peer to peer media traffic through the VPN tunnel.

    Figure 5. VPN subnet defined as the local IP, VPN and corporate subnets defined as remote subnets.

     

    When in the Scope section, customize the interface type to include only Remote Access. See Figure 6. This prevents the configuration from being applied when not connected to the corporate VPN.

    Figure 6. Custom Interface Type of Remote Access selected

     

    For action, choose block as shown in Figure 7.

    Figure 7. Blocking configured to prevent connections from utilizing VPN based IP address

     

    In the Profile screen select Domain. See Figure 8. This ensures the settings are only applied when connected to the users’ corporate Active Directory domain. This setting cannot be used for machines that are not joined to the domain. This setting keeps the configuration from being applied when connected to VPN networks other than the users’ corporate connection with the same network numbering.

    Figure 8. Network profile type of Domain

     

    Give the rule a meaningful name and description see Figure 9.

    Figure 9. Configure the name of your rule and provide a description

     

    After creating the inbound rule, create an outbound rule with the same configuration.

    Specialized DNS Entries

    Because connections to all internal IP addresses are blocked, you must provide valid DNS entries that resolve public IP addresses in response to queries from the Lync client. To achieve this use a dedicated DNS server, with pin point zones as explained in the article Communicator Automatic Configuration and Split-Brain DNS.

    The Lync client makes connections to the following resources. You need to provide the public IP addresses back for those requests:

    • Lync Edge Server services (Access Edge, Web Conferencing Edge, and Audio/Video Edge).
    • Simple URLs (reachable through the reverse proxy).
    • Exchange Web Services (EWS), Autodiscover service and all other client connectivity.

    Lync Edge Services

    To force the Lync client traffic around the VPN, the public IP addresses for all three Edge services must be returned to the Lync client when it makes a query. This allows the Lync client to connect to the Access Edge as an external client. This is required because users must register as external to obtain proper Media Relay Authentication Server (MRAS) credentials. For more details on MRAS, see Microsoft Lync Server 2010 Resource Kit: External User Access.

    Example:

    Table 2. Example Edge Server DNS Entries

    Record

    Resolves to

    Description

    Sip.contoso.com

    167.55.49.32

    Access Edge interface

    _sip._tls.contoso.com

    Sip.contoso.com:443

    Auto Login SRV record for clients

    Web.contoso.com

    167.55.49.33

    Web Conferencing Edge Server

    Av.contoso.com

    167.55.49.34

    A/V Edge Server

    Simple URLs

    Just like SIP traffic, you must block all https pool traffic from entering the VPN. All URLs defined for simple URLs and pool web services (including external web services FQDNs) must return a public IP address routed outside of the VPN tunnel.

    Example:

    Table 3. Example Simple URL DNS Entries

    Record

    Resolves to

    Description

    Web-external.contoso.com

    167.55.49.35

    Pool external web services

    Meet.contoso.com

    167.55.49.35

    Meeting join page

    Dialin.contoso.com

    167.55.49.35

    Dial-In conferencing settings page

    Exchange Web Services

    Because you are blocking the Lync client from reaching any internal subnets, you must ensure that all Exchange services are reached through their public IP addresses.

    Example:

    Table 4. Example Exchange Web Services DNS Entries

    Record

    Resolves to

    Description

    autodiscover.contoso.com

    167.55.49.36

    Exchange Auto Discover

    owa.contoso.com

    167.55.49.36

    Exchange Web Services/Outlook Web Access

    Summary

    When these changes are implemented, the Lync client will connect to the Access Edge Server for all signaling connections when on the corporate VPN (see Figure 10). In addition, media sessions will not be allowed to establish connectivity through the VPN tunnel. Media sessions will be routed through the A/V Edge Server public interface (see Figure 11).

    Figure 10. Lync client signaling bypassing the corporate VPN with windows firewall configuration

     

    Figure 11. Lync client media bypassing the corporate VPN with windows firewall configuration

     

    Reference Articles

    Lync Server Resources

    We Want to Hear from You

    Keywords: Lync, VPN, ICE, Lync Edge Server, Windows Firewall, Virtual Private Network

  • DNS Load Balancing in Lync Server 2010

    DNS load balancing is introduced in Microsoft Lync Server 2010 communications software. The objective of DNS load balancing is to provide a native load balancing mechanism option in Lync Server 2010. DNS load balancing can be quickly and easily configured in Lync Server 2010 and is a very cost effective option for load balancing. Lync Server 2010 DNS load balancing supports “connection draining.”

    Author: Keith Hanna

    Publication date: May 2011

    Revision history:

    · November 2011: To reduce customer confusion, removed the table on Server Roles, Services, and Clients that Support DNS Load Balancing.

    Product version: Microsoft Lync Server 2010

    Microsoft Office Communications Server 2007 R2 and Office Communications Server 2007 require a Hardware Load Balancer (HLB) to provide resilience for the Enterprise pool. Microsoft Lync Server 2010 introduces support for DNS load balancing for SIP, as an additional option to hardware load balancing. This article explains what DNS load balancing is and where it’s used within Lync Server.

    What is DNS Load Balancing?

    Domain Name System (DNS) load balancing uses DNS as a way to load-balance across multiple servers. DNS load balancing is implemented at the application level in both servers and clients. They both participate in the load-balancing logic.

    The process of DNS load balancing is simple and as follows:

    1. The front-end servers register their fully qualified domain name (FQDN) as A records in DNS.

    2. When the Enterprise pool is created, the pool FQDN (that is, the SRV record) is registered to return from DNS the list of IP addresses of all the front-end servers.

    3. The client attempts to connect to one of the IP addresses that were returned. If this connection fails, the client attempts to connect to the next IP address in the list until the connection succeeds.

    Note Is this DNS “round robin”? Not quite. DNS “round robin” typically refers to a method of load balancing the results of the DNS query: the first client connection request receives the first record, the second query receives the second record, and so on. In each case, only one record is returned There is no intelligence behind this method to facilitate failover—purely a connection-distribution method.

    How Does DNS Load Balancing Work—in Practice?

    To explain how DNS load balancing works, let’s assume we have a single pool that consists of four front-end servers with a back-end server running Microsoft SQL Server, as shown in Figure 1.

    Figure 1. Pool configuration

     

    DNS is configured as shown in Table 1. Note that the pool FQDN has multiple entries, each referring to a separate front-end server within the pool.

    Table 1. DNS configuration

    FQDN

    IP/FQDN

    Comments

    _sip._tls.contoso.com

    Pool.contoso.com

    This is the SRV record that is used during automatic log on.

    FE1.contoso.com

    192.168.1.1

     

    FE2.contoso.com

    192.168.1.2

     

    FE3.contoso.com

    192.168.1.3

     

    FE4.contoso.com

    192.168.1.4

     

    Pool.contoso.com

     

    192.168.1.1

    Without using DNS load balancing, this FQDN would resolve to the IP address of the hardware load balancer, which in turn would be responsible for directing traffic to front-end servers.

    192.168.1.2

    192.168.1.3

    192.168.1.4

    The client queries DNS to resolve the FQDN of the pool (for example, pool.contoso.com) similar to Office Communications Server 2007 R2. Instead of returning the virtual IP address of the hardware load balancer, the DNS query returns the list of front-end server FQDNs as shown in Table 1. With previous versions of Office Communications Server, this query would return the IP address of the hardware load balancer.

    In Lync Server, the DNS query returns the list, {192.168.1.1, 192.168.1.2, 192.168.1.3, 192.168.1.4}, to the client. The order in which these are returned to the client is irrelevant. The client chooses an IP address from the list at random, and then attempt to connect to the front-end server. If the connection fails, the client continues down the list in a random fashion until a successful connection to the pool is achieved or the list is empty.

    Client Registration

    With previous versions of Office Communications Server, the client would be able to successfully connect to a front-end server. It would then register the client’s SIP URI into the single-shared registration database that is stored on the back-end server running Microsoft SQL Server. However, in Lync Server, each front-end server in a pool has a completely independent registration database. Each user is assigned a predefined registration database (that is, registrar) that they should connect to. This registrar assignment is calculated by a hash value of the user’s SIP URI. Therefore, it is highly likely that a randomly selected front-end server is the incorrect server for the client to connect to. In this example, there is a 75 percent chance the client would randomly contact the wrong server. In other words, there is a 25 percent chance that the correct server was reached on the first attempt. No SIP redirect would be required.

    Important When multiple clients from the same user are considered, all clients must register to the same front-end server (registrar). This ensures that any client that is associated with a single user can be located in a single location. This simplifies the call-routing logic.

    A static mapping of users to registrars cannot be used because of the requirement to cater for individual server failure. To solve this problem, Lync Server uses a hash algorithm to determine which front-end server the client will primarily connect to, and also the order of failover–for every front-end server in the pool. This will ensure that all clients from the same user will consistently connect to the same front-end server, and in turn connect to the same registration database. The hash algorithm is based on the maximum number of servers in the pool (10). This will help ensure that users are evenly spread across all available front-end servers in a pool. The maximum number of servers is used to ensure that hash values never need to be recomputed with the addition or removal of servers to or from the pool.

    Let’s look at the following example in more detail.

    In Figure 1, we have four front-end servers, {FE1, FE2, FE3, FE4}. The user retrieves this list of servers from DNS, and then randomly connects to one in the list. In our example, let’s assume that the client connects to FE3. Upon connecting, the client presents its SIP URI from which a hash is generated by the front-end server. From this hash, the server determines the location of the registrar assigned to it.

    Note When a user is first enabled on (or moved to) a pool, a hash is generated to determine which front-end server is the primary registration database for the user, along with the order in which the remaining front-end servers will be attempted (as the backup registrar services).

    For our example, our user hash results in {FE4, FE2, FE1, FE3}. This is then interpreted as the order in which the clients will attempt to register.

    The client attempts to register with FE3, but because it’s not the primary registrar assigned to the user, FE3 redirects the client to FE4 as the correct registrar to connect to. The client successfully registers with FE4.

    Now, in the case of the primary registrar front-end server being unavailable, there are two scenarios to consider and are as follows:

    • The initial server chosen from the DNS response is unavailable. Using DNS load balancing, the client will then simply attempt another server from the list until a successful connection is received. From here, a registration is attempted by using the previously mentioned logic.
    • The primary registrar is unavailable. In this scenario, the server that provides the redirect will be fully aware of the states of other servers in the pool and will then redirect the client to connect to the first available backup registrar front-end server that is determined by the hash list of the user’s SIP URI.

    In the previous example, we considered only four servers; however, as previously mentioned, these hash values are calculated based on the maximum number of servers in a pool (10). When front-end servers are added to a pool in topology builder, they are assigned an ID in the range of 1 through 10 to allow the hash mapping to take place. These IDs are randomly assigned.

    This introduces another complexity. If we have less than 10 servers deployed, how is a front-end server determined to be available? Figure 2 shows a mapping of IDs to front-end servers for our example.

    Figure 2. Server ID mapping

     

    All registrars marked with “X” are nonexistent (either due to temporary failure or because they have not yet been commissioned).

    Figure 3 shows two sample logical registrar sequences for two different users. This is used to determine the order in which the respective user’s clients will attempt to register to their pool.

    Figure 3. User Logical Registrar Sequence

     

    Using both the logical registrar sequence and the physical registrar sequence, the pool can determine which registrar the user’s client should connect to. This is done by iterating through the logical sequence and mapping to the physical registrar sequence until the first physical registrar (that is, front-end server) that is available is found. In the case of User 1, the first logical registrar is {7}. It maps to FE3 as shown in Figure 4.

    Figure 4. Example of user mapping

     

    In the case of User 2, the first three logical registrars, {3, 6, 2}, are unavailable. The next logical registrar, {7}, which maps to FE3, is available. User 2’s client would connect to FE3. In this case, User 2 is said to be connected in backup mode.

    Server Failure and Recovery

    Now our client has the DNS and registration information. What happens in the scenario where a server has failed?

    When a server fails, the physical registrar sequence is updated to show the server as unavailable and shared amongst all surviving servers by using a server-server heartbeat. This ensures that all the servers are continually aware of the state of the pool. Any connecting clients are managed as shown in Figure 3 and Figure 4. Any users who would primarily connect to the failed server are redirected to the next server in their logical registrar sequence and are then connected in backup mode.

    Now, at some point in the future, the server will be recovered, returning the physical registrar sequence back to its original state. When the physical registrar sequence is updated, each server that has been available during the outage checks to see if any of the users in backup mode should be registered as primary on the (now-recovered) server. If this number is greater than 0, the users will be de-registered and redirected to their primary registrar.

    Note De-registration is carried out in batches of users (not batches of clients) to ensure that the network is not overloaded. All clients that belong to a user must be re-registered in the same batch. Because of this batching nature, it will take time for the front-end servers to stabilize.

    Server Commission and Decommission

    The difference between the previous section and this section is reflected in a change to the topology. When topology changes occur, the logical registrar sequence is recalculated for all users, resulting in some users being re-homed to a different front-end server in the same pool.

    Using the same example in Figure 3 and the users in Figure 4, if a new front-end server is commissioned and is given ID=3 (or 6 or 2), the mapping for User 2 is changed to introduce a new primary registrar for that user as shown in Figure 5. When the server is fully operational, the heartbeat process updates the physical registrar sequence, from which a check for users in backup mode is triggered. This results in the batched re-registration process (if necessary).

    Figure 5. User mapping to a new server

     

    If the newly commissioned server was given ID=10, changes would result for neither User 1 nor User 2. Both are currently registered to a server that appears before {10} in their logical registrar sequence. The result would be that both users would have an additional server that could be used in backup mode.

    Decommission is very similar to server failure, with the exception of the re-home to a new primary registrar being part of the decommission process. The topology change results in the recalculation of the logical registrar sequence. This step doesn’t happen in a server failure.

    Note In these examples, the server names are shown to match the diagram in Figure 1, making the correlation easier to follow. The actual physical and logical sequences are managed by using an internal server ID—not by using the server name.

    Why Do We Still Need Hardware Load Balancers?

    Both HTTP and HTTPS are session-state–oriented protocols. This means that if I start a conversation with Server A, Client A needs to continue to talk with Server A to complete the entire request. With DNS load balancing, there is no sticky-session state that can be set up. As a result, there is no way to ensure that a session is going to be continued on Server A.

    HLB specifically addresses this session problem by caching the client-server state information; when the next request comes in from Client A, the HLB refers it back to Server A–regardless of whether Server A is busy. It waits and sends the request when possible. Hence, for Web-based traffic, DNS load balancing is not a solution.

    Summary

    In addition to supporting hardware load balancers, Lync Server introduces the option to load balance clients’ SIP connections to a pool of front-end servers using DNS. DNS load balancing is only part of the client connectivity matrix. The internal hashing and distribution of the client registration information is the other part. The two mechanisms work together to determine how a client connects to a pool.

    DNS load balancing is not supported for load balancing Web traffic. As a result, hardware load balancing is still required for load balancing Web traffic (such as address book services) in Lync Server 2010.

    Hardware load balancer is still required to load balance SIP traffic when operating in a mixed Lync Server and legacy environment (Office Communications Server 2007 R2 or Office Communications Server 2007).

    Lync Server Resources

    We Want to Hear from You

  • Working with Microsoft Lync Registry Settings

     

    Remember the registry? Of course you do: the registry was first introduced in Windows 3.1 and now, almost 20 years later, the registry is still very much alive and kicking. We're the first to admit that the registry hasn't always been the most-beloved piece of software that Microsoft ever created, but it still maintains its importance as a central storehouse for both operating system and application configuration information.

     

    And yes, as a matter of fact, that does include configuration information for Microsoft Lync 2010. There's no doubt that the client policy settings introduced in Microsoft Lync Server 2010 give administrators considerable centralized control of the behavior of Microsoft Lync; for example, an administrator can configure a policy that enables free/busy information to be included in your presence information, or a policy that prevents users from including emoticons in any instant messages that they send or receive. That's nice, and there are other policy settings that control such things as the display of the Activity Feeds tab, the ability of users to save instant message transcripts, and whether or not a disclaimer appears in the Conversation Window each time you participate in a new instant messaging session.

     

    That said, there are many other Lync settings that are not available as client policy settings; instead, they're available only as user preferences. What does that mean? That simply means that the users can decide for themselves whether or not they want to enable a feature. For example, there happens to be a user preference that determines whether or not Microsoft Lync automatically starts each time the user logs on to Windows. Who controls that setting? The user does, and by doing nothing more complicated than selecting (or deselecting) a checkbox in the Options dialog box:

     

     

    So what happens when a user enables (or disables) one of these user preferences? Well, in many cases, that information is recorded in the registry. For example, if you enable the option Automatically start Lync when I log on to Windows then this registry value gets set to 1:

     

    HKEY_CURRENT_USER\Software\Microsoft\Communicator\AutoRunWhenLogonToWindows

     

    And if you disable that setting? Then that same registry value will be set to 0. Each time you start Lync, the application reads these values from the registry and then configures itself accordingly.

     

    In other words, many of the Lync user preferences rely on values stored in the registry. So does that mean that you're thinking what we're thinking?

     

    Oh. Well, that's definitely not what we were thinking. We were thinking this: if preference information is stored in the registry, that means that you could use a Windows PowerShell script to retrieve the values of those registry-based settings. In fact, you could even use a Windows PowerShell script to change the values of those settings.

     

    That's what we were thinking.

     

    Of course, by now you're thinking, "Why would I even want to do that?" Well, imagine this scenario. A user calls you up and tells you that "Microsoft Lync used to start up every time I logged into Windows and now it doesn't. Why not?"

     

    The most obvious reason is because he or she has cleared the Automatically start Lync when I log on to Windows option. But how can you be sure that this is what happened? One way, of course, is to ask the user. But another way is to run a script like this one, a script that retrieves the value of AutoRunWhenLogonToWindows from the computer atl-ws-001.litwareinc.com:

     

    $computer = "atl-ws-001.litwareinc.com"

     

    $registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("CurrentUser", $computer)

    $key = $registry.OpenSubKey("SOFTWARE\Microsoft\Communicator", $True)

     

    Write-Host "Automatically start Lync when I log on to Windows:",`

        ($key.GetValue("AutoRunWhenLogonToWindows",$null))

     

    If this script returns a 0, that means that Automatically start Lync when I log on to Windows has been disabled; in turn, that's probably why Lync is no longer starting up whenever the user logs on to Windows. If the script returns a 1, then you know that this option actually is enabled, which means that something else must be preventing Lync from auto-starting. Either way, you've managed to get this information without having to guide the user through the Lync UI, and without running the risk of the user accidentally clicking something else and making the problem even more complicated than it was before.

     

    But wait: it gets even better. If you want to, you could even run a script that modifies the registry and thus re-enables the setting:

     

    $computer = "atl-ws-001.litwareinc.com"

     

    $registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("CurrentUser", $computer)

    $key = $registry.OpenSubKey("SOFTWARE\Microsoft\Communicator", $True)

     

    $key.SetValue("AutoRunWhenLogonToWindows",1,"DWORD")

     

    Now, admittedly, we typically don't recommend that people make changes to an application by modifying the registry; after all, if you assign the wrong value to the wrong setting, well …. But keep in mind that we're not saying that you have to do this; we're just saying that you could do this. Being able to run a script that returns a considerable amount of information about how Microsoft Lync has been configured could be extremely useful for administrators and help desk personnel. Being able to run a script that modifies one of those settings could be equally valuable. For example, imagine a script that you could run after installing a new copy of Microsoft Lync, a script that would immediately configure that copy of Lync with your organization's preferred settings. Useful? It sounds useful. But that's your call.

     

    We should also point out that modifying a registry value does not prevent the user from going in and changing things back. For example, suppose you set AutoRunWhenLogonToWindows to 1, thus configuring Lync to automatically start any time the user logs on to Windows. What's to prevent the user from simply opening up the Options dialog box and disabling auto-start? Absolutely nothing. After all, that's how user preferences work.

     

    Note. This is as good a time as any to mention that there are a few cases where policies and preferences overlap. For example, users can decide for themselves if they want to use emoticons in instant messages; however, there's also a client policy setting (DisableEmoticons) that administrators can use to prevent users from employing emoticons. So what happens when worlds collide; that is, what happens if a user has enabled the use of emoticons but an administrator has disabled the use of emoticons?

     

    Actually, there's a very simple answer to that: the policy set by the administrator always wins. Always. If an administrator uses a client policy to disable emoticons then it doesn't matter what the user has set in the Options dialog box and it doesn’t matter what value might be configured in the registry. And, while there might be one or two privacy-related exceptions, after a setting has been configured via a policy, the user will no longer have the option of changing that setting. In this case, for example, the Show emoticons in instant messages option will be grayed-out and will no longer be available to the user.

     

    As we hinted at a moment ago, the purpose of this series of articles is to introduce some of the registry settings used by Microsoft Lync and to explain how those settings relate both to the Lync user interface and, in some cases, to Lync Server client policies. Our goal here is purely educational: we're just reporting back the things we discovered while exploring Lync and the Lync registry settings. Do these articles contain useful nuggets of administrative information? That's something you'll have to decide for yourself. You know what they say: we report, you decide.

     

    Here are the Lync features that we've managed to map to the registry, at least up to this point in time:

     

    ·         Allow Microsoft to collect information about how I use Lync

    ·         Always on Top

    ·         Automatically start Lync when I log on to Windows

    ·         Display my Out of Office Information to contacts in my Friends and Family, Workgroup, and Colleagues privacy relationships

    ·         File Transfer Save to

    ·         Hide the Notification Balloon

    ·         Join meeting audio from

    ·         Keep sounds to a minimum when my status is Busy

    ·         Keep sounds to a minimum when my status is Do Not Disturb

    ·         Last Dialed Number

    ·         Lync Language

    ·         Minimize to the notification area instead of the task bar

    ·         Mute incoming IM alert sounds when viewing an IM conversation

    ·         Play sounds in Lync (including ringtones for incoming calls and IM alerts)

    ·         Lync Product Version

    ·         Prompt me before joining to confirm or select another audio source

    ·         Show an alternating background color for messages in the conversation window

    ·         Show emoticons in instant messages

    ·         Show Lync in foreground when it starts

    ·         Show me as Away when my status has been Inactive for this many minutes

    ·         Show me as Inactive when my computer has been idle for this many minutes

    ·         Show photos of contacts

    ·         Show the Menu Bar

    ·         Turn logging on in Lync

    ·         Turn on TYY mode

    ·         Turn on Windows Event logging for Lync

     

    And here's a script that can return detailed information about Microsoft Lync and how it's been configured. As written, the script returns this information for the local computer. To retrieve this data from a remote computer, simply assign the name of that computer to the variable $computer. For example:

     

    $computer = "atl-ws-001.litwareinc.com"

     

    Here's the script:

     

    $computer = "."

     

    $registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("CurrentUser", $computer)

    $key = $registry.OpenSubKey("SOFTWARE\Microsoft\Communicator", $True)

     

    $value =$key.GetValue("ShowEmoticons",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Show emoticons: $value"

     

    $value =$key.GetValue("ShowColorBand",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Show an alternating background color for messages in the" `

        "conversation: $value"

     

    $value =$key.GetValue("CEIPEnabled",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

     

    Write-Host "Allow Microsoft to collection information about how I use" `

        "Lync: $value"

     

    $value =$key.GetValue("EnableTracing",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Turn logging on in Lync: $value"

     

    $value =$key.GetValue("EnableEventLogging",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Turn on Windows event logging for Lync: $value"

     

    $value =$key.GetValue("MinimizeWindowToNotificationArea",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Minimize to the notification area instead of the task bar: $value"

     

    $value =$key.GetValue("AutoRunWhenLogonToWindows",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Automatically start Lync when I log on to Windows: $value"

     

    $value =$key.GetValue("AutoOpenMainWindowWhenStartup",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Show Lync in foreground when it starts: $value"

     

    $value =$key.GetValue("AutoRetriveOOFSettings",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Display my Out of Office information to contacts in my Friends" `

        "and Family, Workgroup, and Colleagues privacy relationships: $value"

     

    $value =$key.GetValue("ShowPhoto",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Show photos of contacts: $value"

     

    Write-Host "Show me as Inactive when my computer has been idle for this" `

        "many minutes:",($key.GetValue("IdleThreshold",$null))

     

    Write-Host "Show me as Away when my status has been Inactive for this" `

        "many minutes:",($key.GetValue("AwayThreshold",$null))

     

    $value =$key.GetValue("EnableTTY",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Turn on TTY mode: $value"

     

    $value =$key.GetValue("AllowOverridingDeviceAtJoinTime",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Prompt me before joining to confirm or select another audio" `

        "source: $value"

     

    $value =$key.GetValue("PlaySoundFeedback",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Play sounds in Lync (including ringtones for incoming calls" `

        "and IM alerts): $value"

     

    $value =$key.GetValue("suspendSoundWhenConversationWindowInForeground",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Mute incoming IM alert sounds when viewing an IM conversation: $value"

     

    $value =$key.GetValue("suspendSoundWhenBusy",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Keep sounds to a minimum when my status is Busy: $value"

     

    $value =$key.GetValue("suspendSoundWhenDND",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Keep sounds to a minimum when my status is Do Not Disturb: $value"

     

    $value =$key.GetValue("AlwaysOnTop",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Always on tops: $value"

     

    $value =$key.GetValue("DsBkgndMode",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Hide notification balloon: $value"

     

    $value =$key.GetValue("AlwaysShowMenu",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Show menu bar: $value"

     

    $value =$key.GetValue("ShowPhoto",$null)

    if ($value -eq 1) {$value = "Yes"}

    if ($value -eq 0) {$value = "No"}

    Write-Host "Show photos of contacts: $value"

     

    $value =$key.GetValue("JoinAudioConferenceFrom",$null)

    if ($value -eq 1) {$value = "Lync"}

    if ($value -eq 0) {$value = "Do not join meeting audio"}

    Write-Host "Join audio conference from: $value"

     

    Write-Host "File transfer Save to folder:",($key.GetValue("FtReceiveFolder",$null))

    Write-Host "Last Dialed Number:",($key.GetValue("LastDialedNumber",$null))

    Write-Host "Product Version:",($key.GetValue("ProductVersion",$null))

     

    $value =$key.GetValue("Language",$null)

    switch ($value) {

        1025 {$value = "Arabic "}

        1026 {$value = "Bulgarian "}

        1027 {$value = "Catalan "}

        2052 {$value = "Chinese - Simplified "}

        1028 {$value = "Chinese - Traditional "}

        3076 {$value = "Chinese Hong Kong "}

        1050 {$value = "Croatian "}

        1029 {$value = "Czech "}

        1030 {$value = "Danish "}

        1043 {$value = "Dutch "}

        1033 {$value = "English "}

        1061 {$value = "Estonian "}

        1035 {$value = "Finnish "}

        1036 {$value = "French "}

        1031 {$value = "German "}

        1032 {$value = "Greek "}

        1037 {$value = "Hebrew "}

        1081 {$value = "Hindi "}

        1038 {$value = "Hungarian "}

        1040 {$value = "Italian "}

        1041 {$value = "Japanese "}

        1042 {$value = "Korean "}

        1062 {$value = "Latvian "}

        1063 {$value = "Lithuanian "}

        1044 {$value = "Norwegian "}

        1045 {$value = "Polish "}

        2070 {$value = "Portuguese (Portugal) "}

        1046 {$value = "Portuguese (Brazil) "}

        1048 {$value = "Romanian "}

        1049 {$value = "Russian "}

        2074 {$value = "Serbian "}

        1051 {$value = "Slovak "}

        1060 {$value = "Slovenian "}

        3082 {$value = "Spanish "}

        1053 {$value = "Swedish "}

        1054 {$value = "Thai "}

        1055 {$value = "Turkish "}

        1058 {$value = "Ukrainian"}

    }

     

    Write-Host "Lync Language: $value"

     

    And what the heck: here's a bonus script, one that resets the Lync registry settings to their default values:

     

    $computer = "."

     

    $registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey("CurrentUser", $computer)

    $key = $registry.OpenSubKey("SOFTWARE\Microsoft\Communicator", $True)

     

    $key.SetValue("PlaySoundFeedback",1,"DWORD")

    $key.SetValue("AllowOverridingDeviceAtJoinTime",1,"DWORD")

    $key.SetValue("MinimizeWindowToNotificationArea",0,"DWORD")

    $key.SetValue("suspendSoundWhenDND",1,"DWORD")

    $key.SetValue("AutoRetrieveOOFSettings",1,"DWORD")

    $key.SetValue("AlwaysShowMenu",[byte[]]@(0,0,0,0),"Binary")

    $key.SetValue("suspendSoundWhenConversationWindowInForeground",1,"DWORD")

    $key.SetValue("EnableTracing",0,"DWORD")

    $key.SetValue("ShowColorBand",1,"DWORD")

    $key.SetValue("EnableEventLogging",0,"DWORD")

    $key.SetValue("IdleThreshold",5,"DWORD")

    $key.SetValue("JoinAudioConferenceFrom",1,"DWORD")

    $key.SetValue("FtReceiveFolder","$env:userprofile\Documents\My Received Files","String")

    $key.SetValue("CEIPEnabled",0,"DWORD")

    $key.SetValue("DsBkgndMode",[byte[]]@(0,0,0,0),"Binary")

    $key.SetValue("EnableTTY",0,"DWORD")

    $key.SetValue("AwayThreshold",5,"DWORD")

    $key.SetValue("AlwaysOnTop",[byte[]]@(0,0,0,0),"Binary")

    $key.SetValue("AutoOpenMainWindowWhenStartup",1,"DWORD")

    $key.SetValue("suspendSoundWhenBusy",1,"DWORD")

    $key.SetValue("AutoRunWhenLogonToWindows",1,"DWORD")

    $key.SetValue("ShowEmoticons",1,"DWORD")

     

    Enjoy!

  • Troubleshooting External Lync Mobility Connectivity Issues Step-by-Step

    This article provides step-by-step troubleshooting for Microsoft Lync Server 2010 connectivity issues for external users with mobile devices. This article assumes that Lync Server 2010 Mobility Service and Lync Server 2010 Autodiscover Service are successfully deployed and internal users are able to connect using the Lync 2010 mobile client. It assumes that Lync Server clients can successfully connect to an external mobile device user without error messages or warnings for web services connectivity. This article does not include steps for troubleshooting push notifications for Windows Phone 7 and iOS devices.

    Author: Edwin Joseph

    Publication date: February 21, 2012

    Product version: Microsoft Lync Server 2010 with Cumulative update for November 2012

    Symptom

    When a mobile device with a Lync 2010 client tries to connect to Lync Server 2010, the user receives the error message:

    Can’t connect to the server. It might be unavailable. Also please check your network connection, sign-in address, and server addresses.

    Troubleshooting

    Note: The SIP domain used throughout this document is contoso.com; replace contoso.com with your actual SIP domain. Lyncexternal.contoso.com is the external web services URL of the pool.

    Step 1. Autodiscover setup check

    If you use Autodiscover Service to locate Lync Server 2010, the first step is to type the Autodiscover URL into the web browser. For example after typing https://lyncdiscover.contoso.com in the browser, you should receive a prompt to open or save the lyncdiscover_contoso.com file.

    If you receive a warning or an error, check the browser settings. If you are prompted for authentication when browsing lyncdiscover.contoso.com, there is a configuration issue on the reverse proxy.

    If you are unable to obtain the lyncdiscover_contoso.com file, perform a Nslookup for lyncdiscover.contoso.com. Verify that the A record is setup for lyncdiscover.contoso.com and that it points to the correct external IP address.

    When you open the lyncdiscover_contoso.com file in notepad, you should see the following content.

    {"AccessLocation":"External","Root":{"Links":[{"href":"https:\/\/lyncexternal.contoso.com\/Autodiscover\/AutodiscoverService.svc\/root\/domain","token":"Domain"},{"href":"https:\/\/lyncexternal.contoso.com\/Autodiscover\/AutodiscoverService.svc\/root\/user","token":"User"}]}}

    The URL identified in the lyncdiscover_contoso.com file must be the external web services URL for the Lync Server 2010 Front End Server or Lync Server 2010 Director pool. If the internal web services URL is identified, the web publishing rule is incorrect and is bridging the connection to port 443 instead of port 4443 for the Lync external web services.

    When you have verified that the A record for lyncdiscover.contoso.com is correct and that the URL returned in the lyncdiscover_contoso.com file is the external web services URL for the Lync Server Front End Server or Lync Server Director pool, you are ready to look at the Lync mobility setup.

    Step 2. Check Web Services Internal URL

    A prerequisite for the Lync mobility component is that the Front End pool internal web FQDN must be distinct from the Front End pool external web FQDN.

    To configure internal web services

    1. Log on to the computer where Topology Builder is installed, as a member of the Domain Admins group and the RTCUniversalServerAdmins group.
    2. To start Topology Builder, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder.
    3. In the Topology Builder console tree under Standard Edition Front End Servers, Enterprise Edition Front End pools, and Directory pools, select the pool name. Right-click the name, click Edit Properties, and click Web Services.
    4. Under Internal Web Services check the option Override FQDN.
    5. Add an Internal Web Services FQDN, and then click OK.
    6. Verify the listening and published ports are configured correctly for your environment.
    7. Repeat these steps for all Standard Edition Servers, Front End pools, and Director pools in your environment.
    8. In the console tree, click Lync Server 2010. In the Actions pane, click Publish Topology.

    Step 3. MCX configuration check

    Log on to the computer as a member of the CsAdministrator group. In the Lync Management Shell run the following cmdlet.

    Get-CsMCXconfiguration |fl

    Verify the ExposedWebUrl is set to External. If this value is set to the Internal, only your internal mobility client can connect to Lync Server. To set the value for ExposedWebUrl to external, use the following cmdlet.

    Set-CsMcxConfiguration –ExposedWebUrl External

    Step 4. DNS record check

    Verify that the A record for Lyncdiscover is setup correctly in the internal DNS.

    External DNS Records

    Record type

    Host name

    Resolves to

    CNAME

    lyncdiscover.contoso.com

    External Web Services FQDN for your Director pool, if you have one, or for your Front End pool if you do not have a Director

    A (host)

    lyncdiscover.contoso.com

    External or public or IP address of the reverse proxy

    Step 5. Certificate check

    Refer to the certificate requirements in the Lync Server 2010 Mobility Guide.

    If you are using a Director, verify the certificate.

    Director Pool Certificate

    Description

    Subject alternative name entry

    Internal Autodiscover Service URL

    SAN=lyncdiscoverinternal.contoso.com

    External Autodiscover Service URL

    SAN=lyncdiscover.contoso.com

    Note: Alternatively, you can use SAN= *.contoso.com.

    Front End Pool Certificate

    Description

    Subject alternative name entry

    Internal Autodiscover Service URL

    SAN=lyncdiscoverinternal.contoso.com

    External Autodiscover Service URL

    SAN=lyncdiscover.contoso.com

    Note: Alternatively, you can use SAN= *.contoso.com.

    Reverse Proxy (Public CA) Certificate

    Description

    Subject alternative name entry

    External Autodiscover Service URL

    SAN=lyncdiscover.contoso.com

    Note: Assign this certificate to the SSL Listener on the reverse proxy.

    After completing the four steps outlined above, browse to the Autodiscover URL in web browser https://lyncdiscover.contoso.com.

    You should receive a prompt to open or save the file Lyncdiscover_contoso.com.

    If you still do not receive an option to open or save the file lyncdiscover_contoso.com, verify the reverse proxy setup. Refer to the Lync Server 2010 Mobility Guide.

    Step 6. Domain file check

    If you receive the option to open or save the lyncdiscover_contoso.com file in the web browser, proceed to step 5.

    Try to browse to the following URL in your web browser. http://lyncdiscover.contoso.com/autodiscover/autodiscoverservice.svc/root/domain

    You should receive a prompt to open or save the domain file.

    When you open the domain file in notepad you should see the following content.

    {"AccessLocation":"External","Domain":{"Links":[{"href":"https:\/\/lyncexternal.contoso.com\/Autodiscover\/AutodiscoverService.svc\/root","token":"External\/Autodiscover"},{"href":"https:\/\/lyncexternal.contoso.com\/Reach\/sip.svc","token":"External\/AuthBroker"},{"href":"https:\/\/lyncexternal.contoso.com\/Mcx\/McxService.svc","token":"External\/Mcx"}],"SipClientExternalAccess":{"fqdn":"edge.contoso.com","port":"5061"},"SipClientInternalAccess":null,"SipServerExternalAccess":{"fqdn":"edge.contoso.com","port":"5061"},"SipServerInternalAccess":null}}

    The URL mentioned in the domain file must be the external web services URL for the Front End Server or Director pool. If the internal web services URL is returned, the web publishing rule is incorrect. This means that it is bridging the connection to port 443 instead of 4443 for Lync Server external web services.

    If you are unable to download the Domain file, there is a problem with the reverse proxy configuration or authentication settings for web services in Lync Server 2010.

    Step 7. Web Services authentication check

    Try to browse the URL https://lyncexternal. contoso.com/mcx/mcxservice.svc/mex in your web browser.

    Depending on your browser settings, you should see https://lyncexternal.contoso.com/Mcx/McxService.svc/WebTicket_Bearer in the browser or the XML SOAP information. This means the web services URL authentication setting is set to negotiate.

    To quickly verify the web services URL authentication settings, use the Lync Management Shell to run the following cmdlet.

    Get-CsWebServicesConfiguration |fl

    Verify the value for the UseWindowsAuth parameter is set to Negotiate.

    Step 8. Debug log from mobile device

    Enable and collect debugging logs from a mobile device to verify the reverse proxy configuration.

    Note: The logging information may contain personal information. To address privacy concerns, edit the log file in accordance with company guidelines before forwarding logging information.

    To Enable logging on a Windows Phone

    1. From any screen of the Lync for Windows Phone application, touch the ellipses, to bring up the menu, and then tap settings.

    2. On the settings page, toggle Diagnostic Logging to the on position.

    3. Close and exit Lync. Launch Lync and sign-in to reproduce the issue.

    4. To send the logs, tap the ellipses to bring up the menu and tap about.

    5. On the about page, tap send diagnostic logs. The logs are stored in your Saved Pictures folder. To send the logs, tap ok and attach the image to the email that opens automatically.

    6. When the new email opens, tap the paperclip to attach the log file. Swipe the menu to change to date view and select the most recent Lync log identified by the Lync icon.

    7. Type in the recipient’s name and tap send.

    8. To review the log, open the received file in a text editor. The log has a .jpg extension. Change the file extension to .txt and open a text editor.

    To Enable logging on an iPhone

    1. To enable logging access the Logging option from My Info tab -> Options -> Logging.

    2. Within the Send Feedback screen, you have the option to submit Bug.

    3. After you have completed the feedback, click the Next button at the top of the screen. This brings up your iPhone email client. Use your corporate account to send the feedback.

    Note: Logging on an iPad is similar to an iPhone.

    To Enable logging on an Android device

    1. After sign in, tap Options on the Signing in tab. On the Options page, tap Diagnostic logging to enable logging. Sign out and then sign in.

    2. Recreate the issue. Return to the Options screen and tap About Lync.

    3. Tap Send diagnostic logs and then choose a configured email account.

    4. Enter the recipients and subject line information and tap Send. The logs are attached as a .zip file.

    Sample error messages

    Here are some errors you might see in the device logs from Windows Phone 7.

    Error : 410674486 : HttpRequestPump : Got a failure response to request UnauthGethttps://lyncexternal.contoso.com/Autodiscover/AutodiscoverService.svc/root/user. Status: UnknownError. Code: 403.

    Verbose : 410674486 : HttpRequestPump : Error status description for request UnauthGethttps://lyncexternal.contoso.com/Autodiscover/AutodiscoverService.svc/root/user is "Forbidden ( The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. )".

    Error : 410674486 : MetadataManager : Web request to resolve failed. Error: HttpClientForbiddenError [Error, Transport, TransportFramework].

    Here are some errors you might see in the device logs from an Android device.

    ERROR TRANSPORT /mnt/hgfs/marvin_LyncRTM/dev/como/transport/metaDataManager/private/CMetaDataManager.cpp/511:Unable to get a response to an unauthenticated get to url https://Lyncexternal.contoso.com/autodiscover/autodiscoverservice.svc/root/user

    ERROR TRANSPORT /mnt/hgfs/marvin_LyncRTM/dev/como/transport/authenticationResolver/private/CAuthenticationResolver.cpp/554:Unable to get the meta data for server url https://Lyncexternal.contoso.com/autodiscover/autodiscoverservice.svc/root/user

    ERROR APPLICATION /mnt/hgfs/marvin_LyncRTM/dev/como/applicationLayer/infrastructure/private/CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/348:Auto-discovery failed. Analysing the failure

    ERROR APPLICATION /mnt/hgfs/marvin_LyncRTM/dev/como/applicationLayer/infrastructure/private/CLogonSession.cpp/1050:Auto-discovery failed, aborting sign-in!Error Samples

    Here are some of the errors you might see in the device logs from an iPhone or iPad.

    Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)

    ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../metaDataManager/private/CMetaDataManager.cpp/511:Unable to get a response to an unauthenticated get to url https://Lyncexternal.contoso.com/autodiscover/autodiscoverservice.svc/root/user

    ERROR TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../authenticationResolver/private/CAuthenticationResolver.cpp/562:Unable to get the meta data for server url https://Lyncexternal.contoso.com/autodiscover/autodiscoverservice.svc/root/user

    ERROR APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/348:Auto-discovery failed. Analysing the failure

    ERROR APPLICATION /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/applicationLayer/_buildIos/../infrastructure/private/CLogonSession.cpp/1050:Auto-discovery failed, aborting sign-in!

    Note: Log information and verbosity varies as per device and platform.

    These error messages indicate the client is having an issue authenticating with Lync Server 2010. First, verify that Authentication Delegation is verified on the reverse proxy publishing rule configuration. This must be set to No delegation, but client may authenticate directly. If the reverse proxy publishing rules are set to No delegate and client cannot authenticate directly, it fails to sign-in when it reaches the step to provide credentials to request a token after MEX retrieval.

    Summary

    This article describes a process to verify connectivity from an external Lync mobility client to Lync Server 2010.

    1. Browse to https://lyncdiscover.contoso.com. You will receive a prompt to open or save the lyncdiscover_contoso.com file.
    2. Browse to http://lyncdiscover.contoso.com/autodiscover/autodiscoverservice.svc/root/domain. You will receive a prompt you to open or save the Domain file.
    3. Browse to https://lyncexternal. contoso.com/mcx/mcxservice.svc/mex. Depending on your browser settings, you should see a banner for https://lyncexternal.contoso.com/Mcx/McxService.svc/WebTicket_Bearer or you should see XML SOAP information.

    If are unable to connect, verifying the reverse proxy publishing rule configuration. If reverse proxy settings are correct, verify the Lync mobility settings as described in the Lync Server 2010 Mobility Guide. Verify that you have installed the latest updates for Lync Server 2010 Mobility Service. Service Here is the update for Lync Server 2010, Mobility Service: February 2012.

    References

    Lync Server Resources

    We Want to Hear from You