About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2012/12/31

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…

image

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

2012/12/20

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.

2012/12/14

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.

2012/12/11

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.

2012/12/03

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.

test 02 Feb

this is a test it’s only a test this should be a picture