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.

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.

The SharePoint Team announced a while back that there had been important changes to the MOSS for Internet Sites. This is definitely good news that makes licensing a little easier for some organizations. However, I think that a lot of people might be too excited about this possibility. There are a couple of reasons why I see this as a bad thing, both of which have nothing to do with this specific change in licensing. I do think the change was needed.

Reason #1 the change is bad: This change makes small to mid size companies think that they can just install a SharePoint server with the two licenses (normal/For Internet) and *poof* there is our extranet/public facing site. If only it were that simple. As with everything SharePoint, this scenario is much more complicated than that. As an example, how will authentication be handled for the external site? Where will the server be placed in the network? DMZ, outside the Firewall, inside the firewall? Of course each of those options presents its own little situation of issues too (outside scope of this post). My recommendation has always been that when you want an external/public SharePoint site, that you setup a separate farm anyway. This is primarily for security concerns. So, I think this licensing change just makes it more difficult for me to explain that the customer doesn't want to do a single server with both internal and external content. I mean "after all", the customer can say, "Microsoft obviously thinks this is a good model."

Reason #2 this is bad: The Microsoft community still cannot come to an agreement on how the Standard and Enterprise CALs should be licensed. Can the customer have some users with Standard only and others with Standard+Enterprise? The answer to that depends completely at this point on who at Microsoft you ask. In fact, I am still waiting on responses from a few different people HOPING for a definitive answer that isn't open to interpretation. Oh, let me tie in this current MOSS for Internet Sites issue. The MOSS for Internet Sites is ONLY sold with fully implemented enterprise features. So guess what, you install a server with it, but you only have licenses for standard for your internal users and suddenly you are now out of compliance with your CALs. Um, yeah, not bad enough that you had to fork out big bucks for that Internet Sites thing, but now you have to (well maybe anyway – depending on who you asked) go and buy Enterprise CALs for everybody even though you weren't really planning on using the BDC, Report Center, or Forms Server. Doesn't quite seem fair to me.

So, with those two biggie reasons why I don't like the change, I still think it is a good thing. Why? Well, it is nice to know I have the option at least to reduce the number of SharePoint servers I need in my deployments. So, instead of having an entirely separate farm, I could just do another server that gets placed out in the DMZ. This seems to be a better solution to me at first glance. Who knows, I might change my mind later. I am finicky that way .