August 31, 2012 at 6:38 am
schleep (7/13/2012)
The OS reboot solved everything,
Possibly because its bound itself to a different DC upon reboot
What does the following return on each sql server when run from a command prompt
set logonserver
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 31, 2012 at 6:58 am
Interesting: the prod (and problematic) SQL box is bound to what is, according to our network admin, the PDC for AD; I was forcing AD replication from it to the other DCs.
The two SQL boxes that had no problems with the newname accounts are binding to two different DCs...
August 31, 2012 at 7:23 am
Ok, what other roles does this DC hold or are they spread amongst the remaining members?
Are all DC's in the same site or do you have multiple AD sites?
Check the event logs for errors on the DC and also check the network settings (DNS, gateway, etc) on this DC too.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 9, 2014 at 6:14 am
I ran into the same problem in a SQL Server 2012 instance (SP2 applied). I haven't found the root cause yet, but we will be looking at the AD caching mechanism.
By accident I have found a simple solution that worked for me without rebooting the server. I created a Windows Authenticated login for the old username (yes, that worked) and then dropped it - problem solved.
After the create / drop I was unable to create the same login a second time, so it looks like the "drop login" is a way of forcing the old username out of the AD cache.
Viewing 4 posts - 31 through 33 (of 33 total)
You must be logged in to reply to this topic. Login to reply