|
POST
|
I'd imagine the reason why you can sign in with the web adaptor on machine 01 is because it sees portal 01 as down and sends it to portal 02. I think you made a mention to it, but just to be clear, is your portal https only, or can you reach portal through http?
... View more
05-26-2016
05:14 PM
|
0
|
3
|
3819
|
|
POST
|
Hm, which machine is configured to be the primary? The one that is up or the one that is down? Are the logs you provided from the machine that is down? The second portal should be the primary. Do you see 2 javaw.exe processes running and some postrges processes running on the machine that is down? Can you sign in and do all normal stuff on the machine that is up?
... View more
05-26-2016
10:08 AM
|
0
|
5
|
3819
|
|
POST
|
I second Paul's comment. You need something in the DMZ that can be used to reach your internal ArcGIS Server. The tough part about your implementation will be having separate entry points into a federated Server. For example, you federate using https://internal_services.domain.com/internal_wa/ as the services URL and https://server.domain.com:6443/arcgis as the admin URL. The web adaptor "internal_wa" resides on machine internal_services.domain.com within your internal network and the server is installed on server.domain.com. However, you can't reach these services from outside of the organization. You can set up another entry point within the DMZ, (another web adaptor, reverse proxy, whatever it is), so that people outside of the organization have a way to get to the services they're supposed to get to, (for example https://external_services.domain.com/external_wa/services). Then, you can share whichever services should be publicly available with Everyone within Portal, and external users reach the services through the external URL. The tricky part will be if you're intending on having secure services that are available externally. I don't think that will work, since Portal will be federated to Server through the internal services URL, and that's the URL allowed to go through the oauth authentication for Portal.
... View more
05-25-2016
03:44 PM
|
3
|
0
|
2528
|
|
POST
|
Did you follow the troubleshooting steps that were taken in that thread? If you can't reach the portal through the 7443, (ex https://portal.domain.com:7443/arcgis/home/), then you can try to restart the Portal service. When you stop the service, make sure there are no Portal processes running within the Task Manager. Start the Portal service again and see if you can reach the url above. If not, you can try to restart the whole machine, but I doubt that'll do much, and worst case, uninstall and reinstall Portal.
... View more
05-25-2016
03:28 PM
|
0
|
7
|
3819
|
|
POST
|
If you go to ArcGIS Server Manager, then click on the Service Workspaces button next to the Service name and the type of service, (it looks like a geodatabase/database icon), you can see the workspaces the data in the service resides in. You can expand the workspace to see the individual feature classes in the service. These are Rest calls, so take a look at the web traffic when traversing the Service Workspaces windows.
... View more
05-25-2016
03:17 PM
|
4
|
7
|
9815
|
|
POST
|
You can install another web adaptor and leave the authentication at Anonymous and then make sure that "Allow anonymous access to your portal" is enabled. Please note that the recommendation is to disable anonymous access. I apologize for the misleading information, but after a bit more research and discussion, this is NOT possible. In order to register two different web adaptors with Portal, you need to set the Web Context URL: This defines an entry point into the Portal, and in the case of multiple web adaptors, it's meant to be a load balancer that can balance requests to the web adapters. Setting the Web Context URL also disables this error from coming up, so you can actually register multiple different web adaptors to Portal, even if you don't intend on using the web context URL to balance requests to them. This may make it seems like you can have multiple web adaptors with different security settings, but that's not the case. To put this in perspective, let's say you have a Portal you want configured with IWA, and you set the Web Context URL to point to a reverse proxy that then points to a web adaptor that is open, for example https://public_portal.domain.com/open. This allows anonymous access. You have a separate web adaptor configured with IWA that's accessible through your internal network, so domain users can sign in and create content, accessible through https://internal_portal.domain.com/iwa. Since only named users create content, all items are created with the URL set to https://internal_portal.domain.com/iwa. When named users create content, the URL for those items are going to point to https://internal_portal.domain.com/iwa, so when external users reach the portal through https://public_portal.domain.com/open, all items will reference https://internal_portal.domain.com/iwa, and they won't be able to reach the item as they can't be authenticated correctly. We are going to update the documentation to explain this further. I'm also interested in how Adam from that other post configured his Portal.
... View more
05-24-2016
09:50 AM
|
1
|
4
|
6632
|
|
POST
|
Can you provide screenshots of the errors? Are you using secure services? If so, what security type?
... View more
05-23-2016
02:51 PM
|
0
|
1
|
2069
|
|
POST
|
You can point a load balancer or reverse proxy directly to Portal without using the web adaptor. In fact, that's a configuration recommendation if IWA is not being used; there's no need for an additional hop within the traffic. This is a documentation issue that will be corrected. Thanks for bringing it up.
... View more
05-20-2016
02:18 PM
|
0
|
4
|
3085
|
|
POST
|
The first thing you should do is install another web adaptor with a different name, and configure either Portal or Server with it. Using the same web adaptor for both is not supported, see here for more info.
... View more
05-20-2016
01:34 PM
|
0
|
0
|
3389
|
|
POST
|
Are Portal and Server federated? Do they use the same web adaptor, or different ones? Can you check the requests using Fiddler or your browsers developer tools and figure out which specific request receives a response that indicates a sign-in or some type of authentication is required?
... View more
05-20-2016
01:07 PM
|
1
|
2
|
3389
|
|
POST
|
Thanks for the feedback. It's something we'd rather fix than say there's a common issue of upgrading with Chrome so we'll look into this and how it relates to upgrades.
... View more
05-19-2016
02:33 PM
|
0
|
0
|
3633
|
|
POST
|
This is likely an issue with some internal changes made at 6.8 of RHEL that affect ArcGIS Server. My suggestion is to stay at 6.7 until thorough testing as been done at 6.8.
... View more
05-19-2016
01:52 PM
|
0
|
0
|
1948
|
|
POST
|
Are you using built-in security for the routing service? If so, you'll want to follow the instructions here. There's a section on if the service is not from a federated server and requires credentials.
... View more
05-19-2016
11:46 AM
|
0
|
0
|
939
|
|
POST
|
What print service are you using within Portal? The default or one from an ArcGIS Server? If you're using one from an ArcGIS Server, you should check the logs on that Server for any errors that occurred when the map was printed. You can also check the http traffic for more information on the request to print, as well as the response from that request. That should help in troubleshooting.
... View more
05-19-2016
11:38 AM
|
0
|
3
|
2069
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-28-2026 06:05 AM | |
| 1 | 08-26-2016 10:10 AM | |
| 2 | 02-22-2024 07:22 AM | |
| 1 | 06-07-2024 07:11 AM | |
| 4 | 12-12-2024 08:52 AM |
| Online Status |
Offline
|
| Date Last Visited |
06-08-2026
07:43 AM
|