I am working on a checklist for a migration from standard server or sbs 2003/2000. Look for it soon.

1. Hit f10 to configure  your RAID, if needed. Reboot.
2. Download and install firmware updates for RAID controllers and backplanes. Reboot.
3. Enter bios and turn on virtualization support on the processor. Reboot.
4. Configure iDrac IP settings and password (Ctrl-e at the prompt). Reboot and test access via the web console. Default username/password is root/calvin
5. Boot to ESX 4.0 installer disc, go through installation prompts with defaults. Remove disc and reboot.
6. After reboot, log in to the console, set IP information and password.
7. On a machine on the same network, go to https://<server IP> and download the appropriate vsphere client for the version of VMWare ESXi you are running, if needed. Install the host update utility.
8. Log in to the server via the vsphere client and enter your serial number. Select the host IP in the left hand panel, choose the configuration tab on the right hand panel, then select “licensed features” on the left and then choose edit in the top right corner. Enter your key. If you don’t have one, get it from VMware.
9. Configure your NTP server. Exit vSphere.
10. Open the host update utility, connect to your new host, scan for patches and install them. Run through this process until you can do it twice and find no new patches.
11. If needed, open vSphere and configure networking (vlans)
12. Create an ISO directory on your data store, copy needed ISO files to that folder using either the store browser or the Veeam SCP utility.
13. Build your VM. Configure startup options for the vm if needed.
14. Install the vmware tools for the server in question.

1. Applications compatibility – Will your companies applications run ( in a supported fashion) on a 64 bit server? Any modern application should at least have a forthcoming update to support 64bit, but there are plenty of non-modern applications out there that are lagging behind. In the event that it is not supported, your best option may be to either host a VM on your new 64 bit server, or run both of them on a hypervisor. Call  your vendor and get their support statement in writing. You do not want to get halfway through a migration and find out that you will have to run beta code to make it work, sort of, in the meantime.
2. Backups – Most newer versions of BackupExec support 64 bit, so you should be fine there, if that is what you are running. Obviously if you are using the built in backup, it would be supported as well. Make sure that whatever device (especially tape drives) you are using to back up to is supported.
3. Printers – Ah yes, the lowly print server. Plenty of printers have either crap 64bit drivers or nothing at all. Either plan on replacing those printers or using plan b from item 1 above.
4. Antivirus – Don’t forget this. You need it and the chances that your existing install package will work on 64bit are basically zero

“The directory service was unable to transfer ownership of one or more floating single-master operation roles to other servers”

Weird. So I had him do all the normal steps, moving FSMO back and forth, waiting 15 minutes, restarting netlogon and FRS services. Nothing helped. FRS was running, stuff was replicating, but apparently something was still missing.

Running “repadmin /showreps” yielded a few errors:

“Last attempt @ 2009-11-12 18:45:37 failed, result 1256 (0x4e8): The remote system is not available. For information about network troubleshooting, see Windows Help.”

Bottom line, R2 and 2003 servers sometimes have security problems replicating between them. There is a hotfix, probably the worst-titled one in history, to fix it.

“Events 1925, 1006, 1645, 1055, 40961 on a Windows Server 2008-based domain controller or error message: “No authority could be contacted for authentication” when you use Remote Desktop Connection”

Crap huh? No way you would find that if you were searching for a problem with AD replication. There is a tiny note in there that one of the problems you might experience is replication-related. So we requested and ran the hotfix, rebooted and magically dcpromo worked as the maker intended it to. I hope that this makes it into a service pack or critical update at some point soon, because we have a lot of Windows 2003 servers that are eventually going to need to be replaced.

1. Memory optimization: VMWare has over-commit protection. Hyper-V really doesn’t. It can reserve RAM, but it is pretty hokey compared to what VMware can do. Who cares right? RAM is cheap! Not so fast. Some RAM on these higher end virtualization and blade servers can break the bank.
2. Live migration: VMware wins here too. Hyper-V R2 has it, but it can only do one machine at a time, and the way it handles shared storage is weak. VMware has been at the game longer and I expect that this gap will be closed but for now it could be a dealbreaker for those who load their hosts down.
3. Guest support: Another score for VMware. The only non-Windows guest supported on Hyper-V is Suse Linux. Not a huge deal if you are running Web servers I guess, but those guest tools start to get really nice if you are needing to do any of the more advanced functionality. VMware supports most *ux’s including SCO OpenServer, SCO Unixware, Free BSD, Debian and CentOS. Again, not necessarily a deal breaker.
4. Ability to hot-add disks: VMware can add them easily. Hyper-V can only add virtual SCSI devices, not IDE
5. Number of guests: This one is a mix. Hyper-V can have 512 loaded, but only 192 running (“only,” he says). VMware can run 256 at the same time, with up to 8 virtual CPUs and 255GB of virtual memory, compared to 4 CPU’s and 64GB on Hyper-V.
6. Monitoring: Hyper-V wins here. Since it is based on a Windows Core box that is joined to the domain, you can capitalize on the tools built into Windows, which are legion.

So who wins? Honestly, it depends on who is judging. For implementations of 30 Windows virtual servers and under, I don’t see why you would pick VMware, honestly. It comes out cheaper by most people’s math, you have fewer vendors to beg for support from, and you have fewer new interfaces to learn. For larger implementations, it depends a lot on how heavily you intend to stack the VM’s on the hosts and what kind of downtime you can tolerate should one of the hosts fail.

As far as dollars are concerned, most calculators will show that the initial cost for Hyper-V is cheaper for similar implementations. Most, of course, except for the one that VMware provides (big shock).

Dollars for initial implementation are small potatoes though, compared to supporting a poorly planned implementation. It is always going to be good to bring in an experienced party that can help guide you through some of the pitfalls.

Some sites will tell you to simply log in to IIS and set a redirect on the default site to /owa. Problem is, that setting will be pushed down to all the virtual directories, which will then have to be un-set manually. If you don’t do this, you can expect the sub-sites to fail, including activesync. If you have ever worked as an admin on an Exchange or IIS server, you know that, if you are running a Microsoft web-based application, you change as little as you can get away with and you do it in the simplest manner possible. The best way to do this is to set up a redirect on the iisstart.htm file.

To do this,

1. Select the default website in IIS (this assumes Server 2008 and Exchange 2007, btw).
2. Select the content view at the bottom to see the documents in the root of the directory.
3. Highlight the iisstart.htm file and hit the “switch to features view” Now we are looking at the features for just this one file.
4. Now select the HTTP Redirect button and check the box for “Redirect request to this destination” and put in “/owa” (no quotes).
5. Hit apply and test. This should not require a bounce of IIS.

To ensure that users get directed to the correct site even if they forget to type in https, you can force the error they get to redirect them to the correct site.

1. In the IIS manager, click on the default site and choose “Error Pages.”
2. Select the 403 error and choose to edit it.
3. Choose to “Respond with a 302 redirect” and put in the full path (including https and /owa) of your owa login page. Hit OK. No restart of IIS should be necessary.
4. Test.

Old Server: Windows 2003 Std/Exchange 2003 Std, all patches (pretty basic)

New environment: 2 Windows 2008 Enterprise Mailbox servers running the Exchange 2007 Enterprise mailbox role in CCR with a Windows 2008 Standard machine running the CAS/HT roles and serving as the File Share Witness host. Each of the mailbox servers have three volumes (CCR likes both machines to be as nearly identical as possible): a 40GB C:, a 20GB D: for log files (on a RAID10) and a 300GB E: (on a RAID6). These volumes were set up by a co-worker a few weeks ago and he did a great job with it. The servers are fast and they have great I/O on disk writes. All three machines are hosted in a ESX/Blade server environment with a SAN backend connected via Fibre Channel. This is becoming a pretty popular arrangement. The RAID10 logfile volume is considered best practice for performance reasons. The mailbox store lives on the big RAID6 volume for fault tolerance.

Anyway, all machines were updated and I had tested failing over the CCR cluster nodes successfully, so at about midnight last night, I started moving mailboxes. At around 2am, the old mail server went offline. It responded to ping, but I could not RDP to it or get to and SMB shares. Couldn’t get to the services either. It was, for my purposes, dead. The big issue here is that the mailbox move process was still trying to work, for all 225 mailboxes. The lack of old server caused all kinds of issues to take place that had the effect of hammering the log files. And since log shipping is pretty much how CCR works, both servers started choking. In two hours, we generated 19.8GB of log files, which then knocked the mailstore offline. I could not remount it, since there was no room for more logfiles.

Panic mode.

I temporarily stopped the replication, created new log file folders on both of the cluster nodes, moved the location of the log files in AD, moved the files themselves over to the big data volume, and restarted replication. These steps were originally from EXPTA.com, but it appears that that site is down, so I am linking to the google cache. These should all be done in the Exchange Management Shell (launched as administrator), and only performed after the new log directories have been created on both cluster nodes in the exact same location. Obviously, you will need to also change the paths to match your environment.

Step 1:  Suspend-StorageGroupCopy -Identity “First Storage Group” -SuspendComment “Moving transaction logs” -Confirm:$False

Step 2:  Move-StorageGroupPath -Identity ‘First Storage Group’ -LogFolderPath ‘E:\ExchangeLogs’ -SystemFolderPath ‘E:\ExchangeLogs’ -ConfigurationOnly

Step 3: move [oldpath]\*.* [newpath]

Step 4: Resume-StorageGroupCopy -Identity “exchange1\First Storage Group”

After this was completed (step 3 took a while, since I had 20GB of logfiles) I was able to remount the store and test via OWA. Then it was time to figure out why the Ex2003 box went down. After the moves are complete, I will run a backup to commit those log files to the DB and then move them back to the correct drive, as 20GB should be enough in any  normal case.

On calculator 2, you can either put in the number of servers you have with the avg. VMs per server, or you can list each server individually, which is more likely to be the best scenario for smaller shops. In the below screencap, I entered in one dual Proc (note that cores are immaterial) physical server running 3 virtual machines.

Virtualization Results Example

It reports that we will need either 3 Standards, 1 Enterprise, or 2 Data center licenses (since Data center is licensed per proc).

The pricing columns report that the cheapest way to do this is with the 3 std licenses, but it you wanted to add a 4^th vm, the Enterprise license would be cheaper. If you wanted to expand way beyond that in terms of Vm per physical server and core pair, the data center starts to be more cost-effective.

Both calcs are available here

Basically, if you are running the Hyper-V role on Server 2008 standard, you get two installations of Windows 2008 for the price of one. One acts as host (and that is it. it only acts as a hyper-v host) plus you get one free Virtualized OSE (operating system environment). If you are running Enterprise, you get 1 free host (running just hyper-v and nothing else) and up to 4 free virtual OSE’s. With datacenter, you get unlimited free VM’s.

Since products like ESXi are free as well, it has been asked what advantage this really gives you. Well , if you are running a Core install of server 2008 as your hyper-visor, you can monitor the services, automatically patch, and apply security policies to your hosts, just like you can with regular windows servers, but you don’t give up the low resource usage and reduced attack surface of a more stripped down OS like the Linux that serves as the basis for ESXi. Plus, if it breaks, you call Microsoft and they fix it for $250, rather than having a whole separate licensing scheme and updating process for ESXi. There is nothing worse than building your environement on two vendors and having them point their fingers at each other.

If you are running a different product, you are similarly limited. The wording is complicated, but basically they say you get one VM per license. If you are running Standard server on VMWare ESXi, you burn that license on the first one and have no extras.

“If a server is running ESX as the virtualization technology, then Windows Server is not deployed as a host operating system in the physical OSE. However, a license is required for every instance running in a virtual OSE.

If you have assigned a single license for Windows Server 2008 Standard to a server running ESX, then you may run one instance of Windows Server 2008 Standard at a time. The right to run an instance of Windows Server 2008 in the physical OSE cannot be used in this case since ESX runs on the physical OSE (and as a result, Windows Server 2008 cannot be deployed as the operating system on the physical OSE.

If you have assigned a single license of Windows Server 2008 Enterprise to the server running ESX, then you may run up to four instances at a time of Windows Server 2008 Enterprise. You may not run a fifth instance under the same  license since that right requires that the fifth instance be running hardware virtualization software and software managing and servicing the OSEs on the server.”

From the horse’s mouth (Word 2007 required):

http://download.microsoft.com/download/F/C/A/FCAB58A9-CCAD-4E0A-A673-88A5EE74E2CC/Windows_Server_2008_Virtual_Tech-VL_Brief-Jan_09.docx