Benefits of Public Sites for External Monitoring

Exoprise supports monitoring from inside the firewall and outside the firewall. Every day, we have prospects spin up Synthetic Transaction Monitoring (STM) as part of their free trial to test tenant access and performance from one of the Exoprise public points of presence, which we refer to as public sites.

Exoprise Public Sites are cloud-based Virtual Machines that are owned, operated, and paid for by Exoprise. They are a shared resource available to every customer and free trial users. Private sites refer to a cloud-connected installation of our service (or daemon) on Windows, macOS, or Linux on customers’ premises – customer computers or VMs. We also have many customers who run our private sites from cloud-based VMs for when they want to test VPNs or other scenarios.

In this article, we will be covering some benefits of Public Sites. We’ll detail the differences between private and public sites, as well as providing some real customer scenarios for using public sites.

Since the beginning of the pandemic, working from home (or anywhere) has become common. Although some organizations have begun returning to the office a few days a week, the majority are still hybrid or fully remote. This creates a blind spot, as monitoring the end users’ home networks, or remote work locations, is not something typically offered by IT teams.

Differences Between Public and Private Sites

Private sites are devices or virtual machines that customers own that run our synthetic monitors (sensors or probes, whatever you want to call them). When everyone was working from offices, deploying CloudReady synthetic sensors to private sites provided lots of what was needed to monitor SaaS applications, web pages, services, etc. Running probes from locations where you have the preponderance of employees was just the ticket to proactively measure the digital experience of SaaS and Web apps from a customer’s networks including gateways, access points, and proxies – and everything-in-between.

Ideally, for every Exoprise deployment, you want to model what the user experiences. You want the transactions to execute through the same network layers; SSL inspection, proxies, and devices so that you can emulate the employee digital experience and know about problems or outages in the service delivery chain before they grow and impact the business.

Nowadays, with knowledge workers no longer working centrally, you still need to provide the same detection and emulation to ensure optimal experiences. The question is: Where do you monitor from? This is one reason we provide Public Sites or Points of Presence (POPs).

Public sites offer cloud-based locations to run probes from. They run from Exoprise owned public cloud locations, such as Amazon, Azure, and others. These sites are managed and maintained by Exoprise alleviating the need for customers to manage the resources. We ensure superior uptime and availability of our public sites. Almost all CloudReady synthetics can be deployed to public sites, excluding a few that don’t make sense, like the Azure Virtual Desktop and Teams Audio Video sensors. You can read more about Public Sites here.

Public sites should be used in situations where you don’t have a dedicated device to run your synthetic tests in that region. Another reason to utilize public sites is when you want to monitor a web-or relay resource from outside the corporate LAN. Say, you have a dependent service or a component of Single Sign-On, VPN, or Cloud Access Security Broker that is hosted on-premises. You will definitely want to synthetically test that resource for availability and response times.

Public site locations are “virtual”, we have a farm of resources behind each public site and automatically balance the load depending on trial starts and customer deployments. And we’re always evaluating new locations for public sites, new providers, and new site types.

Example Use Case For Public Sites

For example, one US-based organization we have been working closely with has recently expanded its sales team to the UK. All their UK users work remotely and are using their own devices to work from. Since they don’t instrument end users’ personal devices, they need to find an alternative to monitoring their apps. This led them to deploy their sensors to the London Public site.

The customer identified tenant outages on the Microsoft side in tandem with their Single Sign-on provider that were only being detected from the sensors running externally to their network. At that same time, their sensors running from the US offices on the internal network didn’t experience the outage. By leveraging external SSO monitoring, they could proactively notify users about the diminished experience ahead of time; 40 minutes before the SSO vendor acknowledged the outage on their end.

This customer was able to communicate to their team before getting a surge in tickets.

Not Just For Remote Regions – Baseline Metrics

Deploying sensors to public sites isn’t only for monitoring from remote regions. Deploying to public sites can also serve as a control or baseline measurement when deciphering whether and where an outage is impacting productivity.

In the previous example, an outage was detected overseas that wasn’t affecting the US offices. However, if an internal network isn’t performing optimally, public site sensors can be examined, to determine whether the issue is specific to the tenant, network, or application provider. Typically, sensors run from public sites are more consistent and reliable compared to ones that run from internal corporate networks. Why? Because public cloud hosts and networks have built in network capacity limits that offer a more reliable and consistent experience.

Running synthetic tests from Private Sites and Public Sites is ideal for comparing internal security posture with applications versus bypassing them. From a private site, if a proxy is in place, the sensor will run as if a user were accessing the app – through the proxy. The identical sensor running from a public site would not utilize the proxy, allowing comparisons for network throughput, latency, and access.

External Monitoring from Public Sites

Originally, Exoprise accelerated development of public sites for monitoring Active Directory Federated Services (ADFS) because it was mission-critical, deployed on-premises, exposed to the Internet, and required high-availability.

Similar characteristics exist for web-based apps and network security services that are provided by IT for end-users. If you offer or host web-based applications that your users are dependent on, then you should contemplate deploying a Web Login-based sensor that automatically signs in to the application and provides real-time availability and performance alarms.

If you provide services to customers throughout the world and need to ensure web resources are accessible and performing well, this can easily be accomplished by deploying specific sensors to the public sites in regions where customers are located.

Web Monitor and Web Get sensors deployed to multiple public sites will continuously test the availability of the specified URLs and web servers. Ensure the availability of these resources for customers and if there is a problem you can set up notifications to be integrated with any system such as ServiceNow or Big Panda.

Conclusion

There are many reasons for deploying synthetic testing to Exoprise Public sites. Whether trying to monitor remote access, or needing an external vantage baseline performance comparisons, or ensuring external facing resources are highly available for customers. Exoprise public sites integrated alongside on-premises enable numerous benefits to the entire IT organization.