I had a call from a customer with a very strange problem. The team that builds servers for his company likes to keep the Administrator account out of reach of everyone but a tiny circle of people. That is a good thing in most cases. They add individual user accounts to the Administrators local group to handle the deployment and day to day maintenance.
My customer (let’s call him Ted) had a pair of Windows Server 2008 standalone (not joined to a domain, or in a workgroup) servers that he was building a web application on. They needed to use NLB for that application. He logged onto the two servers with his local account in the Administrators group, and was able to add NLB role. Then he tried to configure it through the NLB management console. He was able to add the first node in the console, but when he tried to add the second node, he received an access denied error after a 30 second pause.
I did exactly what he had done at my desk on a pair of Virtual Machines built for the purpose. It all worked perfectly.
We took network traces of the behavior, and never saw any authentication traffic on the wire. We established an authenticated connection to the IPC$ on the second server. That means we had a secure channel that could be used, but we still experienced the problem. That connection used the Ted user account and password, so we should have had Administrator credentials established between the machines.
The one factor that differed between our environments was I was using the Administrator account, and he was using a member of the local Administrators group on each machine.
I added a test user (let’s call that user Bill) to each server and put the account in the Administrators group on both servers. I logged on to one of the nodes using the Bill test account. I had the same problem as my customer.
While I researched the problem, Ted talked to his build group, and convinced them that he needed the Administrator account password. Once he logged on as Administrator everything went smoothly. NLB configuration worked as expected through the console.
Suspecting that User Account Control might be involved, I logged in to my server as Administrator. I navigated to the Control Panel, then User Accounts. There, I turned off the User Account Control. I repeated that on my second server. After the reboot that is needed to disable User Account Control, both members of the administrators group could manage NLB without problems.
Leaving User Account Control turned off is not recommended, but in unusual situations like this, it can provide relief for pain felt during the installation of software and services before the server gets put into production. Just remember to turn it back on again.
- Bill Blomgren
we've actually come across many examples of this in our domain... lots of sql related stuff, but also iis/asp.net related stuff... uac is just bad juju, especially since you cannot "elevate" remotely.
214 Microsoft Team blogs searched, 93 blogs have new articles in the past 7 days. 212 new articles found
We've had to disable UAC on Server 2008 (but leave it on for our Vista clients) because of Local User Acces s- managing file/folder permissions as a member that isn't administrator is nearly impossible as you receive a similar error.
Muchas gracias por la informacion, nos fue muy util. saludos!
Thank you very much for the information, it was very useful. regards