Tuesday, September 11, 2012 3:37 PM
Windows Server 2008 R2 Enterprise
SQL Server 2008 Standard
Exchange Server 2010 Enterprise
We’ll say the domain is called SECOND.FIRST where the NetBIOS name is called FIRST.
Two AD DC’s running full 2008 R2 functional level (from the initial installation – fresh install on this company site). There are only two servers, Exchange is on one box, SQL is on the other.
SQL server running in mixed mode, with Analysis Services and Reporting Services.
Entire network has been running with no issues for 10 months.
This issue is new for me so forgive me if it seems a bit wordy.
I couldn’t find anything like it on the net or in the forums.
Went to install SharePoint 2010 Server, on the SQL box. Prerequisites went on with no errors. Initial configuration began and I had to give it the admin account to manage the SharePoint DB. I open ADUC and create an account. I go to SSMS to create/map the new login from AD. I type in the name when searching the AD, it autofills on checkname. Clicking ok brings it into the “Login – New” window in SQL, but….
the username says SECOND\Username, when it should say FIRST\Username (which is what every other AD login in SQL says on the screen).
Clicking Ok generates
Which I look up, and see that the error is very common, so I start getting happy, until no resolution matches my issue, and the one’s I do try don’t work. So troubleshooting the issue revealed something.
I create other users, and the same thing happens (from either AD DC). I create a whole new OU with new users, and same thing. Then I get more specific by searching, from SQL, directly into the OU’s with the users I first created, and the new OU I just created.
SQL cannot see the new OU I just created (after SharePoint was installed).
SQL cannot see the users if I drill below the “Entire Directory” level.
I tried changing a username from SECOND\Username to FIRST\Username but that generated the same error.
I then REMOVED ALL of SharePoint and SQL from the server. Rebooted a couple of times. Let the server sit for some time to sync the changes with the other AD controller.
Now I install SQL Server 2012 Standard (hey, why go back). The thinking is to overwrite any SQL 2008 items that are causing issues, but during installation, I can’t assign any accounts as service accounts that have been recently created (though the SQL 2012 browser during installation can see the recently created OU) but will not use the user accounts. I assign the services to accounts that have already existed, and it installs without a hitch (I mean flawlessly).
Now SQL 2012 is installed, and it has the EXACT same problem, and it can’t see either OU or objects in AD that weren’t previously there.
So obviously, the word I’m trying to convey is HEEEELLLLLLLP!!!!!
Tuesday, September 11, 2012 6:49 PM
What happens if you launch SSMS with "Run as an administrator"?
Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu
Tuesday, September 11, 2012 9:44 PM
I just tried that. It has the same response (though I had actually logged on as the domain Admin prior with no success).
I also forgot to mention that its only happening to SQL Server (either version - 2008 R2 or 2012).
I can have Exchange make new mailboxes for those same users (or any user).
I can also apply those users to Access Control Lists when changing NTFS permissions, on a server or client drive. Everything else is getting AD information with no problems.