topic Re: arcpy.DisconnectUser non-administrator user in Data Management Questions

arcpy.DisconnectUser non-administrator user

TaraDeRosa — Thu, 02 Nov 2017 16:18:11 GMT

We are attempting to execute arcpy.DisconnectUser before running a nightly compression of a geodatabase. But when running arcpy.DisconnectUser, we are intermittently receiving an error stating that the connection information provided was for a non-administrative user. The geodatabase uses dbo-schema and we have confirmed that the geodatabase administrator is a member of the sysadmin and process admin server roles.

Our SDE maintenance scripts fail periodically due to this issue similar to this post: https://community.esri.com/thread/180900. SDE is running v10.3.1 with a SQL Server 2012 back-end. The script runs from a batch file/scheduled task on a VM that has ArcGIS 10.4.1 installed.

Re: arcpy.DisconnectUser non-administrator user

JeffreyWilkerson — Thu, 16 Nov 2017 16:37:00 GMT

Under the direction of this discussion (https://community.esri.com/thread/92948 ) I added the 'processadmin' grant to the server role of the login I was using and the script worked as expected. Sysadmin should take care of that role grant as well but it worked in my case (which didn't already have a sysadmin role).

Re: arcpy.DisconnectUser non-administrator user

AhmadSALEH1 — Fri, 01 Dec 2017 13:28:26 GMT

Try to use an admin user with Database Authentication not OS Authentication, it might work with you.

Re: arcpy.DisconnectUser non-administrator user

DarrylKlassen1 — Thu, 07 Dec 2017 21:01:27 GMT

Tara, did you ever find a resolution to this? We are having the same issue, but with 10.2.1 and an Oracle db back end on our sde.

Re: arcpy.DisconnectUser non-administrator user

TaraDeRosa — Thu, 07 Dec 2017 21:29:55 GMT

Hi Darryl. We are actually still battling this problem and have opened an ESRI support ticket. The arcpy.disconnectuser will work for several days and then unexpectedly fail with the same error as above. The script is run from a batch file using a windows-authenticated admin user and the python script references a sysadmin/processadmin SDE database connection. What we are working on now is granting the windows user SQL permissions so that the scheduled task and database connection run as the same user. We are testing that tonight to see if the scripts works successfully and will monitor for several days. I will report back our findings after that time.

Re: arcpy.DisconnectUser non-administrator user

DarrylKlassen1 — Thu, 07 Dec 2017 21:33:09 GMT

Thanks Tara,

we are having similar issues, except more often than not, the script fails to disconnect the users, and there for our database compress doesn't fully work. We too are running it through a BAT file on a scheduled task. I also have a ticket open with ESRI, which is who pointed me to this thread. I will also keep you posted if we resolve anything.

Thanks

Darryl

Re: arcpy.DisconnectUser non-administrator user

KenCarrier1 — Mon, 18 Dec 2017 13:59:05 GMT

Darryl,

We are also experiencing the exact same issue. In our case some scripts will throw the error and some will not. All scripts are scheduled with the same user and all scripts use the same *.sde file. One script though refuses to work as intended when run as a scheduled task. When run manually and not Run As Administrator it works just fine. Please respond back if you hear anything. This just started happening on our new environment Windows Server 2012 OS, ArcGIS 10.5.1, SQL 2016.

Re: arcpy.DisconnectUser non-administrator user

DarrylKlassen1 — Tue, 19 Dec 2017 00:23:47 GMT

Will do Ken. My issue isn't the scheduled task, but I have had issues with that in the past. The scheduled task would run - the .bat file would run, but the Python script within the .bat file didn't. The solution we came up with was in the Actions tab - you have to put the full path to the .py script in the 'Star in (optional):' dialog - even if it is in the .bat file path or elsewhere. We also quoted the program, script. See screen shot attached. Once we did this - the python script began running again. We used to not have to do this, but something changed (windows update?) and we had to debug. Not sure if this will help you or not, but might be worth a try.

Darryl