asked on

SBS 2008 Migration from SBS 2003

Chaps/Chapettes,

I am trying to migrate an existing SBS2003 std server to a new box with SBS2008 std using the windows sbs 2008 migration tool.

I have the old server prep'd and have installed the new server with the generated answerfile.

When it gets to the migration stage it fails and says the server was not prep'd properly. I have check the SBSSetup.log file and it fails on something that looks like SQL or similar. Only thing is I had a copy of MSDE on the old server, but it was removed prior to the migration attempt.

Anybody have any ideas? All comments appreciated.

SBSSetup.log attached - I have cropped this from just before the error. Up to this point everything has passed including schema.

[3740] 100126.160843.8131: Setup: Running requirement check: SourceWMICheck
[3740] 100126.160843.8131: Setup: 	Requirement passed.
[3740] 100126.160843.8131: Setup: Running requirement check: SbsSp1Check
[3740] 100126.160843.8131: Setup: 	Requirement passed.
[3740] 100126.160843.8131: Setup: Running requirement check: SourceChkRequirement
[3740] 100126.160844.4371: Setup: Caught exception: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   at System.Management.ManagementScope.InitializeGuts(Object o)
   at System.Management.ManagementScope.Initialize()
   at System.Management.ManagementObject.Initialize(Boolean getObject)
   at System.Management.ManagementObject.GetMethodParameters(String methodName, ManagementBaseObject& inParameters, IWbemClassObjectFreeThreaded& inParametersClass, IWbemClassObjectFreeThreaded& outParametersClass)
   at System.Management.ManagementObject.GetMethodParameters(String methodName)
   at Microsoft.WindowsServerSolutions.Setup.SBSSetup.RegistrykeyCheck.DoCheck(SourceServerType sourceType, String domainName, String sourceServerName, String userName, String password)
   at Microsoft.WindowsServerSolutions.Setup.SBSSetup.CompositeRequirement.DoCheck(SourceServerType sourceType, String domainName, String sourceServerName, String userName, String password)
   at Microsoft.WindowsServerSolutions.Setup.SBSSetup.MigrationRequirement.CheckRequirement(SourceServerType sourceType, String domainName, String sourceServerName, String userName, String password)
[3740] 100126.160844.4371: Setup: 	Error - Run the Migration Preparation Tool on the Source Server - Has Help
[2212] 100126.160844.4995: Setup: Failure: Error - Run the Migration Preparation Tool on the Source Server - Has Help

Open in new window

Philip Elder

Firstly, our migration guide:
http://blog.mpecsinc.ca/2009/06/sbs-2003-to-sbs-2008-migration-guide.html

Did you run the SBS Best Practices Analyzer on SBS 2003? Check the logs for an AD Journal Wrap error.

Run the health tests listed in the above guide to verify that things are good.

Philip

tom_napier1

ASKER

Hi Philip,

I thanks for the response. There was indeed a AD Journal Wrap issue. I have now resolved this, however the migration fails with the same error.

Seems like its something else that its tripping up on.

Does anyone know what the 'SourceChkRequirement' stage of the migration test relates to?

Philip Elder

Is your AD set to 2003 Native for forest and domain?

Philip

tom_napier1

ASKER

Hi Philip,

Yes, all confirmed as native 2003 at forest and domain. Also exchange is in native mode.

All AD checks following your website links also pass.

Philip Elder

Is WSUS off on SBS 2003 before starting the SBS 08 install?

So, service pack 2 for Windows Server 2003 plus Service Pack 1 for SBS (two different things) are installed?

Philip

tom_napier1

ASKER

Yes thats correct SP1 for SBS is installed, and SP2 for windows 2003 is also installed. confirmed via registry entires and the health check tool.

WSUS is off on the source server also (before the install began).

Philip Elder

What version of the SBS 2008 OS are you installing? RTM or media with Windows Server 2008 SP2 installed? You can tell by the source tool whether it is an .EXE or .MSI. MSI is SP2 version.

Philip

tom_napier1

ASKER

MSI, which i took straight from the install media so they are the latest version and the same as each other.

Compendic

FYI, I am following this thread with interest, as I have exactly the same problem with a migration I am attempting.
For whatever it's worth, I note from another thread here that at least one of the things SBS 2008 setup does under the heading "SourceChkRequirement" is to attempt to access two values under the key HKLM\SOFTWARE\Microsoft\SmallBusinessServer\Migration from the source server. I dont' know if this is what's yielding the Access Denied error, but I can tell you that I ran regedit on the destination server, connected to the registry on the source server using the credentials I supplied in my answer file, and was able to successfully read this information. So that's not it.
Also, in my case, my log also shows a failure to obtain the "OS version" from my source server, also due to an Access Denied error (see attachment).
I have posed this question to Microsoft as well; if I find anything out, I will report back here.

[1896] 100128.225010.7415: Setup: Getting OS version for SERVER
[1896] 100128.225011.6931: Setup: Caught exception when getting source OS Version: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
   at System.Management.ThreadDispatch.Start()
   at System.Management.ManagementScope.Initialize()
   at System.Management.ManagementObjectSearcher.Initialize()
   at System.Management.ManagementObjectSearcher.Get()
   at Microsoft.WindowsServerSolutions.Setup.SBSSetup.SchemaUpdatePagePresenter.PopulateSourceServerOS(String sourceServer, String username, String password)
[1896] 100128.225011.7087: Setup: Setting source OS to Other

Open in new window

Compendic

Hey! Turns out my "OS Version" problem was significant after all, at least in my case. Doing further research on that yielded the suggestion that it happened because DCOM was turned off on the source server. And sure enough, it was. Once I turned it on (and rebooted the source server), both the OS Version and SourceChkRequirement problems went away!
I"d therefore suggest you attempt this (same) solution:

On the source server, Click Start / Run and type DCOMCNFG.EXE and hit ENTER.
In the right-hand pane, double-click Component Services, then Computers.
In the right-hand pane, right click on My Computer and select Properties
Click the Default Properties tab
Click to check the box: "Enable distributed COM on this computer".
Click OK.
Reboot the source server

The server will now come up with DCOM enabled, and will allow the destination server to obtain the information it needs without producing the message about needing to run the prep tool.
Or at least, it did on mine.

ASKER CERTIFIED SOLUTION

tom_napier1

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Compendic

Looks like we both have solved our problems, Tom. Just one comment for anyone reading this later -- in Micosoft's published DCOM solution, they fail to mention that you must reboot the source server the the DCOM changes to take effect. This is extremely important, as without the reboot, there is no change. There may be some combinations of service restarts that could also achieve this, but if there are, I couldn't find them.

tom_napier1

ASKER

yes good point.

Also Microsoft suggest running msconfig on the source server prior to the migration and stopping ALL non-microsoft services, then rebooting.

Kind of takes the 'live' out of 'live migration' doing all this uninstalling, disabling and rebooting!