Changing to AD service account for Portal 10.9.1 fails

[Brian_Wilson]

I've been working with Esri support on this for weeks on this problem to no avail.

About a year ago I migrated from a single machine to 3 separate machines for Portal, Server, and DataStore. Everything runs fine. But the Portal is still running on a local account.This means I cannot run webgisdr, which has to write to a network share when running in multi-machine mode. The Esri tech that helped with some other issues back when I migrated gave up on this one so I've just lived with it.

Before upgrading to 11.x I want to make sure it's running on an Active Directory account so that it can use networked file shares and make a full webgisdr backup.

configureserviceaccount runs just fine, and the Portal starts with the new AD account. But then it fails to start up, and logs this message roughly every 10 seconds.

<Msg time="2024-01-30T17:53:58,159" type="WARNING" code="218017" source="Portal Admin" process="9684" thread="1" methodName="" machine="CC-GIS.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">The Portal site has been initialized and configured but is currently not accessible, because the content directory is not available. This may be due to incorrect permissions, a file server hosting the directory being unavailable, or network issues. As a last resort, if the content directory can not be recovered, then uninstall the software, re-install, and restore from a backup.</Msg>

Of course, we've checked the permissions on the Program Files\ArcGIS\Portal folder and on the arcgisportal folder many times, they are fine. We've checked the location of the content directory to make sure it's using the normal place.

All I change is the LOGON account; it works with a local account but not a network account. No other settings change so the content directory setting is not changed. It works with a local account but not a network account.

Last night we tried doing REPAIR of the application. It made no difference. The tech then wandered far afield and started trying random things. I hate it when they do that.

Though I am reluctant to run the 11 upgrade before fixing this it's probably what I need to do. Three outcomes I can see are:

(1) 11 does not work at all and I have wasted hours but can recover from a snapshot backup

(2) 11 works but runs in local account and I just go on living with it

(3) 11 works and I can switch to a networked service account and I share my elation with the world.

That's 2 positive outcomes of 3 so I am inclined to go that way.

I'd love to hear from anyone who can shed light on the underlying problem though --- "content directory is not available" -- but it is!! Thanks

[BillFox]

maybe your organization has a group policy about running as a service or running as a batch job

[Brian_Wilson]

The account is already in use for ArcGIS Server and ArcGIS Data Store. It runs Portal just fine, just doesn't have permissions on the content directory. (Only it does.)

If it were open source I would have simply isolated the problem and fixed it and submitted a pull request 6 months ago. I say this because it frustrates me that the staff at Esri can't do the same thing-- actually find the problem instead of throwing randomness at the wall until something works or the customer gives up.

[BillFox · Accepted solution]

maybe try:

add the AD user to the local admin group

or

move the portal's content folder to a network share, and set the share and file/folder privileges read/write

[Brian_Wilson]

I have been thinking about trying your "option B" -- move the folder to a share, I had to go through that to move the Server to the new machine. Worth a shot. I am asking our admin about the permissions again

[Brian_Wilson]

Added the user to the local admin group.

THANK YOU @BillFox

[Scott_Tansley]

That's a surefire way of making it work (it always works) but you could potentially open yourself up to security risks by doing so.  Please be aware.

[Brian_Wilson]

Thanks, yes, this is the equivalent of giving root permissions to the process running Portal. I understand that. But Esri won't even acknowledge that it's a bug so this is what I have for now. I plan on updating (not upgrading 🙂 to version 11 soon and I will try turning it off once that's done.

[BillFox]

I've read in the past that it is not required, but here we are...

[Scott_Tansley]

Okay - left field, but you could create your WebGISDR backups on the portal machine using local disk.  The local system account can have permissions to write to that folder.  THEN - have a scheduled task that robocopy's (other technology exists) the output file to your remote file share.  You will achieve the same outcome, just using a different method.