Server Operating Systems:

At this time, I see little reason to upgrade to Windows 2008. For what most servers do, Windows 2003 does the job just fine, and is still being supported (with hot-fixes, but not Service Packs) by Microsoft. The software you run on it likes 2003 just fine. Before long, new hardware will be built with Windows 2008 in mind, and Windows 2003 drivers for your hardware might get harder to find. However, I recommend moving to virtual servers at that time, and it will then not be necessary to have Windows drivers for your new server. The virtualization layer (hypervisor) will handle that, and the “virtual hardware” assigned to your server will work fine with Windows 2003 for many years to come.

Exchange 2007? Let’s just not talk about that right now. This is an OS discussion, and I will just say that I intend to resist that one as long as possible too, until Microsoft remembers that if we wanted to manage everything with command lines and scripts, we’d be using Linux with Sendmail or some open-source, command-line driven equivalent.

Terminal Servers, however, could benefit from a Windows 2008 upgrade. Terminal Services (now called Remote Desktop Services) functions have been greatly improved in 2008, specifically in the area of publishing applications seamlessly without giving the users access to the entire desktop – and in the area of remote printing. Remote printing has been a major thorn in your side, and Windows 2008 can help you with that. I believe the new Terminal Services is web-accessible, making it very easy to set up new workstations to use it.

Here is another, more detailed discussion of those improvements.

Is it worth the cost to upgrade? Your customer will have to decide.
Workstation Operating Systems:

I am happy to say that most of my customers have managed to skip right over Windows Vista.

I have not had much experience yet with Windows 7, but my limited experience suggests that Microsoft learned a lot from their Vista flop, and worked to smooth out the rough edges that made people despise Vista. My limited experience also suggests that Windows 7 is still too new for widespread adoption, with pitfalls lurking due to software applications and drivers not being fully compatible with Windows 7 yet.

That being said, we are entering a more sophisticated age of malware and viruses, and it may be time to leave behind the less intrusive security measures we have been enjoying with Windows XP, which is now allowing more and more PCs to become infected – just as it happened with Windows 2000. It will be a rocky time, when we try to balance having appropriate access to our own computers against making them wide open to attacks. Some software will work OK when installed with an administrative account and then used by someone else. Some will not. We’ll have to work out which software requires which installation method, and perhaps sometimes temporarily give a user administrative access to their machine to get something installed and configured, then take it away to help protect them. We can do this with Windows XP for now, and then later with Windows 7.

For the time being, I will recommend that my customers continue to purchase workstations that come with Windows 7 licenses, but have a downgrade to XP installed on them. This will continue for as long as possible, until we start seeing the rate of virus infection become too high, or other factors necessitate a change. The age-old cycle of viruses and antivirus software one-upping each other continues, and maybe we’ll see a comeback of the antivirus software.

For now, Dell is offering workstations with Windows 7 licenses, with Windows XP installed – but only in the Business section.

So, am I just being resistant to change? There is some of that, but I do not embrace change for its own sake. there has to be some benefit, other than the many hours of billable work I could get from pushing customers into unfamilair operating systems just because Microsoft wants to keep their money machine rolling. Let me just say that I was determined to be open-minded abot Vista. I gave it a solid try. When asked whether I wanted Vista or XP on my company-supplied laptop, I chose Vista. I suffered it for 6 months, before finally deciding that enough was enough. I had passed the learning curve and the pain continued. I went back to XP. So no, it is not just resistance to change. There are good reasons for me to hold back. They are related to deficiencies of the new OSes, financial reasons, and the general difficulty of being among the first to move to new technology.

Unless there are specific, compelling benefits to be gained in each scenario, then you won’t see me jumping first to new versions of the OS. Not me, not this time.

Tags: remote Desktop Services, Terminal Services, Virtualization, Windows 2003, Windows 2008, Windows 7, Windows Vista, Windows XP

 

 

There are some cool things about the new version:

 

1.    Supports 64-bit Windows 2008/Vista.

 

2.    No longer requires licensed version to convert a physical source to an ESXi VM from a management station without installing Converter on the source machine (still installs agent of course).

 

3.    Has options for telling individual services to stop/start or change startup state. This will be VERY helpful for converting a machine and settings services which are known to cause problems to “Disabled” on the target VM, without changing the source machine. Then we can boot the VM, fix stuff, and do what we want with those services. Very handy.

 

4.    Synchronize source and destination. This will synchronize changes that happen to the source machine during the cloning process.

 

5.    Power off source machine after cloning (not sure if this is new, but it’s cool).

 

6.    Status window now includes transfer rate as well as percentage and estimated running time.

  

 

I am currently running a conversion of an SBS2008 VM from Hyper-V to ESXi. Both hosts are Quad-Core white-boxes with SATA ICH8 controllers on a gigabit network with a high quality HP switch. I’m getting about 10.8 MB/s. Not great, but at least it tells me how it is doing.

 

VMware Converter 4 Download link (requires login)

 

 

 

 

 

Tags: Converter, P2V, VMware

I am a network consultant. I specialize in migration projects such as upgrading NT4 to Windows 2003/2008, migrating from Exchange 5.5 to 2003/2007, retiring domain controllers and promoting new ones, etc.   I also do my fair share of emptying temp folders, removing malware, and fiddling with backup systems. I tell you this so you will understand that the idea of performing migration projects and reconfiguring networks does not intimidate me. However, I also know that there are always more details and time-sinks involved in such an endeavor than you remember.

Not long ago, my business was running on an HP Proliant DL380 server with Small Business Server 2003 on it. My server was running fine. It was not a brand new server, but was not showing any signs of instability or failure either. I had spare hard disks available, ready to hot-swap, and I had reliable backups.

When I became familiar with virtualization, the idea of virtualizing my server entered my head and percolated there for a while. Virtualization is cool, I thought, but my current server is working fine. Why go to the trouble?

Then I advanced my thinking a couple of years ahead. Then my server would be long since out of warranty, parts would be difficult to find, and I might find myself at the mercy of used hard disk resellers on eBay. Worse than that, if I had to replace a motherboard or hard disk controller, I might find that my server was not so happy with that idea.

Backup software has been claiming for some time now to be able to do “bare metal”, “hardware-independent” restore operations - but if you’ve ever tried one of those, you find out quickly that if there aren’t lots of asterisks and disclaimers in those feature lists, there should be. It’s never as easy as they claim, and the more different the new hardware is, the less likely it is to succeed. If it does succeed, the result is usually somewhat slower, and prone to quirks for the rest of its life.

Then I thought about how a restore works for a virtualized server. The underlying hardware can be totally different, but the hypervisor presents the same hardware layer to the operating system of the VM - so in the event my server failed, I could load up the hypervisor on a completely new, different server (a much faster one), and restore without a hitch.

Failures aside, I also thought about what would happen if I wanted to continue using SBS2003 and do a planned migration from one server to another. I’d have to load up a fresh SBS2003 instance, use ADMT, or manually migrate my user accounts and workstations. Then I would need to install my LOB apps, and migrate databases, files, printers, etc. If I wasn’t using ADMT, or if for some reason ADMT failed on my workstations (you and I know how reliable ADMT is for workstation migration), I’d be manually migrating them. That’s always at least a full weekend worth of work, with another couple of weeks of minor adjustments - a little detail here, a missed setting there. That’s no fun.

With a virtual server, I’d just copy it from one server to the other and be done with it. Then I could spend the rest of my weekend with friends and family, riding my ATV in the woods.

Finally, I thought about upgrades of software on my server. The last upgrade of my accounting software was done with my heart in my throat. If it didn’t work, how well would my backups protect me? How much time and effort would I spend rolling back? The antivirus software upgrade was even more of a concern. You never know when that’s going to backfire on you, and what the cleanup will be like.

With a virtual server, I would simply take a snapshot before beginning the upgrade, and when I was satisfied that it was working properly, remove the snapshot. If it went sideways on me, I’d just revert to the snapshot. If there was changed data after the snapshot, that’s not too difficult to back up and restore to the server after reverting. I’d certainly rather do that than sweat it out trying to repair the damage.

In the end, I decided to go ahead with virtualizing my SBS2003 server. I’m glad I did, and I haven’t looked back.

Tags: Why Virtualize?

Just when you think you’ve really seen the last of NT4, a new client shows up, they have an NT4 domain, and they want to upgrade it. Crap, you think. You’ve tossed that old workstation that you knew was compatible with NT4 AND with 2003, and wouldn’t crash in the middle of the upgrade due to driver issues.

You generally don’t want to use one of the customer’s NT servers, because:

• The rollback plan is difficult and risky.
• Sometimes they only have one and that’s a big risk of losing everything during the upgrade.
• Most of the time their servers are full of software that makes them run slow and will probably cause errors during setup or not run properly afterward.

So the best thing is to provide a computer for the task, install NT4 on it as a BDC, promote it to PDC, upgrade it to W2K3, and then bring in the shiny new server they just bought as another W2K3 DC and move all of the FSMO roles over.
Maybe you still have that old SMC NIC with the 10bT RJ-45 plug and the coax BNC connector on it, if you can find it, and if it hasn’t been damaged, kicking around in the bottom of a drawer somewhere.

The problem is that hardware which NT4 can detect and load drivers for natively is almost completely extinct now, and searching for NT4 drivers for stuff is time-consuming and often futile.

Leaving your loaner workstation, and maybe your 2-port KVM switch onsite during the upgrade was always kind of a bummer anyway.

Well, my friends, there is a better way. You can skip all of this hardware difficulty by using a virtual machine. You can carry a DVD around with me containing ISO images for NT4, SP6, IE6sp1, Win2003, SP2, and VMware server on it. You can load this on any XP workstation at the client site during the upgrade, or maybe their new server. You can use VMware Server to host an NT4 BDC, promote it to PDC, and then upgrade that to Windows 2003.

I had only previously done this in a lab environment - but last week, I did it for real. The customer was a 10-user geographic data mapping company in a downtown Seattle skyscraper.

There are some tricks that you have to observe to make this work. The first time I tried this, in the lab, I was able to load up NT4 just fine, but when I tried the in-place upgrade to Windows 2003, it failed. I don’t remember the exact failure mode, but it just plain didn’t work - until I used Windows 2003 RTM instead of R2. For some reason R2 had issues with the VM, or the upgrade, or something, but RTM did not. You also want to have NT4 SP6a handy, for bringing your VM (and their server if necessary) up to speed.

 Here is the winning combination - make a VM with the following specs:

• OS: Windows NT
• SCSI Controller: LSI Logic (not really important but you have to choose one, so…) 
• Hard Disk: 8gb IDE (not SCSI!)
• Memory: 512mb or more. 

1. Start the VM and immediately go into the BIOS to set the time and change the boot order to HDD, then CD.
2. Attach an NT4 Server ISO or put an NT4 CD in the drive.
3. Format 4gb of that 8gb disk, and install Windows NT as a BDC. (NT4 picks up the VMware NIC during setup, so you can obtain an IP address and join the domain as a BDC)
4. Install NT4 SP6a_128, and (optionally) IE6 SP1.
5. Attach a Windows Server 2003 RTM (not R2!) ISO or put a CD in the drive and attach it to the VM.
6. Upgrade the OS and install Active Directory.
7. Allocate the remaining 4gb of disk space to another drive letter and move the swapfile over to it to free up some disk space on C.
8. Install SP2 for Windows 2003.
9. If your new 2003 server is R2, you’ll need to update your schema at this point, just like a normal upgrade.

Now you can add your new DC to the network and move your FSMO roles around.

Will this work with Windows 2008? I don’t know, I haven’t tried it yet. I doubt you can do an in-place upgrade from NT4 to 2008, but you can certainly do the in-place upgrade to 2003, extend its schema all of the way to 2008 levels, and then join up your new 2008 server.

 

Tags: Domain Upgrade, Migration, NT4 to 2003, VMware Server

 

First, let me just say it is excellent that Microsoft has changed their attitude toward SBS migration, and the SMB market is very appreciative of that. This is the first version of SBS that has an in-the-box, MS-supported migration path from a previous version of SBS. Big kudos to the SBS team for this.

 

After installing SBS2008 using the answer file for a migration, the SBS console contains a group of wizards and instructions. Some of the migration tasks are handled for you, and others are links to help files with instructions for performing migration tasks.

 

However, like any of Microsoft’s first efforts in a given direction, the going is a bit rough. Some of the manual migration tasks could have been done in a wizard, and others were omitted entirely.

 

If one were to follow this migration wizard strictly, and do no more than is listed, the customer would be left with a non-functional network (from their point of view). They would come in on Monday morning, log in, and their network drives would not map. Their printers would not function. Their web browser, if it opened to http://companyweb, would display no data. Their desktop shortcuts would not work.

 

While this wizard is certainly helpful, with lots of useful information, it falls short in actually guiding a consultant to a conclusion that would be called successful by any customer’s standards. If I followed this guide, and did nothing more, my customer would not pay the bill for this migration.

 

I have seen (and cleaned up) the aftermath of a project done this way. It is the sort of event that prompts a customer to start looking for a new IT company.

 

</soapbox>

 

Every network is a little different, and MS could not be expected to cover all eventualities – but there were a number of tasks I performed after the wizard that I would reasonably expect to perform during any migration.

 

Click here to skip down to the post-migration-wizard tasks that I performed.

 

What follows below is a list of steps I went through during this migration. First, I did a migration from a freshly built SBS 2003 to SBS 2008 in a test lab, and of course it went perfectly. Then I did a real migration in a production environment, and it was a far more interesting journey.

 

Preparation and Pre-Wizard Migration Steps:

 

A. Checked to ensure that I had a restorable backup.

 

B. Cleaned up unnecessary files taking up space.

 

C. Powered down my SBS2003 VM and resource server VM, took snapshots, and powered them back on.

 

D. Edited Autounattend.xml and inputted the proper settings for my environment (this is not necessary for an SBS 2008 migration, but since I already covered doing a fully unattended SBS 2008 load, I figured I’d include this bit).

 

E. Ran SBSAFG.exe to create an SBS answer file for this migration, and put it into a virtual floppy disk along with the autounattend.xml file.

 

F. Created a VM with 4 CPUs, 8GB RAM, C:60GB, D:125GB, virtual floppy with answer files, ISO file of the SBS DVD.

 

G. Set the SBS2008 VM to boot into BIOS on first boot.

 

H. Booted the SBS2008 VM and adjusted the time (it was 8 hours off) and boot sequence.

 

I. Rebooted the VM and it started setup.

 

Note: I experienced some issues with the disk sizing, either due to geometry issues, conversion math issues, or something. Anyway, the answer file specified that the disk size should be 61440 KiB. This should fit neatly into a 60GB container, but apparently does not. This is undoubtedly due to the difference between SI values and Binary values, and the confusion between them. See this web site for details.

 

Also, here is a handy calculator:

Anyway, I adjusted the answer file to use 60000 instead of 61440 and it’s all good.

 

J. Waited for the unattended installation to finish.

 

K. Received an error about the source server not meeting minimum requirements for migration.

 

Things missing:

· AD Schema needs to be extended to Windows 2008 level.

· Domain and forest functional levels need to be set to Windows 2003.

· Hotfix needs to be installed to extend time limit for multiple SBS servers in one domain.

 

Note: This is the “Point of no return” as it were. Obviously, it is possible to proceed past this point, stop, and still recover - but cleanup will be required, and possibly technical support from Microsoft.

 

L. Ran the Source tool on the source SBS server, which failed because I was running it as an account that did not have the required permissions. I ran it again successfully using the administrator account.

 

The source tool updated the schema, installed the hotfix to extend the multiple SBS server deadline, adjusted Exchange to allow migration, and required a reboot. I rebooted.

 

M. After the reboot, I upgraded the domain and forest functional levels to Windows 2003. This did not require a reboot.

 

N. Clicked the “Check Again” button on the SBS2008 server. It found that all of the issues were resolved, and continued forward. Note: During this phase, in addition to the schema changes above, the new SBS server appears in AD users and computers in the domain.

 

 

It should be noted here that during this phase, I ran into a serious road block that took me more than a few hours to resolve. The underlying issue and the solution are detailed in another blog entry.

 

The initial SBS wizard completed with errors. The error was “An update could not be applied”. I won’t lose any sleep over that one.

 

O. Added two partitions, one 12 GiB volume for the pagefile, and one 125 GiB volume for data. (You can choose your own preference here)

 

P. Adjusted the pagefile to be a system managed pagefile on the 12 GiB volume. (Again, your preference)

 

Started the Migration Tasks in the wizard provided by SBS:

 

On the Windows SBS Console, I clicked the Migration task, but it would not let me run it as the built-in administrator. It wants me to create an administrator user for the tasks. This is annoying because many of the tasks will require elevation, which means using the runas command to run them as the built-in administrator.

 

I created an administrative user using the SBS console, and during that process it failed to send a welcome e-mail to the new user using webmail. The error message is: “Service Discovery failed in looking up the CAS Server in the target AD Site.” I guess this has something to do with SSL certificates for the website. This problem solved itself later when I moved my certificate over.

 

A. Change Data Locations:

i) Change Exchange server data locations

(1) (Clicked OK to continue without backing up the server)

(2) Chose the location for the Exchange data and moved the databases.

ii) Change the Sharepoint Data location

(1) (Clicked OK to continue without backing up the server)

(2) Chose the location for the Sharepoint data and moved the database.

iii) Change the User data location

(1) (Clicked OK to continue without backing up the server)

(2) Chose the location for the user data.

iv) Change the users’ Redirected Documents location

(1) (Clicked OK to continue without backing up the server)

(2) Chose the new location for the redirected documents.

v) Change the Windows Update Repository data location

(1) I chose not to move this.

vi) Clicked Task Complete and Next

 

B. Configure the Network:

At this point, I was expecting to have to use netsh to export the DHCP database from the old server and import it to the new, as I did during my test migration. However, when I attempted to do so, I discovered that SBS08 had already disabled the DHCP server service on the source server, and created a new one without regard for any reservations or static IP addresses I may have had on my network (in fact, this created an IP address conflict – way to go, MS!). I was, however, able to stop DHCP on the new server, start it on the old server, retrieve my DHCP database, delete the scope on the new server, and import my previous database to the new server.

 

I used the netsh utility to export the scope from the source server, and import it on the destination server. This turned out to be premature, because the DHCP scope got wiped out again later – so my advice is to export the DHCP database from the source server before you begin the entire process, and then after every step that changes the networking via an SBS 2008 wizard, check the DHCP scope and re-import if necessary. If you’re doing this on a weekend and it doesn’t matter if the machines lose their DHCP leases, then just wait until everything else is done and do this step last.

 

You’ll want to use the NETSH utility with elevated permissions at the CMD promp, as follows:

 

1. On the SBS2003 server, run this at a command prompt:
netsh dhcp server export c:\dhcp.data 192.168.0.0  (substitute your internal network subnet)
This saves your DHCP database to a file o the root of C on your old SBS server.
2. Copy that file to C:\ on your SBS2008 server.
3. Stop and disable DHCP on your old SBS server.
4. On the SBS2008 server, enable and start the DHCP service.
5. On the SBS2008 server, run this at a command prompt:
netsh dhcp server import c:\dhcp.data 192.168.0.0  (substitute your internal network subnet).

 

 

Normally, when doing a migration, I recommend setting the DHCP scope to a low lease duration – but in this case, I think an 8-day lease duration is probably best, especially since the DHCP server address will remain the same if you swap IP addresses at the end, and you will get to keep your DHCP database if you export it with the netsh command.

 

C. Connect to the Internet (Clicked to start the CTIW).

The CTIW wizard ran successfully, trashing my DHCP scope again. I restored it again.

D. Configure the Internet address.

i) Start the Internet Address Management Wizard

(1) Selected “I already have a domain name”.

(2) Selected “I want to manage the domain name myself”.

(3) Typed my domain name into the field.

(4) Clicked the Advanced button.

(5) Chose not to use a domain prefix. (My SSL certificate does not have one.)

(6) Clicked OK, Yes on the warning, and Configure.

(7) Viewed the warning about the wizard failing to administer my firewall (good!).

 

The second part of this wizard deals with self-signed certs, which I am not using.

Skipped the self-signed cert bit because I have a real one.

I’ll see about moving the cert later if not prompted to do so.

ii) Task Complete -> Next

 

E. Migrate Network Settings.

i) Migrated DNS forwarders.

ii) Migrated the Mobile Users Group.

iii) Clicked to open the help for migrating SSL certificates.

iv) Followed the instructions for migrating my certificates (2 of them).

v) The “Add a trusted certificate” only allows one at a time.

vi) I have a second one which I will figure out how to add to another SSL website later.

vii) Task Complete -> Next

 

It should be noted at this point that the migration wizard trashed my internal authoritative DNS zone for my external domain name, and replaced it with a single host record for the new domain. How rude. I modified it manually to restore my DNS records.

 

F. Migrate Exchange mailboxes and settings.

i) Migrate Exchange mailboxes and settings. This brings up a help topic telling you how to:

(1) Remove Internet connectors from the Source Server.

(2) Migrate POP3 connectors (optional) from the Source Server.

(3) Move the Offline Address Book

(4) Move mailboxes from the Source Server to the Destination Server

(5) Move Exchange Server public folders.

 

It should be noted here that public folders and mailboxes have default size limits on them that should be adjusted before moving anything.

 

Before I started this, I fixed my FQDN in the SMTP connector so that the two exchange servers could talk to each other properly.

 

My event log had errors about communication between the servers, and I could not move a mailbox. This turned out to be because permission inheritance was blocked on the source server. This is a fairly common practice, because it was required in order to use EXMerge when migrating mailboxes into SBS2003.

 

Setting permission inheritance and restarting all Exchange services was not enough to resolve the issue. It was necessary to restart the source server. Once the source server was rebooted, the test mailbox moved successfully. I then started moving them all.

 

While the mailboxes were moving, I took care of the other tasks as well:

 

ii) Remove internet connectors from the source server

(a) Moved my smart host setting to the Send Connector on the new server first.

iii) Migrate POP3 connectors.

(a) None to migrate. Skipped.

iv) Move the offline address book.

(a) Followed the help file instructions.

v) Move the Public Folders

(a) Followed the instructions.

 

 

Additional notes here: When SBS works itself into the Exchange system, it disables the previous default recipient policy, and adds a new one. This does not cut off access to additional e-mail domains that might be in the old policy, but things in the old policy should be migrated to the new one anyway.

 

vi) Finish migrating Exchange and removed the old server from the organization.

vii) Task Complete -> Next

 

There are some procedures not covered in the migration help files regarding decommissioning the old server. In the page of the migration wizard where it told me that I would need to do so, there may have been a link to an MS article on doing so, but I didn’t see it. I’ll look for this next time around.

 

Basically, removing the old Exchange server entails deleting the routing group connectors (both sides) that were created when SBS2008 joined the organization, modifying the home server for the recipient update services, and uninstalling Exchange from the old server (SBS Disc 2 is required).

 

 

G. Remove legacy group policies and logon settings.

i) Clicked the link for removing legacy login scripts, which was a help file explaining how to remove them.

(1) I was not using SBS_Login_Script.bat. I removed my custom login scripts.

 

Login scripts stored in the netlogon share are being replaced with GPOs. This is due to the fact that UAC events are being triggered by conventional scripts. However, the SBS migration wizard does not specifically tell you to put your scripts into GPOs.

 

ii) Went on to the help section for removing legacy GPOs.

(1) I had already removed the default SBS GPOs long ago.

iii) Removed the WMI filter GPOs they referred to in the help.

iv) Task Complete -> Next

 

H. Migrate Users’ Shared Data.

i) Clicked the link for “How do I migrate…”, and it brought up a help topic.

(1) I used Robocopy with the /COPY:DATSO switch to migrate data.

(2) Recreated shares as appropriate.

 

I. Migrate SharePoint Web site

i) This opened a help topic with instructions to follow on both servers.

 

I started working through these instructions, and got to the part where it was going to have me create a new website called “Old Companyweb”.

 

At first, I thought that that this was not truly a migration and integration of the old SharePoint with the new – this was adding the old one so people could still access it, while someone manually moves things over to the new one.

 

I read further, and found where it says that it will, actually, upgrade the old site to SharePoint 3.0 as part of this process. I recommend, therefore, that you do NOT name the site “OldCompanyWeb” as they suggest, and instead name it something that the customer will be happy to keep using as you move forward – like for example, CompanyWebSite, or put their company name in it, or something. Further, when you detach the database files and move them over, you may want to take the time to rename the database files to something that does not include the old server name, for cleanliness – although this is behind the scenes.

 

J. Migrate Fax Data.

i) This was an automated process, which ailed for me because there is no fax service installed on the source server.

ii) Task Complete -> Next

 

K. Migrate Users and Groups.

 

Users and groups have already been migrated, but require some tweaking to show up in the new SBS console.

Note: This section is ripe for automation. Why didn’t MS make a wizard for this?

Note: I found out later that the Change User Role wizard removed all of my users from their previously assigned groups. Thanks, MS, that’s very helpful for a seamless migration!

 

i) Clicked the link for “Display the security group migration instructions.”

(1) Followed the instructions.

ii) Clicked Next to get to the Migrate User Accounts section.

(1) Clicked the link for Run the Change User Role Wizard.

(2) Ran the Roles wizard a couple of times for my user base.

 

L. Demote the Source Server

i) Clicked the link for “How do I demote the Source Server?”

(1) This help topic simply tells you to dcpromo down the old server.

 

Note: The help topic regarding demoting the source server is sadly lacking. It does not mention that you will need to update any static DNS or WINS pointers that you have on your other servers, workstations, or network appliances.

 

It also fails to mention that after you demote the old server, it might be helpful to remove its computer account from the Active Directory and run the netdom command to add an alias with the old server’s name, to help with any static shortcuts or registry entries on the workstations that might be pointing to the old server name.

 

M. Checked the box for “My source server is no longer a domain controller” and finished the wizard.

 

 

 

 

Things I did after the wizard:

 

1. Changed the server name and IP address of the source server so that it is still available on the network, but the old name and ip is available.

2. Exported the DHCP database in anticipation of the CTIW wizard trashing it for me again when I changed the server IP to match the previous source server’s IP.

3. Took a screen shot of my internal DNS zone for my external namespace in anticipation of the CTIW wizard trashing it for me (not worth the extra effort of exporting the DNS file, there are only a few records in there, I can fix them afterward.)

4. Ran the Connect to the Internet Wizard and adjusted the server IP address to be the IP the source server used to have. This is a helpful step because it avoids the necessity of changing static DNS settings and other settings that point to the IP address of the old server in network appliances, other servers, statically assigned workstations, firewalls, etc.

 

Note: The CTIW said it did not properly configure e-mail. It told me to run it again, and it failed again. I had to go into the Exchange Console and manually adjust the IP address bindings on the Receive Connectors.

 

5. Imported my DHCP database, made necessary adjustments, and fixed my DNS zone.

6. Ran the netdom command to add the computer name alias, and adjusted the registry setting to allow the netdom fix to work.

7. Added my login script into a new GPO called Login Scripts and applied it.

8. Installed printer objects with the exact same printer name and share name as on the source server, and tested network printers on workstations.

 

 

 

Some additional things that came up:

 

1. IE’s phishing filter was enabled via GPO. Some users don’t like that. I modified the GPO to allow the user to decide.

2. IE’s homepage was set to http://companyweb. Some users don’t like that, etc.

3. The anti-spam software requires MAPI and CDO. I had to install them. Here’s a blog entry about that.

4. The antivirus software wants to use .Net Framework 1.1, which is 32-bit only. Fortunately, it knows that this would kill OWA and other 64-bit application pools in SBS 2008, and warned me about it in time to cancel the installation.

 

After much Googling, it seems that this may be something that can be worked around, but the app installer does not know this, so it doesn’t really help. I will need to install the application console on another server, and push the Exchange and File System Antivirus components to the SBS server over the network.

 

 

So that’s it, in a nutshell. Your mileage may vary, of course. This is my first SBS 2008 migration from SBS 2003, so I’m sure I missed some things. Perhaps later, some other tips/tricks will come up that make some of the above unnecessary, or even incorrect. We can only hope.

 

Tags: answer file, deployment, Exchange, from boot to welcome, lua, Migration, replication, SBS 2008, SBSAFG, unattended