MSPL, and its parent SDK, the Lync Server SDK, are some of the most powerful (and complex) tools for modifying Lync Server behavior. I have a number of posts about how to use the Lync Server SDK and what useful things you can do with it. But since my examples always show MSPL scripts being deployed on the Front End Servers, I wanted to briefly talk about what you can do with MSPL on the Edge Servers.There are really only two Lync server roles on which an MSPL script can be deployed: Front End Servers and Edge Servers. (Actually, you can also put them on other servers besides Front Ends that also have the Registrar service, such as SBAs.) Of these, MSPL scripts on the Front End are generally the more useful of the two, as you can guess from looking at how many of the built-in scripts included with Lync Server are located on the Front Ends. However, there are two important reasons why you might locate a script on the Edge rather than the Front End: security and efficiency.
Any script that has a security function, such as blocking potentially dangerous traffic, should generally be installed on the Edge Servers, so that threats can be blocked before they reach the internal network or the Front End Servers. This is what the Edge Server is designed for, so it makes sense to deploy scripts that complement the Edge Server’s function on the Edge Server itself.
The other side of the coin is that any script that is concerned only with traffic that will go through the Edge Server (to/from remote users, federated users, or PIC users) is usually better deployed on the Edge Server for efficiency and stability reasons. While scripts can and should always be written to operate on the minimum amount of SIP traffic necessary to perform their functions, any time your script has to inspect or modify a message, and particularly when the message has to be dispatched to managed code, there is a tiny impact on the performance of message routing in Lync Server. By themselves these slight slowdowns won’t have any measureable impact, but in the aggregate, if there are very many messages involved, they can affect performance.
By locating scripts on the Edge Server when possible, you restrict the affected traffic to messages passing through the Edge Server to or from an external network. Also, if your script should fail, or cause an unexpected side effect, it can only possibly affect Edge traffic if it is located on the Edge Server.
When registering a new application with Lync Server, you use the New-CsServerApplication command in Lync Management Shell. You have to supply an identity property for the application, which looks something like this:
The word Registrar, after the first colon, identifies this as an application that will work with the Registrar service, usually on a Front End Server. To install on an Edge Server, change the identity as follows:
So your full command will look something like this:
New-CsServerApplication -Identity Service:EdgeServer:edgepool.domain.com/MyApplication -Uri http://www.domain.com/mspl -ScriptName “c:\mspl\myapplication.am”
Once your script is registered, getting it to run, whether as a script-only or managed-code application, works exactly the same as on a Front End Server.