Latest Contributions by JoshuaDalton

‎03-12-2024

See it, we will be there once food line moves

‎10-12-2023

Sorry, to be clear, I resolved the issue using the commands I posted. There were some additional objects left behind by the failed first run of the Enable Enterprise Geodatabase tool. I really ran it 3 times to encounter the problem. Try #1: Oracle TEXT package was missing. I installed Oracle Text package by following steps as the oracle OS userid: at shell: sqlplus -nolog in sqlplus: connect / as sysdba in sqlplus: @$ORACLE_HOME/ctx/admin/catctx.sql temp1password SYSAUX TEMP NOLOCK; in sqlplus: alter user ctxsys identified by better2password; in sqlplus: connect CTXSYS/better2password in sqlplus: @$ORACLE_HOME/ctx/admin/defaults/drdefus.sql; Try #2: Failed because one of the CTXSYS packages didn't compile correctly during TEXT install. ORA-06508: PL/SQL: could not find program unit being called: "CTXSYS.DRVDML" Fixed using following: in os shell: sqlplus -nolog in sqlplus: connect / as sysdba in sqlplus: GRANT EXECUTE ON UTL_HTTP TO CTXSYS; in sqlplus: ALTER PACKAGE CTXSYS.DRVDML COMPILE BODY; Try #3 and beyond started failing because the Enable Enterprise Geodatabase left some objects behind after failing on try #2. For me these objects were the LAST_EDIT_ID_GENERATOR sequencer, some ST_GEOMETRY operators, types, and type bodies. I resolved this issue by dropping the objects that still existed for SDE. note TYPE BODYs and OPERATORs must be dropped before dropping the ST_GEOMETRY type itself. So, I ran these commands in SQL using the SDE login: DROP SEQUENCE LAST_EDIT_ID_GENERATOR; DROP OPERATOR ST_DWITHIN; DROP TYPE BODY ST_GEOMETRY; DROP TYPE ST_GEOMETRY; You can get a list of commands to run to drop remnants left by failed runs of the Enable Enterprise Geodatabase tool using this command: select 'DROP '||object_type||' SDE.'||object_name||';' from dba_objects where owner='SDE' and object_type<>'LIBRARY' order by decode(object_type, 'PACKAGE BODY',1, 'PACKAGE',2, 'FUNCTION',3, 'SEQUENCE',4, 'TRIGGER',5, 'VIEW',6, 'LOB',7, 'INDEX',8, 'TABLE',9, 'INDEXTYPE',10, 'OPERATOR',11, 'TYPE BODY',12, 'TYPE',13, 14); For anyone dealing with this issue, it may be simpler to do this than drop the whole SDE user and remake it with needed permissions, quotas, and roles granted, but that would work too. Since this tool enables Geodatabase function on an existing database, which in this case had a ton of data already present in other user schemas, dropping the SID and starting all over would be significant overkill. The above SELECT command gets you a list of all things left behind that are preventing installation that need to be dropped so the tool will run to completion.

‎10-10-2023

I've just encountered the same thing after a failed install for Oracle TEXT, then fixing Oracle TEXT, and getting a CTXSYS error about OIDCINDEXCREATE ,EXT_Error = 29855 ,EXT_ERROR1 = ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine ORA-20000: Oracle Text error: DRG-50857: oracle error in drepopen ORA-04063: package body "CTXSYS.DRVDML" has errors ORA-06508: PL/SQL: could not find program unit being called: "CTXSYS.DRVDML" So then running GRANT EXECUTE ON UTL_HTTP TO CTXSYS; ALTER PACKAGE CTXSYS.DRVDML COMPILE BODY; left me with this error: [01:15:19.841] MULTIBRANCH_TABLES table being created... [01:15:19.946] MULTIBRANCH_TABLES table created... [01:15:19.995] TABLES_LAST_EDIT_TIME table being created... [01:15:20.074] ERROR in creating TABLES_LAST_EDIT_TIME table. Error: -901 [01:15:20.074] DBMS error code: 955 ORA-00955: name is already used by an existing object [01:15:20.074] SDE schema object install not completed. [01:15:20.129] ERROR installing/upgrading ArcSDE, Error = -1 This statement below should resolve the issue. This is probably reportable as a bug in the post-failure cleanup for the Enable Enterprise Geodatabase tool, as the sequence isn't being deleted after a failure. DROP SEQUENCE LAST_EDIT_ID_GENERATOR; Also the following may linger after a failure to create or enable a geodatabase: [01:32:19.068] ERROR setting up st_geometry type. [01:32:19.068] Failed to create the ST_Geometry metadata tables during install. [01:32:19.068] DBMS error code: 955 ORA-00955: name is already used by an existing object Do the following to resolve: DROP SEQUENCE LAST_EDIT_ID_GENERATOR; drop operator st_dwithin; drop type body st_geometry; drop type st_geometry;

‎10-06-2023

Recently I fixed an arcgis server instance that died due to a lack of disk space causing the server.xml refresh done at service startup to write out a 0 length file, and break the site. I thought I'd share my notes on how to fix this so others could benefit. The file <installroot>\arcgis\server\framework\tomcat\conf\server.xml was empty due to a startup refresh of the file failing to write it because of 0 disk space, as indicated by logs in <installroot>\arcgis\server\framework\tomcat\logs\catalina.0.log (empty unless you rename conf\logging.properties.disabled to conf\logging.properties first and then restart your server): SEVERE: Parse fatal error at line [1] column [1] org.xml.sax.SAXParseException; systemId: file:/<installroot>/ArcGIS/Server/framework/runtime/tomcat/conf/server.xml; lineNumber: 1; columnNumber: 1; Premature end of file. This meant the background tomcat server that hosts the arcgis admin, manager, and rest/services pages would not start, as evidenced by repeating entries in the logs in C:\arcgisserver\logs\HOSTNAME.MYDOMAIN.COM\server. <Msg time="2023-10-05T07:19:41,390" type="WARNING" code="7709" source="Server" process="9860" thread="1" methodName="" machine="BROKENHOSTNAME.MYDOMAIN.COM" user="" elapsed="" requestID="">The Web Server was found to be stopped when it should have been started. Restarting it.</Msg> <Msg time="2023-10-05T07:20:41,686" type="WARNING" code="7709" source="Server" process="9860" thread="1" methodName="" machine="BROKENHOSTNAME.MYDOMAIN.COM" user="" elapsed="" requestID="">The Web Server was found to be stopped when it should have been started. Restarting it.</Msg> As additional symptoms, the arcgis\manager and arcgis\admin endpoints were not reachable after service start, ArcSOCs would launch and crash after few minutes, and the tomcat javaw process would start, fail, then start multiple processes with additional catalina logs with the error "Caused by: java.net.BindException: Address already in use: bind" because it was launching multiple instances due to not getting a response from port 6443. Low memory warnings would soon result as it started so many parallel instances of tomcat (<installroot>\arcgis\server\framework/runtime/jre\bin\javaw) Because this server.xml holds the only unencrypted copy of the web SSL certificate store’s password, and other processes use an encrypted key to the same certificate store that is saved in keystorepass.dat, there was no way for me to determine the test server’s old certificate store password, and I could not unencrypt it from keystorepass.dat or make a new encrypted one to replace that keystorepass.dat manually, so I took the following steps to use a working environment’s configuration to repair the broken one: 1: I cleared a bunch of disk space so the issue wouldn't repeat... 2: I imported the BROKENMACHINENAME.MYDOMAIN.COM's certificate to a working arcgis instance using the same alias as indicated by the broken machine’s <installroot>arcgis\server\framework\etc\machine-config.xml 3: I then copied the working machine's <installroot>\arcgis\server\framework\tomcat\conf\server.xml and <installroot>\arcgis\server\framework\etc\certificates\arcgis.keystore + keystorepass.dat to test, and edited the new test copy of server.xml to use broken machine’s certificate alias instead of working machine’s, on the <Connector …> xml tag by changing the keyAlias value from this: <Connector … OTHER SETTINGS … keyAlias="workingHostname2023cert" keystoreFile="<installroot>\ArcGIS\Server\framework\etc\certificates\arcgis.keystore" keystorePass="...” > xml tags. To this: <Connector … OTHER SETTINGS … keyAlias="brokenHostname2023cert" keystoreFile="<installroot>\ArcGIS\Server\framework\etc\certificates\arcgis.keystore" keystorePass="...” > xml tags. These steps should be usable to recover any broken arcgis server in the event it runs out of disk space with similar log entries as evidence of the issue and a 0 length server.xml, as the server.xml is one of the few config files that get overwritten or updated during restarts unless you are actively adjusting the configuration using the admin endpoint. Most other disk usage is for temporary caches, etc. Some of you may not have another ArcGIS server sitting around to use to do this, but probably ESRI could help make a replacement set of the three files for you, given a support ticket. As an additional note, I initially imported the certificate to the working machine with a different alias from what I originally used on the brokenmachine, and thought I could adjust the server.xml keyAlias to use the new alias, so who cares? Wrong. During startup arcgis adjusts the server.xml to use the alias saved in the config-store, so then I got "Caused by: java.io.IOException: jsse.alias_no_key_entry" and saw it had restored the old keyAlias value into my server.xml from the broken machine’s <installroot>arcgis\server\framework\etc\machine-config.xml file. It left other values alone though. So, I had to use keytool -changealias -keystore <installroot>\arcgis\server\framework\etc\certificates\arcgis.keystore -keypass <password from server.xml <Connections ... keystorePass=password> tag value> -alias <wrong_new_alias> -destalias <alias from machine-config.xml> I know a similar answer exists in this thread: Solved: ArcGIS Service started but ArcSOC and javaw proces... - Esri Community, but I thought more details with error text and steps regarding certificate issues may help others. -Josh Dalton

‎09-22-2023

Additional notes for linux installs. 1: stop server, unset http_proxy, https_proxy, and no_proxy environment variables, then restart server. create site. 2: if that doesn't work, look into hostname.properties file as an option if machine has multiple NIC cards.

‎12-09-2020

You are my hero. Thank you. I've been fighting with this for days. As an addendum, the arcgis\portaladmin page will give you Error response of "Unable to import certificate Code: 500" and the Catalina logs under ArcGIS\portal\framework\runtime\tomcat\logs will show following errors: 09-Dec-2020 14:29:07.682 SEVERE [https-jsse-nio-7443-exec-4] com.esri.commons.web.rest.resources.BaseResource.buildErrorResponse Unable to import certificate com.esri.commons.web.rest.HttpException: Unable to import certificate at com.esri.commons.web.rest.resources.BaseResource.buildErrorResponse(BaseResource.java:236) at com.esri.arcgis.portal.admin.rest.security.SSLResource.importExistingServerCert(SSLResource.java:487) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60) at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205) at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75) at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381) at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538) at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:910) at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:858) at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:812) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.esri.commons.web.AppFilter.doFilter(AppFilter.java:274) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.esri.arcgis.portal.admin.rest.filters.AdminFilter.doFilter(AdminFilter.java:87) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:607) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at com.esri.arcgis.portal.util.TomcatValve.invoke(TomcatValve.java:43) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Unknown Source) Caused by: java.lang.Exception: Unable to import certificate at com.esri.arcgis.portal.admin.core.security.SSLManager.importKeyStore(SSLManager.java:277) at com.esri.arcgis.portal.admin.core.security.SSLManager.importExistingServerCertificate(SSLManager.java:258) at com.esri.arcgis.portal.admin.rest.security.SSLResource.importExistingServerCert(SSLResource.java:479) ... 50 more Caused by: java.lang.Exception: Unable to import existing certificate. at com.esri.arcgis.portal.util.KeyTool.importKeyStore(KeyTool.java:633) at com.esri.arcgis.portal.admin.core.security.SSLManager.importKeyStore(SSLManager.java:273) ... 52 more Caused by: java.lang.Exception: No certificates found. at com.esri.arcgis.portal.util.KeyTool.importKeyStore(KeyTool.java:618) ... 53 more

‎11-06-2020

Also check your source data account if connecting to sde, and if oracle and 10.2 crashes, but 10.3+ works, it may be because you never added select_catalog_role to your sde user accounts. Additional tricks: export all layers using a newer version using this python and try dragging them into a new mxd file to see which layer is bad. import arcpy mxd = arcpy.mapping.MapDocument("CURRENT") for lyr in arcpy.mapping.ListLayers(mxd): lyr.saveACopy("layers\"+lyr.name+".lyr","10.1") Or, disconnect network cord, and open your mxd, then when all layers have dead connections, fix their sources to corrected sde account and layer.

‎09-30-2020

So, this is not a question so much as a kludge for those of you who have http apps built on the javascript api which broke today because ESRI turned off http for the World Geocode Service, as detailed here: FAQ: How is the World Geocoding Service affected by HTTPS Only enforcement? You can change your all of your apps to https only, and you should... but while you do all of that, here's a kludge that may fix the address search widget until you can get the work done: 1: Find your arcgis_js_api folder that you deployed in your web server. 2: Locate the <version>/js/esri/dijit subfolder. 3: Edit Geocoder.js 4: Replace the text: "http:":location.protocol)+"//geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer"), With: "http:":"https")+"//geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer"), 5: Save the change, clear your cache, and reload your app and it should work to use the built in arcgisGeocoder again. In theory you could probably do this also by editing each app you have to change the file <app folder>/widgets/Geocoder/config.json, setting "arcgisGeocoder":false, then defining the https geocoder according to the specs here Geocoder | API Reference | ArcGIS API for JavaScript 3.33 under "geocoders", but you will need to do that to each app and I haven't tried that yet, so cannot confirm it works. Has anyone done that change instead? If so, can you share your settings that worked in the config here?

‎05-08-2020

We were getting same error when trying to re-register a machine with site after it went bad, and had been rebuilt. We got the JSONObject error "'A JSONObject text must begin with '{' at character 0 of '". The machine was not listed in the admin endpoint for the live main site, but it still had files left over in the config-store\machines folder. Once I removed those files, the site was able to register with the server once again. Thanks for the fix!

‎10-16-2019

Addendum... so, I had to do it for ArcGIS 10.3.1... and encountered issue after issue, and could not decipher the problem, until I tried a java app called sslpoke which makes sure your root certificates are set up right and you can get to the target host given... and I learned that ArcGIS 10.3.1 runs on java 1.7.0_76, found in <install folder>\ArcGIS\server\framework\runtime\jre, which does not support TLSv1.1 or TLSv1.2. It only supports TLSv1. This is obsolete, and not allowed to connect to newer ldap versions, or other server types, so it causes a big problem if your it department decides to upgrade the LDAP servers to disallow TLSv1, which honestly, they should really do. So, what's the fix? You need to go find at LEAST java se 1.7.0_131, which is the first one to include TLS1.1 / 1.2 support, which requires an oracle support contract to download. Trust me that this is the first one that works, I tested connecting to LDAP with every 1.7.0_X version out there that is lower than 1.7.0_131. Anything higher than 1.7.0_131 should work also, I tested for TLS1.2 sslpoke success up to the current developer-only build 1.7.0_241 from the oracle patching support site, but I didn't try placing them into the ArcGIS folder yet, so back up your config_store. Once you have that, you can save your cacerts file, or just reimport your root certs to it, then stop arcgis server, and replace the server's jre folder under <install root>\ArcGIS\server\framework\runtime\jre folder with the 1.7.0_131 (or higher) jre folder you obtained. Make sure you add your root certificates back into the new jre\lib\security\cacerts file as detailed above in original post. One thing I haven't checked, but might be a nice side effect, tls1.2 ArcGIS online connectivity. Maybe someone can advise if this resolves that. This may also work for ArcGIS Portal 10.3.1, but I haven't tried it yet.

‎08-16-2019

Having encountered this now, it's possible the solution is that your portal machine cannot browse to the target URL due to company proxies that prevent portal's tomcat process catalina proxy settings from passing through your firewall. These can be configured in /arcgis/portaladmin/system/properties ...or for <= 10.2.2 follow steps here: https://support.esri.com/en/technical-article/000011933 A web secured service actually proxies through the portal process on your portal server, and does not obey the proxy settings of the portal hosting machine's internet options, but uses the options stored in /arcgis/portaladmin/system/properties https://developers.arcgis.com/rest/enterprise-administration/portal/update-system-properties.htm Also, check your certificates to make sure the root certificate for the site you are trying to use is in your \ArcGIS\portal\framework\runtime\jre\lib\security\cacerts file. Information on working with the file can be found here: https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html -Josh Dalton

‎08-07-2019

So, I needed to switch from Windows authentication to LDAP authentication, and our company has set up its own certificate authority trusted root certificates, and I've found the LDAP setup documentation doesn't cover this very well, so I'm posting my findings here for everyone else. The docs are here: https://enterprise.arcgis.com/en/server/latest/administer/linux/configuring-a-highly-available-ldap-with-arcgis-server.htm So, I had to actually go through with support and try a lot of variations to the parameters to get this right. The error it was giving at first was "simple bind failed: <servername>:636", when I provided a secure LDAPS://servername:636/ou=..... link. This was because I needed to import the trusted root certificate authority, which I tried to do in the ArcGIS/admin page, under machines/machinename/sslcertificates, but the error persisted. So... it turns out the jvm's have their own keystore, and here are all of the other steps you may need to follow to get your secure ldap working with ArcGIS server, in excruciatingly overdetailed glory. Also one other note: if you get an error more like this, your password or userid is wrong: LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 775, v2580 If you get an error like this, your OU values are probably wrong, skip to step 3A to see how to find what they should be: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839] 1: Import the certificates into the background jvm keystore as follows (rather than importing through the url:6443/arcgis/admin web page): browse to <installroot>\arcgis\server\framework\runtime\jre\lib\security copy the cacerts file to cacerts.bak (just in case). Also back up your arcgissserver\config-store folder. From a command prompt, run the following commands adjusted for your install location, and location you placed the .cer file(s) for each of your new trusted root authority certificates: <installroot>\ArcGIS\Server\framework\runtime\jre\bin\keytool -import -keystore <installroot>\arcgis\server\framework\runtime\jre\lib\security\cacerts -trustcacerts -alias "certificatename" -file "<trusted root certs folder>\certificatename.cer" Note the default arcgis jre keystore pass is “changeit” 2: Restart ArcGIS Server Windows service. 3: go to https://<machinename>:6443/arcgis/admin and log in as the local arcgis admin account, then browse to Home => security => config => testIdentityStore, and test the following LDAP configs for “Connection Successful!” message, after adjusting for your password and your mechid, and all of the OU / DC values to match those of your own company. If you don’t know them, see step 3A below to find out how to get them. User Store Configuration: { "type": "LDAP", "properties": { "isPasswordEncrypted": "false", "adminUserPassword": "<password>", "adminUser": "CN=<your userid>,OU=userids,OU=esriusers,DC=redmond,DC=esri,DC=com", "ldapURLForUsers": "ldaps://ldapserver.it.esri.com:636/OU=userids,OU=esriusers,DC=redmond,DC=esri,DC=com", "usernameAttribute": "cn", "caseSensitive": "false", "userSearchAttribute": "samaccountname" } } Role Store Configuration: { "type": "LDAP", "properties": { "ldapURLForRoles": "ldaps://ldapserver.it.esri.com:636/ou=roles,dc=redmond,dc=esri,dc=com", "isPasswordEncrypted": "false", "adminUserPassword": "<password>", "memberAttributeInRoles": "uniquemember", "adminUser": "CN=<your userid>,OU=userids,OU=esriusers,DC=redmond,DC=esri,DC=com", "ldapURLForUsers": "ldaps://ldapserver.it.esri.com:636/OU=userids,OU=esriusers,DC=redmond,DC=esri,DC=com", "rolenameAttribute": "cn", "usernameAttribute": "cn" } } 3A: If you do not know your baseDN and OU values… Install the Windows RSAT application tools package with DSQUERY command from Microsoft, then go to control panel => programs (and features) => add windows feature, “Remote Server Administration Tools” and enable the Role Administration Tools and all subitems there. Note that in my examples, I totally made up “userid”, “esriusers”, and “redmond” as values, as these will always vary by your own company’s domain setup. Make sure you run the DSQuery tool to get the right values YOU should be using. Go to command prompt and run this command, with the quotes: dsquery user -name “<username>” Result will look like: “CN=<username>,OU=someparam,OU=maybe-a-secondparam,DC=domain1,DC=domain2,DC=domain3-typically-just-com” So something like: “CN=abc1234,OU=userids,OU=esriusers,DC=redmond,DC=esri,DC=com” would go into your JSON config value like this: "adminUser": "CN=abc1234,OU=userids,OU= esriusers,DC=redmond,DC=esri,DC=com”, Take the resulting value and use it in the adminUser attribute in the json code in step 3. Paste the portion after the CN=<username>, starting with the first OU=, and paste that into the ldapURL parameter. Following the example above, this would go in your JSON config value: "ldapURLForUsers": "ldaps://ldapserver.it.esri.com:636/OU=userids,OU=esriusers,DC=redmond,DC=esri,DC=com”, These values may not be needed based on your company’s LDAP settings, so try without them first... samaccountname is the standard value for windows active-directory setups. "caseSensitive": "false", "userSearchAttribute": "samaccountname" The ldapURLForRoles OU value of “roles” may indicate success in the test page, but it works with anything and is not apparently truly tested, so also use the command “dsquery ou” to see a list of all OUs in your company and find the one that looks like ou=groups or ou=roles. 4: If those functioned, you can browse back to the “config” level in the arcgis/admin page, and use the updateIdentityStore link to change the identity store config to use the adjusted configs you just tested. Hope that helps someone!

‎05-20-2019

A bit of both. We saw a tremendous decrease in response delay for ags services by adjusting the ArcGIS/admin settings for app heap from 256 to 1GB, as the Java worker process was choked at 256 and just stuck in garbage collection all the time. Once that was adjusted, it started consuming up to 4-500mb (no longer maxing out at the new 1GB GC limit) and direct arcsoc request response times dropped by over half during heavy load, so I'm wondering if adding a similar adjustment on the IIS endpoint would improve responsiveness, to spread the load across multiple processes in IIS as worker threads. I can definitely see a 100ms+ addition to the time of response when going through webadaptor vs straight to port for a service request, even when not under load. My thought was that this is another obvious possible chokepoint when under heavy load, as a single process sitting directly in front of the ArcGIS java app process. I don't think it causes any issue for state since most requests come in and go right back out, but I'm wondering if anyone else has made such an adjustment. The complete lack of guidance on it made me worried to make the change. We did have a machine that was running it with 3 worker processes for quite some time (because someone thought that'd be great to set all of the app pools to 3) so I'm fairly sure it's stable. I guess really I'm just wondering if anyone out there ever really performance tested such a change, and what results they saw.

‎05-14-2019

For us, the crash was repeatable by loading MXD and browsing to same coordinates, or using the actual REST service endpoint with the query? function like this to pass in geometry: http://servername.domain.com/arcgis/rest/services/SOMEFOLDER/SERVICENAME/MapServer/9/query?where=&text=&objectIds=&time=&geometry=%7By%3D45.12345%2Cx%3D-0.51234%7D&geometryType=esriGeometryPoint&inSR=&spatialRel=esriSpatialRelIntersects&relationParam=&outFields=&returnGeometry=true&returnTrueCurves=false&maxAllowableOffset=&geometryPrecision=&outSR=&returnIdsOnly=false&returnCountOnly=false&orderByFields=&groupByFieldsForStatistics=&outStatistics=&returnZ=false&returnM=false&gdbVersion=&returnDistinctValues=false&resultOffset=&resultRecordCount=&f=html Which would result in this: Query: LAYERNAME (ID: ###) Error performing query operation and an HRESULT severe error would be logged by the ArcGIS server machinename\service logs. Changing our coordinates would not cause the error. Opening the mxd in arcmap and allowing the whole thing to draw would crash. stopping it early and zooming in to a good coordinate area would not crash, but panning over to the problem coordinates would always crash arcmap.exe (send report to esri dialog and all). The problem was... a bad polygon in the sde layer, which was reloaded nightly by scripts that generate that feature class. Something corrupted the layer during that dataload, and our previously functional service would then crash because of bad polygon data. Reloading the polygon layer with fresh uncorrupted data resolved the crashing of our server. Hope this helps someone else. -Josh Dalton

‎05-07-2019

A few thoughts as I've been doing a lot of memory consumption firefighting and performance tweaking on our arcgis server apps... Merging services has minimal impact, but 5% is 5% so I guess you should take it, but note that grouped layers don't work with all widgets in webappbuilder (like, the screening widget) so check what your usage goals are first. Adjusting machine level java limits and step sizing can have considerable impacts on memory consumption. Consider looking into the Xmx and Xms settings (Xmx can be set in arcgis/admin - machines - <machine name> for the server java process as App Heap, or your individual services as SOC Heaps, which show up as parameters in the java and ArcSOC command lines if you look in task manager after adding the command line column. You can use the windows environment variable for _JAVA_OPTIONS= ...... overriding settings here ...... to add command line settings for the whole machine. Of additional interest, which I've yet to try, is the -XX:MaxHeapFreeRatio which must be used in combo with -XX:+UseG1GC or -XX:+UseSerialGC which may allow heap to shrink after garbage collection. I've NOT tried this, and barely came across it today, so do research it first. Regarding performance, certainly increasing the app heap and the SOC heap in the admin console helped improve performance considerably, and we've begun setting the app to 1024MB on several of our servers as the reduction in garbage collection cpu time made a huge performance impact. Be warned though that adjusting SOC sizing will quickly use up all Virtual memory by spiking commit charge. Look under Details tab on windows server Task Manager and add commit size to see what really goes into using up that committed memory total. Note that exceeding the max committed memory will cause exceptions and all kinds of instability. If you blow way past it, you either need to ramp up your virtual memory for long enough to start ags and turn the arcsoc setting down, or get into the admin console and turn it down before the ArcSOCs launch.

Online Status	Offline
Date Last Visited	‎05-16-2024 03:39 PM

My Ideas

Latest Contributions by JoshuaDalton

Re: Esri Developer Summit - Event Meetup

Re: Create Enterprise Geodatabase fails. ORA-00955 name is already used by an exsisting object

Re: Create Enterprise Geodatabase fails. ORA-00955 name is already used by an exsisting object

ArcGIS Server tomcat server.xml corruption due to lack of disk space

Re: 10.6.1 New Install - Error The server was unable to access the URL

Re: Portal 10.6.1 fails to load CA-signed Server certificates (portaladmin)

Re: Fixing ArcMap crashes

Geocoder http refused fix

Re: ArcGIS Server 10.3 Upgrade Join Machine Issue

Re: ArcGIS LDAP Configuration Errors

Re: Arcgis Online - Feature Services with Stored Credentials - "Service Directory has been Disabled"

ArcGIS LDAP Configuration Errors

Re: IIS Maximum Worker Processes

Re: "Method failed.HRESULT = 0x80070057 : The parameter is incorrect" in AGS 10.1 log

Re: How much does merging services affect server performance?

ArcGIS Server tomcat server.xml corruption due to ...

ArcGIS LDAP Configuration Errors

Re: ArcGIS LDAP Configuration Errors

Re: Arcgis Online - Feature Services with Stored C...

Re: "Method failed.HRESULT = 0x80070057 : The...