DX Unified Infrastructure Management

I have noticed that when the server is restarted the service will not start back up.  Upon attempting to start the Nimsoft Robot Watcher service it will throw an error "Windows could not start the Nimsoft Robot Watcher service on local computer.  Error 1069 the service did not start due to a logon failure."

The solution is to open the properties of the service and on the Log On tab re-enter the password for the domain account.  Please note that the password for this account has NOT changed.  I merely enter the same password again.  I then hit Apply and get a message "The account X has been granted the Log On As A Service right." then I get the expected message "New logon name will not take affect until you stop and restart the service.".

At this point without doing anything else I find the Nimsoft Robot Watcher service "Running".  I then procede to restart the service to verify it starts back up and it does without an issue.

Now that the service is running it will continue to run and I can restart the service if I wish with no problems.  If the server is restarted then I must once again re-enter the password.

It seems the password is not being saved and a restart kills it in memory though the service Log On tab shows a masked out password after restart.  Either that or it is being saved to disk incorrectly after being applied.

NOTE: This is a brand new fresh install of UIM 8.5.1 on new (clean) 2012 R2 Datacenter servers.

I have had to do this for the Nimsoft Robot Watcher service on the UMP Portal, Primary Hub, CABI, and other servers. 

While I want to say this should be a OS level issue with the service login process, it is the only service exhibiting this issue.  Not sure where this issue falls and I am afraid it may get punted into a gray area.

Anyone else experienced this?  Thoughts?

You are absolutely correct that this is an OS level issue.

Other than during an install the application does not make any changes to the service running on the box.

The os is responsible for saving the password and credential information for services.

The only thing I can think of is that maybe there is a group policy that is removing the user from the logon as service rights that is happening in the back ground.

But you will need to check with your OS Admin on why this is not working per the OS design specifications.

Thanks Gene for triggering a thought.  As soon as you said GPO I knew who must have setup my service account (account creation keeps getting bounced between departments) and knew right there they did not do it correctly.  Its not the first time but its been a long while since I requested one.  I just went to my favorite AD person and she knew right away what was not done by the other department.