Remote Connectivity: The Trick to Getting the Most Out of Avaya Support

If there’s one “trick” to getting the absolute most value out of your Avaya support coverage, it would be enabling remote connectivity. Allowing a trained Avaya Support Engineer access to your Avaya system in times of need delivers 21 to 50 percent faster resolution times than without.

In the past, Avaya used the prevalent technology, modems, to provide remote connectivity. In 2009, we introduced our Secure Access Link (SAL) technology which delivers high-speed connectivity over a HTTPS tunnel. The SAL Gateway is a component of a downloadable package called the Avaya Diagnostic Server. This application is deployed on the customer’s network, providing remote connectivity and alarming back to Avaya. It’s a free entitlement to all Avaya customers with active support coverage.

Another component of the SAL solution is the Policy Server, which enables the customer to manage and control policies of how their applications are remotely accessed. Like the SAL Gateway, this application is deployed in the customer’s network. The customer then uses it to build policies that control who, when and how Avaya can access their systems. One of the most popular policies available is inserting a step where the customer’s IT department must manually approve a connection request from a support engineer before connectivity is established. This is certainly more manageable than only plugging in that old modem phone line when you know an engineer wants access.

I won’t go into the nitty-gritty details here about the security features of SAL, but it’s important to understand that all connections are established from the SAL Gateway on the customer’s network, outbound, to Avaya − never inbound from Avaya to the customer. All traffic is encapsulated within a HTTPS tunnel, thus only port 443 outbound must be open on the customer’s firewall.

Our Authorized Business Partner community is an important part of our support offerings, and as such, many of our partners utilize an Avaya SAL Concentrator, which also allows them to use the SAL solution for remote connectivity as requested by the customer.

While implementing SAL is relatively straight-forward, it’s important to understand that for the solution to work, each Avaya product must be properly registered with Avaya in the Global Registration Tool (GRT), which gives the product its own unique ID (“SEID”). Then that SEID must be properly onboarded in GRT so that connectivity can be established.

In August, we made a new tool available to Avaya and partner account teams to not only report out on how healthy the connectivity is to every customer-deployed Avaya product, but to also provide actionable information on how to resolve any issues. Please be sure to work with them to make sure your entire Avaya solution is getting the value of remote connectivity.

dashboard

In summary, remote connectivity is the linchpin in getting the most value out of your Avaya support coverage. With it, you get faster resolution times and the ability to have proactive alarm monitoring and remote diagnostics.

If you missed my first blog in the series about the value proactive support brings compared to reactive support, please read it here. Stay tuned for the rest of this series, where I’ll speak to the value out of alarm monitoring via EXPERT SystemsSM and the SLA Mon™ Server.

The video below covers the material above and more about SAL, including a flow diagram of how connectivity is established with SAL:

Contact or follow me on Twitter: @CarlKnerr