On May 13 and May 20, Ben DeBow and I will be giving two days worth (six sessions) of webinars dedicated to the topic of consolidation with SQL Server. There is no requirement to attend both days, and you can do just one, or both. These webinars are not free, but are great value for the money and your boss does not need to send you anywhere - you can view them right on your computer screen! The cost for a single day is $99, or $178 for both (a savings of $20).

The six sessions we'll be doing are:
May 13 - Part I
11:00 am ET: SQL Server Consolidation Basics
1:00 pm ET: Gathering Information to Make Consolidation Decisions
3:00 pm ET: Applications and SQL Server Consolidation

May 20 - Part II
11:00 am ET: Considerations for SQL Server Consolidation
1:00 pm ET: Approaches for a Consolidated SQL Server Architecture
3:00 pm ET: Administering and Maintaining a Consolidated SQL Server Environment 

Each session will be about 75 minues with a live Q&A with both of us. For more details on each session and to register:

Part I Only http://elearning.left-brain.com/event/sql-server-consolidation-part-1-elearning-series.aspx?code=EP2905A1
Part II Only http://elearning.left-brain.com/event/sql-server-consolidation-part-2-elearning-series.aspx?code=EP2905A2
Both Days (with the $20 Savings) http://elearning.left-brain.com/event/sql-server-consolidation-parts-i-and-ii.aspx?code=EP2905AC

As if that wasn't enough to keep me busy, I've got more going on. Besides working on a few whitepapers which I hope will be released in the next two months as well as customer engagements, I'll be on the road quite a bit. Here's where you can catch me at public or semi-public events besides the webinar:

TechEd North America 2010
I'll be spending time in the SQL Server booth (and probably the Windows Clustering one as well), but the main reason will be my session DAT407 "Windows Server 2008 R2 and Microsoft SQL Server 2008: Failover Clustering Implementations". It will be on Thursday, June 10th from 5 - 6:15 PM in Room 276 (subject to change, I'm sure; check the site and guide when you get there). I know it's late in the day and most likely before the attendee party (update: it is; actually this is arguably one of the last sessions of the conference), but I hope to see you there and your brains are ready for 75 more minutes of content!

Microsoft Certified Master - SQL Server
I was recently honored with being asked to give one day of sessions at the upcoming May rotation for the Microsoft Certified Master - SQL Server certification. That day is May 14th, so if you're in the rotation, I'll see you there.

I'll actually be on the West Coast quite a bit (mainly in the Pacific Northwest and California) in May and June (outside of TechEd, of course), so if you've got a user group that needs a speaker and I'm in town, let's see if we can't coordinate. Click the Contact link above to get in touch.

Puget Sound SQL Server Users Group
Since I will be in the area, I do plan on trying to attend the Puget Sound SQL Server Users Group meeting if my schedule permits on May 12th. I am not going to be speaking if I go; I'm rarely around to just attend user group meetings anywhere. So feel free to say hello if you spot me!

Today I found a bit of nastiness. I recently received a new notebook and was configuring it to dual boot with Windows 7 and Windows Server 2008 R2 so I could run Hyper-V. I had no problem doing that with my Toshiba from last year. So what's the problem? This:
http://blogs.msdn.com/virtual_pc_guy/archive/2009/11/16/understanding-high-end-video-performance-issues-with-hyper-v.aspx

If you install the proper graphics driver under Windows Server 2008 R2 for your laptop with an i5 (or possibly an i7) and configure Hyper-V, you are presented with the lovely BSOD. Consistently.

Unfortunately, it seems like a "not my problem"/"he said she said" problem where MS may not issue a fix, and the graphic card vendor may not either. It's frustrating, as most newer laptops are shipping with the new processors. Right now I'm running with the standard VGA adapter so I can run Hyper-V, but eventually I'd like to run at a better resolution.

Let's hope this problem gets resolved soon, or a lot of unhappy power users and presenters may be storming the proverbial castle.

I just found out one of my proposed sessions was approved, so I'll be speaking at TechEd North America 2010. This year it's back in New Orleans from June 7 - 10. I was at I think the last TechEd in around 2003 or so in New Orleans (well, the last one in New Orleans *I* spoke at). Clearly it's too early to know what day or time, but I'm very happy and honored nonetheless. Stay tuned for more info.

Oh, and if you're curious, it's a clustering-related session - not a surprise.

There has been a lot of discussion lately among MVPs around “Should/can I disable IPv6 on Windows Server 2008 (RTM or R2) for servers that will act as failover clustering nodes?” Obviously this affects any products such as SQL Server or Exchange that will be then clustered on top of a Windows Server 2008 failover cluster.

In the sake of full disclosure, I have been recommending to many customers who were going to cluster over the past year or so to disable IPv6 if they were not using it. There was no definitive statement one way or the other and in all of my use and testing, I’ve seen no issues with doing so. While I didn't say to disable IPv6 in my book Pro SQL Server 2008 Failover Clustering, since I have been telling people to consider it, I had to "fess up".

Due to the MVP discussions, a PM from the Windows clustering team chimed in and they recommend that unless there is a strong reason to disable IPv6, you should not do so. Why? The following three points come directly from the PM:

• In all of our current troubleshooting and investigation of [Windows Server] 2008 and [Windows Server] 2008 R2 networking issues which may have been caused by IPv6, it has turned out that disabling it has not directly solved any problems.  These issues were resolved by disabling related networking components, such as Teredo or TCP Offload.

• By default, all clusters will communicate between nodes over IPv6.  If that is not available on network interfaces, then the cluster will try to communicate using 6-to-4 tunnels.  If IPv6 is completely unavailable in this environment, the nodes will then communicate by IPv4.  So yes, it is possible to disable either IPv4 or IPv6 and still have the cluster function correctly.

• We recommend keeping IPv6 on as this is the default configuration, which means that it is the most thoroughly tested and stable configuration.  IPv4, by itself, certainly will work, but we don’t recommend disabling IPv6 unless there is a good reason to do so.

So there you have the definitive “word” on the topic. As of the writing of this blog post, there is no official SQL Server statement on the “should I disable IPv6” topic (and if there is one at some point, I’ll update this post), but  since a SQL Server failover cluster is built on top of Windows Server 2008, I strongly suggest you follow the recommendation above for IPv6: don’t disable it. I know this will be my recommendation going forward in further talks/presentations, training, and consulting I do.

I just put together and delivered my first consolidation and virtualization class for SQL Server based on Windows Server 2008. One of the technology labs is building a standalone SysPrep'd server that has both Windows Server 2008 R2 and SQL Server 2008 R2 (currently still in pre-release form).

A bit of history: up until now, there really was no way to have a SysPrep'd Windows system with SQL Server on it. In fact, the wasn't supported for that combo, and there were numerous issues if you tried to do it. All of this is pretty well documented. With the release of SQL Server 2008 R2, there is now a way to SysPrep so that you can essentially have a way of creating a SQL Server that can be partially installed earlier, and then finished later.

This is different than the advanced cluster preparation install which is for failover clustering and introduced with SQL Server 2008. In fact, you cannot Sysprep a cluster at all, so if that's what you want to do, sorry. Standalone servers only. SysPrepping a cluster would need support both at the Windows and SQL levels, and it's not there for either. Once it's in Windows to SysPrep a base cluster, SQL can come up with a way to support it. I don't see either happening soon.

The concept of having a Sysprep server makes sense: create a base image with your configuration, and then use that base which can then be "brought to life" during the loading of the image (or the ISO burned from the image). This ensures consistent builds which is a good thing. One of the problems I often help DBAs with is ensuring that the Windows builds (both standalone and clusters) they get to put SQL on isn't a bed of quicksand. So many problems that happen with SQL Server stem from a bad configuration of hardware or underlying software which seemingly has nothing to do with SQL Server. Different rant for another day; just stating facts here.

In this day and age of virtualization, it makes even more sense to have a base image you can then deploy a million times. Just create your image, save it as a template VM, and away you go!

Let me say this before I go further: the way SQL Server implemented SysPrep in the SQL Server 2008 R2 installer works, and it works as advertised. But I feel in this version they did not go all the way.  What do I mean by that?

The way the feature is implemented in SQL Server 2008 R2, you can only Sysprep the Database Engine and Reporting Services - not Analysis Services, nor the tools. My problem stems from not doing the tools (i.e. SSMS). When I build a SysPrep'd image, I want it to have everything, and then I'll bring SQL to life (i.e. completion of the image) to wrap things up. To me, that would mean when that process is done, I also have the tools to do the job. You can get there, but it's more work - in my opinion - than it should be. Here's the process at a high level of what you have to do to have a "complete" image that is Sysprep'd:

1. Create the base OS image and make sure it is left open; don't seal it yet.
2. Install the SQL Server tools.
3. Run the image preparation for SQL Server 2008 R2.
4. Seal the Windows image.

At this point, you've got a usable image that can be used. When you load the image onto the new server, you'll have the process of bringing the server to life, which will include finishing the SQL Server installation. The process is pretty quick. However, the difference is that the process I outline above gives you a usable server. If you just Sysprep the server, you'd have to load the tools after the fact, which to me defeats the whole purpose.

I still think it's a great feature in SQL Server 2008 R2, and something that many of my customers have been asking to have for years. Remember, SQL isn't always built by DBAs, so the more that the experience can be integrated with Windows and be stable, it makes for better SQL Server implementations. It isn't for everyone, but it works just fine if you account for what I talk about above (which is also documented - see the link below) to ensure you have a full image for SQL Server.

Tip
Use the generalize option (either GUI or command line) for the Windows Sysprep process to ensure that each finalized server will get its own SID, new Event Logs, etc. Also use the Out Of Box Experience (oobe) option to prompt for a new system name and such.

Some good links:
1. The Books Online entry for the feature in SQL Server 2008 R2 can be found here.
2. A nice walkthrough of the SQL Server 2008 R2 GUI for SysPrep can be found here.
3. The Windows Sysprep documentation can be found here.

Fun fact:
Note that Windows spells Sysprep with a lowercase p, but SQL uses an uppercase P. Gotta love consistency!

It's 3:11 AM here and I just got my first Vmware demo environment with vSphere 4 (i.e. ESX 4.0) configured to show vMotion. Having set up both Live Migration and now the aforementioned vMotion, I can tell you that I much prefer the setup under Hyper-V. Just getting vSphere installed (pretty simple using its GUI Setup) and configured (not straightforward ... maybe it's my unfamiliarity with the server-based Vmware products, but it is not intuitive like Vmware Workstation is) took me the better part of today to figure out all of the little nuances. OK, sure, I could have probably read some docs (which I wound up referencing), but setting up clustering and then Live Migration is just easier.

I also didn't like the fact that vCenter needs a 32-bit ODBC connection to work (it uses a SQL Server backend), and it does not install the latest SQL Express version (if you choose not to use an existing instance with an appropriate DSN). That means those of you on later versions of Windows (read: Windows Server 2008 R2) will have to patch immediately. I wound up configuring vCenter Server under a Windows Server 2003 R2 VM.

As for the actual features - vMotion and Live Migration - they do essentially the same thing (migrate a virtual machine from one hypervisor host to another while keeping it up and running). They both work well.

The one major advantage of vSphere + vMotion at the moment is that I can demo it live on my laptop; my Live Migration stuff has been captured from a setup I did about a month ago when I had access to hardware. If you're wondering why, it's because the VT-x extensions that enable things like virtualization are not emulated in VMs (and if you think about it - it makes sense; virtualize a virtualized environment isn't a normal use of the technology). Both Microsoft and Vmware do not emulate VT-x. To do vSphere, it seems like Vmware does something special under the covers. I hope MS does something similar because I'd love to demo Live Migration "in the flesh".

Having said all of that, it'll be interesting to see how I get along with vSphere now that I have it set up. Since many customers of mine are invested in vSphere/ESX for their virtual environments, it's clearly in my best interests to have a good working knowledge of setting it up. I know DBAs probably won't be doing most of what I do, but this work I'm doing right now helps in conversations with the other groups (especially the guys setting up the VMs). I'm not new to Vmware - I've been using Workstation for nearly 10 years with a lot of success, and I used Vmware Workstation 7 to set up this new vSphere 4/vMotion environment.

I have yet to play with any of the other virtualization products since quite honestly, my customers really only talk about Vmware or Microsoft. The others don't come up in conversation. If you're using one of the other ones, I'm not denegrating your choice - do not take it that way. It's just that I'm not seeing it out there, much like the most common storage vendor I see at customers is EMC. There is other stuff, too - IBM, some HP, a Hitachi here and there - but EMC seems to be ubiquitous. All I care about is ensuring you have the right configuration no matter what hardware/software choices you make.

OK, off to get a few hours of shuteye and back to the grind in the AM to finish up some stuff before I head to Tokyo!

Well, it's official - the website just went up. Can't hide it anymore ... I'm delivering a 3-day masterclass on consolidation and virtualization at World of Windows Server in Singapore as well as delivering two sessions (although the current website shows two different, it is going to be a two parter on clustering). I'm very exicted and honored to have been asked to do this.

If you don't live in Singapore or can't get there (hey, what's a few thousand US dollars to take a little excursion to Singapore at the last minute - just ask ask your boss!), I do plan on delivering the masterclass and possibly expanding it to four or five days. Or not. I've spent a lot of time over this past month in content development (official v1 of my Windows Server 2008/SQL Server failover clustering class and this upcoming delivery in Singapore), and am going to assess it after I'm done to see if any tweaks are needed. I can promise you that whether you come to Singapore or see it in a town near you, it'l be a lot of fun, technical content, and information.

Contact me if you want to know more!

So it's no secret I've been using Windows Server 2008 R2 for quite some time. I like the PowerShell commandlets, and I've occasionally used the failover clustering module for PowerShell in R2 to manage "downlevel" Windows Server 2008 RTM (and SP2) based clusters with no issue.

This week I also figured, "What the heck?" and installed PowerShell 2.0 on a Windows Server 2008 SP2 cluster, and took the module from R2. It seemed to work just fine. You obviously don't get any new features, so things like Live Migration won't work. Only the basic failover clustering PowerShell commands would technically be applicable.

Despite both of these scenarios seemingly working fine in my limited use of them, they are 100% unsupported by Microsoft. So I will say this: I'm glad I tried it, but I would never recommend you doing something that would put your supportability in jeopardy - especially on a production system. If you do use these in either of the scenarios, do it at your own risk.

I have been at a client all week implementing a SQL Server 2005 Standard Edition SP3 cluster using Windows Server 2008 R2 for the underlying operating system. Since this is W2K8 R2, it's 64-bit only, so we implemented SQL Server 2005 x64. Everything went pretty smoothly, as did the cutover from their current production box. However, we did notice one weird issue: we couldn't configure a Maintenance Plan (I'm not a huge fan - I'm more of a create it on your own kind of guy). As it turns out, I found the following blog post from a Microsoft support engineer. We had named the nodes ending in lowecase letters. The problem was that by the time we figured this out, we were already live in production, and there is no way we could take another outage, and run through the whole process of evicting and renaming nodes.

The blog only mentions Maintenance Plans and Database Mail. What it doesn't mention is that it also does not create the System/Performance Monitor counters for use, and you have replication issues if you are using a Publisher and Distributor on the same instance (although replication works, you get errors and it is just odd). If you configure replication to go against a remote Distributor, everything is just fine. We did a bunch of testing against another cluster we configured (same hardware configuration) for their soon-to-be reporting server and had none of the problems we had on the original cluster we configured as production.

The unfortunate thing is that the customer is now in production and they can't afford another outage to go and evict things and reconfigure the servers in use. Everything else is working and stable. They may consider migrating to the other cluster in another outage, but not anytime soon.

Moral of this sad tale of woe: never use lowercase letters for Windows Server 2008 (RTM or R2) node names with a SQL Server 2005 clustered implementation. It affects more than just Database Mail and Maintenance Plans.

If this isn't a reason to use SQL Server 2008, I don't know what is! :)

I've been talking about it for awhile, but it's finally here - my update of the old SQL Server 2000 consolidation whitepaper. It just went live less than an hour ago.

The basic info including the link to the download of the Word document can be found here:
http://msdn.microsoft.com/en-us/library/ee692366.aspx

or you can just download the Word doc from http://download.microsoft.com/download/D/B/D/DBDE7972-1EB9-470A-BA18-58849DB3EB3B/SQLServer2008Consolidation.docx.

I hope you find it useful!