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

 This causes many of these applications to fail to install correctly or talk to the server. Some of them are written well enough to check for this problem and tell you about it during the installation. Some of them may fail to mention one or the other, or give you a link to the CDO download but not to the one that includes both MAPI and CDO. 

 The CDO installer (the one without MAPI) complains that Outlook 2007 is not yet installed.

It is very likely NOT necesary for you to install Outlook 2007 on your exchange server. Instead, download the Exchange MAPI+CDO add-on from Microsoft. The download size is just 2.4MB.

Since Exchange 2007 does not include MAPI (nor does it use MAPI internally), there are no concerns about a MAPI conflict arising from the installation of it on the Exchange server.

Tags: CDO, Exchange, MAPI

Problem: You want to have separate URLs pointing to two different domain names, with SSL, and both pointing to the same Exchange server.

Environment: Exchange 2007 on Server 2008 with IIS7.

Usage Scenario: Your e-mail domain has two (or more) e-mail domains, and users in both domains want to use their own domain names to access OWA. For example, users with domain1.com e-mail addresses want to go to https://remote.domain1.com/owa, and users with domain2.com e-mail addresses want to go to https://remote.domain2.com/owa to access their e-mail.

In Exchange 2003/IIS6, you might have done some crazy metabase manipulations, such as exporting the entire website to a file, then reading it, and choosing to import the /exchange  subfolder only.

Well, it’s actually somewhat simpler than that with Exchange 2007/IIS7.
Here’s what to do:
1. Open Exchange Management Shell with elevated permissions.
2. Paste this command into the shell:

New-OWAVirtualDirectory -OwaVersion:Exchange2007 -ExternalUrl:https://remote.domain2.com -InternalUrl:https://remote.domain2.com -Name “owa” -WebSiteName “Domain2.com”
Change the parameters in this command to match your environment, of course.

This command makes some assumptions:
a. Your external and internal URLs to access the website are the same. You could use different ones at this point. It’s up to you.
b. Domain1.com already has OWA enabled. So, we’re adding the OWA virtual directory to Domain2.com.

If you’re experimenting with this, and you make a mistake, DO NOT delete the virtual directory from the website using IIS Admin. Instead, use this command in Exchange Management Shell:
Remove-OwaVirtualDirectory -Identity “owa (Domain2.com)”

This will not only remove the virtual directory, but also fix some behind-the-scenes stuff that would have bitten you if you had deleted the virtual directory (voice of experience here).

Here is a Technet article with the complete command reference for the New-OWAVirtualDirectory command, and some related ones.

Updated - Here is a related command to add the ActiveSync virtual directory as well:

New-ActiveSyncVirtualDirectory -WebSiteName “YourWebSite” -ExternalURL “http://YourAccessURL/Microsoft-Server-ActiveSync“

If this gets out of sync, you can use this command to remove it:

Remove-ActiveSyncVirtualDirectory “Microsoft-Server-ActiveSync (YourWebSiteName)“

Tags: Exchange, IIS7, Outlook Web Access, Virtual Directory

Moving Exchange Public Folders from one server to another used to entail a fairly time-consuming process of opening the property sheet for EACH public folder, setting its replication properties, waiting for replication, and then removing the source replica. This was mitigated somewhat by the ability to propagate settings to subfolders. If you were really savvy, you moved all subfolders underneath one top-level folder, made the adjustment, and then moved them back. Even so, it was a labor-intensive, time-consuming process.

So we all cheered mightily when Exchange 2003 SP2 brought us the capability to right-click the Public Folder Store and Move All Replicas. However, this euphoria was short-lived for me. I found that this process often did not move all of the data.

Well, I was missing one important piece of information: Do not dismount the database! If the source database is dismounted before all its contents are moved, you have to tell it to move the replicas again. A dismount of the database creates the system folders again and blocks removal of Public Folder instances in the database.

I suspect that in my impatience to get on with the migration, I most likely made some other changes that required a reboot (which dismounts the database), and my public folder migration was interrupted. I just assumed that, like any other Exchange replication process, it would pick up where it left off when the store came back up.

That being said, I still highly recommend that you take a good backup of the Public Folders to PST before you use this method, just in case. Getting at the Public Folders to restore/verify data after an Exchange migration can be very time consuming if you didn’t export them to PST. It’s time well spent.

 

One additional tidbit: Make sure you set the public folder replication interval in the Public Folder Store properties. By default, the replication values are empty in the UI. I’m not sure if they are really not set in the software, but I always go in there and click the “defaults” button, or set the values I want.

Tags: Exchange, Migration, Public Folder Replication, Replicas

You can configure a setting called “SCL” (Spam Confidence Level) in the SMSMSE console. This corresponds to a setting in the Intelligent Message Filter in MS Exchange System Manager. Using these two settings, you can more finely control which messages get sent to the Junk E-mail folder based on Symantec’s rating of the message.

Changing the Store Action Threshold in Symantec Mail Security for Microsoft Exchange:
Grabbed from here.

Question/Issue:
This page describes how to control the Store Action Threshold (SAT) in Microsoft Exchange 2003. The SAT works with the Spam Confidence Level (SCL) that you specify in Symantec Mail Security for Microsoft Exchange to determine which messages are sent to the users’ Junk E-mail folders. By default, the SAT value is null. The null SAT forces all messages with an SCL value of 1 or greater to the user’s Junk E-Mail folder. You installed one of the following versions: -Symantec Mail Security 4.6 for Microsoft Exchange -Symantec Mail Security 4.5 for Microsoft Exchange -Symantec Mail Security 5.0 for Microsoft Exchange
Solution:
To change the Store Action Threshold

In the Exchange System Manager window, in the left pane, under Global Settings, right-click Message Delivery -> Properties.
In the Properties dialog box, on the Intelligent Message Filtering tab, on the Store Junk E-mail Configuration drop-down list, click the appropriate level.
Click OK.
Close the Exchange System Manager window.
——————————————————————————–
Note: You cannot set the store threshold higher than the gateway threshold.

After you have configured the global settings in the Message Delivery area, you need to enable Intelligent Message Filtering on the Default SMTP Virtual Server properties. Intelligent Message Filtering is installed by default as part of Exchange SP2, but it is not enabled. To enable it:

In the Default SMTP Virtual Server properties, on the General tab, click Advanced.
Select the IP address (or “All Unassigned” and click the Edit button.
Check the box for “Apply Intelligent Message Filter” and click OK.

If you want to verify the SCL rating on a message in Outlook, here is how to do it. This article was written for Outlook 2003. It will probably work in 2007, but the menus will probably be different.

Tags: Exchange, Intelligent Message Filter, Junk E-mail, SCL, Spam, Symantec Mail Security