|
POST
|
Matthew, Assuming you are using Server v10.1 or later, the command line column in the Windows Task Manager or Process Explorer are the easiest ways. If you are using an earlier version, you will have to scour the logs and manually match them.
... View more
07-30-2015
10:50 AM
|
0
|
1
|
3267
|
|
POST
|
Sarah, No, there is not a way in Portal to save credentials for a service that is secured with IWA which is why the option to input credentials and save them is not there. When accessing the IWA secured service using a browser inside your domain, the credentials are automatically passed through the browser. When using a mobile device or accessing them outside the domain, you would more than likely be prompted for credentials. If you want to save credentials, you will need to use token-based security. More information on token-based security can be found here.
... View more
05-19-2015
03:27 PM
|
2
|
5
|
2586
|
|
POST
|
Sarah, Are you using Portal 10.3.1? The ability to add enterprise users through the 'Add Members' option did not exist in 10.3. In 10.3.1, when you click on 'Add Members', you should see three options (add built-in users, add SAML users, add enterprise users). The ability to add SAML and enterprise users will be grayed out until Portal is configured to authenticate via SAML or the user identity store is changed to Windows or LDAP in the portaladmin section.
... View more
05-18-2015
10:05 AM
|
0
|
1
|
1031
|
|
POST
|
Rudy, Yes, web apps created by the Portal Web App Builder can be consumed by anonymous users. How easy this is to accomplish depends a lot on your current Portal configuration. Ultimately, when you select to share the web app with 'Everyone', you are allowing users without named accounts in Portal to access the web map (and all of the contents within the map). From your description, it sounds like the problem you are having is allowing external users to view the contents within the web app. This requires that your Server be exposed externally as well. If you are using a reverse proxy to handle your external traffic, I'd recommend reviewing this help doc. Once you have everything exposed externally, you will need to create the web map using the external service urls. Make sure you are accessing Portal through your external url when creating the web map and using the Web App Builder.
... View more
04-28-2015
04:00 PM
|
2
|
1
|
1373
|
|
POST
|
Jostein, Yes, this can be done but requires the use of the 'keytool' command or a 3rd-party utility like 'Keystore Explorer' to access and export both the public and private keys for the SSL certificate. It is not a straight-forward process and you would need to get into the Server framework to find the correct files. I would recommend contacting Esri Technical Support for assistance with this.
... View more
04-14-2015
01:11 PM
|
0
|
0
|
1293
|
|
POST
|
Matt, The log messages with code 9029 just indicate a request has been made to a specific service on ArcGIS Server (map, feature, gp, etc). If the service is secured, it also shows the authenticated user who made the request. I'm not sure why this log code is not included in the help doc.
... View more
04-10-2015
01:20 PM
|
1
|
2
|
2258
|
|
POST
|
When Pro is launched, there are several things that occur for it to check out the licenses. When Pro first opens, it communicates with Portal over the web adaptor url. This displays the login page. After you sign on, Portal validates that the user has licenses and sends back to Pro the hostname and port number for it to use to communicate directly with the License Manager. I suspect this is where the failure is occurring for you. To see what hostname is being returned, you can login to your Portal Admin directory and access https://portal.domain.com:7443/arcgis/portaladmin/system/licenses. License Manager info will show both the hostname and port. By default this is just a hostname. This can be changed to a fqdn if needed. You mentioned that your Portal server does not have a public DNS entry. If that is the case, Pro will need to be behind your firewall when it is initially opened. Pro needs to communicate directly with the server where the License Manager is installed to check out the licenses. Once they are checked out, you have the option to borrow them (or work offline) for a period of time without needing to communicate with the License Manager. More information on that can be found here: Review ArcGIS Pro licensing information—ArcGIS Pro | ArcGIS for Professionals Sorry for the long reply. Hope that helps.
... View more
03-25-2015
02:05 PM
|
1
|
0
|
1621
|
|
POST
|
Hi Mody, Yes, accessing the license manager is unique to portal. AGOL does not use the same license manager.
... View more
03-25-2015
08:24 AM
|
0
|
0
|
1621
|
|
POST
|
Jay, Yes, when Pro opens, it first communicates with Portal to retrieve licensing information. This is done over the web adaptor url. It then needs to communicate directly with the License Manager to check-out the licenses. This is done by default over port 27000. In your case, since your License Manager is installed on your portal machine, you should just need to open port 27000 in your firewall to allow Pro to open and run successfully.
... View more
03-24-2015
01:39 PM
|
0
|
4
|
1621
|
|
POST
|
No, in 10.3 it will be the same as how you are seeing it in 10.2.2. The protocol defined in the WebContextUrl is not used. In other words, if your F5 load balancer is doing SSL offloading, the Login url you see on the Rest page will be HTTP, not HTTPS. If you configure the F5 load balancer to redirect to the web adaptor over HTTPS, the Login url on the Rest page will be HTTPS. I want to make a correction from my last post. The 'X-Forwarded-Host' header used from your F5 load balancer just needs to be the fqdn, not fqdn/webadaptor.
... View more
03-03-2015
02:23 PM
|
1
|
0
|
2474
|
|
POST
|
Jason, the information you have heard from Support is accurate: the SSL offloading is not supported. Regarding the WebContextUrl, I'm not sure what version of ArcGIS Server and Web Adaptor you are using but in version 10.3, you shouldn't need it. If the X-Forwarded-Host header is included from the F5 load balancer to the web adaptor, the fqdn for the Login url should match that header. The format of the header should be fqdn/webadaptor (ex server.esri.com/arcgis). The WebContextUrl is only necessary if you remove the web adaptor and redirect directly to the Server from the F5 load balancer.
... View more
03-03-2015
12:37 PM
|
0
|
2
|
2474
|
|
POST
|
The ability to integrate Portal for ArcGIS with enterprise groups (Active Directory or LDAP) is a new feature that is being introduced in 10.3. This will allow you to link your Portal groups to Active Directory groups and maintain the group membership through Active Directory alone. In 10.2, 10.2.1, and 10.2.2, you can add users from Active Directory but there is not a way to link to the groups.
... View more
11-05-2014
04:58 PM
|
1
|
1
|
1466
|
|
POST
|
Masaaki, yes, an enhancement request has been logged to address this but I'm not sure of the time frame for when it might be implemented.
... View more
02-04-2014
06:22 AM
|
0
|
0
|
2417
|
|
POST
|
The issue you are seeing when linking a reverse proxy to a web adaptor to ArcGIS Server is a known limitation when the context name is different between the reverse proxy and the web adaptor. As you have already mentioned, the webContextUrl parameter for ArcGIS Server is only applied when there is no web adaptor in the configuration. The two solutions I can think of are ones you have already described. 1. Remove the web adaptor from the configuration and specify the external url in the webContextUrl parameters in the ArcGIS Server Admin API. This matches this configuration: Clients - Reverse Proxy 1 - Reverse Proxy 2 - ArcGIS Server. 2. Install a second web adaptor called 'accesspoint' and configure your reverse proxy to redirect to the 'accesspoint' web adaptor url to access ArcGIS Server. You can leave the 'arcgis' web adaptor in place if you'd like or uninstall it. It won't impact ArcGIS Server having multiple web adaptors. Hopefully one of those will work for you.
... View more
01-31-2014
11:19 AM
|
0
|
0
|
2417
|
|
POST
|
Rick, Since you are defining the TNS_ADMIN variable to refer to the folder where you tnsnames.ora file resides, I assume you are using the full Oracle clients. I would double-check to make sure the 'arcgis' user account has access to that file. This may be difficult or impossible if the tnsnames.ora file is in a folder accessed via a UNC path and the 'arcgis' user is a local account. If this is the case, you might have to store a copy of the tnsnames file locally or change the 'arcgis' user to be a domain account. A good way to test this is to open the command prompt as the 'arcgis' user and try to use sqlplus to connect to your Oracle database. This should confirm if the arcgis user has access to the tnsnames.ora file.
... View more
11-04-2013
07:42 AM
|
0
|
0
|
550
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 10-31-2025 04:09 PM | |
| 2 | 06-27-2025 11:47 AM | |
| 1 | 06-27-2025 10:37 AM | |
| 1 | 09-09-2020 08:47 AM | |
| 1 | 10-04-2023 08:40 AM |
| Online Status |
Offline
|
| Date Last Visited |
yesterday
|