Latest Contributions by RandallWilliams

A cert created for a web server isn't the same as a code signing certificate. If your organization has an internal CA server, can you can get signed code signing cert from there, otherwise you'd need to get one from a public CA. OR, you can create a self signed code signing certificate for DEV purposes, which I suppose you can use if your portal is internal only. This should help: https://www.sslshopper.com/what-is-code-signing.html http://stackoverflow.com/questions/84847/how-do-i-create-a-self-signed-certificate-for-code-signing-on-windows ... View more

For context, the domain prefix requirement is in place at this point because many users require ArcGIS Server to support multi-forested domains. Without qualifying the account, and without a transitive trust there's no way for the server to know which domain a user belongs with. [#NIM082956 Support ArcGIS Server security with the users and roles in multiple Active Directory trees] ... View more

This can also be addressed by disabling the html representation of the services directory. http://server.arcgis.com/en/server/10.3/administer/linux/disabling-the-services-directory.htm http://server.arcgis.com/en/server/latest/administer/linux/best-practices-for-configuring-a-secure-environment.htm ... View more

Piggybacking on these comments: First, check out this KB. It's helpful when you believe you have the resources to publish more services but are still limited: Unable to publish new or start existing services when a large number of ArcSOC.exe processes are running http://support.esri.com/technical-article/000001218 With regard to FC's comment, the commit charge is a function of both physical memory and virtual memory. I've seen issues where admins hamstring virtual memory in favor of hard disk space, which can limit the amount of physical memory the OS can address. When that happens, the number of SOCs that can be instantiated can be severely limited. ... View more

Agree with Jake. Sounds like your GIS Server has access to the Mosaic and service overviews but not to the source imagery. https://community.esri.com/thread/68795 ... View more

Awesome response, Rebecca. Lloyd and I discussed some of this via PM yesterday. At this point I think he's going to be good to go, but the HTTPS discussion wasn't a topic we broached (yet). ... View more

This is expected behavior because ownership based access control is predicated on the user that's logged into the service, not on the user that's logged into ArcGIS.com. When you store credentials with ArcGIS.com, the credentials used are always the credentials supplied when the service is added - it's how the service is accessed through the sharing proxy. I don't think this would happen with hosted feature services with either ArcGIS.com or Portal for ArcGIS. ... View more

After installing the Web Adaptor, a web based dialog should pop up and direct you to supply the URL to your GIS Server. Assuming the web adaptor is installed on a public facing web server, you shouldn't have to configure IIS unless you're setting up HTTPS or using Integrated Windows Authentication. ... View more

Hi Lloyd, Sorry, I missed the last post. In order for your internal GIS Server to be 'seen' by the outside world, you'd need to make it public. The ArcGIS Server's hostname doesn't need to end in .com, but you'll need to use some kind of NATting or proxy (like the ArcGIS Web Adaptor) to expose your server to the public. In essence, you likely have a public-facing router that has an IP address. Depending on where you host your website, you may have registered your .com domain name with this IP.  If you have your own web server and that web server is accessible to the outside world, then the easiest thing to do will be to install the ArcGIS Web Adaptor on your web server (which is typically located in your 'DMZ', or 'Screened Subnet', which is a spot on your network in between your external facing router and internally facing firewall that is accessible from both internal machines and the outside world), open ports 6080 and 6443 on your firewall, and register the Web Adaptor with your GIS Server. Other options exist, like using a Reverse Proxy. More details here. You COULD just install the GIS Server on the Server in the DMZ, but that's not particularly secure. So to answer your specific question, your internal LAN (domain) does not need to end in .com to be accessible to the web, but your GIS Server DOES need to be exposed in some manner. ... View more

I really like the idea of trying to connect with PGADMINIII. The error message indicates something's up with PG_HBA.conf that's rendered it unusable. If you enable 'show extensions for known file types' in windows explorer, was there a .txt extension slapped on the end of PG_HBA? Personally, I'd replace PG_HBA.conf with a backup and attempt to connect to the database with a local copy of PGADMINIII (or ArcGIS Desktop), since localhost will be allowed by default. ... View more

Sure! Should work if you're only using HTTP. If you're using HTTPS, then you're going to get certificate mismatch errors in your browser because the certificate is issued to a machine name rather than an IP (because IP addresses can change while machine names are generally static). ... View more

Hi Lloyd, Don't fret! I think we can address this. Every machine on a network has a private IP address called a 'loopback address' with the name 'LOCALHOST' that resolves to IP 127.0.0.1. This is why your services are visible on your server - you're telling the browser to look at LOCALHOST for the service resource. Now, because you don't have ArcGIS Server running on every machine on your network, nobody can see your service. Think about it like this: Assume you have a gold bar in your pocket. You send out an email to your office telling them 'you have a gold bar in your pocket'. Everyone gets excited and checks their pockets, but they don't have any gold. Instead, you send out a new email saying 'Lloyd Bronn has a gold bar in his pocket'. Now everyone flocks to you to marvel at your fortune. In this case, we need to do the same thing with how you've referenced your service in ArcGIS.com - we need to tell it to not look at 'LOCALHOST', but instead to your GIS Server name - which I'm betting folks on your network can 'see'. To to this, you can right click on 'My Computer' on the server and go to properties, and get the full computer name. For instance, on my server the full computer name is 'randallsserver.esri.com'. (that's not the real host, I've obfuscated that in the screen cap below). So, instead of adding the service to ArcGIS.com as http://localhost:6080/arcgis/rest/services/myservice/mapserver, you'd add the service as http://yourmachinename.yourdomain.com/arcgis/rest/services/myservice/mapserver. That should fix it. Essentially, instead of telling everyone to look on their own machines for the service, you're now telling them to look at your server for the service. You don't have to have an externally accessible .com domain - mine's not. Hope that helps!! ... View more

I believe that this is an issue with Chrome v 52. I also believe that Chrome has committed to fixing this in the next update. ... View more

To add to Anthony's comment: "My issue is this: I can view the data with attachments on the web app from the web browser on the server. If I view the same page on the web browser on other computers, I can't see the data." My guess is that you're referencing your services using http://localhost/arcgis/rest instead of your server's Fully Qualified Domain name. In any case, the issue is that the other machines on your network can't resolve to the hostname that was used when you added your service as items to 'My Content' on ArcGIS.com. ... View more

Hi Marc, We've done some testing along these lines in house and haven't been able to reproduce this issue. Have you logged a case with Esri Support Services describing your environment? ... View more