In our migration to SBS 2008 at SATV, I got bitten by a network configuration that may happen to you as well, so take note.
SBS 2008, like past versions, has a wizard to configure your network connection; in the old days it was called the CEICW; now it is the Connect to the Internet Wizard (CTIW). It’s a great tool. It sets the defaults and lines things up just the way they should be on a small network. I love it since it sets a known baseline for me. Then, when I run the wizard, I’m free to do all the customizing I need.
That’s also the bad part: It sets, or resets the defaults and sets the baseline. If your baseline is different from the one SBS has out of the box, you need to know that before you run the wizard so that you can set things right.
The above screenshot is our DHCP configuration. We have a number of static IP devices. To give us space and consistent allocations, I reserved .1 through .50 and .241 through .254 in our subnet for static devices.
Normally, SBS will reserve .1 through .10 and optionally .254 if the router is at that address, as it is in our installation. You’re on the hook for any other exclusions you need to make. If you already have an exclusion for .1 to .20, for example, the CTIW will delete it, and make its new default exclusion for .1 to .10.
What if you have static IP’s in the .11 through .20 area?
That has some interesting effects on a Windows network. Some devices may not respond. DNS entries might mysteriously disappear (since Windows DNS is dynamically updated.) You might wonder if your AD is corrupted.
And your VPN clients may not be able to access internal network resources. Or their connections may work the next time but not the next time after that.
I’m fortunate not to find out what would have happened if I had a DC in that IP range!
Moral: Pay close attention to your existing configuration. Perform the migration. As soon as it’s complete and you’ve run the CTIW, open the DHCP console, open your server, the IP4 tab, your scope and your address range, create an exclusion that covers your devices.
Since the CTIW already makes an exclusion for .1 through .10, I prefer to make another exclusion from .11 to whereever my highest reserved number should be, usually .20, .30 or .50. Then I may make another exclusion at the high end of my subnet, say, .241 to .254. (If your router is at .254, it may already have an exclusion.)
UPDATE: I’ve revised this to cover the “This security ID may not be assigned as the owner of this object” error that is commonly seen when configuring folder redirection.
One challenge you may run into in an SBS 2008 migration is Folder Redirection. The migration document makes it very clear that if your client PCs have been configured for folder redirection, you must make sure your users log in while both servers are connected to the network.
Sometimes, this may not be possible. The migration period is for 21 days at most. SATV, like other businesses, has a number of part-time or contract workers that may have access to our IT, like a webmaster, an accountant or an engineer. They may come in just once a month, or for just a few weeks around the end of the fiscal year.
Any way it’s expressed, you probably do have users that aren’t logged on during the migration period, and won’t be aware of anything different until you tell them the next time they’re there.
Or they get errors like the one above.
There have been problems with folder redirection in Windows XP SP3, as explained in several threads on the TechNet forums, "GP error with folder redirections (ids 107, 1504, 1509, 1085)", and "Folder Redirection on Windows XP SP3".
Distilling the advice, there are two things you should check.
- Check the destination folder, which will be C:\Users\FolderRedirections, on a stock SBS 2008 server. Check the permissions on the folders for each affected user and make sure the user has Full Control and ownership.
- If the source server isn’t online anymore, copy the files manually from the old SBS machine, which should be under the share Computer Folders$. You should have had a backup or have kept the old server around just in case. Then open Group Policy Manager, select the Small Business Server Folder Redirection policy, make a backup of the GPO and edit it like this:
Uncheck “Move the contents of Documents to the new location”. Also uncheck “Grant the user exclusive rights to Documents”. Click OK.
On the machine of the affected user, log on as administrator. Open a command prompt. Refresh and force the group policy by typing:
Click OK to log off. Log back on as admin one more time and then log off.
This explanation of XP SP3’s folder redirection comes from the thread on TechNet Forums:
There is a difference in the way Fdeploy.dll works in SP3. I am not too sure if this is a deliberate change to the functionality, however.
If you have a client that is running Windows XP SP3 and their redirect is updated to a new location, you need to ensure that the source is reachable as well as the destination. If the source is not reachable for fdeploy.dll to verify that its moving content, the function will fail and the redirection path will not be updated to the new destination. This differs from SP2 in that if the source isn’t reachable, the process ‘moves on’ and updates the folder redirect location to the new destination.
If you have replicated the content to the new area using Robocopy or similar utilities and intend to do so as a procedure, I recommend that you update your GPO and uncheck the "Move the contents of My Documents to the new location" option in the GPO (which is enabled by default on a new GPO). Once the GPO change has replicated to all sites, have the client logout and log back in and verify the results.
There is another option cited in the threads, replacing a DLL with one from XP SP2, which I do not recommend; our machines have had XP SP3 for over a year and I really don’t want to make that kind of change. System File Protection may not let the DLL be replaced anyway.
If it still doesn’t work, a few other links:
- Turn on Folder Redirection logging on the client.
- Security Recommendations for Folder Redirection
- Event ID 101 and Event ID 1000 Messages May Be Displaye…
Good luck with your migration!
UPDATE: Phil has some kind words for me!
Today, I thought of the old saying about being nibbled to death by ducks.
I had all sorts of little problems crop up today. We have a PBX with a built-in router that I had hoped we would be able to use. No such luck. It locked up after hours for no good reason. Not good. We have a cable modem/router that will be familiar to many, since it is the one provided to business customers of this large cable operator; we are now using its firewall capabilities.
It works better. At least it hasn’t locked up.
But the VPN works. Our PBX vendor will gladly license our appliance to be a VPN server, but with SBS it’s a waste; we already have a license for as many people as we expect to use it (not many, mainly staff.)
(Our staff uses Macs at home, so Remote Web Workplace is not a great fit. I’m aware of the disadvantages of a VPN, but the staff is most familiar with it so that’s what I’m going with.)
I also had all the usual problems one has with 6-year old workstations; I don’t believe in “Winrot”, but these machines have been used hard. (To their credit, Dell Optiplexes are very good machines.)
Two larger problems I had to deal with:
1) When the users are migrated from SBS 2003, the users themselves aren’t migrated as such—they’re already there in Active Directory. But the user roles and permissions have to be assigned at the new server, otherwise they’ll not show up in the console.
But I had gotten ahead of myself and copied User’s Shared Folders from the old SBS 2003 server to the 2008 machine.
The User Role Wizard doesn’t like that. It will report it can’t set quota because the folders already exist.
OK, I move the folders to somewhere else and try again.
Nope. This time it says it can’t set quota on folder “xxxxxx”. Turns out folder “xxxxxx” doesn’t exist. Fix: Run the User Role wizard and note what folders it complains about.
In the folder assigned to users’ shared folders, make a folder or folders with the name the wizard lists. If if complains about a folder named “davidmoisan”, then create that new folder named “davidmoisan”.
Rerun the User Role Wizard and tell it to add a role (not replace). Do this until you get green checkboxes for every user going forward to the new server.
This is known, in sysadmin practice, as “Giving the bleeping computer a cookie until it gets what it wants and is happy with it!”
Of course, you’re using the SBS 2008 Group Migration Tool, right?
2) I had problems getting the SBS 2008 Backup wizard to work; I got an error “Unable to configure the backup schedule”. The log had an ugly error about something being missing in Task Scheduler, so I assumed the worst.
There are two possible causes: The old EMEA SBS blog suggests it’s due to having a backup device that’s too small for the data being backed up.
Our backup disk is a pair of LaCie Big Disk Quadra, 2 TB each. Not likely to be too small!
The other reason was uncovered by Nick Whittome: His machine, and ours, is a Dell PowerEdge that was configured at the factory. It has a 2 gig FAT partition named “OS”. The Backup Wizard does not like this. His fix, and mine, is to convert the 2 gig FAT partition to NTFS.
I’m wondering if it’ll break the diagnostic partition that Dell installs on its machines; it usually puts that in a tiny EISA partition (that is on the server.) I haven’t gone into the partition to see what’s actually in it.
Fix is to type in a command prompt:
convert <drive> /fs:ntfs
where <drive> is the Dell OS partition (usually D:.)
I’ve heard nothing about this. The SBS team was supposed to post about this but that was in February and it’s now June. There had to have been hundreds of Dell boxes with SBS. Why I never knew this…?
But the fix worked and I should get a good backup report in my morning email.
With that, nearly everything is done. I only have to verify that all the workstations are applying folder redirection to the new server, redirect some file shares, and decommission the old server.
One last post in this series and I’ll be done.
Our migration to SBS 2008 at SATV is moving along. Last week, Exchange public folders and mailboxes were moved to the new server. I’ve been warned that this is the longest step of the migration. Depending on replication settings, it could take hours or days to move the public folders over to Exchange 2007.
It took about 28 hours. The public folders were migrated starting at 10 AM Thursday, and finally finished on Friday afternoon. The migration instructions have you look at the output of a Exchange command shell to determine if the migration is complete. Unfortunately, the instructions are vague and the command output is very verbose. There should perhaps be a filter and a format-table. Perhaps next time.
Instead, follow the instructions in You Had Me At EHLO… How to Remove a Public Folder Database in Exchange Server 2007 RTM. When you are on the source Exchange server, look at Public Folder Instances. It will be populated with objects while replication takes place.
The screenshot above was taken after replication was complete and I was ready to go on to the next step of the migration.