Microsoft Lync and Skype for Business have a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use those APIs.

MSPL on the Edge Server

Posted: December 28th, 2014 | Author: | Filed under: MSPL | 4 Comments »

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:

Service:Registrar:lyncfepool.domain.com/MyApplication

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:

Service:EdgeServer:edgepool.domain.com/MyApplication

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.


4 Comments on “MSPL on the Edge Server”

  1. 1 Zoltan said at 8:23 am on January 21st, 2015:

    Hi Michael,

    is it possible to run a UCMA application on an Edge server which is connecting back to the Frontends? Currently Im stucked, if I define a trusted application pool within the edge server name, Lync complains about inconsistent CMS database and the FE service stop working. Any help is appreciated…

    Zoltan

  2. 2 Thomas said at 5:39 am on January 22nd, 2015:

    Hi, I’m getting the following errormessage in event viewer:
    Lync Server Application MSPL script execution aborted because of an error. Application Uri: ‘http://www.mydomain/LyncServerFilter’, at line 57
    Error: 0x80070057 – The parameter is incorrect
    Additional information: ProxyRequest only valid for sipRequest

    Do you have any idea what this means? Snippet from my manifest code:
    if(sipRequest) { DispatchNotification(“OnRequest”, sipRequest.Method, sipMessage.From, sipMessage.To, callId, cseq, content, xdir, xevent, sstate, xexp, referto);
    ProxyRequest();}

    Get-CsServerApplication:
    Identity: Service:Registrar:fqdn.local/Name.LyncServerFilter
    Priority: 3
    etc.
    Enabled: True
    ScriptName: “”

    I’m running a windows service, compiling the manifest (without errors), and I event see some (10) SIP-messages before Lync disables my application.

  3. 3 Mkris said at 7:55 am on February 16th, 2015:

    Hi, you mention that MSPL scripts can be installed on any server that runs registrar component such as SBA. Is that statement correct ?

  4. 4 Ademola said at 3:28 pm on January 28th, 2016:

    Michael, I am getting these two errors on my Front End Servers and this seems to be disabling my application and causing issue for users. Can you tell me what is causing the errors and how i can resolve them.. I have looked into servers perfmon, but healthy.

    event ID 30222

    Script for application is attempting to load a file and there was not enough memory to complete the operation. The application will be disabled.

    Uri: ‘http://Application.domain.com/registrarapplication’
    File: ‘E:\application\Registrar\Filter.txt’
    Flat File Definition Line: 21
    Error: -2147024809!_HRX!
    Cause: Application Specific
    Resolution:
    Application specific.

    Event ID 30297
    Lync Server application MSPL script disabled because of too many errors.
    Application Uri ‘http://application.domain.com/registrarapplication’
    Cause: Application specific.
    Resolution:
    Review the event log entries prior to this one. There should be 10 error events with the same Application Uri. Resolving the sources of those errors should prevent this error from occurring.


Leave a Reply

  • Note: Comment moderation is in use because of excessive spam. Your comment may not appear immediately.

  •