Hi All, We currently support several customers who use MSP for device staging over WLAN, but after that their devices only communicate back to MSP via their WWAN radios. Many of these customers utilise applications that initiate a GPRS data connection for a specific task and close the connection once that task has completed. The major issue we have in this scenario is that the MSP Agent requires an active data connection before communication with MSP, and this data connection isn't always active. Is there any way to get the MSP Agent to initiate the data connection, rather than relying on the connection existing before it performs any action. Regards Gazza
MSP3.3 Agent Check-In and WWAN only devices// Expert user has replied. |
3 Replies
Hi Allan, Thanks for the response, it answers all my questions. I'll give the whole issue some more thought and decide whether to proceed with the GRIP process. Gazza
Hello Gazza, Have had the similar issue, in the end, we set the data connection to be always on via a .reg file, something like this, [HKEY_LOCAL_MACHINE\Comm\ConnMgr\Providers\{7C4B7A38-5FF7-4bc1-80F6-5DA7870BB1AA}\Connections\My Connection] "AlwaysOn"=dword:00000001
No, MSP will not initiate a WWAN data connection, it will only use one if it exists. So, it will "piggy back" on a WWAN data connection that is established by another application, but it will NOT establish a WWAN data connection of its own. If the application periodically establishes a WWAN data connection, and the time comes for the MSP Agent to check-in while that WWAN data connection is active, the MSP Agent will share that WWAN data connection, You can increase the chance that the MSP Agent will do so by setting the check-in interval to 1 minute. This will cause a small increase in processing since the MSP Agent will run every minute. But if there is no WWAN data connection at the time the MSP Agent checks-in, the check-in will have minimal impact. Note that if the application disconnects the WWAN data connection while the MSP Agent is using it, it could cause a Job that was in progress to fail. To help alleviate this, you could set the Pause/Resume flag on the Policy or Action so the Job will not fail due to a communications error but will instead be "paused" and can "resume" (pick up where it left off) on the next check-in where a WWAN data connection is present. That would allow a Job to make some progress each time until it can finally complete. Another approach would be to use the GPRS Setttings Object to set the Always Connected flag to true. This will cause the WWAN data connection to be automatically established by the Windows Connection Manager each time the power to the WWAN radio is turned on. The end result is that the WWAN data connection will be active most of the time, although data traffic will only occur when an application is actually using it. In such a case, the application would not need to connect and disconnect the WWAN data connection, it would just use it when it wants to. And in such a case, you would want to consider the best value to use for the MSP Agent check-in interval since each time the MSP Agent checks-in in will connect to the Relay Server, thus causing data traffic. If neither of those solutions works for you, the only other thing you could do would be to write an application of your own that controls the WWAN data connection. Such an application could ensure that the WWAN data connection is connected every so often, and kept connected for some minimum period of time, even if the application was not using it. If you syncrhonized that with time chosen for the MSP Agent check-in interval, you should be able to get good results. We have been discussing for some time a Net Manager Control Module that would do a number of things, including turning radios on and off, connecting and disconnecting data connections, and controlling routing when multiple adapters are active at the same time. Such a Control Module would need to be highly configurable, so you could define preferred times, routes, etc. The complexity comes from the fact that it is unlikely that any two situations would require the identical rules for when to do what. We don't have enough information to build the right solution yet, so it remains in the investigation phase. If you want to participate in the discussion, you are welcome to provide your feedback and requirements. The best way to do that would be through this forum and/or via the GRIP process, if it directly represents customer requirements. Allan