Sean Wallbridge
Ah, the life I lead. It’s 11:49pm on a Sunday night and I’m tired. This will be an ugly and sporadic post, as I want to go to bed… But I figured I’d better share before this drops out of my head (ala Brainlitter). Here’s what happened today.
The Goal
Customer wanted to migrate SharePoint 2010 Foundation from one domain to another. I had my task list all prepped out. Heck, I’ll even share its basic skeleton with you (this is by no means complete, but I didn’t want to forget anything):
Figure 1 : the above is by no means complete, just my little notes to myself, in OneNote of course 😉
They were collapsing a few domains into a new single domain.
The Challenges
First off (not recommended), when creating a new domain and migrating stuff to it, be sure you use a new domain name. The company had chosen to change their old DNS domain name from CorporateX.net (faked example) to CorporateX.com. But they decided to go with the same downlevel/NT domain name of CorporateX (this was a mistake I think, as it caused untold grief).
So I had a number of challenges to work with, no less, trying to trick SharePoint into believing that CORPORATEXSPFarm was indeed a different account than CORPORATEXSPFarm… but that is a story for another time. This story is about after getting the domain all fixed (by the way, this is the syntax needed to get the farm to play nice again using the farm account – stsadm -o updatefarmcredentials -userlogin SOMEDOMAINSOMEACCOUNT -password XXXXXXXXXX) and getting search rolling again as I had the following errors to work with…
Foundation Search Errors after the Domain Move
No matter what I tried to do, when trying to start the SharePoint Foundation Search service, I got the following…
Figure 2 : Some or all identity references could not be translated
The Resolution (for me anyways)
I did the following things, of which I believe all helped in the resolution of the matter though if I had time to lab things, I think I could trim this list. If you are Googling this late at night, have backups, do so at your own risk and only if you understand the ramifications, etc. I.e. this comes with no warranty, expressed, implied or decaffeinated…
By the way, I realize STSADM commands are deprecated in SharePoint 2010 but I couldn’t find an equivalent for doing what I needed to do, particularly on a tired mind. Besides, TechNet says IISRESET is deprecated and no longer used and we ALL know that isn’t true in the SharePoint world. 🙂
I migrated the original SharePoint Server Search Account to the new one I wanted to use:
stsadm –o migrateuser –oldlogin CORPORATEXSPSERVICES –newlogin CORPORATEX SP2010SERVICES –ignoresidhistory
I forcefully removed SharePoint Foundation Search (This command yanks the search database and sets it back to needing to be configured)
stsadm.exe -o spsearch -action stop
That didn’t work (at least yet) until I used the following to remap/tell SharePoint Foundation Search which accounts to use, so I could even begin to seize control
stsadm.exe -o spsearch -farmserviceaccount CORPORATEX SP2010SERVICES -farmservicepassword No_I’m_Not_Giving_You_The_Password_:)
stsadm.exe -o spsearch -farmcontentaccessaccount CORPORATEX SP2010CONTENTACCESS -farmcontentaccesspassword No_I’m_Not_Giving_You_The_Password_:)
Ah, that’s better. Now I could actually attempt to start the service in the Central Admin GUI again (before it would just give the above error re: ‘some or all identity references could not be translated’
So I ran this again now that I was in control…
stsadm.exe -o spsearch -action stop
And voila, the next time I went to start SharePoint Foundation Search Service and define a new Service Account and Content Access Account, it started as expected
Yeesh. Gnight. Seriously, if I make it so you have a shorter night than I did, you gotta buy me a pint dude. https://itgroove42.wufoo.com/forms/beer-me/
wow. thank you so much…..this is worked perfectly.
wow. thank you so much…..this is worked perfectly.