Today's joy is an attempt to provide a migration from 2003 full version to SBS 2011. It's only a 20 user company with a single file, print and email server so in theory SBS is the perfect product for the job. I'm now very close to wishing I'd gone full product for the small disparity in cost.
In accordance with documentation, the "source" server has been prepared by running the Migration Wizard tool. This has run without a hitch, the forest and domain functional levels raised and adprep run to extend the active directory schema as required.
Goody, thinks me, in the kind of misguided way that I did when I attempted this process a couple of years ago when 2K8 first hit the market. This whole automated thingy might just save me some time and effort. How wrong I was.
Fundamentally, there's nothing wrong with the idea of scripting the domain joining, FSMO role relocation and such tasks, but it is an annoyance when such things fail to perform the task as well as a human with some IT skills.
My migration is failing with errors joining the source domain, I'll post the actual text from the sbssetup.log when not on the train, but it appears that for some reason the .net method of domain join is unable to read the list of domains from the AD forest. Several solutions have been proposed in Forumsphere, including the following:
- edit the default domain controller security policy on the source domain and under local policies add the domain admins group for them domain to the value "trust user and computer accounts for delegation" then GPUpdate /force. In my case, this makes no difference.
- check for dual homed NICs and other similar traits, including such things as any VMnet adapters that might be used in case there are issues with the target server contacting the source - in my case, I. Have HP Network Teaming enabled and I suspect my solution will lie somewhere in this arena. My annoyance here is that a test server running 2K8 R2 Standard can join the domain using the traditional method without issue and that all the clients are able to communicate correctly with the source server. DCDiag reports no errors of consequence and Event Viewer shows no errors of the Directory Service or File Replication nature.
So far though, I have learnt a couple of useful things:
Unlike SBS 2008, 2011 does at least prompt you during the initial stages of Setup to determine if you want migration mode or a regular install. This is a massive advance as I've wasted many hours reinstalling from scratch when 2008 blindly refused to admit that a USB device was attached and merrily sailed it's way through the installation to proudly announce (some 2 hours later) that a regular install had been completed.
Running sbssetup.exe from C:\program files\Microsoft small business server\bin can save you much time - the default assumption here would be that you would need to reinstall. However, if you've not actually even joined the domain yet then you can safely re-attempt from here. I'm tempted to try and join the domain manually and then re-kick sbssetup and see what happens - nothing really to lose.
I will update on progress and my eventual solution when I know more. Hoping desperately that a PSS call isn't part of the bargain.......
Today's update on this is that I did a complete install from scratch over night. Still no joy in getting the migration wizard to actually join the domain. I blew the box back to nothing, including deleting and re-creating the array and deploying again using SmartStart. Same error, at exactly the same point.
To satisfy my curiosity, I did cancel out of the wizard, join the machine to the domain using Control Panel, System, reboot and run a DCPROMO. Suffice to say that this completed without error....
Sadly, re-running sbssetup.exe didn't get me anywhere - with 2K3 you always had the option of completing the various components of SBS setup manually as a backup option but this doesn't appear to be the case here.
So . . . (cue drum roll) - I've bitten the bullet and called Microsoft PSS. 50 of my life which I'll never get back while being on hold and trying to set up the case with a guy who sounded like he was standing in the bottom of a sewer in Western Samoa. When he was asking me about the credit card details I actually wondered if he had seen a credit card in his life........
As I'm typing, I'm 46 minutes into the actual call. To be fair to MS I got a call back within 20 minutes and my representative (Kumar, whose email footer proclaims he is in the US . . .yeah right!!) is chewing through the DCPromoUI logfile. So far, the best has has come up with is that the password for the domain account I'm using to do the migration doesn't meet the complexity requirements for SBS 2011 . . . I mean really, if such a thing is going to be an issue then it should have error trapping. It's a 12 character alphanumeric password, just DOESN'T HAVE A CAPITAL LETTER IN IT.....GRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
Update on this one, migration installation 5 did in fact complete successfully using a new administrative account. I do have respect for Microsoft PSS as if you get a good agent then the chances are you'll get the issue resolved fairly swiftly. However - WTF Microsoft, surely the whole premise of migrating from a previous iteration of a product is that it might contain weaker security than the target product. Allowances should be made for this. At least trap the error intelligently at the point of running the migration tool - it inserts the password into the XML file in plain text for god's sake - wouldn't take a genius to analyse the complexity requirements before allowing submission from the source preparation tool.
I'll post the dcpromoui.log later so those affected can hopefully find their way here. Finally, 3 days after the initial attempt, I can now get the migration under way!!
- Posted using BlogPress from my iPad
Location:Carlisle Pl,London,United Kingdom
No comments:
Post a Comment