Solved

will reloaded sbs 2003 with the same name cause problems when re-joining workstations?

Posted on 2011-02-25
11
280 Views
Last Modified: 2012-05-11
We are installing a new server at a client site, we are currently running sbs 2003 and we are going to be running the same software on the new server.

We are NOT using a system state restore because we are moving to new hardware - and although I know this is doable, it is a small network and we are happy to do a fresh load.

The only query I have is the following:

I want to keep the same internal domain name and the same server name to make everything run as smoothly as possible, I understand that despite leaving these details teh same, we will still ahve to log all of the workstations off and back on to the domain, but I am just wondering if anyone has done this with sbs in the past and whether it is likely to cause any problems - only because I have a voice in the back of my head thats telling me it may cause problems...???

Thanks
0
Comment
Question by:davids355
  • 4
  • 3
  • 3
  • +1
11 Comments
 
LVL 4

Expert Comment

by:szichen
Comment Utility
Hi David

Is this a domain controller you are replacing?
0
 

Author Comment

by:davids355
Comment Utility
yes it is domain controller, we have ad,dns,dhcp and exchange running - planning to backup data, backup email with exmerge, log clients OFF domain, reload sbs on new hardware, restore data and mail via exmerge then join all workstations back to the domain
0
 
LVL 4

Expert Comment

by:szichen
Comment Utility
with domain controllers, you simply cannot backup and then reload a machine with the same name and expect everythin got be ok and even restoring from backup will give you a headache as I have experienced. even though the network is small, i would still exercise caution.

i suggest using a trial version of either acronis or shadow protect, backup the intended system and test restore to the new server and see how it goes. use acronis universal restore for different hardware. or if the server comes with its own migration software (like most HP servers) then this could also work.

(if you gonna do this below option, ensure you have a backup image of the dc)
Otherwise safest way to do this is to load a separate machine, do a 'dcpromo' and transfer all fsmo roles to the new dc server. make the new dc the PDC and main DNS server. also load dhcp and export DHCP scope configuration on the current dhcp and import to new dhcp server. stop all dns and dhcp services on old dc. check and confirm that everything is functioning as normal like email flow, dhcp address leasing, dns, etc. Then create another backup image of the old dc and take the old dc offline and restore the image to the new server. bring the new server online once all drivers are loaded.
test again to make sure that everything is working before transferring all fsmo roles back to the new server and eventually demoting the temporary dc.

you can find a lot of articles on additional DC's and fsmo roles online.
0
 
LVL 4

Expert Comment

by:ChiefTechGuru
Comment Utility
It will cause problems.  You will have to re-add all your workstations to the new SBS server.  You CAN run the command NETDOM from each of the workstations to join the new domain, but you are likely going to still be missing other configuration items that you would normally get when setting up a workstation to SBS.  As previous poster mentioned, you can get Acronis or Shadow Protect, but another option is using the Swing It! toolkit from Jeff Middleton at www.sbsmigration.com.  Jeff's done all the work figuring out how to properly migrate SBS in multiple scenarios, including yours.  Good luck.
0
 

Author Comment

by:davids355
Comment Utility
I have done FSMO role transfer before - it was really hard, I have also successfully used acronis with universal restore - this worked very well, and I have also installed sbs, then restored from system state to new hardware then done a repair on the operating system, which ahs also worked.

However, in this scenario it is a small network (as I said) of 5 client machines, the server setup itself has grown alot and got slightly out of hand so I am actually keen to start it from scratch in terms of AD users, email accounts etc.

However, if its likely to be problematic I dont want to do it this way, obviously, BUT can I just clarify exactly what I plan to do:

I have the old server set up and working, I am going to copy all user data to a new drive, I am going to copy all email data via exmerge to a new drive.

I am going to then take the old server offline - and keep it exactly as it is, in case of any issues.

I am then going to reload sbs on the new server, from scratch, I am going to set up AD, Exchange and re-create ALL user accounts and email settings exactly as they were on the old server - Im doing all of this off site.

I'm then planning to log all workstations OFF the old domain and back on to a workgroup.

Then I am going to install the new server on-site, and log the workstations on (as if for the first time).

I have done this on many occasions for small networks, but I have always used a slightly different (local) domain name and server name on the new server.

So basically all Im asking is, from the workstation point of view, if it is going from workgroup to domain, but the domain has the same name as the "old" domain/server that it was previously connected to, will this cause an issue?
Primarily Im thinking that for one thing, the local profile it tries to create gfor the domain user, would already exist, so maybe renaming that old user profile to something else would avoid that problem?

Bare in mind Im not doing it this way to try and bring any configuration accross from old server to new.
0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 4

Expert Comment

by:ChiefTechGuru
Comment Utility
Not trying to sell you on anything (nor am I profiting in any way), but the Swing It! kit walks you through all the steps you've already mentioned, plus other 'gotchas' involved with migrating from one physical server to another.  As part of the swing migration, you'll be migrating only clean data (e.g. AD info).  You'll also be able to keep your existing server online while migrating, only turning off when done with new server.  NOTHING will need to be done on workstations.
0
 

Author Comment

by:davids355
Comment Utility
Would have tried it but too short notice -reload going ahead tomorrow - I'll post here after to let people know how I get on, and for the record, I will definately try that kit on the next install, it sounds like it could be usefull.

Thanks for the help, il work out how to award points tomorrow.
0
 
LVL 4

Accepted Solution

by:
ChiefTechGuru earned 200 total points
Comment Utility
Good luck.  Looks like you have most of the bases covered.  Regarding renaming profiles on workstations, I'm fairly certain the workstation will detect that it's on a different domain (even with same name), and will create new profile.
0
 
LVL 56

Assisted Solution

by:Cliff Galiher
Cliff Galiher earned 100 total points
Comment Utility
If you haven't started yet, I'd encourage you to look at performing what is called a "swing" migration. This will allow you to swing your SBS installation to new hardware, keeping intact your server name, domain name, all file permissions, etc, basically accomplishing exactly what you want without introducing the risk or complicatoin that you are currently considering.

The techniques in a swing kit were written for SBSers, but are actually features built into AD and could apply to any sized topology. It is common in SBS environments though that SBS is the only DC so the documentation was written to help single DC environments easily and safely migrate to new hardware (and new SBS versions if desired) while maintaining their naming infrastructure.

www.sbsmigration.com    ...you won't regret taking a half-day to look it over before making a final decision and pulling the trigger.

-Cliff
0
 
LVL 4

Assisted Solution

by:szichen
szichen earned 200 total points
Comment Utility
New profiles will be created when you rejoin machines on the newly created domain.

If it is only a small network and you are happy to go with the way you want to, then I wouldn't say no to that. Although i am certain that your method will take longer then the other posts above.
0
 

Author Comment

by:davids355
Comment Utility
Hi guys sorry I left this open -been so busy at work havnt had a chance to get on here.

Firstly thanks for all your help - it did clear a few things up.

Ok, in the end I. Stuck with my plan ( based on your advise and time constraints), and I went ahead and disconnected and re-joined everything.

Here's the steps I took (might interest some people):

1. Two days before the install I went on site and made extensive notes of every detail of the setup - all shares, data sizes, ip ranges, user logins, email accounts - there were loads because the company runs about 15 domains!
I then made sure all user data was server-side - just so I knew everything was in one place.
Then I done a backup of exchange using exmerge - I have a bat file that backs up and gzips all email in 3monthly increments - I left this running all night, then I scheduled nightly exmerge backups for the next two nights -now I knew all the email was ready to export.

The day before The upgrade we loaded the new hardware with Sbs - we set this up of site on a simulated LAN - so we could set up the ip space, install dc roles etc.

On the morning of the upgrade we took the new kit to site, slaves up the current servers drive to the new server and set the data (including exmerge backups) transferring on to the new server. - this was the first point of failure as I had planned to transfer this data to a second drive the night before -ready to slot into the new server - this would have saved a few hours on the day.

As it was, whist the data was transferring, I logged all the clients (5) off of the domain, added some more ram, installed any necessary updates (windows, flash, java etc) and set the machines to defray, then I went out for breakfast.

I came back once the data had Transfered, connected the new server to the network, set up all the data shares, set up the primary users and then logged everyone back on to the domain - mapped drives, setup email on the clients then I had to create all the users for each additional domain - for send as purposes, this took ages, finally I set exmerge to restoring all the email.

This was done using the same server name same domain name etc.
It took about 4 hours planning, 2 hours to load the server and a fill day installation on site (8-4) as well as a bit of work in the evening making sure exmerge had transferred all the email correctly.

The only mistakes I made were not having a hard drive peeped to transfer data to remotely, and the fact that I ran exmerge two days prior to install which meant some emails that had been moved around the day after were reverted back to their original locations!!

Other than that it went pretty well.

I think I will try a swing migration kit next time and if possible il report back here with the results.
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

I work for a company that primarily works with small businesses as their outsourced IT vendor. As such the majority of these customers utilize some version of Small Business Server. Due to the economics of running a small business, many of these cus…
Disabling the Directory Sync Service Account in Office 365 will stop directory synchronization from working.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now