Thinking through Exchange and SQL Virtualization (high level intro - more to come)

This won't be a deep dive on the technical issues that you need to cover in a virtualized Exchange/SQL solution. Rather, this is an initial caution to those people thinking about virtualizing those typically high-transaction systems.

First off, PLEASE remember that Microsoft simply doesn't support Exchange 2003, SQL 2000 or older in a virtualized system. SO DON'T DO IT! With that said, I am all about virtualizing those newer versions as long as you keep these primary things/questions in mind (I will dig in on these in later posts).

• What will be the new ('cause you don't want to keep using the current one) availability/recoverability strategy?
• How will you migrate existing servers and data? Just because you can P2V that server, doesn't mean you should! There are serious performance reasons we just don't do that all the time.
• Do you have an overall virtualization strategy for your datacenter? If not, then I would advise you take a step back and hold off on the tactical SQL/Exchange projects. Also, check out www.vmetc.com for some REALLY good info on virtualization from one of the most experienced VMWare experts around.
• How are your current performance metrics and what is your growth expectation for the next couple of years?

If you keep those questions/topics in mind as you start thinking about high-transaction systems, you will find that making the final call to virtualize or not will be easier. You will also find that the details (I will discuss later) as far as how much storage, how many spindles, how many and what type of servers, network conectivity, and licensing strategies will be much easier.

Cannot enable Intel VT-X feature on recent Gateway laptop

This might give some indication as to why it has been a while since the last post. I am trying my best to help my sales team, customers, and even myself become more educated on the many different editions of the Microsoft products.

It was bad enough before Vista, but now with the way too many numbers of Vista editions and the 32/64 bit differences, it is just getting to be too much to keep in one persons brain. So, I am at least going to dump some of the major points here. So you know, this is as much for my benefit as for anyone who actually reads my junk here.

Windows Server 2003 R2 Major point here - it moves to "extended support" 7/13/2010
32 bit Standard: 4GB RAM max, up to 4 procs, 2 node cluster
64 bit Standard: 32GB Ram max, up to 4 procs, 2 node cluster
32 bit Enterprise: 64GB Ram max, up to 8 procs, multi-node clusters
64 bit Enterprise: 2TB Ram max, up to 8 procs, multi-node clusters

SQL Server 2005 http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
32 bit Standard: 4 procs, OS max for memory, 2 node cluster support
64 bit Standard: um, yeah, it's the same for SQL - at least something is easy
32/64 bit Enterprise: unlimited procs, OS Max on Memory, multi-node clusters

With SQL there are a few additional features you get with Enterprise: Indexed views, database partioning, parallel index operations, and some good integration tools. Check the link above for the full set of feature diffs.

Office SharePoint Server
This one is kind of like SQL Server; it's pretty easy. There is actually no difference in Enterprise/Standard as far as the server goes. Also no difference in price tags. That the server though. The CALs (client access licenses) are where the differences come in.

The Standard CAL gives you all the workspaces, doc libs, lists, enterprise search, Records management, workflow, publishing features, profiles/my sites, and a bunch of the other well known SharePoint features.

The additive Enterprise CAL brings along Excel Calc Services, Froms Server, Report Center and the Business Data Catalog (BDC - not to be confused with the depricated backup domain controller).

Other Product CALs
Here is another cool link to see what features the CALs for the different products include: http://www.microsoft.com/calsuites/enterprise_product.mspx

I will try to add OCS and Exchange edition information a little later. I'm not too sure I will EVER add the Vista editions.

In the last post, I was clearly overjoyed with my new HTTP handler to deal with some PDF display issues. This thing worked exactly as I had hoped it would on my development box running from the IDE. Unfortunately, once I copied my code base up to the test server (um, actually that was my production server, but that's another issue) I no longer had a working HTTP handler. In fact, the test server (prod) simply dropped a 404 error where it should have shown a PDF via my handler.

So, the first thing I was thinking was that my abstract class for the handler was not being reconized on the test/prod box. So, strong named it, recompiled, updated the reference, added it as an assembly to the web.config, and finally (just for good measure) installed it into the GAC. Guess what? None of these things worked. Still getting the stupid 404.

Searched on Google, found little help. Searched on Google again, still found little help. Finally, found this little gem on the ASP.Net Forums: http://forums.asp.net/t/1177230.aspx. In case they drop this thread in the future, let me give you the gist: IIS has a little area that no matter what your web.config says to do, it just won't care. So, I opened up IIS on my problem machine, went to the properties of my web site, clicked on the "Configuration" button on the Directory tab, and finally added a new entry for PDF to point it to the aspnet_isapi.dll like all the other extensions listed in that box.

SOLVED and my lovely handler now renders my dynamic PDF files like a champ on my test (prod) system as well as in my IDE.

Well, as my previous post lamented, I had to do some clever CSS/HTML/JavaScript work arounds in a solution I am building to prevent undesirable user interaction with my site. And, it worked pretty well. Unfortunately, the PDF Viewer control I was using in there didn't!

Actually, let me be fair, it worked, just not completely for what I needed it to do. I need the users to laod a PDF into the IFrame by selecting the document in the list box right? No problem, that works. Now, if the user then selects the Save button in the PDF window, it needs to actually show the PDF file name in the Save text box on that window. This is where the 3rd party viewer tool and I completely disagree on things. It wants to ONLY use the base file name in the SRC property of the IFrame. This would be just fine and dandy if I were using static PDF files, but I am most certainly NOT. I have to render these PDF files out from a Database (by the way, this system is WAY cool). So, what happens is that the Save As shows my ASPX page name in the Save As text box. Not good. I don't want users seeing my page names unless I put them on that page myself. And, again to be fair, it isn't the controls fault, it is actually the Adobe Reader.

The solution: throw away that 3rd party tool, write my own HttpHandler, register the handler to cover all PDF files, and then fake the SRC tag of the iframe to point to a bogus PDF file with the name I want to show in the Save As box.

This solution gets my issue resolved, but it also gives me the ability to do SO much more. Now I can do all kinds of cool stuff with parameters on a PDF file that wouldn't have really been possible without that HttpHandler. And the best part: those handlers are a breeze to write. I will share some of that later.

Yes, I think I might just be. I recently went out to Best Buy and grabbed a brand new Gateway laptop. That right there comes close to qualifying me as crazy. I just haven't been a huge fan of the cow for a long time, so it hurt a little to buy that one. But, it was the ONLY 64 bit, 4GB RAM, 250GB HD I could find for under $800. So, it's mine.

The second issue is it has a Red outer shell. I am a Georgia Tech guy, so this too hurts too much to discuss further.

Next crazy thing, it came preloaded with (gulp) Vista Home Premium 64 bit. I like the 64 bit. Not too sure about Vista and REALLY not sure about Home stuff and not being able to join domains. OK, so I actually like the Vista OS now. And I REALLY love the 64 bit and 4GB RAM on it. And, hate the home premuim. It doesn't support Virtual Server 2005.

And finally, the thing that really makes me crazy: I am now watching my brand new PC, now loaded with all of my great tools/data already (about 2 days worth of effort), attempt to "upgrade" itself to Vista Ultimate 64 bit. Yep, taking a perfectly working Vista machine and screwing with it. I am TOTALLY nuts. The stuff I do just to have Virtual systems. I really am crazy.