We have a server site with web adaptor installed on machine A and there is another machine B with server installed and joined to machine A.
We are observing that after federating machine A with portal (on machine C), machine B just goes into please wait mode. If we un-federate machine A this issue does not happen and machine B works fine. What is triggering this? We tried reinstalling, issue persist.
Thank you!!
Can machine c (portal) communicate with both arcgis server (a and b) machines on port 6443?
Hello @tigerwoulds,
Thank you for responding. Below communication is successful when checked through Machine C.
telnet <ArcGIS Server Machine A IP> 6443
telnet <ArcGIS Server Machine B IP> 6443
and
ping <ArcGIS Server Machine A IP>
ping <ArcGIS Server Machine B IP>
Note: Issue only triggers post federating on Joined Site.
Server A - ArcGIS Server with Web Adaptor.
Server B - ArcGIS Server
Server C - Portal for ArcGIS
Some clarification questions:
1. When you're joining Server B to Server A (prior to federating) - is the config-store for Server A in a shared location, accessible to both Server A and B?
2. Is there a Web Adaptor on Server B?
3. When federating with Portal, what are you using as the URLs for both the ArcGIS Server and the ArcGIS Administration URL?
4. Can Server B resolve and 'see' Server C (via hostname or FQDN)?
Thank you @MingLee for pitching in.
Kindly find the details below:
1. When you're joining Server B to Server A (prior to federating) - is the config-store for Server A in a shared location, accessible to both Server A and B?
Yes, config-store is on a network share and is accessible without any issues.
2. Is there a Web Adaptor on Server B?
No, web adaptor is only on Server A.
3. When federating with Portal, what are you using as the URLs for both the ArcGIS Server and the ArcGIS Administration URL?
When federating Server A with Portal, we are using Web Adaptor URL(https://germany.try.net/arcgis) and Admin URL(https://germany.try.net:6443/arcgis)
4. Can Server B resolve and 'see' Server C (via hostname or FQDN)?
You mean can server B and portal communicate? Yes, both communicate without any issues.
Are these servers in the same subnet? Ie. all in your internal network or are one or more servers the DMZ. Wondering if there is firewall in place that would be blocking the following communication:
Portal > Server A on 6443
Portal > Server B on 6443
Server A > Portal on 7443
Server B > Portal on 7443
Does dual server work if you omit web adaptors entirely? That may help your narrow down the issue. Otherwise, I would recommend an esri support ticket for this.
Can I suggest the following, let's reverse the server configuration:
1. Unfederate Server A.
2. Install Web Adaptor onto Server B. Call the web context as 'server' instead of the default 'arcgis'.
3. Federate Server B to the Portal. Test and Confirm that all is working as expected.
4. Delete the server site from Server A. Uninstall the Web Adaptor on Server A.
5. Reinstall the Web Adaptor and call it 'server' instead of 'arcgis'.
6. On Server A, 'join server site' to Server B.
7. Federate to Portal using the address of Server B.
Question: have you considered using a load balancer in front of Server A and Server B?
Thank you @MingLee for the suggestion. Surely I can try this.
Just a quick question, in step 4 you have mentioned to delete server site, do you mean completely uninstall Server A, which we can definitely try and if that's the case before step 6 we need to install and setup site on machine A. Is this correct that I have understood?
For your question: have you considered using a load balancer in front of Server A and Server B? The answer is Yes we do have an internal NLB addition planned if everything works out well.
Hello, @Yogesh_Chavan for step 4, delete the ArcGIS Server site on Server A. This is through the ArcGIS Server Administrator Directory where there is an option to 'deleteSite'; this removes the config-store information but doesn't go as far as completely reinstalling the software. All I am suggesting is to switch Server A with B; so that it is B that has Server A join it. We're trying to isolate the cause of the joining site issue.