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

[MichaelTorbett]

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]

That's a tricky one—sounds like the VPN context during the initial setup might’ve influenced how ArcGIS Enterprise resolved or registered hostnames internally. I've seen similar behavior where the federation or service URLs were captured with VPN-bound FQDNs or IPs during install/config, especially affecting service registration from AGOL.

Before going for a full reinstall, you might want to check:

• server.properties and Portal sharing URLs to ensure there are no VPN-resolved hostnames/IPs.

• webgisdr restore logs or federation JSON to see if the internal URL mappings reference the VPN context.

• Test by manually registering a service in AGOL using the public DNS/FQDN instead of internal path.

A reinstall off-VPN could help, but if the config entries are the issue, a targeted cleanup might save time.

– Venkat

[MichaelTorbett]

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]

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://<portal-url>: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://<portal-url>/sharing/rest/content/items/<item-id>?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://<server>: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/<webadaptor>/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.

[VenkataKondepati]

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.