SQL Server - WMI Provider Error (Access is Denied) while changing service account using SQL Server Configuration Manager

Coming back to my blogs nearly after 3 action packed months with another interesting topic (I hope), which is on a common WMI error which haunts many DBAs.

In a DBA's lifetime, he\she has changed SQL services account and\or its password at-least once and many of us may agree that they have faced "WMI Provider Error - Access is Denied" error while changing the password using "SQL Server Configuration Manager". So, for those of us who are still looking for clues, let us try to understand what happened here with an example: 

Let's assume that you have joined an organisation and where they have "CompDomain\SQLsrvAccount" fixed domain account under which all your SQL Services runs. Now, a new security policy have been enforced according to which you have to recycle\change your password (due to any condition).

Now, you've the new policy perfect password in your possession along with planned maintenance down-time, you went to the server opened "SQL Server Configuration Manager" then jumped to "SQL Server Services", double clicked on "SQL Server", which opened sql server service's properties page. You checked the correct account name (remember "CompDomain\SQLsrvAccount" above), quickly typed in the password and clicked on apply and after few seconds (or may be a minute or two) you get the below error:




You got surprised, but you thought to give it one more try and you did a double check on the password and carefully entered it into both "password" and "Confirm Password" sections and clicked "Apply" button and you again got surprised with same error.

But, when you tried to change the password using "Windows Services Console" (services.msc) using the same password, it magically worked.

Unfortunately, there is no magic here but a feature\bug\inability (choose your pick) of "SQL Server Configuration Manager" console disguised as an error. In case of "SQL Server Configuration Manager", you have to look-up for the account (using the "Browse" button available besides "Account Name" field) before changing its password, even if the account already written is valid. So, once you look-up for the account in the appropriate domain tree and then fill on that password and click on "Apply" it will work just fine.

I hope Microsoft have a fix for this soon as there is no official wording or link came across to me, which can can confirm its status as feature and I have also observed this behavior of "configuration manager" in SQL Server 2008 R2 as well. 


Comments

Popular posts from this blog

SQL Server: SQL Server services not starting. TDSSNIClient initialization failed with error 0x139f, status code 0x80. Reason: Unable to initialize SSL support.

SQL Server 2014 SP\CU installation getting stuck at “MsiTimingAction”

SQL Server: Cluster Installation failed with error “Wait on the Database Engine recovery handle failed.”