Latest Contributions by AllenDailey1

I got an answer!  I worked with Esri representatives and it took some time and digging, but they ultimately told me that you need to be connected to the Esri License Manager, like via ArcGIS Pro on the machine, in order to use geoprocessing tools like Rebuild Address Locator in Python.  This explains why I was able to run the function in a Pro Notebook, and then later in Windows Command Prompt using the Python .exe that comes with Pro, but not the Python .exe that comes with ArcGIS Server.  Side note - I was trying to run the script on an actual ArcGIS Server, rather than a PC or file server, because we needed to rebuild our address locators that are in our Public DMZ network.  Internal network machines cannot access the DMZ servers for this purpose, so I was trying to run the script on the DMZ server using the Python .exe that comes with ArcGIS Server software (because Pro was not installed on that server, and regardless, that server can't access the license manager in order for Pro to work there).   So the solution is to have Pro on the machine and connect to the license manager.  If the machine cannot do that, which is the case for our DMZ servers, then you have to find a workaround.  We might try rebuilding the locators on the internal network and then copying the files onto the DMZ server, or allowing the ability to have a shared folder on the DMZ server where the internal server can access the locator files. Esri previously told me that Server Python and Pro Python were equivalent, and I'm sure they have the same ingredients, but it would be nice if there was documentation somewhere that said you basically can't use arcpy via Server Python. ... View more

Update - I figured it out.  I submitted a help request to Esri, and they tested my code and it worked in their environment.  So then I tried to drill deeper into possible issues other than the code itself.  I eventually discovered that on our DMZ servers, the account that is running the script (i.e. the account being used to run software like IDLE, Command Prompt, Pro, etc.) has to be the account that enters the credentials - used as an argument for the Server object - into Windows Credential Manager.  We are using Keyring to get the credentials from Windows Credential Manager in order to avoid hard-coding them in the script, which would be a security risk.  The account I need to use to run the script is different from the account whose credentials have to be passed into the Server object.  I ran Command Prompt as the account used to run the script, and in Command Prompt I used Python keyring to set_password for the credentials to be called in the Server object.  It seems that in our server environment, an account cannot access credentials that someone else (a different account) entered into Windows Credential Manager.   Now the script is able to stop and start services! This issue will probably only apply to a miniscule number of people out there, but it would be cool if this could help at least one other person! ... View more