Answering PPFX question posted on 2/1/2011 2:41 PM - In regards to an in-place upgrade from SBS 2003 to SBS 2008, this is impossible as SBS 2003 is 32 bit OS, and SBS 2008 is 64 bit OS.

I don't find any documentation on how to upgrade SBS 2003 to 2008... (On same server)

I am in the middle of migrating a SBS2003 server to SBS2008 - using the official SBS2008 blog

No issues - except I could not see the new EX2007 Admin groups on old server using the EX2003 Adminisrator program

I found a soln by searching another MS newsgroup - but it should be submitted to the official SBS blog (keys to success or troubleshooting tips) - because Im sure others are seeing the same thing.

Does anyone know how to contact someone to add content to the blog? - this information should be added.


here is the soln:

Go to Start - Programs - Support Tools - Tools and launch ADSI Edit.
- In the left side pane expand the Configuration container.
- Next expand CN=Configuration
- Then CN=Services
- CN=Microsoft Exchange
- CN=" "your organization name here&;;gt;
- CN=Administrative Groups
- CN=First Administrative Group
- CN=Servers
- CN=Protocols
- CN=HTTP
- CN=1
- Right Click on CN=Exadmin and choose Properties.
- In the Properties dialog box observed that msExchSecureBindings was set to 443
- Removed the entry 443 from msExchSecureBindings
- Close out of ADSI Edit,
- Restarted IISadmin service.

I install SBS in my office... far away from the existing server and a full week before I deliver.

Now what? (I require of myself that I break any breakable hardware BEFORE the customer gets it.)

Plus, I don't want all the "Domain Junk" that has built up over the years.
Faulty policies, etc.

I want a clean, fresh domain. With 7 users, this is not a problem.

3. If you have renamed your Administrator account via Group Policy you need to disable that setting and reboot so that the default Administrator account is indeed Administrator - Sharepoint and WSUS depend on this and will fail to set up, failing the entire setup in the process.

I have run several migrations since SBS2008 was first released almost 2 years ago. Yes, there are some issues, but for the most part, I have been able to get my client's sites going in the first run. One of my concerns is the lack of a DR plan, except to restore from backup. As such, I would recommend that people look at the third party methods such as sbsmigration.com. The swing migration still uses the MS method, but does other things to ensure that you have a decent DR plan, in case you need to roll back and start again.

WFDick, I would be interested to know what the ten minor issues you mentioned are, and where these are documented.

I'm proof that a Microsoft migration method works. For those that are looking for third party solutions or guidance check out www.sbsmigration.com as an additional migration resource.

Please go to the SBS forum at www.sbsforum.info to get migration help.

The Guide is good--but essentially incomplete in a few VERY important aspects.
0. CTRL-ALT-DEL will bring up the task manager. New tasks can then be started. 'Control' will start the control panel. 'cmd' and 'explorer' are also handy. Any executable you can get to with explorer can also be attempted to run. Internet Explorer can be run in this fashion--as can a number of driver install programs. SBSsetup log and also be viewed. This is invaluable to know.

1. DCOM must be properly configured on the source server, as per
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/SBS_Small_Business_Server/Q_25087329.html

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.

If it is not, the destination server will whine that the Migration Wizard has not been run--and you may do a bunch of fruitless Wizard/Reboot iterations till you discover that

2. The changes requested to the network configuration pre-migration are EVIL and need to be dealt with in much greater detail.
My SBS setup is multi-site. Disabling RRAS will trash any static routes--these need to be documented and re-created manually. Forewarned is forearmed.
Multi-site also means multi-homed--and possibly the source server may have more than one DNS entry.

THE FQDN OF THE SOURCE SERVER MUST RESOLVE TO ONLY ONE AND ONLY ONE ADDRESS, ON A CLASS 'C' SUBNET SHARED BY THE SOURCE AND DESTINATION SERVERS.
If it does not, DCPROMO will fail--and you will be required to reformat the destination server. Which can be very time consuming. You may also be required to restore the system state of the source server (fortunately I did not) which may introduce other possible problems that may need registry hacks.

3. Multi-site AD replication MUST be tested BEFORE migrating and AFTER reconfiguring the source server's network. The migration process will attempt to replicate the AD--failure results in VERY long delays and eventually a message asking whether or not to ignore the failure. CTRL-ALT-DEL | task manager | new task| control | administrative tools | AD Sites and Services can be accessed to determine if replication can be forced on the destination server. Replication can be tested on the source server during the migration. Issues can be sorted out and allow the migration to continue.

Given that multi-homed SBS boxes were the desired configuration, why does the migration REQUIRE trashing the existing routing setup, instead of migrating it?

WFDick I agree with you 100%. I have been waiting to take my clients to Windows SBS 2008... I have been waiting for the migration process to smooth out. I have lost faith in MS. MS has blinders on and only looks one direction (forward). I am not even sure MS knows what the word backward compatibility means. Microsoft has no interest in making the technical installers life easier by providing a migration tool that work. Shame on them.

I will go the safe way.

As the tech support representative for my major hardware vendor told me when I called for advice prior to starting the migration, "Don't even attempt the migration. It is a waste of time. You will spend hours and you will end up starting all over again and doing it manually." Well, he was wrong about one thing. I won't be migrating manually because I don't put software I know to be dangerously buggy on my clients' computers. A professional with 27 years of experience, I have installed every previous version of SBS several times. I have migrated many, many times with previous versions. Convinced that someone with my experience could avoid the pitfalls, I followed every step of the migration guide religiously. I read the "Keys to Success" prior to starting. I practically memorized "SBS Issues We Would Like to See Less Of". I practiced the migration on lab servers. The result of all that work was that ten "minor issues" were listed at the end of the migration. Unfortunately, the solution for one of those "minor" issues was "Microsoft is aware of this issue and is working on it." The only solution to the problem, according to every Internet source I could find, including Microsoft, was to restore the source server and start all over again. Why would I do that? Why would I waste another day only to end up right back in the same spot? Thank you but no thank you. Microsoft has had its problems over the years and I have listened as people bad-mouthed them mercilessly. I saw the problems but always had faith that Microsoft would never put something truly dangerous on the market. That faith is gone. Without a system state backup, my client would have had a 21-day ticking time bomb for a server this Monday morning. Sure, Microsoft warned me that I needed a backup - but they put that same warning on absolutely everything. Well, if you decide to play with SBS 2008 dynamite, you had better believe them this time: make a backup. Better yet, don't buy it.

One tech writer recently did an SBS 2003 to SBS 2008 migration using a virtualized SBS 2003 server as the source server. This method has two primary advantages over a non-virtualized approach.

1. The physical SBS 2003 server is untouched and remains ready to go online if you need to restore to a pre-migration state. A tested and easy fall back solution.
2. You can retain the pre-migration SBS 2003 virtual image so repurposing the physical SBS 2003 server can be done eariler and with the assurance of no data loss.

For an overview of the process, see:

http://social.technet.microsoft.com/wiki/contents/articles/consider-a-virtual-sbs-2003-to-sbs-2008-migration.aspx

Hello, I have a problem with migration SBS 2003 to SBS 2008 Czech English, a problem arises when you use the migration tool. Where to update to extend the use of SBS server for 21 days will give an error. It can not migrate from Czech to English? Thanks so much for the information
Patrick Mika

Thank you for your help