Latest Contributions by JonathanQuinn

Do you recall the URL used to access the Web Application Builder to build the app? If you look at the properties for the application, the URLs all point to the invalid url: https://public.co.wasco.or.us/gisportal/sharing/rest/content/items/b561e4d788844cb1a4f7741d71f74761 Are you using a reverse proxy, (public.co.wasco.or.us), and is wc-esri-product-wasco-co.local the web adaptor URL? Easiest thing to do is to update the URL manually within the item information page when you're signed in, but my guess is the application was created/saved when accessing the Portal via wc-esri-product-wasco-co.local and not public.co.wasco.or.us. What I would do is a simple test, reach the Portal via the WA and create a test app. Reach the Portal via the public URL and create another app. Check which works when accessed externally. ... View more

Looks like there are a number of network related problems. First, your machine name isn't resolving even within your internal network. DNS should be associating the IP address, of the Enterprise machine (10.0.0.1, let's say), to the hostname, (enterprise.domain.com, let's say). Outside of the network, your machine needs to be publicly accessible and you need to assign a hostname/domain to the public IP address, that'll give you access to the site from outside of your network. Unfortunately, none of those problems are something Esri Technical Support or our documentation will help with. Those problems should be addressed by your IT staff. The invalid_redirect_uri problem is due to the fact that Portal is configured with a certain set of hostnames that can sign into Portal, for example enterprise.domain.com or *.domain.com. When you reach the Portal home page through those hostnames, there shouldn't be a problem. Portal doesn't know what the IP address is and it doesn't match the hostnames it's configured to allow a sign in from, which is why you receive the invalid_redirect_uri error. I'd sort out the network problem first, and then everything else should fall into place. ... View more

No, it doesn't matter. You can configure a new server for the hosting server or just reuse your existing server as the hosting server. The latter is an easier option for your users/applications as the URL to existing services likely won't change, unless you decide to change the front-end to the Server, (change the machine hosting the web adaptor or reverse proxy, for example). ... View more

There is no out of the box way to migrate from Windows to Linux. If you have the original MXD's or SD files, you can loop through them with Python and the arcpy module to republish them. You can also loop through your arcgisinput folder to find the MXD's to republish. You'll need to republish manually or via scripting. ... View more

It sounds like there'd be less moving parts if you incorporated that existing Server into your Enterprise as either a federated Server or the hosting Server. If there are enough resources on the machine, everything can exist on that one box, otherwise you'll need to look into a distributed environment where Portal and Data Store are on separate machines. To answer your question, no there shouldn't be a problem federating your existing Server with Portal. Take care to understand how security for existing services will be affected, though, This is described in the Federation section: There is a tie-in between federation as defined by the IT industry and as used within ArcGIS Enterprise. The tie-in is that once you federate your ArcGIS Server site to an ArcGIS Enterprise portal, the ArcGIS Enterprise identity based security model will take over, meaning any security you had previously set on your ArcGIS Server site will be bypassed by the identity-based security you set within the portal. Once you have federated an ArcGIS Server site to Portal for ArcGIS, security is handled by the portal; only users who have an identity in your portal will be able to view secured content. Therefore, when you migrate a standalone ArcGIS Server site to ArcGIS Enterprise you will need to recreate your security structure using the ArcGIS Enterprise security model and give everyone who requires access an identity within the portal. ... View more

HA means high availability which requires specific settings and configurations. The privatePortalURL should be https://internalportalname.domain.gov:7443/arcgis, there shouldn't be a reason to update it. Was that what it was set to previously? At a high level, the publishing process goes as follows: 1) The item to publish is uploaded to Portal 2) Server will download the item via a URL constructed from the privatePortalURL, https://internalportalname.domain.gov:7443/arcgis 3) The Server will extract the item, (for example, the shapefile or SD file) and publish it It sounds like it's failing at step 2. Did you do anything to modify the certificate used for 7443, or is this all configured out of the box without any customizations? ... View more

This may only be possible on Linux, and I also don't know if it applies to geoprocessing services: http://enterprise.arcgis.com/en/server/latest/administer/linux/linux-python.htm ... View more

Can you describe what you mean by Server is picking up an invalid certificate? Are you referring to the certificate on 6443? By default, that's the self-signed certificate and it's created based on the machine name of the Server. You can check the Machines API to determine if it's grabbing the correct machine name from the system. If not, it sounds like you have multiple hostnames on the machine and would benefit from setting the hostname.properties file: http://enterprise.arcgis.com/en/server/10.6/administer/windows/advanced-considerations-when-using-domain-accounts.htm#ESRI_SECTION1_B336F257CBAB49DBA594DDADEF7AF386 I'm not sure why the Linux help is greyed out for this topic, (perhaps because it includes information on AD?), but the path is similar, just the Linux version. The 10.7 help will apply to 10.6.x: http://enterprise.arcgis.com/en/server/latest/deploy/linux/multiple-nic-cards-dns-entries.htm If you need to import a new certificate to use, import it via the importExistingServerCertificate API: http://enterprise.arcgis.com/en/server/10.6/administer/linux/configuring-https-using-an-existing-ssl-certificate.htm I see the note in your original post is the same note in the link above, but that workflow should work. ... View more

Can you describe you environment a bit? Are Portal and Server on the same machine, or different machines? Is it HA? If it's not HA and they're on different machines, can you reach https://portal.domain.com:7443/arcgis/sharing/rest on the Server machine? ... View more

If the password to the account used to run the services changes, you'll only run into a problem if the service is stopped and then you attempt to start it. Since the password is invalid, you'll receive an error. As you guessed, you'll need to run the utilities to update the password or use a local account whose password won't change. ... View more

Thanks for bringing this to our attention, we'll get it corrected in the documentation. ... View more

The baseURL variable on line 3 is where you define the host and optionally port and context to the Server you want to connect to. It doesn't matter if you go through 443, 80, 6443 or 6080 as long as you can reach the Admin API via that URL. For example, you could use your web adaptor URL, https://webadaptor.domain.com/server. You need to make sure that the machine you're running the script on has access to the URL you want to use to connect to. To validate certificates, get rid of lines 20 and 27 and update line 22 to be response = urllib2.urlopen(request) and 29 to be: response = urllib2.urlopen(request,encoded_params) You're basically just getting rid of the logic to define the SSL context as "unverified". ... View more

Programmatically interacting with any administrative API is and will continue to be an integral part of the software. HTTPS doesn't necessarily mean they're secured, at least in the same sense that you'd say you need a token to reach them. It simply means that the traffic to reach them is encrypted. In order to reach an HTTPS endpoint via Python, the certificate used for the endpoint needs to be trusted by Python or an untrusted certificate needs to be ignored. This isn't specific to Esri, ArcGIS Server, arcpy, etc. Server, even at 10.7, can be HTTPS and HTTP, but by default on a new site, it is HTTPS. Ideally, the certificate is already trusted by Python, or with a bit of work, you can configure Python to trust your own certificates: https://stackoverflow.com/questions/39356413/how-to-add-a-custom-ca-root-certificate-to-the-ca-store-used-by-pip-in-windows The following script uses urllib and urllib2 instead of the httplib library to make web requests and disables certificate validation: import urllib, urllib2, json,ssl baseURL = 'https://server.domain.com:6443/arcgis' username = 'admin' password = 'admin' whatToDo = "start" def openURL(url,params=None, protocol=None): try: if params: params.update(dict(f="json")) else: params = dict(f="json") if protocol: encoded_params = str.encode(urllib.urlencode(params)) encoded_params = encoded_params.decode("utf-8") url = "{0}?{1}".format(url, encoded_params) request = urllib2.Request(url) #Ignore certificate validation sslContext = ssl._create_unverified_context() request.add_header('referer',baseURL) response = urllib2.urlopen(request, context=sslContext) else: encoded_params = str.encode(urllib.urlencode(params)) request = urllib2.Request(url) #Ignore certificate validation sslContext = ssl._create_unverified_context() request.add_header('referer',baseURL) response = urllib2.urlopen(request,encoded_params,context=sslContext) decodedResponse = response.read().decode('utf-8') jsonResponse = json.loads(decodedResponse) return jsonResponse except urllib2.HTTPError as e: return e except urllib2.URLError as e: return e except Exception as e: print(e) def createToken(baseURL,username,password): tokenURL = "{}/tokens/generateToken".format(baseURL) params = {"username":username, "password":password, "client":'referer', "referer":baseURL} token = openURL(tokenURL,params)['token'] return token '''Function to stop or start services''' def startStopService(serviceURL): serviceName = urllib2.urlparse.urlparse(serviceURL).path.split("/")[-1] resp = openURL("{}/{}".format(serviceURL,whatToDo),params) if "status" in resp and resp['status'] == 'success': print("Successfully {} {}".format(msg,serviceName)) else: print("Unable to {} {}.\n {}".format(whatToDo,serviceName,resp)) token = createToken(baseURL,username,password) params = {"token":token} servicesURL = '{}/admin/services'.format(baseURL) root = openURL(servicesURL,params) if whatToDo == "stop": msg = "stopped" else: msg = "started" for service in root['services']: serviceURL = '{}/{}.{}'.format(servicesURL,service['serviceName'],service['type']) startStopService(serviceURL) for folder in root['folders']: if not folder in ['System','Utilities']: folderURL = "{}/{}".format(servicesURL,folder) folderServices = openURL(folderURL,params) for service in folderServices['services']: serviceURL = '{}/{}/{}.{}'.format(servicesURL,folder,service['serviceName'],service['type']) startStopService(serviceURL)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ https://community.netapp.com/t5/Software-Development-Kit-SDK-and-API-Discussions/Python-How-to-disable-SSL-certificate-verification/td-p/113697 You can do this with the requests module as well: https://stackoverflow.com/questions/15445981/how-do-i-disable-the-security-certificate-check-in-python-requests I'll reiterate that the preferred solution isn't disabling certificate validation, though. ... View more

The Web Adaptor is not required for either Portal nor Server. The only reasons to use the web adaptor are 1) you don't want to manage your own reverse proxy or load balancer in the case of a multi-machine site and 2) you want to use IWA. If you want to use your own reverse proxy or load balancer in front of either Portal or Server, then you can send the traffic directly to 6443 (Server) or 7443 (Portal). ... View more