Home Networking
Last updated
Last updated
The Home Networking pack measures the employee Digital Experience from home providing insight using both the existing Digital Experience Scores that is part of Nexthink's core technology, through to the actual health and speed of the connection. It is built around Remote Action output as well as core Digital Experience metrics and as such, some configuration is necessary for the pack to function correctly.
With the pack in place, we can measure the health of the local connection of the device, the speed and Round Trip Time (RTT) to external and internal websites, and file shares. Any of the components can be enabled or disabled as desired.
Before implementing the pack it is important to fully understand the remote network connection mechanism for the devices (more details below).
Also, the Digital Experience score library pack should be fully installed in your environment as these values are used in the metrics configuration.
Because the dashboards use the Digital Experience score version 2.x it is required that version 6.27 of Nexthink is installed, the recommended being 6.28 or above.
Affecting all the Remote Actions in this pack is a need for a clear understanding of device configuration. Consider a typical setup that might be found in a customer environment:
This kind of configuration, with different routes possible to different services, must be understood for the Home Networking pack to be effective. Note that it's entirely possible instead to have a simple configuration – if all traffic goes down a VPN, or if all traffic goes out to the open Internet with no other alternative possible, then the configuration of the Remote Actions will become simpler. Commonly, in larger environments, to separate the traffic, some will go directly out to the open internet, some going to SaaS services through an IP Tunnel and some might go down a VPN to the datacenter. When configuring the Remote Actions in the pack, always understand what route will be taken by the traffic going to a particular destination as it affects the results you are getting back:
If you wish to measure the download speed of the pure internet connection, for example, then ensure the file that you place in your cloud service is accessed via the local internet facing interface and not via a VPN interface if one exists – because if it goes down the VPN, you’ll end up with the download speed of the company internet connection as the packet will be going through the VPN, through the company network, and out their internet connection.
The same principle applies for all configurations – for the RTT to websites, if what is wanted is the RTT via the home direct connection to the internet, then make sure that the destinations to those websites are not going down the VPN connection because if they do, then, in fact, you will measure the speed down the VPN, into the corporate network, out the corporate network’s internet connection, to the website and then back again.
There may well be cases, such as the download speed to the UNC location where you do want it to go correctly through the VPN to the company and back. In this case, make sure that the configuration on the device is such that this traffic goes out through the VPN interface.
Also - and separate to the individual Home Networking Pack - if you choose to use the Geolocation RA which can be downloaded from the Nexthink Library, consider this too – the Geolocation RA uses a third-party service, http://ipapi.com for its lookup. In this instance, make sure this domain (fully) is not going down your VPN - otherwise, you will end up with the ISP of your Corporate provider and not the local connection.
The Home Networking Library Pack uses a number of remote actions. This page outlines how to configure these for optimal use. The following RA’s are involved in the solution:
This remote action is compatible with both Windows and macOS devices.
Get Local Speed to Gateway – determines various connection health and speed properties of the local connection into the home router/default gateway. This doesn’t need any additional parameters to be configured as it is a simple test to the local router, however, we recommend leaving the randomized delay in at the start the default of 60 seconds so that not all clients execute this at the same time.
The one input parameter, MaximumDelayInSeconds is the Maximum random delay set to avoid network overload. This defaults at 60 seconds and we recommend leaving at this value as this test is only to the local gateway of the employee, it does not impact the corporate network.
This remote action is compatible with both Windows and macOS devices.
This Remote Action will determine the speed, in terms of the Round Trip Time, to a given URL and report this back. It also gives Boolean outputs for whether this is greater than the threshold that is requested enabling dashboarding of this property.
Two input parameters define whether this is a public URL or a Business URL. In fact, these are interchangeable, they are just functional guidance, i.e. you can leave two external sites, two sites that are internal to your network, it's entirely flexible, they are just two URLs. The Remote action will test the round trip time to these two URLs and report them.
The configuration required is simply to ensure that the URL’s are configured and once again think closely about what is being tested – if the test goes down the VPN to the URL then it's not a test of the internet latency direct from the home network, it’s a test of the latency to that URL which (if this is the intended configuration) may well be a web service in a data center. If it goes to a public URL such as google it is more a test of the response time of their device to the internet. A threshold defines the level at which the RTT is considered too slow and marked as bad for that test run.
When public Round Trip time is higher than the average set in the threshold it is a sign of a bad connection. We recommend executing the Remote Action frequently because connection quality can change during the day. Note that you do not have to give both parameters, you can configure one only if wished.
IMPORTANT: From a dashboarding perspective from this pack, this RA also returns the value “Connection Type” which is used in a lot of the dashboarding, so it is important that this RA is running at least daily to keep the dashboard reflecting the correct data for all RA’s in the pack. Ideally, as this is low bandwidth, it should be run more frequently (hourly). Note that the Connection Type property can be Wired, WiFi, Cellular, or “Unknown”. This last type may be encountered in certain VPN configurations where Nexthink cannot retrieve the VPN configuration with guaranteed certainty, so shows Unknown in this instance as a reflection that we cannot guarantee what we have found.
There are some parameters to note:
MaximumDelayInSeconds: Maximum random delay set to avoid network overload. Provide the number of seconds lower than 600, Nexthink recommends setting this between 60-300 seconds to balance getting prompt results with overloading the environment with multiple devices querying the destination at once.
ExternalURL: The external URL to check the Web RTT against. It’s important to enter the full URL of the website you wish to run your check against, otherwise, the check may fail, i.e. if you wish to test against http://google.com then enter the URL https://www.google.com . Entering just http://www.google.com will cause a failure.
WebRTTThreshold: The time threshold for the external URL Web RTT. Nexthink can recommend a value here, such as 600ms, however, it is going to be very specific to the customer environment. We recommend setting this according to your needs after running it with the default parameter of 600ms and seeing which values are coming back from your devices. Note that there is a dashboard metric, “Home Networking - Internet Connectivity - Devices with high RTT to external URL” which also uses this threshold in its calculation so if the value is changed in the RA, please update the metric accordingly. This also applies to the equivalent metric which covers the Business URL.
BusinessURL: The URL in the corporate environment to be checked the Web RTT against. It’s important to enter the full URL of the website you wish to run your check against, otherwise, the check may fail, i.e. if you wish to test against http://google.com then enter the URL https://www.google.com . Entering just http://www.google.com will cause a failure.
BusinessWebRTTThreshold: The time threshold for the business URL Web RTT, please see above for “WebRTTThreshold” for guidance on this parameter.
Please note that this remote action is compatible with Windows only
The Get Download Speed Remote Action downloads a file placed on a cloud service or a file share and will then calculate the speed of the connection based on the time taken to download this file. Please note the file is not fully downloaded to disk, it is simply streamed to the local device and the calculation made.
It will use whichever interface is configured for this destination. Note that with the possibility of UNC and URL-based locations that can be specified, ensure that you understand the configuration needed on the client to make sure you go in the right direction for each download.
VERY IMPORTANT:: This Remote Action downloads a file. There is a randomized delay as per normal that can be set up to 600 seconds however if run across a wide range of devices be absolutely sure that you understand what is happening. It is the intended behavior but particularly for files placed on UNC locations considering that many machines may download this at the same time. It is why we recommend a 50-100mb file as the optimal size if network capacity allows it.
There are three parameters to understand:
MaximumDelayInSeconds: Maximum random delay set to avoid network overload. Provide the number of seconds lower than 600. This parameter should be left high because this Remote Action can absorb significant network traffic, so having all devices execute at the same time is not desirable. We recommend leaving this at the maximum, 600, which will mean it may be up to 10 minutes before the Remote Action completes.
BusinessServiceUNC: Path to a file located in a corporate network's shared location. Eg. \\server\\SharedFolder\\file.txt. IMPORTANT - Do not use a large file or this could flood your network. Provide an empty value to skip this test. Nexthink recommends a value of between 50-100mb for optimal results of this Remote Action if your corporate network will allow it.
BusinessServiceURL: URL to a file located on a cloud location which will then be downloaded to perform the speed test. IMPORTANT - Do not use a large file or this could flood your network. Provide an empty value to skip this test. Nexthink recommends a value of between 50-100mb for optimal results of this Remote Action if your corporate network will allow it.
The following steps now go into how to configure the files which will be downloaded in more detail. If you are not planning to use this Remote Action these steps can be skipped.
The Get Download speed Remote Action downloads a file placed on a cloud service. It will use whichever interface is configured for this destination. Note that with the possibility of UNC and URL-based locations that can be specified, ensure that you understand the configuration needed on the client to make sure you go in the right direction for each download.
NOTE: This example uses Azure, however, any cloud storage is possible, for example, AWS. Ensure that the client devices can reach the file destinations, both the UNC and HTTPS (if both are configured) otherwise you will get a failure to connect the message. The Get Download Speed Remote Action has both HTTPS and UNC parameters for both files on the cloud and files on a file share.
To configure this component a file must be placed on a cloud service that can then be downloaded. It should not be too big (we recommend about 50mb) and it is mandatory that it has open access because the mechanism to download the file needs to be unauthenticated. The following steps outline how to achieve this using Azure, though any cloud provider can be used.
log in to the Azure Portal (this example uses Azure but any cloud provider can be used).
In Any Resource group you wish, create (by clicking on the “+” sign) a new object of type “Storage Account”:
note the importance of the location field for where it will be based and how it will be accessed (https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy ).
Set the properties of the storage:
Continue the wizard to describe the properties of the storage account in terms of networking, data protection, advanced settings, and tags. This is entirely dependent on your choice as an organization, please consult your Azure, AWS, or other cloud service team if in doubt.
Finally, click on Create in the Review and Create to create the storage.
Go to the storage and go to Storage Explorer (Preview) and select Create File Share. Note that you can also create a Blob Storage to do this also (in this case make sure you enable anonymous access in the wizard).
Create a file share with a suitable name for your Remote Action test.
Refresh the page and now you are able to upload a file into the share:
Upload the file you wish to test from bearing in mind that too small may give inaccurate results, too large will potentially congest your network. This can be as you wish, here at Nexthink we recommend a 50-100MB for the most optimal results. Due to the way the file is streamed to the client (though not actually downloaded) it must be a .bin extension. This does not have to be a real binary file, it can be something harmless like a text file renamed. If you use other file types you may receive an error in terms of MIME type when the remote action executes.
Once uploaded refresh the page, the file is now there in the file share. Now right-click on it and choose Get Shared Access Signature and set the length of access to where you desire:
Once created now copy this URI
Now paste this into the parameter field in the Remote Action for the BusinessServiceURL:
A UNC parameter can be specified for the DownloadSpeedUNC. In this instance, the configuration is much simpler but again care must be taken. Firstly, if you configure this property make sure that the device can get to the UNC location, if not, the RA will fail. Once you are sure of this, the UNC parameter, in the simple form of \\server\share\filename is specified. The Remote Action runs in the context of the current user, so they must have access to the share. With this configured, the RA will execute successfully. Note that for this Remote Action, the Maximum Delay in Seconds should be 600 so that there is a randomized start to the activity so as not to flood the network.
This remote action is compatible with both Windows and macOS devices.
NOTE: For macOS, this is only available from v6.30 and onwards as it uses output fields only available from that version.
This will check the signal strength of the WiFi connection and report it back. It will also work on a threshold (configurable) of AcceptableSignalQuality which indicates the signal strength that must be reached to be considered acceptable as a percentage. If below this signal strength on each execution it is noted by the Remote Action and if the number of times this occurs in 24 hours passes the AlertUserAfterBadSignals value then there is a campaign attached to this that informs the user of how to get a better WiFi signal. This campaign is very basic, and the idea is it can be evolved as wished. If your customer wishes to use it, it is a good idea to upgrade it to a relevant set of campaign statements for your environment. We recommend running this Remote Action regularly so that the Wifi signal is tested regularly throughout the day, ideally hourly.
A number of parameters are available for this Remote Action:
Connection
CorporateNetworks: Comma-separated list of SSIDs which are defined as corporate. It can be empty
AcceptableSignalQuality: Minimum signal quality percentage to consider the current wireless network as good (0 to 100), Nexthink recommends a value above 80 here.
AlertUserAfterBadSignals: Number of times (1 to 200) the signal has to be under the acceptable threshold during the current day to notify the user via a campaign. This will depend on how many times you wish to run the Remote action. Nexthink recommends running this hourly, so on a given day there will be 8 samples taken, so if this value is set to 4, then 50% of signals over the course of a day would have to be poor and it would trigger the campaign.
CampaignId: Campaign to show with recommendations such as getting closer to the router. Use an empty GUID (00000000-0000-0000-0000-000000000000) to avoid the campaign.
If a remote worker is in an environment in which there are multiple networks operating on the same channel, congestion occurs in that channel. This congestion results in slow network speeds and reduced productivity. Below is a diagram of a home networking setup that can cause Co-channel interference:
In the context of home networking, if a remote worker has multiple networks sharing the same channel, this decreases the network throughput and reduces the overall quality of their home networking experience. The following measures can be taken to avoid Co-channel interference:
To fix the issue the competing access points should be moved to a new channel so they don't interfere. There is a Campaign within the pack that can be sent to the employee advising them how to improve their wifi signal strength, which by default advises them to move closer to the access point. This can be enhanced if there is co-channel interference with some advice to reconfigure one of their access points to point to a new channel. NOTE: The steps to do this will depend on the access point type which may vary per employee."
If the employee is running a 2.4ghz WiFi network, the campaign can be modified to advise them to move to 5ghz (if range allows it, as 5Ghz has less range). Likewise, it can be a good idea to modify the strength of the signal if one of them is weak. Note: If the employee's WiFi routers support mesh networking, this should automatically reconfigure the WiFi networks so this issue should not occur. This would be the best solution but may come at a cost for the employee. Additional solutions can be to move the access points further away from each other and to keep a 20 dB received signal strength indication (RSSI) or more between networks on the same channel.
Adjacent-Channel interference
If a remote worker is in an environment in which there are multiple access points broadcasting on overlapping channels, data corruption, and transmission issues occur. This will result in poor signal quality and subsequently a lower home networking experience. The following measures can be taken to avoid adjacent-channel interference:
Move access points further away from each other.
Use the 5GHz band to increase the amount of non-overlapping channels to 24. If only the 2.4 GHz band is available, use the non-overlapping 1, 6, and 11 channels.
The parameters that are relevant to cochannel interference are:
NearbyNetworksAcceptableSignalQuality is the minimum signal strength, as a percentage, that a competing network must be to see whether it has an overlapping channel with your current Wifi network. So for example, if you have a Wifi network that has the same channel number as your current one (i.e. will interfere) but you have an acceptable signal quality value of 20% and the competing network is only at 20% then it will not be counted. This is because often in cities there are many low-strength networks present.
NearbyNetworksMaximumSignalDifference is the difference in signal strength that must exist for the analysis to complete. For example, if the signal strength of your network is 80% and a competing network is at 20%, but the maximum signal difference is 50% then this will not count because 80-50>20. If the competing network were at 40%, then it would (80-50<40). This factor is used because there must be a significant strength for wireless networks to actually interfere with your signal.
It is recommended that this RA is run regularly, ideally hourly, so that single bad signals do not interfere with the results, i.e. the values are sampled regularly during the day.
This RA is not part of the Home Networking pack but may be used if wished. The purpose is to give more information about where the local connection is originating from. The Geolocation RA has been updated so that it can return more than just the location, it can now return the ISP name which is useful for customers who want to know which ISP’s are in use.
The RA uses a service from a third party, http://ipapi.com , who has services ranging from free to paid subscriptions, paid monthly. The use of http://ipapi.com has been approved by Nexthink Security and Compliance. The free service allows location lookup and up to 10000 executions per month. This has been around for some time at Nexthink as an RA and is still available to use and the Remote Action will still work.
Should you wish to retrieve a greater range of information there are paid subscriptions that can be used. Note that it is customer-centric – the customer should subscribe themselves to the plan they wish, they will then receive a key that can be used as a parameter in the Remote Action. If a subscription level of “Standard” or above is chosen then the Remote Action will now return the ISP as part of the returned data, which can be useful for customers who want to look at home networking from this particular angle.
IMPORTANT: An absolutely key point here is that the route to *.ipapi.com should go out of the correct interface in a split tunneling configuration. In the event that the customer uses split tunneling, the traffic must go out of the internet-facing interface and not the VPN interface. If it goes out of the latter you will only get the ISP of the Business as it is really going out of the Business’s gateway. This may well require the addition of this URL to the proxy.pac (or whatever autoconfiguration URL is being used) on the devices that are to run this RA.
Get Geolocation – Note: Not part of the core Home Networking pack – is used to give location information on the connection and also optionally ISP details.
APIKey: API key to be used for the external geolocation service
HTTPS enabled. Valid values are true/false
Maximum random delay set to avoid external API overload. Provide the number of seconds lower than 600
The pack comes with the Home Networking score. This is a standard Nexthink Score that is targeted at Physical Desktops and Laptops. The score can (and is recommended) be customized. An outline of the scores composite and leaf scores is shown in the image below, it is taking each Remote Action output and summarizes it up into an overall score describing both the local and network connectivity.
