Ability to access InSite Admin console via HTTPS
There should be a way to configureInSite boxes to use HTTPS rather than cleartext HTTP for the admin interface. As it is now, accessing these devices is done in an unsecure method which could be compromised. According to support, the 1.6.3 version of the software that is running on these boxes does not have this ability and although it is thought to be included ina future release, there is no predetermined date for release. This is just one of the features that these InSite boxes fail to provide for customers. As such, I believe that a more robust effort should be made to make the InSite boxes comparative in nature to running scripts through thepay per click methodology.
Important Update for InSite/Private Node Customers: New Firewall Rule Needed - Migrating Endpoint
For InSite/Private Node customers: You will need to update your firewall/proxy rules for InSite and Private Node outbound communication. This action needs to be completed by May 31, 2017. Please add a rule for the new dynamic IP endpoint: https://privateagent.jupiter.alertsite.com TCP Port 443 Outbound to “privateagent.jupiter.alertsite.com” Please update your firewall to use the URL name and not the current IP ofhttps://privateagent.jupiter.alertsite.comas it will change Please keep your existing firewall rule for the current endpoint: https://privateagent.alertsite.com TCP Port 443 Outbound to “privateagent.alertsite.com” (204.2.244.25) The new endpoint is a dynamic IP endpoint. (The current endpoint is a static IP endpoint.)PrivateNode Connectivity Alerting!
We've rolled out integrated connectivity alerting to let you know when a PrivateNode has stopped communicating to the AlertSite platform. These alerts are critical to letting you know when a PrivateNode has been shut down unexpectedly or when it can no longer communicate with the AlertSite platform. These new alerts are configured via the Private Location settings screen in the UXM console and do not require additional components to be added to the actual Private Node (such as the Server Agent module). This first release supports all PrivateNode Server versions, including InSite hardware appliances and all VM versions. Support for PrivateNode EndPoint will be released later this year. Read more here!Reminder to Update PrivateNode/InSite Remote Access Firewall Rules
Important Reminder: On Thursday, we are migrating the connection endpoint for Private Location/InSite Remote Access. Please add the following endpoint to your firewall rules: insiterepair.jupiter.alertsite.com (35.171.105.191) on TCP port 22 The existing endpoint, insiterepair.alertsite.com (209.156.160.90) will be migrated to an upgraded infrastructure at 9pm EDT on the evening of 10/18/18 (1am 10/19/18 UTC). After successful migration we will send out a follow up message informing you that you can remove the existing IP (209.156.160.90) from your firewall rules.PrivateNode Server Updated to Version 2.1.4
Hi, We have released PrivateNode Server 2.1.4, which brings long-awaited Test On Demand functionality to our Private Nodes! 2.1.4 private locations will now appear in the list of available locations for Test On Demand. Additionally, Chrome has been upgraded to version 65 to match our public monitoring nodes. Any InSite/PrivateNode Server running version 2.1.0 can upgrade directly to 2.1.4 via Manage InSite Location > Upgrade Software. To ensure the best experience, pleasebe sure to reboot your server after the update completes. Thanks! Denis
Private locations should be able to round robin
Hi, I submitted "Case #00397845: Private node server round robin" and was given a complex workaround. Private locations should be treated no differently than your public ones. During our POC we were told that monitors that use private locations can round robin the test runs. This is not the case. All PLs run the test at exactly the same time. This creates a load test if a monitor has many PLs and is not desirable. The monitor should run 1 test at a time equally spaced. Many other vendors have this standard feature and Alertsite should too. thanksBackup Private Locations
Specific scenario that I'm curious about. If I have a monitor running on a private location, and that location for some reason goes down so that I'm unable to run any monitors on it. Is it possible to set another private location as a backup so that if the monitor's primary location goes down, the monitor can still run and alert on the backup? I know there is an option to have monitors run on multiple locations either at the same time or through a rotation, however, I would only want the monitor to run on the backup location if the primary location is unavailable.
