Issue Accepting Invite for a Distributed Collaboration

Question

I'm trying to link my org AGOL site to our on prem Portal site via the Distributed Collaboration model.  I've set up everything in AGOL such that I get the invite file at the end of the process.  I then attempt to open that invite within my on prem Portal site and I get the following error:  "The chosen invitation file was intended for another recipient. Please choose an invitation for your organization." I can't figure out what is wrong.  I've checked the guest and host URL in the invite file and they both seem correct.  If I paste the guest URL that is in the invite file into my browser address bar, our Portal site comes up as expected.  The URL is in the form https://mysite.mydomian.org/arcgisportal   where "arcgisportal" is my configured web adapter for our Portal site.  What am I doing wrong with this?

Royce_Simpson · Answer

Hi Jon.  No datastore in the mix.  The goal is to use our Oracle/SDE gdb for the DC if possible.

If I open the portal site and go to settings/Servers and then click "validate server sites", the response back is "a green exclamation triangle" with "systems operational, some issues".  When I hover over that message, it says that all is good except I don't have a data store registered.

On your "you may have missed a step" part, I'm not sure how else to get an internal Server site out to the world without doing the web adapter piece... is that a "domain change"?  I guess, but doesn't every Server Site that uses a web adapter do this?  What would be the point of the web adapter if I wasn't trying to get my internal Server Site exposed externally?  So... my internal ArcGIS Server is "https://xyz.yyy.org:6443/arcgis2" and externally through the web adapter it's "https://agomaps.larimer.org/arcgis2".  Same with the Portal site as well.  Internally that server is "https://abc.yyy.org:7443/arcgisporta" but externally via the web adapter it's "https://agomaps.larimer.org/arcgisportal".  What specific "domain change" workflow do I need to investigate?

I did actually log a case when I was at the "this invite is for another org" piece of the puzzle but then when I tried it again using that internal name for or Portal site "https://internalname.org/arcgisportal" while in the zoom tech session, and that worked, he was like, "huh, weird, ok good to go"... so here we are.  I guess I need to open a new ticket for this particular issue?

JEmch · Answer

Usually having a bunch of WA;s on a single web server is fine, however as a quick confirmation did you install and configure the DataStore? Also does the federation of Server2 validate at Portal  Organization? Additionally, there you may have missed a step when setting the web context URL which usually coms into play when there is a domain change in the mix (https://enterprise.arcgis.com/en/portal/latest/administer/windows/components-of-arcgis-urls.htm).

Are you able to log a support case? I would suggest having our tech support staff take a look at this deployment.

Royce_Simpson · Answer

Hi Jon,

I have one server with Server (10.9.1).  One server with Portal (10.9.1).  One web adapter server (10.9.1).

I created a new Server site... basic setup, local directories.

I installed Portal on the second server.

I then got onto the web server (third server in the setup), which already has our production "arcgis" web adapter installed and running on it, and I installed an "arcgis2" web adapter for Server and then did another install for Portal and called it "arcgisportal".  So, that web server exposed to the world has three web adapters (10.9.1) on it.  One for our standard, production ArcGIS Server site (ArcGIS), one for this test Server, Dist. Collab. site (arcgis2), and one for Portal (arcgisportal).

That web server setup maybe my first point of issue... not sure about installing multiple web adapters on the same web server... seems like it should be ok but maybe not.

More specifics on the two "test" Server and Portal web adapter configs...

I logged into the webserver, which we'll call "abc.internal.org", fired up the web adapter install, and ran through the dialogue wizard to configure the Server web adapter... I entered "ArcGIS server" in the first set of options, then entered the server name that has Server installed... entered the admin info, and was good to go.  Tested externally (xyc.larimer.org/arcgis2/rest/service"  and was able to see the "sample cities" service.  Then logged into .../arcgis2/manager with no issues.

Onto Portal web adapter.  The same basic process as Server above except for choosing the initial option of "Portal" and then putting in the internal portal server name and admin/password info.

That all worked fine.  Was then able to log in to Portal using the initial admin creds.

I then went to the Portal settings page, down to "Servers"... and walked through the federating servers process.  I entered the external name of the above Server site (arcgis2) for the service URL and the same for the Admin URL... that was completed successfully.

Once that was done I was no longer able to directly log into Server Manager.  I guess that's normal when you federate?

However, I did fire up Pro and I "shared" a web layer to the new Portal and that went through without any issues.  I set it to publicly share and all looks good.

Ok, onto the distributed collab. (DC) stuff.

I then went into our org AGOL site, went to the collaborations area, and walked through the collab process.  I put in the external URL for Portal, chose the "send content" option, set up the workspace and group, and saved the .invite file.  I then went over to our Portal site, collaborations, and "accept invite", grabbed the .invite file, and got the "this invite is for another org" message.

I then went back into our AGOL site, deleted the collab, and walked through the process again, but this time I entered the internal name for our Portal site... the internal server name, not the external web adapter name, saved the invite, accepted the invite on our Portal site, and that worked.

Of all that stuff, the only thing that sticks out as being a "no-no" is the multiple web adapters on a single server part.

Thanks for having a look Jon.

-r

x (x)