Closed arashmalekz closed 2 years ago
The reason the "Logon as a service" is not changing is because that process is only fired when a user is created with the run_as_user name provided.
Setting the subscribes to another trigger or writing your own call to the :update_account action should assign the "Logon as a Service" and the user file permissions to the install dir. The other parts where a run_as_user would be assigned for Portal and Datastore have a similar trigger. Geoevent however is set to run only_if Geoevent is installed, but is instantiated prior to the install step.
I ran into this issue myself with a domain auth not being able to read/write a content_dir that I know I had full control over.
Hope this helps.
@cdflint Thank you for the suggestion. In my case the update_account action does get triggered. If I add log info lines in that function, I do see them get printed. The logon account for the Arcgis Server service does get changed, which I believe is because of Utils.sc_config call inside update_account function. The only issue is with executing ServerConfigurationUtility.exe. I'm using release 3.5.0 for configuring Arcgis 10.7.1.
Give your run_as_user permissions to install_dir\bin, install_dir\framework, install_dir\XMLSchema and install_dir\DatabaseSupport
ref: https://enterprise.arcgis.com/en/server/latest/install/windows/the-arcgis-server-account.htm
Thanks, I tried giving full control access to all Arcgis folders for run_as_user before running the Chef recipes but that didn't help with executing ServerConfigurationUtility.exe. I can probably write custom codes/scripts as a workaround to apply the changes suggested on the page you mentioned after running Chef scripts, but I'm trying to avoid custom code to reduce maintenance and avoid random issues. I'm curious if it's a requirement to run Chef script under the same user account set for run_as_user. If it's not then this is possibly a bug.
Hello @arashmalekz ,
It's not a requirement to run Chef as the same user account set for run_as_user. However, in this particular case you may need to run Chef as a Domain Administrator account since the local Administrator account is unable to 'find the network path to the domain user' which is the error described when manually running the ServerConfigurationUtility.exe. Chef likely isn't catching the error or the ServerConfigurationUtility.exe tool isn't exiting when this error occurs.
"I tried modifying the command to run under a different user by setting :user, :domain, :password parameter to Mixlib::ShellOut command and it still did nothing."
There was a bug with Mixlib::ShellOut and account impersonation, where it doesn't load the user profile correctly. Could be running into it or something similar when you tried setting :user, :domain, :password parameter to Mixlib::ShellOut command.
Hope this helps!
Happy Automating, Cameron K.
Hello,
The update_account function in server.rb provider runs ServerConfigurationUtility.exe for setting up Arcgis server account and logon as service permissions. We set run_as_user to a domain account (eg. domain\user), and run the Chef scripts while bringing up EC2 instances in AWS environment. These instances are joined to a domain prior to running Chef scripts, but the scripts are executed under the local Administrator account.
I've noticed when update_account runs ServerConfigurationUtility.exe, nothing happens and there are no errors. The ServerConfigurationUtility.exe is supposed to add server account to "Logon as a Service" local policy, but it's not happening. I tried running ServerConfigurationUtility.exe manually and it actually gives me errors saying it can't find the network path for the domain user, which makes sense since it's being executed under the local Administrator account. In the update_account code, I tried modifying the command to run under a different user by setting :user, :domain, :password parameter to Mixlib::ShellOut command and it still did nothing.
Is there a requirement to run the Chef scripts under the same user that is set for run_as_user parameter? Or can something be done in update_account function to handle this situation?
Thanks!