Lync 2010 Pool / Lync 2013 Client Coexistence

Scenario

If you are in a coexistence environment, and you have your LyncDiscover pointing at your 2013 Front End Pool, you may experience some odd behavior.

Your Lync 2013 clients that are still homed on the 2010 pool (why you would do this, I don’t know) will start pitching an error that says they cannot trust the server…

clicking on “Connect” here lets the login continue.  But the next time, this error does not reappear.  It does not reappear because the endpointconfiguration.cache file is holding your information.  However, we don’t want this error to appear at all!

Why is this happening?

Well, it happens the first time because the LyncDiscover.domain.com is the primary discover tool for the Lync 2013 client.  For a more detailed look at this new method, see this. When you click on the “Connect” the endpointconfiguration.cache (c:\\users\username\appdata\local\microsoft\office\15.0\lync\sip_username@domain.com)  file is updated with the proper information.  You can prove this by logging out the user, deleting the endpointconfiguration.cache file, then login again.  The error will reappear.  Worse, if you have a large environment with the Lync 2013 client deployed to users on a Lync 2010 pool, you may see this a lot.  Help Desk calls galore.

How to fix this?

This is happening because the LyncDiscover service is pointing the user at the Lync 2013 pool.  And then that server is doing an AD lookup, discovering that the user is homed on a 2010 pool, and telling the client to talk to that server – at which point the pool name and the cert used by the client for the initial login no longer matches – hence the error.

To fix this, you need to keep your LyncDiscover DNS pointing at the Lync 2010 pool.  Alternatively, if you never deployed Lync 2010 Mobility (where LyncDiscover comes from in Lync 2010) and you don’t plan on using Lync 2013 Mobility, then you can simply not define LyncDiscover at all.  Personally, I do not like this second option – I would go out of my way to deploy the Lync 2010 Mobility just to get the entire suite deployed, and start using LyncDiscover; after all, Mobility is now part of Lync natively, and the 2013 client is looking for this service.

YMMV

Lync 2013 Migration Process Outline

 

Do you get frustrated with the online documentation that makes you flip back and forth between pages?  I know I get lost a lot.  And sometimes I would like a nice, easy-peesy layout that will allow me to click on the subject I want without having to go diving in and out.  Accordingly, I assembled all the Lync 2013 migration process pages into one doc.  Links should be clickable.

The following information is taken directly from the latest online Microsoft Lync Server 2013 documentation. Full understanding  the implications of each action inside of each migration project phase will make your Lync 2013 migration much easier.

• Before You Begin the Migration
  • Deploying Lync Server 2013
  • Deploying Lync Server 2013 Standard Edition into an Existing Lync Server 2013 Enterprise
  • Deploying External User Access
  • Deploying Clients and Devices
• Phase 1: Plan Your Migration from Lync Server 2010
  • User Migration
  • Migrating Archiving and Monitoring Servers
  • Migrating Group Chat Servers
  • Administering Servers after Migration
  • Migrating Multiple Sites and Pools
  • Migrating XMPP Federation
• Phase 2: Prepare for Migration
  • Apply Lync Server 2010 Updates
  • Configure DNS Records for Pilot Pool Deployment
  • Run Best Practices Analyzer
  • Back Up Systems and Data
  • Configure Clients for Migration
  • Verify Lync Server 2010 Environment
• Phase 3: Deploy Lync Server 2013 Pilot Pool
  • Prepare Active Directory for Lync Server
  • Download Topology From Existing Deployment
  • Deploy Lync Server 2013 Pilot Pool
  • Verify Pilot Pool Coexistence with Legacy Pool
  • Connect Pilot Pool to Legacy Edge Servers
  • Configure XMPP Gateway Access Policies and Certificates
• Phase 4: Move test users to the Pilot Pool
  • View Current Users in Lync Server 2010 Pool
  • Verify User Replication Has Completed
  • Move a single user to the Pilot Pool
  • Move multiple users to the Pilot Pool
• Phase 5: Add Lync Server 2013 Edge Server to Pilot Pool
  • Deploy Pilot Edge Server
  • Verify Configuration Settings
• Phase 6: Move from Pilot Deployment into Production
  • Configure Federation Routes and Media Traffic
  • Verify Federation and Remote Access for External Users
  • Change Simple URLs after Migration
  • Move Remaining Users to Lync Server 2013
  • Configure XMPP Gateway on Lync Server 2013
• Phase 7: Complete Post-Migration Tasks
  • Migrate Existing Meetings and Meeting Content
  • Migrate Dial-In Access Numbers
  • Migrate Call Park Application Settings
  • Migrate Response Groups
  • Migrate Address Book
  • Configure the Meeting Join Page
  • Remove Legacy Archiving and Monitoring Servers
  • Configure Trusted Application Servers
  • Deploy Lync Server 2013 Clients
  • Connect a Survivable Branch Appliance
  • Configure SCOM Monitoring
  • Migrate Common Area Phones
  • Migrate Analog Devices
• Phase 8: Decommission Legacy Pools
  • Update DNS SRV Records
  • Move the Lync Server 2010 Configuration Management Server to Lync Server 2013
  • Remove the Archiving Server Association
  • Remove the Monitoring Server Association
  • Remove the Enterprise Edition Front End Server or Standard Edition Front End Server
  • Remove SQL Server Instances and Databases on the Back End Server

Lync File Share Size

One of Lync’s great features is Web Conferencing.  With users leveraging Web Conferencing more and more, complete with content uploads, a question of “how big does my share space need to be” comes up.

The Lync File Share, per pool, is an amalgamation of all web services content, address book, and conferencing data uploaded by users. By default, the size limit per conference is 500MB and the Conferencing Server will maintain the conference data for 15 days. In my experience, the uploaded meeting content will be the bulk of any projected Lync share space usage.

I had a project with 60,000 users and the initial decision was to let them ALL have full global conferencing profile status.  Using the numbers above and the projected 60,000 conferencing users would have created a file share need of 450TB.

  

days to retain	max data (MB	provisioned users	file share size (MB)
15	500	60,000	450,000,000

So we had to do something.  450TB of data storage, even thin-provisioned and potentially spread across multiple servers, represents a considerable cost and commitment. 

One Solution

Let’s take a look at the default  CSConferencingConfiguration:

Get-CsConferencingConfiguration

Identity                           : Global
MaxContentStorageMb                : 500
MaxUploadFileSizeMb                : 500
MaxBandwidthPerAppSharingServiceMb : 375
ContentGracePeriod                 : 15.00:00:00
ClientMediaPortRangeEnabled        : False
ClientMediaPort                    : 5350
ClientMediaPortRange               : 40
ClientAudioPort                    : 5350
ClientAudioPortRange               : 40
ClientVideoPort                    : 5350
ClientVideoPortRange               : 40
ClientAppSharingPort               : 5350
ClientAppSharingPortRange          : 40
ClientFileTransferPort             : 5350
ClientFileTransferPortRange        : 40
ClientSipDynamicPort               : 7100
ClientSipDynamicPortRange          : 3
Organization                       :
HelpdeskInternalUrl                :
HelpdeskExternalUrl                :
ConsoleDownloadInternalUrl         :
ConsoleDownloadExternalUrl         :

From here is it fairly easy to see that we can use a few of these attributes to make some changes:

Set-CsConferencingConfiguration -identity global -MaxCon
tentStorageMb 200 -MaxUploadFilesize 10 -ContentGracePeriod 7.00:00:00

This gives us a totally different outcome:

Get-CsConferencingConfiguration

Identity                           : Global
MaxContentStorageMb                : 200
MaxUploadFileSizeMb                : 10
MaxBandwidthPerAppSharingServiceMb : 375
ContentGracePeriod                 : 7.00:00:00
ClientMediaPortRangeEnabled        : False
ClientMediaPort                    : 5350
ClientMediaPortRange               : 40
ClientAudioPort                    : 5350
ClientAudioPortRange               : 40
ClientVideoPort                    : 5350
ClientVideoPortRange               : 40
ClientAppSharingPort               : 5350
ClientAppSharingPortRange          : 40
ClientFileTransferPort             : 5350
ClientFileTransferPortRange        : 40
ClientSipDynamicPort               : 7100
ClientSipDynamicPortRange          : 3
Organization                       :
HelpdeskInternalUrl                :
HelpdeskExternalUrl                :
ConsoleDownloadInternalUrl         :
ConsoleDownloadExternalUrl         :

days to retain	max data (MB	provisioned users	file share size (MB)
7	200	60,000	84,000,000

Still not great, but much better.  You will notice that in the previous command, I also restricted the size of the maximum upload, which will help also. What they ended up deciding was that only 10k users would have the ability to create a web conference with 100MB of storage for a retention period of 7 days. even so, the projected need at that point was 7TB. 

While that one project is LARGE in terms of users, a more recent project with only 200 users calculated out to needing 600GB projected storage for 15 days of 200 users at 200MB.  This project team will want to use policies to control the ability to create conferences and control content also.  After all, even in the days of multi-terabyte drives, throwing drive space at the issue is not a substitute for understanding and planning. Here is a handy chart that might help visualize the issue:

days to retain	max data (MB	provisioned users	file share size (MB)
7	100	200	140,000
15	200	200	600,000
10	300	200	600,000
10	400	200	800,000
15	500	200	1,500,000
7	200	60,000	84,000,000

Clearly, there may be other methods to control the size of the file share, this is just one.  Remember that in your efforts to be concise in capacity planning that the file share holds the uploaded conference material and plan accordingly.  A few questions come to mind:

1. How much uploaded material will there be for the typical user?
2. Can the users be segregated in terms of capacity?
3. If #2, can we safely place users in distinct pools to help control size?

This list can go on for a long time, but I think you get the idea.

YMMV.

Project Guidance

This article was written with Lync in mind; however, it also applies to Exchange and almost any other IT project as well.

http://blogs.technet.com/b/nexthop/archive/2012/12/11/ten-tips-plus-one-for-implementing-lync-server.aspx

As a modest disclaimer, I wrote it.

YMMV.

IIS AAR hotfix

With TMG on the verge of no longer being sold, we need to find some reasonable alternatives to Reverse Proxy solutions for both Exchange and Lync.

IIS Application Request Routing is one such solution that may work for you or your client’s environment. If that is the case, then you will want to be aware of this hotfix: MS KB 2785586

http://www.microsoft.com/en-us/download/details.aspx?id=35827&WT.mc_id=rss_alldownloads_all

YMMV.