Monday, December 19, 2011

Exchange OWA and Lync Integration Issue: Multiple SIP ProxyAddresses

I was recently troubleshooting a pesky Lync-OWA integration issue where some users could see the integration and some couldn’t.  I was getting the dreaded:

“Instant Messaging isn’t available right now.  The Contact List will appear when the service becomes available.”

Lync-OWA - OWA error - markup

First thoughts were that because it was only happening to a subset of users, maybe the Exchange CAS server that they were accessing through was having issues.  I was able to force a working connection through that same CAS server without issue for other users, so I knew that the CAS was healthy.

Next step was to investigate the user mailbox since it was very consistent as to whether a user worked or didn’t work.  After comparing two users (one working, one not working), I noticed that the non-working user had multiple SIP addresses defined in the Email Addresses Tab:

Lync-OWA - Exch properties dual SIP - markup

Turns out that in this particular implementation, a Resource Forest model was being used for both Exchange and Lync.  The tools used for user synchronization were copying the current user’s SIP proxy addresses to the new Resource Forest and when the users were getting enabled for Lync, multiple SIP addresses were being applied to the “proxyAddresses” AD attribute:

Lync-OWA - Proxy Addresses

After removing the extra SIP proxy addresses from the resource forest proxyAddresses AD attribute, Lync-OWA integration was restored:

Lync-OWA - OWA working

The SIP entries in the proxyAddresses AD attribute should only contain the SIP address that matches the SIP address that Lync is using.

Friday, December 9, 2011

10 Tips for Keeping Lync Jitter Free

As we wind down 2011, it is a great time to review these tips to keep your Lync infrastructure trouble free in the year ahead.

1. Keep up with Server/Client updates

Microsoft releases major updates for Lync Server and Lync clients (desktop and phone), called Cumulative Updates (CU), on a regular basis. Usually every two to three months. It is extremely important to stay current on all updates as these contain hotfixes, performance improvements, security updates and possibly new functionality. The latest CU at the time of this writing was CU4, which was released at the end of November 2011.

2. Monitor Certificate Expiration Dates

Lync relies very heavily on certificates. In fact, all Lync servers require certificates to function since all server to server and client to server communication is encrypted. Lync can utilize both private and public certificates depending on infrastructure and workloads deployed. Since all certificates have an expiration date, it is best to renew certificates that are set to expire before you get too close to that deadline. If a certificate expires, the workload/service that depends on it will stop functioning. You should centrally coordinate the expiration/renewal of all Lync certificates so that administrators aren’t chasing certificate renewals year round.

3. Review Event Logs (constantly)

As with any Windows application, Event Logs play a major role not only in troubleshooting root causes of existing problems, but also in revealing overall system health issues. Lync Server will create its own Event Log so that all Lync events can be easily read and managed. It is best to use a central monitoring platform that will not only gather Events, but provide real-time alerting on errors and warnings.

4. Use the Best Practices Analyzer and Topology Validator Tools

For system health monitoring and validation use the Best Practices Analyzer (BPA) and the Topology Validator tools from Microsoft. BPA will scan your deployment against defined Microsoft best practices for that application. It is a good idea to run this tool at least once per year to assess the Lync infrastructure and its dependent environmental components for problems. The Lync Topology Validator is part of the Lync Resource Kit, which is a freely downloadable set of troubleshooting and documentation tools. It runs synthetic transactions to test all aspects of Lync’s topology including IM, conferencing, PSTN calling, etc. Lync Topology Validator should be run on a regular basis or as part of a monitoring package that will run the synthetic transactions or a scheduled basis. Since it tests most of the workloads utilizing the production infrastructure, real-time validation and troubleshooting can be achieved.

5. Test Failover/Disaster Recover Plans

As with any other vital application in your organization, regular failover and Disaster Recovery procedures should be performed. Depending on your organization’s goals, this plan might span database recovery, server rebuilds, to complete site failovers. Hopefully you will never need your Disaster Recovery plan, but you don’t want to be in a situation where you are failing over or recovering for the first time.

6. Review/Use the Lync Monitoring Reports

The Lync Monitoring role is vital to any Lync implementation. It contains all sorts of reports ranging from usage statistics, trend analysis, and performance metrics. All Lync call quality or failure issue troubleshooting should start with the Monitoring reports. These will expose trouble spots ranging from poor performing network segments, device issues, and problematic users.

7. Validate Backups of Configuration and User Data

Backups are a part of any good disaster recovery plan. For Lync, it is very important to make sure that configuration data, location information, and persistent user data is backed up on a regular basis. Since most Lync information is dynamic, have the preceding three backups will allow an administrator to recover from most scenarios. I always recommend a two-pronged backup plan: backup Lync databases using backup software like Microsoft Data Protection Manager and export the data by using Lync PowerShell commands.  Also, you should back up archiving and monitoring databases.

8. Review Network Utilization

Lync will place quite a bit of stress on your network if you are deploying voice, video, and web conferencing. You should routinely review historical bandwidth utilization reports across all network segments and determine if any Call Admission Control (CAC), Quality of Service (QoS), or workload policies need to be adjusted.

9. Review Administrative Access

Lync uses Role-based Access Control (RBAC) much like Exchange Server. This allows assigning non-administrators delegated access to perform Lync administration duties within Lync. Some examples would include assigning specific users read-only access and the ability to perform troubleshooting tasks (CsHelpDesk) or allowing specific users to provision, move, or assign policies to Lync enabled accounts (CSUserAdministrator). If Enterprise Voice is enabled, delegated access can be granted to configure voice settings and policies (CSVoiceAdministrator). Custom RBAC roles can also be created.  You should regularly review these groups and determine if group membership is still valid.

10. Review Dependent/Environmental Components

Lync is not a siloed application.  It relies on a healthy Active Directory, DNS, SQL Server backend for its databases, Exchange Server for calendar/presence integration, and networking to provide bandwidth and access.  All complimentary components must be monitored and cared for along with the Lync servers to maintain a properly functioning environment.

As you can see from these 10 tips, Lync is a large and complex infrastructure with many dependencies. However, by using this checklist you will be able to avoid many problems, detect pending issues before they can create downtime, and maintain communications service levels your users expect.

Monday, December 5, 2011

Exchange 2010 SP2 Released!

After months of anticipation, SP2 has released and you can get it HERE!
This will bring the Exchange version to 14.2.247.5.  Here are some additional links:

Also note that SP2 can be installed as a new installation. No need to install RTM or SP1 before installing SP2.