Just as a heads up, most of the Technet articles I found on doing a SBS 2003 to Windows Server 2012 R2 Essentials migration cover Server 2012, not 2012 R2 and they all mention installing the server in “Migration Mode” and grabbing the “Server Migration Prep Tool” from a folder on the DVD called support\tools.
THESE DON’T EXIST IN R2.
Server 2012 Essentials R2 is a separate product than Server 2012 Essentials, and the two, tho related, do not share some bits.
I found out the hard way by doing an install, then seeing the Migration Mode stuff, and restarting the install, only to find there was no migration mode option.
But, they do have a document that spells it all out for you, without using the missing Migration Mode install… Lots of threads with “I just installed Server 2012 R2 Essentials and I am also not seeing the migration install option anywhere.” messages. Happily someone pointed them (and me) here:
Migrate from Previous Versions to Windows Server 2012 R2 Essentials or Windows Server Essentials Experience which can be found here: http://technet.microsoft.com/en-us/library/dn408633.aspx
Posted so I don’t lose the link, and maybe people Googling will find it easier than I did. 🙂
Dropped a Server 2008 R2 machine in to a client’s environment to act as a Remote Desktop Host, but when I went to check on Previous Versions functionality, I saw that all the entries were the same date when accessed from the 2008 box, but they were fine on my XP clients and the 2003 box itself.
Happily, the good folks over the SBS Blog at Technet (where I stole the above screenshot from) had a simple fix there for the searching. We just had to delete a registry key that was there to help Windows 2000 clients. Since we don’t have those anymore, we can safely get rid of the key and restore our functionality. It doesn’t even require a reboot! (This holds for non SBS flavors of Server 2003 as well.)
- On your SBS 2003 server, open REGEDIT and navigate to the following location:
- Right click on parameters and select Export.
- Once the export is completed, find the entry for DisableDownLevelTimewarp, select it and then delete it.
We have a client who has an old in-house app that relies on the DynaZIP 32-Bit OCX Interface to run. We’ve been trying to get it to run under Windows 7, but couldn’t find much info — but I happened to come across a text file from DynaZIP that had the dependencies on it, and it turned out we were missing a couple files; loaded them into SYSWOW64 and the OCXs register.
You need to make sure the following files are in your c:\windows\ syswow64 directory:
Then open a command prompt with admin privileges and run REGSVR32 on the lot of OCXs.
The SoftwareDistribution.log file on a client’s SBS system went insane and spooled to 66GB and filled up their C: partition. Deleting it was easy enough, but we had a larger issue that didn’t reveal itself until a little later — the server’s licensing database corrupted and the Server Manager was showing only 5 licenses instead of 20, and when the 11th person tried to log on (I assume MS isn’t heartless and gives you some wiggle room before dropping the banhammer) they were shut out.
A restart of the license logging service provided temporary relief, but I was getting ready to head over there to find the license keys that shipped with the server back in 2009.
But, the IT community is nothing if not a bunch of people who watch each other’s backs, and I must throw a GIANT THANK YOU to Chris Knight, an IT guy from halfway across the world in Tasmania, who posted an article — seven years ago!! — “Small Business Server 2003 – The Dreaded 5 CAL Reset Issue” on his blog.
Long story short, MS makes a backup of your license file called autolicstr.cpa which lives in c:\windows\system32. It’s made at the time of license install and it should be a copy of licstr.cpa which also lives in the system32 directory.
But, if, like me, your licstr.cpa gets corrupted, you can just:
- Stop the License Logging Service
- Copy autolicstr.cpa over licstr.cpa
- Restart the License Logging Service
- Verify in Server Manager that your licenses are back
Worked for me and my client is thrilled; and best of all, I didn’t have to leave my office.
We have a client who manages multiple accounts for different identities under one Outlook instance. He was running into an issue where Identity 1’s name was showing up in replies sent from Identity 2. So, he’d click reply on something sent to Identity 2, Identity 2 was selected in the accounts selector at the top of the message, but in the body of the message was:
FROM: Sender <firstname.lastname@example.org>
TO: IDENTITY 1 <email@example.com>
It was a simple fix once we found it (and we looked everywhere, since Identity 1 is the name the Mac was registered to, we didn’t know where it was grabbing the name from).
There was a contact card in Outlook that had Identity 2’s email address associated with Identity 1’s name; so Outlook “resolved” the name incorrectly – instead of taking it from the account properties, like we assume it should have; it took it from the contact card.
Once we deleted the Identity 2 address from the Identity 1 contact, all was right in the world, and our replies went back to looking like:
FROM: Sender <firstname.lastname@example.org>
TO: IDENTITY 2 <email@example.com>