Home » Anywhere365 » Notes from the Field with Anywhere365 and Skype for Business

Notes from the Field with Anywhere365 and Skype for Business

Over the last few months I have been delivering a project that uses Skype for Business and Anywhere 365 to deliver some complex routing scenarios for a customer. As this is my first real heavy weight deployment with Anywhere365 I wanted to share some battle notes.

I will state at this moment that I enjoy working with the product, you can do some really cool and cutting edge stuff with it. The notes are the bumps I found along the way and something you need to consider as you design and deploy. I do not mean for this post to be negative, but rather constructive.


The system requires Trusted Application Endpoints to route calls in and out of a UCC. Depending on your requirements this can range from 4 to 10’s.

  • Each UCC requires at least 4 Trusted Application Endpoints (TAE) to start. 1 x Main Endpoint and 3 x Hunting Endpoints. The Main TAE is the one that you will be assigning a Line URI to and will be your main inbound and outbound endpoint from which you make and receive calls into the contact center. The hunting endpoints are used to hunt available agents and invite them into the call.
  • All endpoints require a conferencing policy. This is because all calls are conferences, therefore the endpoints need permission to create a conference on the conferencing pool.
  • If you want to also have an outbound contact center, you need an additional endpoint that is used for routing. This routing endpoint is also required for inbound agent interception (more on this later)
  • Also if you want outbound calling, every endpoint requires a dial plan and voice policy. Calls will be made using these policiesand not the policies assigned to the agent’s Skype object. The endpoint is selected at random. The Caller ID is that of the main endpoint to the contact center or the Agent’s Skype number depending on the setting chosen. This means that hunting endpoints do not require LineURIs, but require EV to be enabled and dial plans, voice policies to be granted.
  • Have multiple inbound lines? A modality endpoint is required for each one. The modality endpoint is like the main endpoint but instead can be used to either enter the same flow as the main endpoint, or be used for side insteps. A side instep is where you call a particular number to bypass the default call flow e.g. field service technician calls a service desk number to get through to a dedicated queue rather than having to listen to a bunch of IVR options.
  • Want webchat? That’s another 4 x Chat Endpoints. 1 for the main chat endpoint, 3 for chat hunting endpoints. 3 chat hunts allow for up to 3 chat conversations per agent, if you dont add chat hunting endpoints, you can only have 1 chat per agent.
  • If you use the WSP naming convention for these endpoints e.g.ucc_hunting00X@domain.com and you get to 100+ then use ucc_hunting00100@domain.com keeping the double zero. This is because their failover script looks for 00 in the sip address to decide whether or not to hide them from the address list. However, if you use your own naming convention, this is also fine, just make WSP aware so they can alter their scripts accordingly.
  • More of a Skype nuance this one, if you create multiple endpoints at once (and you will), be sure to check that you haven’t accidentally named two or more endpoints with the same SIP address. Due to the replication delay in Skype if you hit execute duplicates will be entered into the configuration and the unique sip address validation check is “skipped”. This means pain afterwards trying to figure out the duplicates and then deleting and re-creating them.


In order to use the Agent Extension Window, the Inflight Snapper or the Wallboard, you need to connect to a web service. The web service is hosted on all Anywhere365 servers, but is valid on the active server only. By default all scripts and deployment documentation provided by WSP do not clearly show what is required for HTTPS, only HTTP. If you have external agents then you’ll want this web service to be accessible over the internet. Therefore, HTTP is a bad idea, and HTTPS should be used. My recommendation is to use HTTPS both inside and outside of your organisation. Avoid using direct web connection to the Anywhere servers and use a reverse proxy instead, for both internal and external client ingress. This allows you greater flexibility for DR and does not require a URL update to the client software.

Use Split-DNS, or pin point to make your external FQDN of the web service accessible internally e.g. uccweb1.domain.com.

You can use a wildcard certificate, the application is IIS based so it doesn’t care so much for specific SAN entries. However, dedicated web SSL is always recommended. If using HTTPS the web.config file for each Anywhere365 web service will need to be updated to include a HTTPS binding, only HTTP is included by default. If you don’t do this, you will get a 500 Internal Server Error!

If you expose your web service over the internet to accommodate external agents, then there are additional IIS configurations you will want to consider to secure the Anywhere 365 web services. My recommendation is to configure two web sites in IIS. One for Internal and One for External. The internal site would require no authentication or NTLM, while the external website can be configured for Basic Auth to prompt the external agent to authenticate with the web site before being allowed access to the data via the Anywhere365 client side apps. Much like Skype’s web setup, we are taking additional steps to ensure secure access when external.


The interceptor is used to “intercept” incoming and outgoing calls of an agent. If I was the caller and I called the Agent’s Skype Line URI or a federated call over Skype, the conversation I had with that agent would not be recorded in the contact center. Therefore, I have circumnavigated process and jumped the queue. With the interceptor, Anywhere can prevent this from happening, but looking at each invite to an agent and if it contains audio in the SDP body, the invite will be intercepted and re routed to the contact center in which the agent is added.

There is a setting to ignore any incoming audio invites coming from internal domains, or perhaps you want to enable this for internal callers too.

The interceptor is needed for outbound calls too. If outbound calls require to be recorded (conversation and/or CDR) by the contact center then they need to be intercepted. The interception will ensure that the agent is placed into a conference first before placing the outbound call to the callee. The default experience to the callee is that of a normal call, but to the agent it looks like a conference, although, the agent will hear the dial tone played.

A side effect of having interception enabled means that you cannot use reason codes without the agent being a member of another UCC that is not enabled for interception (subscriber UCC). There is a script available for WSP to keep these two UCCs agent lists in sync so at least the admin effort is reduced for MACDs. I fed this back to WSP and they plan to address this in a future release, so hopefully by the time you are deploying, this is no longer an issue.

The interceptor is an MSPL script on each front end server. It has its own service that must be started. Sometimes it will fail to start if RTCSRV takes too long to start up, so make sure it is started or set to delayed start. As a result, if an agent requires interception, then they cannot be registered to an SBA. They must be registered to the FE pool that has the interceptor installed. Otherwise, the invite never makes it to the FE and the interceptor will not know about the conversation

Delta Syncs

Anywhere gets its configuration from SharePoint lists. Every 10 seconds the configuration is refreshed and cached on the Anywhere server. In delta syncs if you have edited an agent’s SIP address in the agent list, i.e. marital name change for instance, this is not picked up by the delta sync. It seems this is by design and the sync looks for line IDs greater than or missing in that of the last sync to bring down changes, this is why adds / removes work, but edits do not. This appears to only affect the agent list only. So therefore, you have two options. Option 1 – add the agents as a new agent and replace their skills assigned to their old SIP address, then remove their old identity. Or option 2 – restart the UCC with a clean cache to force a full sync. (There is a fix coming).

First Call Blues

After you have restarted or started the UCC for the first time, the first call can take a while to initiate. This is especially noticeable when forwarding between UCCs. Subsequent calls work fine. This is because there is a TLS handshake that needs to be established between the trusted application and the front end pool that it is registered to. This happens on first call, and subsequent calls use the same authentication token from the original handshake.

HA is Server HA, not Voice HA

When discussing High Availability it is important to remember that Anywhere does not perform HA in the same way as Enterprise Voice HA. If an Anywhere server goes down all in progress calls are terminated. No new calls can be received either until such time as the standby Anywhere server has started the UCC service and started the contact centers. This means that HA in Anywhere world is akin to HA in VMware when a host is lost for instance, and all virtual servers are started from a cold start on another host.

Active / Active Servers

It is possible to have two Anywhere servers running in a trusted application pool actively running uccs. However, they must not be running the same ucc application at the same time. If this happens, you will experience weird behaviours like agents not being placed into the correct call, callers hearing hold music as well as the agent speak, caller ID not working correctly and a whole raft of other weirdness.

Techie Product

The Anywhere application is a techie product. What I mean by that is it requires some significant hands on to setup all the advanced features like, automatic HA, DR, Extension Windows etc. When you deploy it, it’s not like a traditional MSI, input a few parameters and away you go, the whole product is deployed and now configurable in an Admin Control Panel, or PS Module. It requires config file manipulations and the deployment of supporting scripts as scheduled tasks to glue some of it together to make it work. Once it’s in it works and works reliably, my intention here is not to tar the product but to ensure it is understood. I do feel that the install process could be worked on to deploy all features and there is definite scope to use SharePoint lists to configure some of the server back end configuration elements in a pure System Admin Portal. This would make the product seem less custom developed app and more enterprise product.

DR is a Dream

I have to say, their DR process and script is probably the best I have seen. In order to get DR to work there are several scheduled scripts that run daily to ensure DR pain is minimal. Each day the config and applications are backed up to the DR standby server. Applications are synched with the DR pool so they exist in both production and DR pools. In a DR event, all that is then required is to execute the failover script to move the trusted application endpoints from the failed pool to the DR pool, update the CDR DB connection string and start the UCC Service on the DR pool. This means that you can perform a DR of Anywhere in less than 30 mins of initial failure.

CDR Database Resiliency and HA

Anywhere relies on the CDR database for historic records and last agent routing. It is recommended therefore to ensure that the CDR database is as close to the Anywhere servers as possible. Anywhere doesn’t have any baked in control or management of SQL like Skype has and therefore supports any native HA and resilient SQL strategy. To Anywhere it’s just an app database that they need to read and write CDR data to, it contains no configuration. So AlwaysOn, Clustering and Mirroring technology can be used for HA.

In a DR situation though, you’ll want to ensure that the CDR database is also replicated to the DR datacenter. My guidance is to follow the supported cross datacenter topologies for the SQL HA technology you are deploying. For Mirroring, it is best to mirror to a local peer with a local witness and configure log shipping to the DR database. In the same way as you would with pChat in Skype. The failover script allows you to update the CDR DB connection string so that Anywhere will be looking in the right place for data.

Wallboard and Snapper Improvements

The client side applications seem to be treated like independent applications rather than extensions of the contact center. Therefore, require localised configuration files to configure for each contact center. The snapper isn’t so bad, but could benefit from an autodiscovery service to auto configure the snapper to look at the agent’s contact center membership. Initial deployment is fine, but MACDs would require snapper reconfiguration by the agent. This is GUI based but nevertheless a step that could be improved.

The Wallboard however relies on the config file for SLA calculations. If a manager wants to change the default SLA calculations this is done in the wallboard config.xml file. It would seemingly be feasible to include these SLA type calculations in SharePoint and push these out to the wallboard

These two small improvements would make the client side applications feel more integrated and easier to manage.



  1. Hey Mark, thanks for this blog. Just found your site and this entry and found it good reading.
    I’m preparing deploying A365 across our organisation (plus customer sites) and it’s been an interesting experience so far.
    Your comment about it being a techie product is 100% correct and I think they have some work to tidy up the installation process of Core and the many other functions. On one hand the product feels a little unfinished but on the other hand I’ve never got to know the ins and outs of a complex system as quick as this one! Thankfully support have been very helpful.
    Also the best thing I can say about this product was how easy it was to deploy to a real customer – we’ve put it out to our IT service desk and not had a single issue with calls dropping, customers getting stuck or anything. It just worked! First time in over a decade I’ve installed a contact centre and it all worked and we did it in no time at all, including wallboards, prompts and reporting. Great stuff.

    Hoping for improvements in the system soon though:
    Snapper – Need to be able to change Reason Codes from the GUI. Although the IM controls work quite well they are a little clunky
    Wallboard – nowhere near enough customisation
    Voicemail – cannot easily send voicemail to a shared email box without using a powershell script and scheduled task
    Creating UCCs or EndPoints – Don’t like that you have to restart the UCC service, or comment out parts of the config file. High risk!
    Call recording – not enough options. Would like to have an option to not record unless the agent clicks start.

    System has loads of potential and excited about what it can offer in the future. Hopefully the developments and improvements keep on coming!

    Good luck with your deployments!


    • Hi Peter
      Thanks for your comments. I do agree with you on your points, it could be a little more polished in places. I am often skeptical of scheduled tasks and supplementary scripts as its just one more moving part to solve a very precise issue. The IM controls in my opinion should be canned and put entirely into the snapper. Lack of customisation of the wallboard, but also lack of a decent web based one as well, it seems beauty has been put above practicality in places. Also my frustration is that the snapper especially is controlled by local machine config xml, making SLA changes and UCC changes a right pain point from an admin perspective. But I know they are working on an autodiscover feature to solve that.

      Voicemail – we got around this particular problem using Exchange UM shared UM mailboxes rather than UCC Voicemail.

      For the endpoints, there is an enterprise plus licence that breaks out UCCs into separate windows services which may be useful, but yeah cut and paste in an config file can be twitchy if you’re in a rush.

      The call recording is as i see it value add, they do it because they can. I am sure if you speak to them about agent start / pause / stop they will help you.

      All in all it has its niggles, but most contact centers do, overall it is a decent product although there is a point where it doesn’t become scaleable due to some advanced routing scenarios and SharePoint limits.

  2. Nice to hear your issues and concerns match mine. I hope Workstream People are listening to the feedback and putting emphasis in the right places. I get a little concerned when I see developments for the Microsoft Bot Framework and PowerBI etc when some of the basics are still lacking. Hoping version six brings some critical system improvements.

    The snapper could be great but it’s a bit of an afterthought, I’ve left them know my thoughts on the matter so hope it becomes a priority for them.

    Don’t want to be too down on the product as it is delivering a lot of improvements for us and from what I’ve seen this is the best native Skype contact centre out there.

    Bit concerned about your comment regarding scalability though! I imagine we’ll hit 100UCCs by the end of the project (we are licensed for unlimited), we’ve been told they have customers much larger than us so wasn’t anticipating an issue. Have resourced the servers appropriately but we’ll see how it goes.

    • My last comment about scale, if you have 100 independent UCCs then that’s no problem. When I deployed it we had specific routing requirements that meant calls had to be passed between different UCC layers because we couldn’t have a prompt message play and then use inbound / last agent routing in the same flow in one UCC. This meant we have to have 2 x UCCs for 1 logical workflow. It was a very unique flow requirement to which it seemed to get a little clunky. but other than that 99% of the time it works fine.

      Don’t get me wrong, I like the product and I like WSP, however, all things need to be considered without emotion to best suit a potential customer.

  3. Hi Mark,

    I like your post it in 90% correspond with my feedback from the deployment this application in our environment. I must say I have different opinion on the HA and resiliency of the application. I think they are very good on the frond end and invest apprently alot to the front end services because what application can do and how it looks is very cool. But I think they are slacking on the backedn development as they are not yet prepared for the enterprise solution really.

    First thing I was communicating with them and they said its already on pipeline is having application servers active-active. In the UCMA this possibility is, but they just dont have it yet and they were never able to provide commitment when this will be ready. Their active-standby scenario is very weak and it introduce an impact during the failover. Also when failover occurs, having 70 UCC in place it take a while to register all the endpoitns and have all UCC back functional. The failover script is actually something they developed on our request as before they were couting only with manual failover which is no way in our environment (its already 2 years since I started work on this project with WSP).

    Secondly they resiliency in case of Skype for Business server failure is also very bad. It happens to me several times that if there was something with a FE that was just serving the AW365 Endpoints registration, the endpoints did not re-register to the another FE server and so get stucked offline. The only thing which always helps is to restart the service which is not really convinient, the application should recover itself.

    Last but not least, their Pool failover procedure is a funny thing. They ask you to use their script to backup all the settings in topology about the trusted application and recreate all the settings to the failover pool. Again this requires a man operation and this could be solved within the application as UCMA and topology supports that endpoints having as a next hop 1 FE pool can easily register to the secondary pool as the TrustedApplication is feature is topology-wide so any FE pool or registrar can communicate to the trusted application.

    Also I dont want to be above taken as an complaint or warning for anyone to not use the application. I think it is good contact center and for sure one of the best for Skype for Business, but I just wanted to pointed out weak points and features that I am missing. Maybe some others have the same or similar opinion so we as a customers can make a pressure to WSP to implement this as from my point of view it is very important for enterprise solutions.

    I would very recommend to read through your blog anyone who is starting to deploy this application, pity it was not here 2 years ago 🙂



  4. does anyone have an objective comparison between A365 + Skype For Bus vs. Cisco Contact Center Enterprise?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: