August 12, 2021 at 11:40 am
Hi All,
We encountered this error on several backup jobs 2 days ago, and finally found the solution. Of course this could be specific for our environment, but maybe it helps if you have the same issue and cannot find the cause.
In short, the solution: On the windows SQL server running the Commvault Client, change "User Account Control Settings" to "Never Notify".
Somehow 2 days ago a GPO or MS update caused this UAC setting on our SQL servers to be changed to "Always Notify", and as a consequence the Commvault account used for the SQL backup could not impersonate. All SQL backup jobs were stuck on 'pending' and then failed with errorcode [30:329]. Failure Reason: Failed to impersonate Error: [Account restrictions are preventing this user from signing in. For example: blank passwords aren't allowed, sign-in times are limited, or a policy restriction has been enforced. ]
In the Commvault client logs on the SQL servers (file SQLiDA.log) we found this:
CSQLCommon::cvImpersonateUser() - Username = [**************], Domain = [************]
CVImpersonateLoggedOnUser() - Failing user impersonation as the user is not able to write to Galaxy log files
CSQLCommon::initializeBackup(1156): -Error-: Failed to Impersonate [Account restrictions are preventing this user from signing in. For example: blank passwords aren't allowed, sign-in times are limited, or a policy restriction has been enforced.
Of course we first tried to check if the Commvault backup account that was used for the backup was ok, if it was allowed to logon, if it had the correct password, if it has the correct rights and roles on Sql. We checked certificates, AD-connections, NTLM restrictions, Kerberos tickets issues, the works... much time was spend on comparing settings in the GPO's with other SQL servers that were still working.... nothing.
Finally we noticed the Windows UAC setting on the SQL server that had the error; someone asked the question "Why is this UAC on Always Notify, i've never seen that before and that is not logical...". So lowering the UAC back to "Never Notify" had immediate effect, we did not have to reboot the server. Backup's were started again and we were save. Great work team !
August 13, 2021 at 12:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
February 27, 2022 at 3:54 am
Thank you for the input,
The option for user account control setting is already set to never notify on my end but still getting the same error.
I am going to reach out to commvault support hopefully I can get an answer
February 27, 2022 at 3:44 pm
SQL Native backup is much better than Commvault SQL backup in my opinion.
Rackspace(a hosting company) uses Commvault SQL backup to back up client databases. Occasionally, backup took days and then was stuck. The only way is to restart SQL server. Rackspace failed to resolve this quickly nor notified the clients. Eventually, I just disabled their managed backup and relied on native backup. No issue for years.
February 28, 2022 at 7:35 pm
This was removed by the editor as SPAM
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply