Cannot add items from ArcGIS Enterprise (Portal) to ArcGIS Online unless connected to VPN.

Question

I've been dealing with this issue for well over a year now. It all started when I did an ArcGIS Enterprise migration from on-premise to Azure. During the installation and migration I was connected to my agency's VPN. Ever since then, If I copy the URL of a service in ArcGIS Enterprise and try to add it as an item in AGOL, it fails unless I'm connected to VPN first. Once the service is added, it works fine even off VPN. However this process has become annoying. My IT Department has determined that there is nothing in our firewall or in Azure blocking Enterprise and AGOL from talking . At this point we feel that while on VPN during the migration, the VPN's IP Address has somehow embedded itself into ArcGIS Enterprise.

The only fix I know to try is doing a complete uninstall and reinstall of ArcGIS Enterprise off of VPN.

Has anyone else ever had this issue?

Thanks, 
Michael

VenkataKondepati · Answer

Hi @MichaelTorbett, I don't have access to the environment but please try following the steps. Check Federation & Portal Items for IP Binding Even though your URLs look correct, sometimes during a VPN-based install, internal FQDNs or IPs get saved deeper in config metadata. In Portal Admin Directory: Go to https://:7443/arcgis/portaladmin → Federation → Servers Confirm the adminUrl and servicesUrl are externally resolvable (i.e., not internal VPN-only hostnames or IPs). In Portal Sharing REST Endpoint: https:///sharing/rest/content/items/?f=json Look at url and data.url fields — they may show embedded VPN-resolved IPs or internal hostnames. 2. ArcGIS Server Admin: Check WebContextURL In your ArcGIS Server Admin Directory: https://:6443/arcgis/admin/system/handlers/rest/servicesdirectory Make sure your WebContextURL is set to a publicly resolvable address — not an internal/VPN-resolved IP or hostname. If it’s wrong, update it here: /arcgis/admin/system/webadaptors//edit 3. Regenerate Service URLs for Hosted Items If these hosted items were published while connected to VPN, their URLs might still point to non-public DNS endpoints. Try: Republish one or two sample services without VPN enabled. Then compare their sharing/rest/content/items URL metadata to older items. 4. Create Public Web Map Without VPN Access Test adding a new map to AGOL without VPN and try pulling in a service by typing the full URL — if it errors immediately: Run a browser network trace (F12 → Network tab) to capture what endpoint it's trying to hit. This will show you which domain fails, even if it looks right in the UI. 5. WebGISDR & Log Triage Although you mentioned webgisdr logs are clean — also inspect: ArcGIS Server logs (set to DEBUG level temporarily) Portal logs from the portaladmin/logs endpoint Search for "URL" or "hostname" entries in logs from the migration day Try a Hosts File Override Just for debugging: Force an external machine to resolve the internal FQDN (used during install) to the public IP using the hosts file. If that works, it confirms that the endpoint is hardcoded somewhere, even if you can’t see it easily.

MichaelTorbett · Answer

Thank you for the reply.  I have torn open the hood and looked at server properties and portal sharing urls. I can't find anything that references VPN. All URLs look correct. Also, the Webgisdr logs are not giving any clues either. Do you have any other recommendations?

VenkataKondepati · Answer

Here are a few thoughts based on what’s worked for me:

* Notebook prints don’t show up in the browser console. Unfortunately, print() in your Python script won’t surface in the Chrome console — it’s server-side, and you’d need to explicitly log or return output through the web tool’s response to capture it.

* For actual debugging, I’d suggest:

* Adding structured JSON or string outputs to your notebook and using them in the tool’s UI to validate logic.

* Wrapping logic in try/except blocks and capturing detailed logs using a return string or output parameter.

* Using arcpy.AddMessage() or AddWarning() if you're working within a script tool context — they’re more traceable through the web tool's job history.

* There’s no official Chrome DevTools-style debugging for the back-end Python logic — it runs in a managed environment in ArcGIS Notebook Server (behind AGOL), so your best bet is building diagnostics into the return payload.