Latest Contributions by DavidCordes

Jamal,  Sure I can help explain this.  ArcSOC.exe is a program.  A program is a set of instructions that tell the computer what to do.  When a program runs, the operating system creates a process, which is a running program.  There can be more than one process running from the same program.  A program can provide instructions that run concurrently, at the same time, and each concurrent execution is called a thread.  Each process is assigned a process id (which is a number) and you can see those running processes in task manager and you can differentiate them using the process id.   The ArcSOC.exe instructions relate to service-related operations.  One of the functions is handling requests for the services that run in an ArcSOC.exe.   ... View more

Jamal,        Instances indicate how many processes are ready to handle incoming requests.  Each instance has a corresponding ArcSOC.exe process.  There are ArcSOC.exe processes that are not related to instances, but the vast majority of ArcSOC.exe processes are for instances handling incoming requests. You can identify which ArcSOC is associated with which service using Task Manager.  Here's how.  In Task Manager, use the "Details" tab, you add columns by right-clicking on any of the current columns (such as "Name" or "PID") and choose "Select Column".  Put a checkmark next to the "Command line" column.  The command line column will be too short to start with, so you can make it larger and you will see the service name listed in the column. ... View more

The patch is about 44 kb.  It is small.  If at any point you want to make sure you have the real and complete files, you can download a tool called md5sum.  You can run this tool at the command line, for example, md5sum c:\users\david-or-whatever-your-account-is-called\downloads\ArcGIS-106-S-IACS-Patch.msp This will then provide a value and you can compare it to the md5 value posted on the patch page.  For instance for the Windows 10.6 version of this patch, the checksum is 8B246B657A6015CC19D66382D6720BEE.  This way you can be sure you have the patch we posted. ... View more

Walter, Once an AMI is created with a particular id, it's frozen in stone - it can't be updated.  However it is possible to create new AMIs based on old ones.  We are working towards creating new AMIs for 10.6 and 10.5.1 that are patched.   For existing instances that are already running, you will need to patch those.  For 10.5, you will need to create a new AMI off our AMIs that is patched.  Once you have done that, you can download and update our cloud formation templates with the new AMI id for the region that you are using.   ... View more

HTTPS is always required with Portal, whether you use LDAP/ActiveDirectory or not.  Portal automatically comes with https enabled and no way to disable it.  Many pages in Portal must be read over https (such as the 'My Organization' page) and links will break if you somehow disable https after the fact.  To prevent problems the web adaptor can not even be configured until https has been enabled in the web server as well.     The thing that differs with ActiveDirectory/LDAP and web tier authentication is that HTTP (unencrypted communications) must be disabled and all communications must go through https.  If you were using built in users you could have HTTP enabled.           --- David ... View more

Tyson,    Could you please let us know which step you ran into the first blocking problem and what the issue was?  I just want to make sure that you are clear that these steps are for a newly generated certificate which requires you to generate a CSR, get it signed, import the root + intermediate certificates, and import the signed certificate.      If you have an existing certificate that was generated elsewhere you won't be able to bring that in (though that's something we are considering for the next release).  Bringing in an existing certificate actually requires you to bring in more than just an existing certificate, it also requires you to bring in the associated private keys.    ---- David ... View more

Christopher,     The message you are seeing that says "the app server was not started" is expected.  When you change SSL settings, a restart of the application server is required.  There is another internal component that monitors ArcGIS Server processes and during the restart it noticed that the app server was indeed not running (though it was only for a few seconds) and correctly reported that.  This particular message was logged at 'warning' level.  If a particular event happens that we know for sure is a "bad thing" then it gets logged at the 'severe' level.  If it's something that may be bad, but may also be normal then we log it as a 'warning'.  In this case (changing SSL settings) it is safe to ignore this particular error message.       The error message that says "port 4000 is in use" is a severe error and is not normal when changing SSL settings.  That is something that does need to be addressed immediately if that is continuing to happen.  That usually means that ArcGIS Server did not shut down cleanly for some reason.  The quickest way to resolve it is to reboot the machine.  Typically when you stop ArcGIS Server the software waits for a period of time for a clean shutdown (about 30 seconds).  If it's not able to cleanly shut down then it forcibly kills left-over processes.  That kill usually works but for some reason it sounds like one of the processes was not able to even be forcibly killed.  That's fairly unusual and if a reboot does not solve the problem or if you see it reoccur in the future then I would open up an Esri support incident for that issue.      ArcGIS Server does support using CA-issued certificates but it must be from a CSR (certificate signing request) generated by ArcGIS Server.  There are several things that can be wrong with a certificate that might prevent port 6443 from working - unfortunately these are hard to diagnose.  The self-signed certificate for ArcGIS Server provides protection against packet sniffing along the network because all your traffic is encrypted but does not provide protection against a man-in-the-middle + DNS spoofing attack.  If you want to protect against the possibility that hackers can modify your DNS records and set up a server on your network to intercept ArcGIS Server traffic then you should use a CA-issued certificate.  This type of "man in the middle" attack is moderately difficult to pull-off.  Each organization has to decide which level of security they wish to use, but if your organization has strong security requirements or you are a potential target for a focused attack on your organization then you should consider using a CA-issued certificate. ... View more

The handlers (REST, SOAP, OGC, Admin), the token service, and Manager application run in a single process.  That process is designed to not use more than 1/4 of the available RAM on the machine.  Since you have 8 GB of RAM, then that process won't use more than 2 GB of memory.  If it does then it will throw an error message since that is a very unusual situation.  We don't provide a means to increase the memory for that process.  The settings that Patrice suggested increase memory in the event that you have a Java-based SOE that consumes a large amount of memory but won't help here. In this case, it's likely that the Flex app is making some call that is returning a huge amount of data (I am guessing 500 MB to 1 GB).  That may not be the desired behavior since just downloading that much data will take a while.  It's also possible there is a bug, but we ourselves haven't seen this error even under heavy load testing.  To really reach a diagnosis we will need you to open a Support incident and we will ask you to do some tests that will help us determine the root cause.        --- David ... View more

There is no real "disable security" option in 10.1.  The easiest way to achieve the same thing as 10.0's disable security (making all services available without security) is to simply edit the permissions on each folder and set the folder to "public" and that will allow everyone to view services in that folder.  I would making sure that your System folder however remains private (those services are not intended for public use).  This part of the help describes how.    If you want to delete the site (and lose all services, all settings, etc) which is a pretty dramatic thing I would not attempt the steps that the support analyst provided - those steps are only for a last resort when your ArcGIS Server itself doesn't even start.  You can simply log into http://<YourServer>:6080/arcgis/admin and then choose the Delete Site link.  That's a pretty dramatic option (it blows everything away) but it is a lot less error prone than deleting files.        --- David ... View more

Ty,     Let me with the area that I am most familiar with, namely the Java aspects of Engine versus using Python to write geoprocessing tools. There isn't a right answer for everyone in terms of which language to pick.  In general I would say the following are true: 1 It's a lot easier to create geoprocessing tools in Python. This is true for two reasons.  First, it's harder to implement the geoprocessing interfaces in Java than it is to write scripts in Python.  Second writing ArcObjects code is generally significantly harder than calling geoprocessing tools. 2 You have a lot more power (you can access any ArcObject) through Java but this gap is dwindling as there are more geoprocessing tools covering the spectrum of ArcGIS functionality. 3 Performance can vary considerably depending on what functionality you are using.  The general feedback I have received from people is that if you are writing a Java-based geoprocessing tool using ArcObjects it will generally outperform a Python script calling into tools.  The performance difference can vary wildly - from having the same performance to many factors better.  I work with Java technology all the time, but my general recommendation to people is to try Python first unless you either know it's impossible,  performance is of paramount importance, or you are already an ArcObjects expert.  In general the amount of time you spend scripting in Python will generally be a small fraction of the time programming ArcObjects in Java.         ---- David ... View more

Hiroshi,    There is no need to use a web adaptor with ArcGIS Server.  There are two problems that customers face that may lead them to use a web adaptor.    (1) Customers may have a distributed site with many machines.  In that situation you don't want to use the URL to a single machine in your site because that machine might fail.  Instead you would likely want to have something in front of ArcGIS Server that can detect a failure and handle fail-over.    (2) Customers may want authentication to happen in their web server - for example IIS customers using Integrated Windows Authentication will want to authenticate in their web server.    The web adaptor is our piece that allows integration into a web server and so if a customer is trying to solve problem #2 then they should definitely use a web adaptor.    If the customer is trying to only solve problem #1, fail-over handling, they can use any http load balancer or reverse proxy software that they are already using.  For instance we configured a Cisco router which has http load-balancing support here in Redlands to work with ArcGIS Server for fail-over. We also used an Apache reverse proxy to support fail-over as well.    If you have an Apache web server (like 66% of the site on the Internet) and you just want that to be the gateway to ArcGIS Server then just set it up as a reverse proxy.  I would not do any "Tomcat forwarding" (aka AJP) protocols. --- David ... View more