Portal on a laptop for remote work

[GWaltersOZ]

Hi all,

We have a scenario where we will have remote workers that are offline for weeks at a time however, they need to share content together on a daily basis while out in the field. 

One scenario we are considering is applying Portal with a datastore and Survey123 web on a laptop. The portal would have collaboration set up with our AGOL instance (which is the origin of the data) but the users would sign in against the laptop portal, download their surveys etc. Then when they are in the field they should be able to sync against the local portal and when online send the features to AGOL for prosperity. 

We are wondering if anyone has done this to share content as there is no way currently of doing this between devices, if it is feasible and practical.

[PeterKnoop · Accepted solution]

We have done this regularly for years to support work at remote field sites having no or unreliable Internet access. We have found it highly effective. It is a tremendous help in doing more with your data, while you are still at the field site, so you can discover and address problems or plan new work while you are still there.

Our approach has been to setup a laptop with an ArcGIS Enterprise base deployment, add any extras we need (e.g., Image Server), and setup a local WiFi intranet. Folks operate in offline mode during the day on the tablets and phones, and do all the syncing and sharing back at base camp. That can also operate in online mode at basecamp for real-time collaboration. (Keep in mind that the core of this is a laptop, however, so you if you have a lot of collaborators, then you need to establish workflows or protocols, such that not everyone is hitting the server at once!)

We haven't yet tried Distributed or Partnered Collaborations with it. It seems like there is good potential for using them as a way to transfer data to your main ArcGIS Online organization or another Enterprise instance back in the real-world. So far we have been relying for basic projects on regular exports of file geodatabases, or for more complex projects, added a SQL Server to the mix for enterprise geodatabases and used two-way replication; and, then sending someone with a thumb drive off-site to where there is Internet access.

In addition to ArcGIS Enterprise, one also needs to run a Domain Name Server (DNS) server, so that clients (e.g., web browsers, Pro, Field Maps, Survey123) can successfully resolve and trust the SSL cert used by the server. We install BIND on the same laptop to handle this, however, there are lots of ways to do this, and I suggest using whatever your IT folks are already familiar with for DNS. (And for things to work correctly when you do have the laptop connected to the Internet, remember to turn off the local DNS server!)

-peter

[GWaltersOZ]

Hi Peter, 

Thanks for your response and great to hear that I am not completely crazy. I do wish that there was a simpler idea to solve this but I can also see that we will actually get far more benefits out of potential solution.

One question I still have is do you use Named users against your domain or use built in accounts for this type of scenario?

Thanks again,

Gareth

[PeterKnoop]

@GWaltersOZ we have stuck with built-in or arcgis accounts for the portable Enterprise deployments. It would be a potential security risk and very complicated to support enterprise accounts and single-sign-on in such a  scenario.

We do use enterprise accounts on our regular ArcGIS Online and Enterprise instances, so we try to make sure the account names used on the portable Enterprise deployment are the same. That way, when you transfer data back, things like the usernames in Editor Tracking are correct.

So if you have a user on your ArcGIS Online organization with an idpusername of "jack" , and the short name for your org is "esri", then their enterprise username is "jack_esri". On the portable Enterprise instance, you would create an arcgis account with that full username "jack_esri" for that user to use.

If you end up with arcgis and enterprise usernames that do not match between systems, then it can be helpful to script the mapping of the two to fix your data when you transfer it back. The script would use the mapping between the two usernames to update the Editor Tracking attributes, or any other attribute fields in which you used usernames.