1

Edging Out the OCS Client

Microsoft’s recommended order for deployment when moving from OCS to Lync is to migrate you’re internal services (Front-End pools, mediation, archiving, etc) first, and then to migrate your Edge services to the new Lync servers last. As I found out, there’s a good reason for the order they suggest. With Lync came the ability to create external access policies, which  among other things control who can login remotely. Funny thing though, OCS clients don’t respect these policies because they don’t know anything about them. And even if Microsoft created an update for the client OCS to enable it to use Lync policies, you would still be able to get around it by using a non-updated version of the OCS client.

Now, I hear what you’re saying, “Isn’t this why Microsoft created the ‘Client Version Filter’ in Lync to control this behavior?” Yes, but what about during the migration process where you may still have users on the OCS client? That’s why Microsoft recommends moving Edge services last. But sometimes this isn’t always possible, especially if there were no OCS Edge servers within the existing deployment. This is where I found myself last week. No way to block OCS clients from connecting externally without interfering with internal OCS users during the migration process. After some Googling I came across a blog post from Mark King over at UnplugThePBX which explains the whole scenario and can be found here http://tinyurl.com/em2501

Checkout my solution after the break.

Continue reading