Tue 1 Apr 2008
I recently build a Windows Small Business 2003 Server that was a migration from old hardware. Following this guide from Microsoft makes it pretty straightforward. However, there are a few things I noticed, especially this late in Windows 2003’s lifetime.
- The guide mentions “Join the new server to the domain” as part of the DCPromo process. I like to separate this out as a way of verifying the join goes well, and that the server can get fully patched more easily. There is a 7 day limit to having 2 SBS 2003 servers live on the network at the same time, and it’s enforced by the old server shutting down after 1 hour uptime. However, this limit isn’t enforced untill after you run the second part of the SBS setup (the first part is the OS setup, the 2nd is the Windows mode “double-click to run” setup). This gives you time to patch and prepare the OS prior to that time limit starting.
- Once the 2nd part of setup has been run, migrate your users immediately.
- Migrating users includes moving their mapped drives to the new server. The Client Side Caching Tool from Microsoft will make this much easier. I normally do this change as follows:
- Create the share on the new server, if you’re not using the default SBS \Users share.
- Edit all user’s profiles to point to the new location. I’ll post a script for this later, but all of the ones I have at this time are protected by IP contracts, and therefore non-sharable. I believe there’s at least a stub for this at either Don Jones’ Scripting Answers or Microsoft’s Script Center.
- I have yet to see an SBS environment with no laptops. Therefore, you’ll want to move the Client Side Cache for the My Documents of your users.
- Copy csccmd.exe to your NetLogon share on your DC (c:\WINDOWS\SYSVOL\sysvol\domain.local\scripts by default)
- Find the current path, and new path (\\dc01\Users for current, and \\dc02\Users for new, below)
- Make the logon script be: “\\domain.local\netlogon\csccmd.exe /moveshare:\\dc01\Users \\dc02\Users”
- When all the laptop users have logged in and run this script, unlink the GPO but keep it around for documentation (knowing how documentation is in most Small Businesses I’ve visited). This will speed up logons for everyone.
- Now you can finish the Exchange / SharePoint / ISA setup. This will require downtime, but is easy to do, if you’re following the document referenced above.
- Finish up cleanup of Exchange prior to the 7 day timeout value. you’ll need to replicate all the Public Folders, OAB, and Free/Busy data as documented in the “Migrating to new Hardware” document.
- Uninstall Exchange on the original server.
- Requires “Modify”ing the Small Business Server roll in “Add/Remove” programs. choose to uninstall Exchange.
- This cleans up a huge number of items in AD, and makes future migrations simple. Also cleans up potential problems down the road.
- DCPromo the original DC, so it’s not a DC on the original network. Just run “dcpromo” and remove the server from being a DC.
- Now you can shut down the old DC and have no issues.
However, if you follow my guide directly, you’ll run into a single issue: https://servername/oma (or Exchange ActiveSync) will fail with an error: Server Error in '/OMA' Application. You will only see this error if you try to access the site directly from the new SBS2003 server. Remotely, you’ll just get a generic error.
Collection was modified; enumeration operation may not execute.
This is caused by .NET Framework 2.0 being installed *prior* to Exchange 2003. If you join the domain with the DCPromo and do patching *after* the fact, this probably won’t come up, because .NET Framework 2.0 won’t install untill after Exchange 2003 is installed. If, however, Exchange 2003 is installed first, you’ll probably get this error.
Good news, it’s a simple fix:
c:
cd\windows\Microsoft.Net\Framework\v1.1.4322\
aspnet_regiis -sn W3SVC/1/ROOT/OMA/
iisreset /restart
It might take 2 minutes to initialize, but OMA and ActiveSync should now work flawlessly. As is always implied, contact us somehow if you have issues!
August 2nd, 2008 at 8:22 pm
This was exactly what I was looking for to get OMA back to asp.net v1.1 from v2! If I tried to update via IIS properties, it would break ActiveSync. Well, now I used your insturctions and got OMA to v1.1 and didn’t break ActiveSync. However, now I get: “A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.” when going to https://server/oma
Any ideas?
August 7th, 2008 at 4:48 pm
Is that the error you get when viewing the “/oma” site from the server console? IIS ASP.NET applications are configured by default to only show detailed error messages to visitors from the server itself, not even clients on the local network. If that’s the error you’re getting when you view from IE on the server itself, I’d just try a restart of IIS, but likely, there’s a more detailed error you can get.
September 29th, 2008 at 3:58 am
This error occurred when i did a windows update wich contained a .net update probably.
The command fixed the error for me, thanks a lot.