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.
To fix the problem mentioned above I chose to use a MSPL script. MSPL is the Microsoft SIP Processing Language and is used pretty extensively within Lync, and even OCS. Here’s what a normal SIP REGISTER looks like when captured on the Lync Edge server.
What I decided to target was the User-Agent shown above as UCCAPI/3.5.6907.236 OC/3.5.6907.244 (Microsoft Office Communicator 2007 R2). OCS clients always report their version number as 3.* whereas the Lync client will report 4.* as the client version. This gave me a simple target to verify client version level. I originally started with trying to run the MSPL script on the Front-End server to target the SIP REGISTER request, however this became problematic as I couldn’t find a good way to separate clients connecting internally versus externally. My goal was to block OCS clients only when they attempted to connect remotely, so I didn’t affect internal users during the migration process. Whenever I checked the message origin on the Front-End server it reported as internal, probably because the message came from the Edge Internal interface. Moving the application to the Edge server I was able to effectively target OCS clients, and not affect the migration process. The script is configured such that it will only look for SIP REGISTER and INVITE message coming from the outside, and then check if the client major version number is 3 which corresponds to the OCS client. When all the conditions are met, it will send a SIP 503 Service Unavailable to OCS clients trying to login externally. Below is the message sent to the client and the conversation as seen on the Edge server via the Lync Logging Tool.
From the users prospective all that the OCS client reports is that the server is temporarily unavailable. While the same user logging in via the Lync client is able to login as normal.
By default the script is set to generate a warning in the event log when a user is blocked from logging in with the OCS client externally. The message shown below is what is recorded.
The event log message can be disabled or customized by modifying line 27 of the script. Changing the setting from “true” to “false” will disable the messages from appearing in the event log, while modifying anything after that will alter the message that appears.
For my lab setup where I built and tested the script, I just dropped the script into the C:\inetpub\wwwroot folder on the Edge server as MSPL scripts need to be accessible via a webcall. To make this work in your environment you’lll need to modify the appUri setting on Line 2 to match the web location where a copy of the script can be accessed. One option for a deployment where redundancy is needed is to put a copy on each of the Front-End servers and adjust the appUri to point to the Front-End pool via HTTPS. You will need to have a local copy on each of the Edge servers also, and it will need to be in the same directory on each server. The last step is to create the CsServerApplication via PowerShell which cannot be done from the Edge servers, but instead must be done from a Front-End server. Below is the command I used to create the CsServerApplication.
New-CsServerApplication –Identity “Service:EdgeServer:Edgepool.domain.com/BlockOCSEdge” –Uri “http://fepool.domain.com/BlockOCSEdge” –ScriptName “C:\Path_to_Script\On_Edge_Server\BlockOCSEdge.am” –Enabled $true –Critical $true –Priority 0
All of the above sections in red will need to be tailored to your environment, the most important thing is that the appUri in the script file matches the Uri field you specify, and that the path on each Edge server is correct. As with all of the stuff I post, PLEASE PLEASE PLEASE test and verify before you deploy this. I’m not responsible for any and all problems that may arise from using this in a testing or production environment. The script download link can be found below.