So the Services applet says SQL Server uses login A and Configuration
Manager says SQL Server uses (non-existent) login B?
They should be getting their information from the same source, so that's
messed up.
There may be some registry setting that could fix this, but a quick check
didn't turn anything up.
And it's possible that the problem is with WMI, and really isn't a SQL
Server issue, but I don't know that much about WMI.
My only suggestion there is to check the WMI permissions.
1. Open the WMI applet WmiMgmt.msc.
2. Right-click WMI Control (Local) and then click Properties. (I don't know
if it will say (Local) on a DC though?)
3. On the Security tab, expand Root, and then click CIMV2.
4. Click Security. Then, if your login is not specifically present, add
yourself with all permissions.
Then try Configuration Manager again.
If it still isn't working, I'd probably stop messing with it and reinstall
SQL Server. I suppose you could install a second instance instead and how
that setup fixes the shared Configuration Manager.
--
Rick Byham (MSFT), SQL Server Books Online
This posting is provided "AS IS" with no warranties, and confers no rights.
"geekyguy" wrote in message
> Thanks for your reply...see below:
>
>> Normally we tell people to always use SQL Server Configuration Manager to
>> change the account used by the SQL Server services.
>
> Yes, that's where I'm getting the error!
>
>> That's because Configuration Manager, in addition to changing the
>> account, grants the appropriate permissions to the registry and file
>> system to that new account.
>> I'm guessing, that your error here occurs because Configuration Manager
>> is trying to resolve the SID of the old account to the name of the user,
>> and can't do it. And it sound like that error prevents Configuration
>> Manager from doing anything. If so, then go to the Windows Services
>> applet (services.msc) and use that to change the account used by the
>> service. For the service to function properly the new account would have
>> to be one that you know has enough privileges. Or just change it to any
>> user that exists, and then go back to Configuration Manager (which will
>> hopefully work now) and change it again, so that the privileges are set
>> correctly.
>
> I'm sort of one-step-forward, two steps back here.
>
> After promoting the server, rebooting, and seeing that SQL wouldn't start,
> I FIRST went to Services and tried to start manually and got the error.
>
> I realized immediately that the local user account was gone, so I created
> a domain user, and then in services updated each SQL service to log on
> with the new domain user, and then rebooted.
>
> When SQL still didn't start, only then did I go into SQL Configuration
> Manager, where I saw that the old user was still configured. When I tried
> to change it to the new domain user in SQL Conf Mgr, I received the WMI
> error.
>
>> --
>> Rick Byham (MSFT), SQL Server Books Online
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "geekyguy" wrote in message
>>
>>> Hi All: I had a standalone 2003 server sp2 in a domain running
>>> IIS/SQL2005, and I decided to promote it to a DC without doing too much
>>> research. After promotion/reboot, SQL did not start and I saw pretty
>>> quickly that it had been running under a local account that no longer
>>> existed.
>>>
>>> I created a domain user to assign to SQL, opened SCM and tried to
>>> change the log on, but when I click "apply" I receive a popup with
>>>
>>> "WMI Provider Error"
>>>
>>> "No mappeing between account names and security IDs was done.
>>> [0x80070534]."
>>>
>>> I've been googling around but haven't figured out what to do to fix
>>> this?
>>
> >> Stay informed about: ""No Mapping between account names and security IDs...""