Server 2008 R2 Considerations:
As Aaron posted over at BinaryWar.com, Windows Server 2008 R2 is the first release of Windows to be 64bit only. We knew it was coming, with SQL and Exchange having already made the jump. With the majority of us still supporting mostly 32bit clients, there are some special considerations to keep in mind when you are planning a deployment of a 64 bit server for general small office use (as opposed to a higer performance or higher demand machine, traditionally the targets of 64 bit architecture).:
- 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.
- 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.
- 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.
- Antivirus - Don't forget this. You need it and the chances that your existing install package will work on 64bit are basically zero
Weird Problem of the Day: Windows 2008 R2 and Windows 2003 DC’s Not Replicating
OK, one of our techs was onsite upgrading a basic single server DC/File Server/App Server. He joined the server to the domain, promoted it and ensured that the files in the sysvol share were replicating. Everything looked fine. He transferred the FSMO roles, again without error. When he ran the dcpromo on the old server to demote it, he got an errors saying that
"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.
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.
Hyper-V R2 Vs. VMware vSphere 4.0
Windows 2008 R2 is available now and one of the 4 key points of improvement is in the area of Microsoft's HyperVisor, Hyper-V. What has been lacking until recently is a side by side comparison of the features and limitations of Hyper-V R2 Vs. VMare vSphere 4.0. The killer feature that everyone has been waiting for on Hyper-V has been the live migration, designed to compete with vMotion. The devil is in the details though, and there are lots of details about this feature and others that factor into the decision as to which product is better for your environment. CTI has a great white paper that discusses the differences. You hit the side by side comparison on about page 17 of the paper (no reg required). Bottom line: here are the top 6 differentiators as far as I am concerned:
- 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.
- 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.
- 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.
- Ability to hot-add disks: VMware can add them easily. Hyper-V can only add virtual SCSI devices, not IDE
- 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.
- 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.
Redirect traffic on Exchange 2007 CAS to OWA Subdirectory and to HTTPS
In the context of a dedicated Client Access server with a public IP, an admin might want to make the default landing point for the server be the /OWA site, so that users can get to the login prompt without appending the /owa to the end (e.g. https://<Public Name>/owa).
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,
- Select the default website in IIS (this assumes Server 2008 and Exchange 2007, btw).
- Select the content view at the bottom to see the documents in the root of the directory.
- Highlight the iisstart.htm file and hit the "switch to features view" Now we are looking at the features for just this one file.
- Now select the HTTP Redirect button and check the box for "Redirect request to this destination" and put in "/owa" (no quotes).
- 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.
- In the IIS manager, click on the default site and choose "Error Pages."
- Select the 403 error and choose to edit it.
- 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.
- Test.
When to panic…
I am working on a 225 mailbox migration this weekend. The environment is basically the following:
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.
Microsoft Virtualization Calculator
MS has released a calculator to help you figure out exactly what you will need in terms of licenses and dollars in order to meet your virtualization requirements. They have two calculators, one of which requires Silverlight (guess which one I did). The calculators are VM-technology agnostic (meaning that they are the same whether you are using hyper-v, VMWare, or VirtualBox)
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 4th 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
Virtualization rights for Windows Server 2008
Microsoft has made their licensing much more friendly to virtualization with the release of the 2008 server product. It is still confusing, especially with the differences between Hyper-V and VMWare/VirtualBox/EverythingElse.
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):