Last week I was in Seattle at the MVP Summit. While it was a lot of fun and great to not only hang with my fellow MVPs, I did learn quite a bit. Unfortunately, I also was working at the same time. The work included moving my domain (the website, my e-mail, this blog, etc.) from one hosting provider to another. Let me tell you, as someone who does stuff like this for a living with and for clients, it's not easy even for my own stuff. Why?

First, a little background: I've been using Hosting Company A since I went independent. I've had the intermittant issue - mainly with e-mail - since the start. It was annoying at times, but it is what it is. Nothing is perfect, right? Fast forward to January. They were going to "migrate" me to their new platform. They claimed they did a bunch of testing and had scheduled my move ... which was last Wednesday. Unfortunately, their definition of testing and my definition of testing were far off. My static pages worked, and my e-mail seemed ok, but my blog was down. Even rudimentary testing would have sussed that out. Having a QA background, needless to say, I was a bit livid. Oh, how I wish my story ended there and it was an easy fix. No. Hosting Company A's new platform had less control, so debugging was hard to say the least. Between online chats and phone calls, I spent nearly three hours trying to get things up and running. No go.

I asked one of my fellow MVPs what company he used for hosting, and he suggested Hosting Company B. I did a bit of research, and not only are they a bit cheaper, but they would apparently give me what I needed as well. So a few hundred bucks later, and I was set up pretty instantaneously. There were a few niggles, and it's taken me about a week to resolve some issues in getting this blog back up, but by golly, it's up. I also had a snag with my MX records, so I couldn't send e-mail, but they have been very helpful and all seems to be well (finally).

This blog was difficult to get up and running. First, I had to migrate the data from the database it was in (SQL Server, naturally ... I try to preach what I practice and use a MS-based blogging tool). That was a combination of exporting data via SSIS (figuring out the order due to PK/FK restrictions) and scripts with INSERT statements. The hosting company finally resolved whatever application issues I was having with IIS7/W2K8 this evening, and now I'm back up and posting again.

Not everything is perfect; unfortunately, I can't seem to get the comments portion working. I'll see what I can do.

What's the moral of this story? Well, testing is your friend would be one possible candidate. Another is practice what you preach (I try to). I guess the real moral is that I am a victim of the same issues you are, and it's one of the reasons that when I work with you, I can truly relate. I don't sit here high on my perch where I don't run into real issues or have to solve some real problems, sometimes creatively.

The other big lesson here is to trust your gut. I've had some so-so luck over the years with hosting companies for one reason or another, and in this case, should have moved earlier. My e-mail issues should have been a clue. At random times my e-mail server would be down, and I'd contact their support. They'd say they were doing something. You know, as a guy who does a lot of availability, an e-mail or some sort of message would be nice. Instead, I'm down. As someone who is independent, I depend on that access to communicate with my customers and potential customers. My new hosting company seems pretty solid so far in this way.

Anyway, that's been my week. Off to finish a few presentations, one of which I deliver this week.

I'm a few days late to the party, but it was announced that SQL Server 2008 R2 will be released in May, 2010.

Today's blog entry is a lesson in politics. It's one of the things I deal with more than anything else at customer sites - there's the politics between groups of workers (say, the DBAs and the SAN guys), and the politics between individual people. Both come into play, and affect working relationships and how things do or don't get done. Sometimes these situations are impossible to break down the proverbial walls, and things come to a standstill. Sometimes it's just personal - there are some people who frankly just don't get along or ever will. Sometimes these reasons for not getting along are valid, other times they are perceptions or incidents that have been blown out of proportion, things heard second hand, etc. What do you do?

1. Pick and choose your battles carefully. Complain too much, and you'll be ignored. Be a shrinking violet, and you become a punching bag. Know what you realistically can possibly "win", and fight for what's really important even if you lose. If you're low man on the totem pole, get someone above you in your corner. Realize that at the end of the day, it's going to be about compromise.

2. Be factual, not emotional in e-mails, calls, or in person. This is the mistake nearly everyone makes. When emotions come into play, tempers flare, things are said, and it devolves quickly. You never want that. Be rational and calm - never vindictive. Everyone pays the price in the end when things escalate.

When it comes to communication, keep e-mails brief or don't even e-mail. If you're in the midst of a potentially (or already) ugly situation, it's best to deal with it in person or if that's not possible, over the phone. IM, Twitter, texts, Facebook, e-mail, or even fax are NOT the right way to handle it. Words on proverbial paper can be easily twisted and misconstrued. Avoid that situation like the plague.

3. If you find yourself in a difficult spot, know when to walk away. At the end of the day, you only have your own integrity and dignity to preserve no matter what people may say or think about you. It certainly isn't the best feeling in the world to hear that people think of you one way, even if a majority feel otherwise. An influential and vocal group of people saying bad things about you can impact your career. Unfortunately, if you're not given the opportunity to at least be heard to respond to any impressions/criticisms/problems/etc. or told directly, do the right thing. Walk away. What's done is done.

Perception is reality sometimes, and maybe it will change over time. Even if that perception is based on something wrong, it's right in their mind and you may never be able to change it. Often times you will never find out what the problem is; one day you'll wake up to find out things are "different" - there will be a vibe, a feeling. You'll know.

Personally, I find it sad and pathetic that people who have a problem with an individual can't confront them and have an honest discourse about it. When you don't say anything, things fester and get to a point where they can't be resolved. Myself? I'm an up front individual and tell it like it is (within reason of course; you can NEVER be all bark and bite ... sometimes you do need to tone it down), and have no problems taking feedback about myself so I can improve, or if there's a problem, let's address it and move on. In my career I've never been 100% successful at that in every case. I'm not perfect, nor is anyone else. I've been wrong and will admit when I am. Being the bigger person - whether it means admitting you're wrong when you are or walking away - takes more guts than people proverbially turning their backs on you.

4. Along similar lines, never betray confidences and don't put someone you like in a tough spot, either. If they're between a rock and a hard place, don't make it any more difficult for them. Bow out gracefully.

5. Last, but not least, treat everyone with kindness and respect. It'll also get you farther ...

What can you take away from this? Realize that the key to success isn't necessarily that you're a rock star at what you do, or that you're even the smartest person. Know what's going on around you and gauge the temperature of a situation or a person before you say or do something. Of course, being smart and really good does help, but it's like being book smart in school and getting all As (at least here in the USA), but lacking street sense out in the world. Politics is everywhere, and an inevitable part of your job. Once you learn how to navigate those waters and deal with difficult situations, you will be all the better for it.

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'll be presenting at the Los Angeles SQL Server Professionals Group on January 21st. For complete details, check their website.

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!

I'm back from Asia and teaching in Singapore. I have some time off over the next few weeks, so I'll be doing a bit of catch up (including finishing the scripts for the book ... no, really). Part of that catch up will be doing a bit of blogging. I try to post things that are not just throwaway, and after speaking in Singapore, I think it's time I get a bit more outspoken on this topic: the shrinking DBA skillset. This is going to be a small series on what I feel many DBAs today are lacking to do their jobs better. This series has its genesis back when I did a series of 6 webinars in the springtime of 2009 for Penton Media/Windows IT Pro on SQL Server DBA basics. It had been a long time since even I had revisited what we sometimes like to call "101" here in the States. (101 is what colleges sometimes call the intro courses to a subject.)

Transact-SQL - It's What's For Dinner
For years, I've felt that the "modern" DBA has become reliant upon graphical-based tools, and not really learned how to do things in alternate ways. Scripting is like an evil curse word to some. Besides teaching my consolidation/virtualization course, I also did a presentation at the World of Windows Server Conference on failover clustering (I know, big surprise). I asked if people wrote Transact-SQL or any kind of admin scripting. No one raised their hands. I was shocked.

I'm going to sound like a crotchety old man here (I'm not; I just turned 38 last month, but I've been around SQL Server for nearly half of my life going back to about 1992). When I started on Sybase SQL Server, there were no GUIs. Just T-SQL and command line. Even 4.21a of Microsoft SQL Server only had a pretty rudimentary Enterprise Manager. Scripting was a way of life.

Transact-SQL dates back to the Sybase days, and is the most fundamental SQL Server programming language. Microsoft and Sybase still use Transact-SQL, but they diverged as of Microsoft SQL Server 7.0 so they are not exactly the same. It was/is the common thread for SQL Server professionals until the era of the GUI was ushered in.

In 2009, I have a hard time finding people who can write even basic BACKUP and RESTORE statements. Let me clarify what I'm saying before people go off on me: I'm not talking about having to memorize every parameter of every Transact-SQL statement here. That's what Books Online is for; it's a great referenec. Even I don't memorize everything; there's only so much I can keep in my head. I'm also not talking about writing T-SQL for applications (that's a whole different ballgame and developers - I've got a bone to pick with you; just not in this blog post); I'm talking for administrative purposes. T-SQL is not a retired feature, DBAs. It's one of your most powerful tools available to you. All of that information you see visually in SQL Server Management Studio? You can generally get at it easily - or easier - via scripting. When I'm doing a consolidation gig, I use things like the SERVERPROPERTY function as part of my scripts that I have clients run. Microsoft has even made it easier to get at some things - you don't even have to remember system tables in many cases. Just know about the dynamic management views (DMVs) first introduced in SQL Server 2005. They are a great way to gather information and monitor what's going on.

Scripting Sometimes Means More Than T-SQL
Over the years I've also written many OS-level scripts in languages like WMI for DBA use. Now, I'm not a coder in the sense that you'd want me writing optimized application code, but admin code is a whole different thing. For example, my backup retention scrips (also included as part of the download for the Pro SQL Server 2005 High Availability book) are all WMI. My current consolidation scripts for gathering OS-level information are all WMI. I'm currently porting a lot of that stuff to PowerShell, which I will talk about in a second. A DBA's job description does not begin and end with just SQL Server (a continuing theme through this series). SQL Server is part of a larger ecosystem that ESPECIALLY includes Windows. That's a topic for another day. I don't even ask DBAs if they can write other code if they can't write T-SQL.

I can't say it enough at this point: learn PowerShell. And if you didn't understand me, this should clear it up for you: L E A R N  P O W E R S H E L L. You'd be foolish not to. Microsoft has often (and sometimes rightly so) been criticized for not standardizing toolsets between products. PowerShell is becoming that unifier, and you WILL be left behind as an administrator if you don't learn it. On the Windows side, for example, the clustering team is sunsetting the .exe version of command line tools for PowerShell only versions. I predict many Microsoft products doing this over time. Windows is a bit ahead of the curve here.

I will admit I do not love SQL Server's implementation of PowerShell at the moment as it does not use a lot of commandlets (cmdlets), but is basically a PowerShell interface directly to SMO. Windows uses a lot of cmdlets and is easy to use, while SQL Server needs a bit more "finesse" at this point. I'm hoping that changes in future releases of SQL Server.

Having said that, the beauty of PowerShell even over older programming paradigms like WMI is that you can write integrated scripts that cross products to administer them. For example, I can write cluster-based scripts with a SQL Server focus that do both OS-level and SQL-level tasks in one fell swoop; I don't need to write different code in different scripts. I'm already experimenting with that, and it's very powerful.

PowerShell is currently at version 2.0, which ships with Windows Server 2008 R2 and Windows 7, and can be downloaded for other platforms like Windows Server 2003). SQL Server 2008 ships with its own provider, and you can even have PowerShell stored procedures.

Don't believe me? Talk to other SQL folks like my friends Buck Woody or Allen White. Read their blogs. See their webcasts and presentations at TechEd and PASS. PowerShell is here to stay.

Why Script? 
At the end of the day, why should you care about scripting? Here are but a handful of reasons:
1. Better control of what you want to do.
I'm sure as a DBA you've had that moment where the GUI doesn't exactly do what you want. Scripting - whatever language you use - is a way to handle that. And it's sometimes incredibly efficient. What you can do in sometimes a few lines of code (and sometimes more than that ... won't lie) can be powerful. That code can then be scheduled as a SQL Server Agent job or via some OS-level scheduler to be run.

2. Understand your environment better
I'm a big believer in knowing how things work underneath the covers so that even if you use the GUI, you have a better idea of why things are the way they are. Scripting helps you get there.

Coding also means that there's no black box, which is really what a SQL Server Maintenance Plan is; you don't see the T-SQL or SMO run under the covers. Coding means there's intent. What do I mean by that? Too many people use Maintenance Plans with no thought behind them. Having jobs you've coded and are executing gives you that control and understanding of why, not just selecting something because it's a checkbox on an option screen. 

3. Some features are only available via script or have script-only options
Not everything has a GUI equivalent or has all options exposed via some fancy interface. I know that may be news to some of you, but it's true. You'd be better off learning a scriptable way to do things because you may have more options at your disposal - some of which may actually be useful.

Anyone ever use BCP these days? It's one of the more powerful SQL Server tools, still ships with the product, and has been around since the Sybase days.

4. Reliability
As an administrator, there's nothing you want more than repeatability and consistency in what you do - especially in terms of how things are executed and the results. Scripting is one of the best ways to make that happen. Scripts can be tested and results easily verified.

5. Disaster recovery/problems
What happens if your SQL Server is locked up and you do not have SSMS accessible? Do you know how to access and use the Dedicated Admin Connection via sqlcmd, and then run the proper commands to see what's going on and resolve the issues? Never assume you'll have a GUI available to you, and quite frankly, scripting can be faster than GUIs - especially if you know what you're doing and/or what has to be done.

What if you need to do something like restore a server from bare metal and need to restore backups in a particular order. Are you really going to do that via the GUI if you've got 100 backup files (most of which are t-logs)? No, you're going to script that. Hopefully you've generated it (like the script I wrote to generate that as part of my last book and downloadable on this website as well as at Apress) already. If you're going to do it via GUI, that may lead to problems (human error) or just be cumbersome. 

Scripts can save your proverbial bacon, and can serve as documents of your current environment. A good example is scripting your replication configuration.

Back to Reality
I don't expect this blog post (or any in this upcoming series) to change anyone's mind overnight, nor is it designed to turn anyone into a coding genius; it's just me posting observations about what I see out there in the SQL Server community. I've done enough research over the past few years to see this as a very disturbing trend.

Yes, I know learning how to code takes time when you're already overloaded with other tasks. Stop thinking of code as a development task. Coding has an administrative side that has nothing to do with application functionality. Exploit it for your own good and productivity.

I don't want to seem like I'm not a GUI user here - I absolutely am. I mix both script and GUI in how I deal with my own environments and test harnesses in addition to how things get done at customer sites. A good administrator knows when to use a tool, or what will be best in a given situation.

What are your thoughts and comments? Agree? Disagree? What are you seeing out there?

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.