SBS 2003 with a full 2003 server

[DougP]

We acquired a Windows 2003 Standard Server when we closed one of our offices.
Our Office is using an SBS 2003 with exchange.
Our SBS 2003 Server has problems and needs to be reformatted, Wizards don’t work etc. It’s also running Exchange 2003 for our email.
I know with earlier versions of SBS it had to the PDC.
We are also moving into another facility, and thought about setting up the Standard 2003 server as the main server. Reformat the SBS and bring it up with Exchange.
Can both servers work Ok together or is the SBS wanting to be the main server.
Any thoughts?


DougP

 

[gavm99]

You can have another DC on the same domain but the SBS Server must have all of the AD Roles (FSMO).

Thanks.

----------------------------------------
"Nobody cares how it works, as long as it works

 

[ShackDaddy]

You might consider backing up the Exchange store very well and then rebuilding the SBS box with the same domain/org names and restoring the Exchange database. That way you could start fresh and just use the wizards to set it up, the way it's built to be set up, and you could also join the other server to the domain and make it a DC if you want. That way you wouldn't have to pay anything for licensing Exchange and W2003 in a non-SBS environment like you'd have to do if you got rid of SBS and still wanted Exchange.

You could actually use a technique called "swing migration" to get your AD copied to your other server before rebuilding the SBS box. There's some great documentation for the entire process, including support, at swingmigration.com. I'd go that route, since you'll get the most bang for your buck and end up with a healthy SBS/Exchange box.

Dave Shackelford
Shackelford Consulting

 

[58sniper]

You're asking about many different options. As ShackDaddy mentions, you could rebuild the box. You could do a swing migration to the other box using

http://www.swingmigration.com/

You could do a transition pack and then move everything over to the other box, clean up the original, and move selected components back.

Lots of options.

Pat Richard
Microsoft Exchange MVP
Contributing author The Complete Reference: Microsoft Exchange Server 2007

 

[rpaverd]

SBS2003 has to be the domain root.

Depending on the number of users and complexity, it is sometimes easier just to wipe out the SBS2003 environmet totally and reinstall from fresh.

ONLY viable if you have relatively few users -Less than 15 or so is probably managable - no special security groups and/or databases.

Back up individual email mailboxes to .pst files on local drives on the PCs.

Perform a full backup of the server.

Wipe the server disks clean (sometimes even a format is not enough!)

Reinstall SBS2003, and service packs etc.
Restore data folders
Add users and computers
Rejoin computers to the domain
Users log on to the new domain and retore their .pst files to Outlook mailboxes.
Restore Users Shared Data folder data back to each individual user

And then you have a brand new fully-functional SBS2003 environment. Wipe the Server 2003 server, reinstall, join it to the domain and use as a terminal service server if you wish...

It is tedious, but it works!

 

[netometer]

Hi,

I have done a similar migartion and here is a plan that I would suggest:

1. Evaluate the current situation – check Active Directory health with DCDIAG, NETDIAG in verbose mode, SYSVOL status, Examine the event logs, check DNS zone (do you have the correct name servers, forwardes – if you are using such, DNS server listening on the wrong interfaces, bindings and IP settings etc).
2. Correct the problems (as much as it is possible).
3. Promote the existing Windows Server 2003 as a DC. Be careful – if the member server is R2 you will need to run adprep on the SBS server to extend the schema (you have to use the 32 bit media disk as SBS 2003 is 32 bit OS). Replicate, check the result of the replication, make it a GC, restart (you need to restart for the GC to become active as you are running Exchange in your network), wait for events 1119 and 1869 (this means that the new server is really a GC). Alternatively you can use LDP to query the new server and check whether it is advertising itself as a GC. The reason I am so through about the GC is that if you loose your GC you loose your domain.
4. Perform a cold backup of the Exchange DataBases (mdbdata folder).
5. (Optional)Install DNS server on the new DC.

At this point if the existing SBS dies:
1. You haven’t lost your domain (you can seize the FSMO roles in a minute with NTDSutil)
2. You haven’t lost your Exchange org – you can reinstall Exchange and forklift the databases
You can have two SBS servers in a domain for as long as 7 days (after that they will start rebooting hourly)
The next phase is to install the new SBS server in the same domain.
1. Stop the SBS installation after the OS installation part finishes and manually DCPROMO the server as an additional DC to an existing domain.
2. Replicate and check the status of the replication. Make it a GC, restart etc. (as I’ve said before).
3. Move the FSMO roles
4. Replicate, check the replication status, run “NETDOM QUERY FSMO” and confirm that every DC sees the new FSMO master correctly.
5. Move DNS, WINS and DHCP services and their databases to the new server .
6.
7. Point all machines to the new server as a DNS and WINS. Change the DHCP server options (to provide the new server as a DNS and WINS server).
8. Do not forget – you have 7 days to demote the old SBS server.
9. Proceed with the SBS installation – it will detect the existing Exchange 2003 Org and install the new Exchange server in it.
10. Move mailboxes, switch the Exchange org to native mode, change the routing master, rehome public folders and RUS, set the new server as the server used for OAL generation.
At this point mailboxes are moved and you have to wait for everybody to login, open outlook and get redirected to the new server which holds their mailboxes (this automatically modifies the users Outlook profiles). The old server is still the bridgehead server (incoming and outgoing e-mail is flowing through it).
Next phase:
1. Install antivirus and antispam software on the new server (if you are using such)
2. Move the SSL certificate (if you are using a public one for OWA) to the new server.
3. Reconfigure the routing connector to include the new server and change the firewall to point to the new server.
4. Remove the old SBS from the routing connector and stop Exchange services on it for a day (couple of days).
5. Uninstall Exchange from the old server
6. Demote the old SBS server

At this point there is no time pressure on you. The old SBS is not a DC anymore and the 7 days restriction is gone.
Next phase:
1. Uninstall DNS from the old SBS server and remove manually its name from the list with name servers for the domain.
2. Manually delete the old SBS from AD Site and Services - first confirm that there are no child objects under it before you do this. If there are child objects you can wait for the KCC to recalculate the new configuration or force it by running “repadmin /kcc yournewSBS”
3. Robocopy file shares to the new server.
4. If you are using Sharepoint services backup, and restore them to the new server.
5. Remove the old SBS server from the domain.

Most people fail:
1. Detecting that there are currently problems with AD which prevent the process of successfully adding a new DC and replicating AD and the SYSVOL to it.
2. Configuring correctly the new DC as a GC - not rebooting or not waiting for successful replication and events 1119, 1869.
3. Moving the FSMO roles – you have to check the result of the move.
4. Wrong DNS configuration – DNS servers listening to the wrong interface, wrong bindings, wrong (non existent name servers or forwarders) etc.

Regards,

Dean

http://www.netometer.com

Online Screencasts and Video-Tutorials