POST
|
Hello Daniel, Can I trouble you for information on what flavor of Linux this is being deployed to? Also, do you know if you are installing with the GUI from the Desktop, or are you ssh'ed in with X11 forwarding? Thanks! And look forward to hearing back! Kenny
... View more
12-02-2019
01:03 PM
|
0
|
0
|
732
|
IDEA
|
I can appreciate the idea of having /var/log be the location for saved logs. One reason the logs are not saved to /var/log is the Enterprise products do not run under root by design. Since most Linux distro's default only allow root to write to that location, the account running portal wouldn't necessarily have write access to that location. As a result the logs are saved in a subfolder of the install location where it can be assured the the software has the correct permissions. I haven't tried it myself, but maybe a symlink from the portal log location into a /var/log/portal or something similar might do the trick?
... View more
11-21-2017
04:00 PM
|
0
|
1
|
479
|
POST
|
Hi Sanne, Would it be possible to contact Esri Support Services? The reason I ask is because they may be in a position to help you clean up some of the components in your user profile directory that is causing the crash for your user profile. One other thing that while not a solution but may allow you to have a short-term workaround is to create a new local user on your machine, and then run ArcMap as that user.
... View more
05-25-2016
03:38 PM
|
2
|
0
|
1297
|
POST
|
Hello, can I ask if you on the previous installation had any Add-in Extensions for ArcGIS Desktop? A problem there would persist even after an uninstallation/reinstallation of ArcGIS Desktop.
... View more
05-24-2016
10:19 AM
|
0
|
1
|
1297
|
POST
|
Hi Ashley, I apologize for the delay, I just saw your message now! It does look to be in the same vein. Essentially the WinINet errors are errors thrown back up the stack to ArcGIS Server when the server asks the Operating System to make a network connection to something, and the OS says "hey, I tried to connect like you asked, but I couldn't and here is the best explanation I can give to you; do with it what you will" Then ArcGIS Server logs that error in its logs. I see on https://support.microsoft.com/en-us/kb/193625 12029 ERROR_INTERNET_CANNOT_CONNECT The attempt to connect to the server failed. This error is not very specific, but I suspect it is because its not even able to connect to the machine at all, so it can't give you a specific error as a result. Which is somewhat handy, because it implies you don't have a problem with SSL or proxies. The best method to troubleshoot this is going to be to log into the machine as the account that is running the arcgis server. (This is critical because you really need to be able to test under the same conditions as arcgis server is running under, to truely see what is affecting it, and you can't get any closer than being the user that is running ArcGIS Server!) Next you need to start checking why you can't connect. I apologize for some nuts and bolts network troubleshooting stuff, but there is no real way to avoid it. You're going to want to check a few things, I wont go into too many details, but if this stuff is unfamiliar, see if you can point your local friendly IT person to this and see if they can help. - Do a quick sanity check to make sure everything is the way you think it is. I use a combiation of the following two commands on windows. ---- ipconfig /all ---- Just to see what IP addresses you have and who you are using as your DNS server to resolve names to IP addresses. ---- netstat -aon ---- This will list the ports on windows. ---- If you see your Web Server is listening only on port 443, but running fiddler you see requests trying to resolve to 80, that would explain the 12029 error. - Is my ArcGIS Server resolving the DNS name to the correct IP address? ---- nslookup <yourserver.yourdomain.com> ---- This command will let you compare the IP address ArcGIS Server think yourserver.yourdomain.com resolves to against what your actual ip address is from the other commands. If you find it's resolving to the wrong IP address, this is the problem and why it can't connect! - try opening up a combination of the different URLs/ports/IP addresses to see if you can isolate which one isn't working, if you can find out which one isn't working, you can probably assume that is one that AGS is trying to use that causes the error. - http://ags.yourdomain.com:6080/arcgis/rest - https://ags.yourdomain.com:6443/arcgis/rest - http://webadaptor.yourdomain.com:80/arcgis/rest - http://webadaptor.yourdomain.com:443/arcgis/rest - ping <yourserver.yourdomain.com> - ping <both of your IP addresses> ---- This is really just a way to make sure you can reach your server at its name and IP address in general. - What path is my machine using to to reach that IP address ---- tracert <yourserver.yourdomain.com> ---- This shows you the different IP addresses along the way you are going to. I dont find this too useful, but if you find it going places it shouldn't it might give you a hint as to the problem. Hopefully that should help at least start you on your way. Lastly, if you have access to Esri Tech Support, please feel free to call them as they might have some additional insights as well. Thanks and good luck!
... View more
04-13-2016
04:41 PM
|
0
|
0
|
570
|
POST
|
I have found that this is normally as a result of registering the web adaptor with Portal via one URL, and accessing it via another. For example you browse to https://internalmachine.domain.com/portal and register your web adaptor with Portal. Then you try to access the Portal via https://dnsalias.domain.com/portal. As a result the Portal basically says "hey, I was told to the web adaptor was at https://internalmachinename.domain.com/portal, but I see a connection coming from https://dnsalias.domain.com/portal, and I was never told to trust that URL, better be safe than sorry; invalid_uri redirect 400" The easiest way I've found to resolve the issue is to unregister the web adaptor from Portal, and then in your browser with the URL you intend to access portal through like https://dnsalias.domain.com/portal, re-register it with portal. At that point Portal knows to trust the web adaptor from that location. Please note that if you do unregister the Web Adaptor you will not be able to access your Portal via the web adaptor for the duration of it being unregistered. This is a somewhat common issue for Esri Support Services, so if you have access to support, I'm sure they can walk you through the process of sorting this out. If not, here is the documentation on how to unregister a web adaptor. Unregistering ArcGIS Web Adaptor with Portal for ArcGIS—Installation Guides (10.4) | ArcGIS for Server Here is the follow up doc on how to register it again. Configure ArcGIS Web Adaptor—Installation Guides (10.4) | ArcGIS for Server Hope this helps! Ken O.
... View more
04-13-2016
03:58 PM
|
2
|
9
|
3559
|
POST
|
Hi Rebecca, Glad that did the trick! Also, I don't know if you recall as it was a long time ago, but we worked together on a few technical issues at the Esri UC two years ago. Thanks again!
... View more
08-27-2015
10:39 AM
|
0
|
1
|
914
|
POST
|
Hi S R, You are right, these questions are really IT centric. In fact, it might be best to point your IT staff to this post so they can take a look. The following talks about how to check certificates View or manage your certificates Also, with regards to the trust, https://support.microsoft.com/en-us/kb/174360 shows a bit about it as well. Long story short though, if you run your browser as the service account and it cannot connect via HTTPS, I would treat it as any other real user, and contact the IT dept. and let them know that there is an account that should be able to access the URL, but cannot. Then they can take it from there.
... View more
08-10-2015
01:50 PM
|
0
|
2
|
570
|
POST
|
Hi S R, Probably the easiest way to see what is happening is to run a web browser as the service account, and then open up https://server.domain.com:6443/arcgis/manager. This will let you see what the AGS sees when it tries to reach the callback URL. It could be a few different things, but it does sound like the service account is differently configured from the regular users. Below is a list of things I've seen cause the issue, though there are probably many other things that could cause a problem: - Service account does not have proxy configured, but regular account does. (You can check this by running Internet Explorer as the service account, then Checking the Internet options for that Service Account.) - Service account does not have the Domain CA that sighed the server cert in it's trusted CAs. (you can check this in certmgr.msc if it's in Windows.) - The trust settings have an excpetion for http://server.domain.com but not https://server.domain.com Hope this helps! Ken O.
... View more
08-10-2015
12:53 PM
|
1
|
5
|
1106
|
POST
|
Hi S R, Did you try switching the account running the ArcGIS Service to your domain account? If your user account can access the server via 6443, if you run ArcGIS Server under those same credentials it should also be able to reach the callback URL. I'd double check with your IT folks to make sure this is ok to do as a test, but I suspect you'll find it fixes it. (Conversely, if you were to log in as the account running the ArcGIS Server Service, I suspect you will see that if you browse to http://server.domain.com:6080/arcgis/manager that it will not open the page.) Hope this helps, Ken O.
... View more
08-10-2015
12:35 PM
|
0
|
7
|
1106
|
POST
|
Hi esri inc, I've seen this error a few times, and it almost always seems to be something to do with the Application Pool/ .NET framework settings in IIS. I'd try the following two things: In IIS Check your application Pool Settings for the "ArcGISWebAdaptorAppPool" and bring up its advanced properties. Click the Identity field, and change it to use something different than the "ApplicationPoolIdentity." I normally start by changing it to network service, and if that doesn't work, I switch it to Custom account, and provide it with my domain account as a test. (There are security implications for changing this, especially if it's public facing, so I'd probably check with the local IT folks to make sure they're OK with the changes.) The second thing I'd check would be to change your .NET Framework, and if it's set to 4.0 change it to 2.0. Lastly, while not a solution, one way to check to see if it's an IIS settings issue is to download the Windows version of Tomcat, http://tomcat.apache.org/ and install the Java Web Adaptor onto Tomcat. (To do this you'll have to stop IIS for the duration of this test/workaround. Hope this helps!
... View more
05-06-2015
04:12 PM
|
3
|
3
|
914
|
POST
|
I did want to mention that one way I've found to work around these kinds of problems is to browse to the Manager page >Site > Machines, and remove the problematic machine from the site. Then add it back in. If something has gone haywire, this normally helps smooth it out. Though as a warning, if things are not working correctly to begin with, you may find yourself with the machine removed and difficulties adding it back in. As a result, I normally recommend to anyone with a 10.2 or newer server to take advantage of the backup functionality before making any changes to the server. Here are the docs for this as well. http://resources.arcgis.com/en/help/main/10.2/index.html#//015500000666000000 - Linux instructions http://resources.arcgis.com/en/help/main/10.2/0154/01540000065s000000.htm - Windows Instructions
... View more
05-06-2015
03:57 PM
|
2
|
0
|
2169
|
POST
|
Hi Gary, I'm certainly not an expert with regards to SAP, but I know we have a product Esri Maps for SAP Business Objects Would something like this be what you're looking for? Hope this helps!
... View more
05-06-2015
03:50 PM
|
0
|
1
|
1403
|
POST
|
Hi Jan, You are correct about having to uninstall any 10.2.x Web Adaptors before installing the 10.3 web Adaptor. With that being said, the Web Adaptor itself just leverages the SSL certificate you have on your Web Server. So you can safely uninstall, and reinstall any Web Adaptor, and the SSL certificates for that Web Server stay in place and are never touched by the uninstall/reinstall. I hope this helps!
... View more
05-05-2015
09:07 AM
|
1
|
0
|
344
|
Title | Kudos | Posted |
---|---|---|
1 | 05-05-2015 09:07 AM | |
2 | 05-06-2015 03:57 PM | |
1 | 08-10-2015 12:53 PM | |
5 | 08-29-2014 02:50 PM | |
2 | 04-13-2016 03:58 PM |
Online Status |
Offline
|
Date Last Visited |
2 weeks ago
|