You'll need to set up a reverse proxy with your web adapter. The proxy should take care of forwarding any specified URLs to the GIS server.
Here's an ESRI article about this:
After installing my web adaptor, iis is configured like this:
The apppool is configured like this:
In my web.config I have the two lines mentioned but I do not receive any error.
I suggest you reinstall the webadaptor.
Okay...so I eventually figured out why it was behaving like that.
Apparently, the URL changes had not been done one the particular instance and it was reading the original copy deployed within the 'js' folder and not the locally deployed one.
When we began the development, we were not using the locally deployed ESR JS API, and later in the development ...
Ok, I found the solution by myself. Basically, my webapp wasn't registered in the applicationhost.config, under the tag. After I put it there, it worked. :D
<site name="sitename" id="2063751141">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="...
The reason for using a proxy, at least as far as I am aware, is to resolve Cross Domain Issues, where you are trying to load from another domain.
If your OpenLayers is hosted on the intranet at
and your kml file sits at
then there is no need for a proxy.
Most likely, there is a problem serving ...
Sorting out the permissions may be a pain, I would try putting the epsg files in a location that you know IIS will read, then reference that location through the map file through a CONFIG statement.
As a get around instead of referencing the epsg look-up file to get the definition of epsg:4326 you can use the definition directly in the map file like:
You need to enable CORS in the servlet engine (Jetty, Tomcat?) that is running GeoServer. You will also need to set the proxy url on the global settings page to reflect the external server address (IIS) otherwise the URLs in the GetCapabilities responses will be wrong.
I host the Java proxy in Apache Tomcat that provides a login page. The ArcGIS proxy runs in the same application context as the login page. This way, my users gain access with credentials stored in a separate, secure database. Tomcat does the usual session management while the slightly modified ArcGIS proxy handles the hidden ArcGIS credentials and tokens. ...
As commented by @bugmenot123, they:
have no idea about Jetty or IIS [but] would probably put a reverse proxy
in front of it, so that eg /geoserver/ gets handled by localhost:8080
internally. That way you would have just one HTTPS server as
"front-end". Quick search suggests that you can configure IIS as
Ah ha! In the end the solution was quite simple. And I think will work?! Here it is:!
1) Disable port 6080 by default outside the intranet. Easy to do in my organization!
2) Create URL Re-write URL in IIS: With a 'wildcard' rule of *services/CULAND and Url Redirect to: http://myarcgisserver:6080/arcgis/rest/services/CULAND (I am making it 'temporary' for ...
we finally fixed the issue. turns out there was an explicit rule in our firewall that allows any connection to our arcgis server through 6080 port that seems to be overriding the IIS restrictions. Once we modified the rule to only allow the local ip to access the server, the access from different ip's are not working anymore. Thanks for your advice Sunil. ...
Ok, problem solved. Like I said early, the problem was in the resolutions, or better, in the zoom. If you use a max resolution or an array of resolutions(along with restricted extent), OpenLayers will ask to the server for the first set of tiles, which is not what I wanted.
To fix the problem, you must tell the server that you want to start from the set of ...
If you do not have to support very old browsers, the easiest way to achieve this is to make the servlet container that your GeoServer runs in (e.g. Tomcat) send CORS headers. A good web site that explains how to set these for all different kinds of servers is http://enable-cors.org.
You may not want to allow cross-domain requests from all hosts, so you ...