Table 1: Maximum databases per Exchange editions

However, the Exchange Server edition is not directly tied to the Windows Server edition:

• For Exchange 2003 failover cluster mailbox servers, Exchange 2007 SCC/CCR environments [1], and  Exchange 2010 DAG environments, you need Windows Server Enterprise Edition in order to get the MSCS cluster component framework.
• For Exchange 2003 servers running purely as bridgeheads or front-end servers, or Exchange 2007/2010 HT, CAS, ET, and UM servers, you only need Windows Server Standard Edition.

I’ve seen some discussion around the fact that Exchange 2010 will install on Windows Server 2008 Datacenter Edition and Windows Server 2008 R2 Datacenter Edition, even though it’s not supported there and is not listed in the Operating System requirements section of the TechNet documentation.

HOWEVER…if we look at the Prerequisites for Exchange 2010 Server section of the Exchange Server 2010 Licensing site, we now see that Datacenter edition is, in fact listed as shown in Figure 1:

 Figure 1: Exchange 2010 server license comparison

This is pretty cool, and the appropriate TechNet documentation is in the process of being updated to reflect this. What this means is that you can deploy Exchange 2010 on Windows Server Datacenter Edition; the differences between editions of Windows Server 2008 R2 are found here.[2] If you take a quick scan through the various feature comparison charts in the sidebar, you might wonder why anyone would want to install Exchange 2010 on Windows Server Datacenter Edition; it’s more costly and seems to provide the same benefits. However, take a look at the technical specifications comparison; this is, I believe, the meat of the matter:

• Both editions give you a maximum of 2 TB – more than you can realistically throw at Exchange 2010.
• Enterprise Edition gives you support for a maximum eight (8) x64 CPU sockets, while Datacenter Edition gives you sixty-four (64). With quad-core CPUs, this means a total of 32 cores under Enterprise vs. 256 cores under Datacenter.
• With the appropriate hardware, you can hot-add memory in Enterprise Edition. However, you can’t perform a hot-replace, nor can you hot-add or hot-replace CPUs under Enterprise. With Datacenter, you can hot-add and hot-remove both memory and CPUs.

These seem to be compelling in many scenarios at first glance, unless you’re familiar with the recommended maximum configurations for Exchange 2010 server sizing. IIRC, the maximum CPUs that are recommended for most Exchange 2010 server configurations (including multirole servers) would be 24 cores – which fits into the 8 socket limitation of Enterprise Edition while using quad core CPUs.

With both Intel and AMD now offering hexa-core (6 core) CPUs, you can move up to 48 cores in Enterprise Edition. This is more than enough for any practical deployment of Exchange Server 2010 I can think of at this time, unless future service packs drastically change the CPU performance factors. Both Enterprise and Datacenter give you a ceiling of 2TB of RAM, which is far greater than required by even the most aggressively gigantic mailbox load I’d want to place on a single server. I’m having a difficult time seeing how anyone could realistically build out an Exchange 2010 server that goes beyond the performance and scalability limits of Enterprise Edition in any meaningful way.

In fact, I can think of only three reasons someone would want to run Exchange 2010 on Windows Server Datacenter Edition:

• You have spare Datacenter Edition licenses, aren’t going to use them, and don’t want to buy more Enterprise Edition licenses. This must be a tough place to be in, but it can happen under certain scenarios.
• You have a very high server availability requirements and require the hot-add/hot-replace capabilities. This will get costly – the server hardware that supports this isn’t cheap – but if you need it, you need it.
• You’re already running a big beefy box with Datacenter and virtualization[3]. The box has spare capacity, so you want to make use of it.

The first two make sense. The last one, though, I’d be somewhat leery of doing. Seriously, think about this – I’m spending money on monstrous hardware with awesome fault tolerance capabilities, I’ve forked over for an OS license[4] that gives me the right to unlimited virtual machines, and now I’m going to clutter up my disaster recovery operations by mixing Exchange and other applications (including virtualization) in the same host OS instance? That may be great for a lab environment, but I’d have a long conversation with any customer who wanted to do this under production. Seriously, just spin up a new VM, use Windows Server Enterprise Edition, and go to town. The loss of hardware configuration flexibility I get from going virtual is less than I gain by compartmentalizing my Exchange server to its own machine, along with the ability to move that virtual machine to any virtualization host I have.

So, there you have it: Exchange 2010 can now be run on Windows Server Datacenter Edition, which means yay! for options. But in the end, I don’t expect this to make a difference for any of the deployments I’m like to be working on. This is a great move for a small handful of customers who really need this.

[1] MSCS is not required for Exchange 2007 SCR, although manual target activation can be easier in some scenarios if your target is configured as a single passive node cluster.

[2] From what I can tell, the same specs seem to be valid for Windows Server 2008, with the caveat that Windows Server 2008 R2 doesn’t offer a 32-bit version so the chart doesn’t give that information. However, since Exchange 2010 is x64 only, this is a moot point.

[3] This is often an attractive option, since you can hosted an unlimited number of Windows Server virtual machines without having to buy further Windows Server licenses for them.

[4] Remember that Datacenter is not licensed at a flat cost per server like Enterprise is; it’s licensed per socket. The beefier the machine you run it on, the more you pay.

³⁴Then shall the King say unto them on his right hand, Come, ye blessed of my Father, inherit the kingdom prepared for you from the foundation of the world: ³⁵For I was an hungred, and ye gave me meat: I was thirsty, and ye gave me drink: I was a stranger, and ye took me in: ³⁶Naked, and ye clothed me: I was sick, and ye visited me: I was in prison, and ye came unto me. ³⁷Then shall the righteous answer him, saying, Lord, when saw we thee an hungred, and fed thee? or thirsty, and gave thee drink? ³⁸When saw we thee a stranger, and took thee in? or naked, and clothed thee? ³⁹Or when saw we thee sick, or in prison, and came unto thee? ⁴⁰And the King shall answer and say unto them, Verily I say unto you, Inasmuch as ye have done it unto one of the least of these my brethren, ye have done it unto me.

⁴¹Then shall he say also unto them on the left hand, Depart from me, ye cursed, into everlasting fire, prepared for the devil and his angels: ⁴²For I was an hungred, and ye gave me no meat: I was thirsty, and ye gave me no drink: ⁴³I was a stranger, and ye took me not in: naked, and ye clothed me not: sick, and in prison, and ye visited me not. ⁴⁴Then shall they also answer him, saying, Lord, when saw we thee an hungred, or athirst, or a stranger, or naked, or sick, or in prison, and did not minister unto thee? ⁴⁵Then shall he answer them, saying, Verily I say unto you, Inasmuch as ye did it not to one of the least of these, ye did it not to me. ⁴⁶And these shall go away into everlasting punishment: but the righteous into life eternal.

Rush Limbaugh may have forgotten the above as well. His claims that Obama is using humanitarian aid for political profit definitely seem to have forgotten Matthew 7:15-20:

15 Beware of false prophets, which come to you in sheep’s clothing, but inwardly they are ravening wolves. 16 Ye shall know them by their fruits. Do men gather grapes of thorns, or figs of thistles? 17 Even so every good tree bringeth forth good fruit; but a corrupt tree bringeth forth evil fruit. 18 A good tree cannot bring forth evil fruit, neither can a corrupt tree bring forth good fruit. 19 Every tree that bringeth not forth good fruit is hewn down, and cast into the fire. 20 Wherefore by their fruits ye shall know them.

If that last passage seems a bit murky, here’s a quote from C. S. Lewis’s The Last Battle (the last book of the Chronicles of Narnia) that I have always loved. The speaker is a Calormene soldier, Emeth, who has had a life-changing encounter with Aslan during the last hours of Narnia:

He answered, Child, all the service thou hast done to Tash, I account as service done to me. Then by reasons of my great desire for wisdom and understanding, I overcame my fear and questioned the Glorious One and said, Lord, is it then true, as the Ape said, that thou and Tash are one? The Lion growled so that the earth shook (but his wrath was not against me) and said, It is false. Not because he and I are one, but because we are opposites, I take to me the services which thou hast done to him. For I and he are of such different kinds that no service which is vile can be done to me, and none which is not vile can be done to him. Therefore if any man swear by Tash and keep his oath for the oath’s sake, it is by me that he had truly sworn, though he know it not, and it is I who reward him. And if any man do a cruelty in my name, then, though he says the name Aslan, it is Tash whom he serves and by Tash his deed is accepted. Dost thou understand, Child?

By their fruits ye shall know them…whatever their claims.

That’s exactly where Google wants you to focus.

Let’s take a closer look at their blog post.

Paragraph 1:

In mid-December, we detected a highly sophisticated and targeted attack on our corporate infrastructure originating from China that resulted in the theft of intellectual property from Google.

Paragraph 2:

As part of our investigation we have discovered that at least twenty other large companies from a wide range of businesses–including the Internet, finance, technology, media and chemical sectors–have been similarly targeted.

Whoa. That’s some heavy-league stuff right there. Coordinated, targeted commercial espionage across a variety of vertical industries. Google first accuses China of stealing its intellectual property, then says that they weren’t the only ones. Mind you, industry experts – including the United States government– have been saying the same thing for years. Cries of ‘China hacked us!” happen relatively frequently in the IT security industry, enough so that it blends into the background noise after awhile.

My question is why, exactly, Google thought this wouldn’t happen to them? They’re a big fat juicy target on many levels. Gmail with thousands upon thousands of juicy mailboxes? Check! Search engine code and data that allows sophisticated monitoring and manipulation of Internet queries? Check! Cloud-based office documents that just might contain some competitive value? Check!

My second question is, why, exactly, is Google trying to shift the focus of the story from the IP theft (which by their own press report was successful) and cloak their actions in the “oh, noes, China tried to grab dissidents’ email” moral veil they’re using?

Paragraph 3:

Second, we have evidence to suggest that a primary goal of the attackers was accessing the Gmail accounts of Chinese human rights activists. Based on our investigation to date we believe their attack did not achieve that objective. Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves.

Two accounts, people, and the attempt wasn’t even fully successful. And the moral outrage shimmering from the screen in Paragraph 4, when Google says that “dozens” of accounts were accessed by third parties not through any sort of security flaw in Google, but rather through what is probably malware, is enough to knock you over.

Really, Google? You’re just now tumbling to the fact that people’s GMail accounts are getting hacked through malware?

I don’t buy the moral outrage. I think the meat of the matter is back in paragraph 1. I believe that the rest of the outrage is a smokescreen to repaint Google into the moral high ground for their actions, when from the sidelines here it certainly looks like Google chose knowingly to play with fire and is now suddenly outraged that they, too, got burned.

Google, you have enough people willing to play along with your attempt to be the victim. I’m not one of them. You compromised human rights principles in 2006 and knowingly put your users into harm’s way. “Do no evil,” my ass.

In the interests of full disclosure, the company I work for now is a strong NetApp reseller, so of course my work environment is conducive to designing Exchange in ways that make it easy to sell the strengths of NetApp kit. However, part of the reason I picked this job is precisely because I agree with how they address Exchange storage and how I think the Exchange storage paradigm is going to shake out in the next 3-5 years as more people start deploying Exchange 2010.

In Exchange 2010, Microsoft re-designed the Exchange storage system to target what we can now consider to be the lowest common denominator of server storage: a directly attached storage (DAS) array of 7200 RPM SATA disks in a Just a Box of Disks (JBOD) configuration. This DAS/JBOD/SATA (what I will now call DJS) configuration has been an unworkable configuration for Exchange for almost its entire lifetime:

• The DAS piece certainly worked for the initial versions of Exchange; that’s what almost all storage was back then. Big centralized SANs weren’t part of the commodity IT server world, reserved instead for the mainframe world. Server administrators managed server storage. The question was what kind of bus you used to attach the array to the server. However, as Exchange moved to clustering, it required some sort of shared storage. While a shared SCSI bus was possible, it not only felt like a hack, but also didn’t scale well beyond two nodes.
• SATA, of course, wasn’t around back in 1996; you had either IDE or SCSI. SCSI was the serious server administrator’s choice, providing better I/O performance for server applications, as well as faster bus speeds. SATA, and its big brother SAS, both are derived from the lessons that years of SCSI deployments have provided. Even for Exchange 2007, though, SATA’s poor random I/O performance made it unsuitable for Exchange storage. You had to use either SAS or FC drives.
• RAID has been a requirement for Exchange deployments, historically, for two reasons: to combine enough drive spindles together for acceptable I/O performance (back when disks were smaller than mailbox databases), and to ensure basic data redundancy. Redundancy was especially important once Exchange began supporting shared storage clustering and required both aggregate I/O performance only achievable with expensive disks and interfaces as well as the reduced chance of a storage failure being a single point of failure.

If you look at the marketing material for Exchange 2010, you would certainly be forgiven for thinking that DJS is the only smart way to deploy Exchange 2010, with SAN, RAID, and non-SATA systems supported only for those companies caught in the mire of legacy deployments. However, this isn’t at all true. There are a growing number of Exchange experts (and not just those of us who either work for storage vendors or resell their products) who think that while DJS is certainly an interesting option, it’s not one that’s a good match for every customer.

In order to understand why DJS is truly possible in Exchange 2010, and more importantly begin to understand where DJS configurations are a good fit and what underlying conditions and assumptions you need to meet in order to get the most value from DJS, we need to separate these three dimensions and discuss them separately.

While I will go into more detail on all three dimensions at later date, I want to focus on the JBOD vs.. RAID question now. If you need some summaries, then check out fellow Exchange MVP (and NetApp consultant) John Fullbright’s post on the economics of DAS vs. SAN as well as Microsoft’s Matt Gossage and his TechEd 2009 session on Exchange 2010 storage. Although there are good arguments for diving into drive technology or storage connection debates, I’ve come to believe that the central philosophy question you must answer in your Exchange 2010 design is at what level you will keep your data redundant. Until Exchange 2007, you had only one option: keeping your data redundant at the disk controller level. Using RAID technologies, you had two copies of your data[1]. Because you had a second copy of the data, shared storage clustering solutions could be used to provide availability for the mailbox service.

With Exchange 2007’s continuous replication features, you could add in data redundancy at the application level and avoid the dependency of shared storage; CCR creates two copies, and SCR can be used to create one or more additional copies off-site. However, given the realities of Exchange storage, for all but the smallest deployments, you had to use RAID to provide the required number of disk spindles for performance. With CCR, this really meant you were creating four copies; with SCR, you were creating an additional two copies for each target replica you created.

This is where Exchange 2010 throws a wrench into the works. By virtue of a re-architected storage engine, it’s possible under specific circumstances to design a mailbox database that will fit on a single drive while still providing acceptable performance. The reworked continuous replication options, now simplified into the DAG functionality, create additional copies on the application level. If you hit that sweet spot of the 1:1 database to disk ratio, then you only have a single copy of the data per replica and can get an n-1 level of redundancy, where n is the number of replicas you have. This is clearly far more efficient for disk usage…or is it? The full answer is complex, the simple answer is, “In some cases.”

In order to get the 1:1 database to disk ratio, you have to follow several guidelines:

1. Have at least three replicas of the database in the DAG, regardless of which sites they are in. Doing so allows you to place both the EDB and transaction log files on the same physical drive, rather than separating them as you did in previous versions of Exchange.
2. Ensure that you have at least two replicas per site. The reason for this is that unlike Exchange 2007, you can reseed a failed replica from another passive copy. This allows you to avoid reseeding over your WAN, which is something you do not want to do.
3. Size your mailbox databases to include no more users than will fit in the drive’s performance envelope. Although Exchange 2010 converts many of the random I/O patterns to sequential, giving better performance, not all has been converted, so you still have to plan against the random I/O specs.
4. Ensure that write transactions can get written successfully to disk. Use a battery-backed caching controller for your storage array to ensure the best possible performance from the disks. Use write caching for the physical disks, which means ensuring each server hosting a replica has a UPS.

At this point, you probably have disk capacity to spare, which is why Exchange 2010 allows the creation of archive mailboxes in the same mailbox database. All of the user’s data is kept at the same level of redundancy, and the archived data – which is less frequently accessed than the mainline data – is stored without additional significant disk or I/O penalty. This all seems to indicate that JBOD is the way to go, yes? Two copies in the main site, two off-site DR copies, and I’m using cheaper storage with larger mailboxes and only four copies of my data instead of the minimum of six I’d have with CCR+SCR (or the equivalent DAG setup) on RAID configurations.

Not so fast. Microsoft’s claims around DJS configurations usually talk about the up-front capital expenditures. There’s more to a solid design than just the up-front storage price tag, and even if the DJS solution does provide savings in your situation, that is only the start. You also need to think about the lifetime of your storage and all the operational costs. For instance, what happens when one of those 1:1 drives fails?

Well, if you bought a really cheap DAS array, your first indication will be when Exchange starts throwing errors and the active copy moves to one of the other replicas. (You are monitoring your Exchange servers, right?) More expensive DAS arrays usually directly let you know that a disk failed. Either way, you have to replace the disk. Again, with a cheap white-box array, you’re on your own to buy replacement disks, while a good DAS vendor will provide replacements within the warranty/maintenance period. Once the disk is replaced, you have to re-establish the database replica. This brings us to the wonderful manual process known as database reseeding, which is not only a manual task, but can take quite a significant amount of time – especially if you made use of archival mailboxes and stuffed that DJS configuration full of data. If we can reseed 20GB of data per hour[2] (from a local passive copy to avoid the I/O hit to the active copy), that’s 10 hours for a 200GB database or 50 hours – over two days! – for a 1 TB database. All during that time, you have one less replica of that database to protect you. If your business processes and requirements don’t give you that amount of leeway, you either have to design smaller databases (and waste the disk capacity, which brings us right back to the good old bad days of Exchange 2000/2003 storage design) or use RAID.

Now, with a RAID solution, we don’t have that same problem. We still have a RAID volume rebuild penalty, but that’s happening inside the disk shelf at the controller, not across our network between Exchange servers. And with a well-designed RAID solution such as generic RAID 10 (1+0) or NetApp’s RAID DP, you can actually survive the loss of more disks at the same time. Plus, a RAID solution gives me the flexibility to populate my databases with smaller or larger mailboxes as I need, and aggregate out the capacity and performance across my disks and databases. Sure, I don’t get that nice 1:1 disk to database ratio, but I have a lot more administrative flexibility and can survive disk loss without automatically having to begin the reseed dance.

Don’t get me wrong – I’m wildly enthusiastic that I as an Exchange architect have the option of designing to JBOD configurations. I like having choices, because that helps me make the right decisions to meet my customers’ needs. And that, in the end, is the point of a well-designed Exchange deployment – to meet your needs. Not the needs of Microsoft, and not the needs of your storage or server vendors. While I’m fairly confident that starting with a default NetApp storage solution is the right choice for many of the environments I’ll be facing, I also know how to ask the questions that lead me to consider DJS instead. There’s still a place for RAID at the Exchange storage table.

In further installments over the next few months, I’ll begin to address the SATA vs. SAS/VC and DAS vs. SAN arguments as well. I’ll then try to wrap it up with a practical and realistic set of design examples that pull all the pieces together.

[1] RAID-1 (mirroring) and RAID-10 (striping and mirroring) both create two physical copies of the data. RAID-5 does not, but it allows the loss of a single drive failure — effectively giving you a virtual second copy of the data.

[2] I don’t yet have solid data on how fast reseeds are in real-world conditions, so this number is an educated guess. I do believe, however, it’s a higher rate than what you’d see in most circumstances.

I wish I could change the RAM, CPU configuration on running VMs in #VMWare and have the changes apply on next reboot.

This prompted one of my nieces, a lovely and intelligent young lady in high school, to ask me to say that in English.

I pondered just hand waving it, but I was loathe to do so. Like I said, she’s intelligent. I firmly believe that kids live up to your expectations; if you talk down to them and treat them like they’re dumb because that’s what you expect, they’re happy to be that way. On the other hand, if you expect them to be able to understand concepts with the proper explanations, even if they may not immediately grasp the fine points, I’ve found that kids are actually quite able to do so – better than many adults, truth be told.

So, this is my answer:

The physical machinery of computers is called hardware. The programs that run on them (Windows, games, etc.) is software.
VMware is software that allows you to create virtual machines. That is, instead of buying (for example) 10 computers to do different tasks and have most of them have unused memory and processor power, you buy one or two really beefy computers and run VMWare. That allows you to create a virtual machine in software, so those two computers become 10. I don’t have to buy quite as much hardware because each virtual machine only uses the resources it needs, leaving the rest for the other virtual machines.

However, one of the problems with VMWare currently is that if you find you’ve given a virtual machine too much memory or processor (or not enough), you have to shut it down, make the change, then start it back up. I want the software to be smart enough to take the change *now* and automatically apply it when it can, such as when the virtual machine is rebooting. For a physical computer, it makes sense — I have to power it down, crack the case open, put memory in, etc. — but for a virtual computer, it should be able to be done in software.

Think of it this way: hardware is like a closet. You can build a big closet or a small closet or a medium closet, but each closet holds a finite amount of stuff. Software is the stuff you put in the closet — clothes, shoes, linens, etc. You can dump a bunch of stuff into a big closet, but doing so makes it cluttered and hard to use. So if you use multiple smaller closets, you’re wasting space because you probably won’t fill every one exactly.

In this metaphor, virtualization is like a closet organizer system. You can add a clothing rod here to hang dresses and blouses on, and underneath that add a shelf or two for shoes, while to the side you have more shelves for pants and towels and other stuff. You waste a little bit of your closet space for the organizer, but you keep everything organized and clutter-free, which means you’re better off and take less time to keep everything up.

Of course, this metaphor fails on my original point, because it totally makes sense you have to take all the stuff off shelves before moving those shelves around. In the world of software, though, it doesn’t necessarily make sense — it’s just the right people didn’t think of it at the right time.

Clear?

I came close to busting out Visio and starting to diagram some of this. I decided not to.

Edit: I don’t have to diagram it! Thank you, Ikea, and your lovely KOMPLEMENT wardrobe organizer line!

First, we have confirmation that his naughty and nice database has been hacked.

Now, there are credible rumors that the North Pole CIO has been covering up a years-long, systemic problem with Santa losing mobile devices. According to unidentified sources, the list of allegations includes:

• Lack of priority for safeguarding key data, especially through mobile systems. Recent refits for the sled have focused on tracking transponders for “greater publicity”, but no corresponding upgrades to mobile IT systems. These systems are specifically characterized as “obsolete 286 systems running DOS and home-brew Paradox applications written by some dentist in his spare time.”
• Habitual problems with smartphones. In order to ensure inexpensive world-wide access, Santa’s system includes the use of multiple handsets from strategically selected regional carriers. “In the last several years, Santa has yet to come back from his Christmas Eve run without having lost at least three of his devices,” one insider claims, “and of course we don’t have remote wipe capabilities. That would require him spending money.”
• Lax information and network practices, including no formal security policies or processes. Remote accesses aren’t even protected via SSL, according to sources, since “anyone who’s so cheap they haven’t updated stock PR footage of elves making wooden toys isn’t likely to shell out for a respected SSL certificate or PKI infrastructure.”

It will take time to gather confirmation of these claims, but if they are true, it shows a shocking disregard for basic security best practices at the North Pole.

At any rate, I’m back with some cool Exchange blogging. I’ve been getting a chance to dive into a “All-Devin, All-Exchange, All The Time” groove and it’s been a lot of fun, some of the details of which I hope to be able to share with you in upcoming months. In the process, I’ve been building a brand new Exchange 2010 lab environment and ran smack into a myth that seems to be making the rounds among people who are deploying Exchange 2010. This myth gives bum advice for those of you who are deploying an Exchange 2010 DAG and not using an Exchange 2010 Hub Transport as your File Share Witness (FSW). I call it the Exchange Trusted Subsystem Myth, and the first hint of it I see seems to be on this blog post. However, that same advice seems to have gotten around the net, as evidenced by this almost word-for-word copy or this posting that links to the first one. Like many myths, this one is pernicious not because it’s completely wrong, but because it works even though it’s wrong.

If you follow the Exchange product group’s deployment assumptions, you’ll never run into the circumstance this myth addresses; the FSW is placed on an Exchange 2010 HT role in the organization. Although you can specify the FSW location (server and directory) or let Exchange pick a server and directory or you, the FSW share isn’t created during the configuration of the DAG (as documented by fellow Exchange MVP Elan Shudnow and the “Witness Server Requirements” section of the Planning for High Availability and Site Resilience TechNet topic). Since it’s being created on an Exchange server as the second member of the DAG is joined, Exchange has all the permissions it needs on the system to create the share. If you elect to put the share on a non-Exchange server, then Exchange doesn’t have permissions to do it. Hence the myth:

1. Add the FSW server’s machine account to the Exchange Trusted Subsystem group.
2. Add the Exchange Trusted Subsystem group to the FSW server’s local Administrators group.

The sad part is, only the second action is necessary. True, doing the above will make the FSW work, but it will also open a much wider hole in your security than you need or want. Let me show you from my shiny new lab! In this configuration, I have three Exchange systems: EX10MB01, EX10MB02, and EX10MB03. All three systems have the Mailbox, Client Access, and Hub Transport roles. Because of this, I want to put the FSW on a separate machine. I could have used a generic member server, but I specifically wanted to debunk the myth, so I picked my DC EX10DC01 with malice aforethought.

• In Figure 1, I show adding the Exchange Trusted Subsystem group to the Builtin/Administrators group on EX10DC01. If this weren’t a domain controller, I could add it to the local Administrators group instead, but DCs require tinkering. [1]

Figure 1: Membership of the Builtin/Administrators group on EX10DC01

• In Figure 2, I show the membership of the Builtin/Administrators group on EX10DC01. No funny business up my sleeve!

Figure 2: Membership of the Exchange Trusted Subsystem group

• I now create the DAG object, specifying EX10DC01 as my FSW server and the C:\EX10DAG01 directory so we can see if it ever gets created (and when).
• In Figure 3, I show the root of the C:\ drive on EX10DC01 after adding the second Exchange 2010 server to the DAG. Now, the directory and share are created, without requiring the server’s machine account to be added to the Exchange Trusted Subsystem group.

Figure 3: The FSW created on EX10DC01

I suspect that this bad advice came about through a combination of circumstances, including an improper understanding of Exchange caching of Active Directory information and when the FSW is actually created. However it came about, though, it needs to be stopped, because any administrator that configures their Exchange organization is opening a big fat hole in the Exchange security model.

So, why is adding the machine account to the Exchange Trusted Subsystem group a security hole? The answer lies in Exchange 2010’s shift to Role Based Access Control (RBAC). In previous versions of Exchange, you delegated permissions directly to Active Directory and Exchange objects, allowing users to perform actions directly from their security context. If they had the appropriate permissions, their actions succeeded.

In Exchange 2010 RBAC, this model goes away; you now delegate permissions by telling RBAC what options given groups, policies, or users can perform, then assigning group memberships or policies as needed. When the EMS cmdlets run, they do so as the local machine account; since the local machine is an Exchange 2010 server, this account has been added to the Exchange Trusted Subsystem group. This group has been delegated the appropriate access entries in Active Directory and Exchange databases objects, as described in the Understanding Split Permissions TechNet topic. For a comprehensive overview of RBAC and how all the pieces fit together, read the Understanding Role Based Access Control TechNet topic.

By improperly adding a non-Exchange server to this group, you’re now giving that server account the ability to read and change any Exchange-related object or property in Active Directory or Exchange databases. Obviously, this is a hole, especially given the relative ease with which one local administrator can get a command line prompt running as one of the local system accounts.

So please, do us all a favor: if you ever hear or see someone passing around this myth, please, link them here.

Busted!

[1] Yes, it is also granting much broader permissions than necessary to make a DC the FSW node. Now the Exchange Trusted Subsystem group is a member of the Domain Admins group. This is probably not what you want to do, so really, don’t do this outside of a demo lab.

I love living in the future. First, though, watch this video that Alaric and I made.

I was a Boy Scout for close to three years. I started as a Boy Scout; I missed Cub Scouts, including Webelos Scout. When I was in Scouting, we had to go door-to-door to do our fundraisers, or spend a lot of time with our relatives over the phone. I hated doing it, for reasons that didn’t become clear until much later in life when I began grappling with autism and Asperger’s. However, I have a lot of good memories of Scouting; it did a lot for me and it was a valuable part of my childhood.

Steph and I wanted Alaric to experience Scouting. Even though the modern BSA has some characteristics that I don’t agree with, I’ve come to the decision that first and foremost, Scouting is about the boys. Scouting needs intelligent, reasonable adults of all persuasions to help drive the program. By being part of Scouting, Alaric will learn and do things Steph and I can’t give him on our own; by having us there with him, Alaric will learn how to deal with people from differing backgrounds in a diplomatic and productive manner.

Over the summer, Alaric has really seen what a good thing Scouting is. He even got me to go to Scout Camp with him for four days in July, and I must admit I even had fun. It was a great experience for both of us, including facing down and conquering some challenges.

Unlike many Scout packs and troops, Alaric’s pack works on the schedule of the school year. As a result, they do their major fundraising push at the beginning of the school year with a number of activities. Alaric’s already helped out pulling Hire-A-Scout wagons at the local auto swap meet and had a great time. However, the major source of operating funds is the traditional Trail’s End popcorn fundraiser. Trail’s End, if you don’t know, has been the go-to-source for Scout fundraising for a long time, and they offer some of the best popcorn on the planet.

Over the past few weeks, we’ve been rather hectic and busy and haven’t really had time to coach Alaric on his first door-to-door sales campaign. (Poor guy seems to have the same issues I did when I was his age, so it was pretty painful.) This last week, I came up with what is I hope a brainstorm: harness the power of the Internet to get Alaric’s sales pitch out there. So, you get to enjoy the results: the following video where Alaric and I pitch popcorn to YOU, the faithful reader. And because this is the future, Trail’s End even got with the program: they now allow you to purchase online, supporting a specific Scout, and have the product shipped directly to your door!

Go to Trail’s End to support Alaric’s fundraising for his pack

Thank you for your support!

I think that the Ecclesiastes 3:1 says it best; in the King James Version, the poet says, “To every thing there is a season, and a time to every purpose under the heaven.” It has been my privilege to use this blog to talk about Exchange, data protection, and all the other topics I’ve talked about since my first post here five years ago (holy crap, has it really been five years???) With 3Sharp’s gracious permission and blessing, I’ll be duplicating all of the content I’ve posted here over on my personal blog, Devin on Earth. If you have a link or bookmark for this blog or are following me via RSS, please take a moment to update it now (Devin on Earth RSS feed). I’ve got a few new posts cooking, but this will be my last post here.

Thank you to 3Sharp and the best damn co-workers I could ever hope to work with over the years. Thank you, my readers. You all have helped me grow and solidify my skills, and I hope I returned the favor. I look forward to continuing the journey with many of you, even if I’m not sure yet where it will take me.

Yes, that’s right, zombies. The RAHR-BRAINS-RAHR shambling undead kind, not the “mystery objects in Active Directory” kind.

Well, now you can see what I was up to.

I was working with long-time fellow 3Sharpie David Gerhardt on creating a series of 60-second vignettes for the upcoming Office 2010 application suite. Each vignette focuses on a single new area of functionality in one of the Office products. I got to work with OneNote 2010.

Here’s where the story gets good.

I got brought into the project somewhat late, after a bunch of initial planning and prep work had been done. The people who had been working on the project had decided that they didn’t want to do the same boring business-related content in their OneNote 2010 vignettes; oh, no! Instead, they hit upon the wonderful idea of using a Zombie Plan as the base document. Now, I don’t really like zombies, but this seemed like a great way to spice up a project!

The rest, as they say, is history. Check out the results (posted both at GetSharp and somewhere out on YouTube) for yourself:

• OneNote 2010 Advanced Wiki Features
• OneNote 2010 Linked Notes
• OneNote 2010 Quick Filing
• OneNote 2010 Search UI

One of the best parts of this project, other than getting a chance to learn about some of the wildly cool stuff the OneNote team is doing to enhance an already wonderful product, was the music selection. We worked a deal with local artist Dave Pezzner to use some of his short music clips for these videos. Dave is immensely talented and provided a wide selection of material, so I enjoyed being able to pick and choose just the right music for each video. It did occur to me how cool it would be if I could use Jonathan Coulton’s fantastic song Re: Your Brains, but somehow I think his people lost my query email. Such is life – and I think Mr. Pezzner’s music provided just the right accompaniment to the Zombie Plan content.

Enjoy!

To head off some of the obvious questions:

• This is not a horrible thing. 3Sharp and I are parting ways peacefully because it’s the right decision for all of us; they need to focus on SharePoint, and I’m so not a SharePoint person. They’ve done fantastic things for my career and I cherish my time with them, but part of being an adult is knowing when to move on. We’re all agreed that time has come.
• I’m not quite sure where I’m going to end up yet. I’ve got a couple of irons in the fire and I have high hopes for them, but it’s not time to talk about them. I am going to have at least a week or two of time off, which is good; there are several projects at home in dire need of sustained attention (unburying my home office, for one; fixing a balky Exchange account for another).
• I’m not going to be a complete shut-in. I’ve got a couple of appointments for the following week, including a Microsoft focus group and a presentation on PowerPoint for Treanna’s English class. I’m open to doing some short-term independent consulting or contracting work as well, so contact me if you know someone who needs some Exchange help.

Thank you to 3Sharp and the best damn co-workers I could ever hope to work with over the years – and a huge thank you to all of my readers, regardless of which blog you’ve been following. The last several years have been a wild ride, and I look forward to continuing the journey with many of you, even if I’m not sure yet where it will take me.

Starting in September, the YMCA agreed to try out dropping class fees for YMCA members, and as you might imagine, we immediately saw a small but steady wave of new sign-ups for class. As a result, for the first time in a while, we have a good number of new students – white belts. As a result, we spend a large chunk of class time going back over many of the basic techniques in more detail than we’ve gotten used to. Those of us who are higher belts get to work with the white belts one-on-one during many of these exercises. This proves beneficial to everyone – they get a personal workout, and we get a mirror to more clearly see how well we’ve mastered the basics (or not, as it usually happens).

The first blessing was working with a gentleman who has been in class somewhere around a month. He and I were working through one-step exercises: one person performs a basic punch attack while the other defends, then we switch roles. We do this with seven defenses. As you work through the ranks, the defense techniques get more complicated, but for white belt one-steps, it’s pretty simple. Or so it seems now after a year; they were quite challenging when I first started and I got to re-experience that working with this gentleman. During our practice, he had one of those epiphany moments and what had been a struggle suddenly turned into AHA! with a clarity we both felt. It was an honor to be working with him in that moment.

The second blessing came about indirectly because of some misbehavior. You see, our protocol and customs direct us to pay attention and not engage in side conversations or monkey business when sensei is teaching. (Turns out there are no exceptions for “if you think you already know this” or “if you’re bored.” I checked. Who knew?) Well, several of us – including me and Treanna – weren’t quite paying attention to that one, and the senior student got called on it. I later told Treanna that he’d taken one for the team; we all were equally guilty of inattention. As class was drawing to an end, though, Treanna engaged in another breach of protocol that earned her some gentle ribbing. (She might read this, so I won’t tell you what she did. This time.)

Being a vigilant father and role model, I immediately realized we had what the experts call “a teachable moment” here. So we cracked open our karate notebooks and made a date to come back tonight after dinner, both having read the protocols, and discuss what we’d found:

• There are three basic sets of protocol in our notebook: white belt (people who’ve just joined), blue belt (9th kyu, or your first belt), and orange belt (7th kyu, or your third belt). After reading them, we decided that they all have the common themes of respect, safety, and responsibility.
• We think that white belt protocol focuses mainly on the what habits I need to become a student (discipline). That is, all of the guidance seems to be directed more at helping the newcomer gain the structures he will need to effectively learn karate.
• We think that blue belt protocol focuses mainly on how I become a member of the community (identity). This comes after the first belt (typically earned after several months) and the guidance is more focused on becoming aware of and fitting into the dojo structure.
• Finally, we think that orange belt protocol focuses mainly on how I give back to the community (service). This comes after three belts and around a year of study – a good foundation from which to be able to start learning to progress by helping others.
• As a final note, we saw that there was no specific protocol for further belts. We speculate that’s because the student in green and brown belts is expected to do the same things she is already doing, just to a greater degree. And once she gets to black belt – that’s a watershed mark, and sensei will teach us what is expected of us on that day at the proper time.

If you’re not in a martial art, that’s probably boring and generic. To Treanna and I, though, it seemed pretty profound, and I think we’ll walk back into class tomorrow with a new-found sense of focus and commitment.

By now you should be aware that Microsoft strongly recommends that you publish Exchange 2010/2007 client access servers (and Exchange 2003/2000 front-end servers) to the Internet through a reverse proxy like Microsoft’s Internet Security and Acceleration Server 2006 SP1 (ISA) or the still-in-beta Microsoft Forefront Threat Management Gateway (TMG). There are other reverse proxy products out there, such as the open source Squid (with some helpful guides on how to configure it for EAS, OWA, and Outlook Anywhere), but many of them can only be used to proxy the HTTP-based protocols (for example, the reverse proxy module for the Apache web server) and won’t handle the RPC component of Outlook Anywhere.

When you’re following this recommendation, you keep your Exchange CAS/HT/front-end servers in your private network and place the ISA Server (or other reverse proxy solution) in your perimeter (DMZ) network. In addition to ensuring that your reverse proxy is scrubbing incoming traffic for you, you can also gain another benefit: SSL bridging. SSL bridging is where there are two SSL connections – one between the client machine and the reverse proxy, and a separate connection (often using a different SSL certificate) between the reverse proxy and the Exchange CAS/front-end server. SSL bridging is awesome because it allows you radically reduce the number of commercial SSL certificates you need to buy. You can use Windows Certificate Services to generate and issue certificates to all of your internal Exchange servers, creating them with all of the Subject Alternate Names that you need and desire, and still have a commercial certificate deployed on your Internet-facing system (nice to avoid certificate issues when you’re dealing with home systems, public kiosks, and mobile devices, no?) that has just the public common namespaces like autodiscover.yourdomain.tld and mail.yourdomain.tld (or whatever you actually use).

In the rest of this article, I’ll be focusing on ISA because, well, I don’t know Squid that well and haven’t actually seen it in use to publish Exchange in a customer environment. Write what you know, right?

One of the most irritating experiences I’ve consistently had when using ISA to publish Exchange securely is getting the certificate configuration on ISA correct. If you all want, I can cover certificate namespaces in another post, because that’s not what I’m talking about – I actually find that relatively easy to deal with these days. No, what I find annoying about ISA and certificates is getting all of the proper root CA certificates and intermediate CA certificates in place. The process you have to go through varies on who you buy your certificates from. There are a couple, like GoDaddy, that offer inexpensive certificates that do exactly what Exchange needs for a decent price – but they require an extra bit of configuration to get everything working.

The problem you’ll see is two-fold:

1. External clients will not be able to connect to Exchange services. This will be inconsistent; some browsers and some Outlook installations (especially those on new Windows installs or well-updated Windows installs) will work fine, while others won’t. You may have big headaches getting mobile devices to work, and the error messages will be cryptic and unhelpful.
2. While validating your Exchange publishing rules with the Exchange Remote Connectivity Analyzer (ExRCA), you get a validation error on your certificate as shown in Figure 1.

Figure 1: Missing intermediate CA certificate validation error in ExRCA

The problem is that some devices don’t have the proper certificate chain in place. Commercial certificates typically have two or three certificates in their signing chain: the root CA certificate, an intermediate CA certificate, and (optionally) an additional intermediate CA certificate. The secondary intermediate CA certificate is typically the source of the problem; it’s configured as a cross-signing certificate, which is intended to help CAs transition old certificates from one CA to another without invalidating the issued certificates. If your certificate was issued by a CA that has these in place, you have to have both intermediate CA certificates in place on your ISA server in the correct certificate stores.

By default, CAs will issue the entire certificate chain to you in a single bundle when they issue your cert. You have to import this bundle on the machine you issued the request from or else you don’t get the private key associated with the certificate. Once you’ve done that, you need to re-export the certificate, with the private key and its entire certificate chain, so that you can import it in ISA. This is important because ISA needs the private key so it can decrypt the SSL session (required for bridging), and ISA needs all the certificate signing chain so that it can hand out missing intermediate certificates to devices that don’t have them (such as Windows Mobile devices that have the root CA certificates). If the device doesn’t have the right intermediates, can’t download it itself (like Internet Explorer can), and can’t get it from ISA, you’ll get the certificate validation errors.

Here’s what you need to do to fix it:

• Ensure that your server certificate has been exported with the private key and *all* necessary intermediate and root CA certificates.
• Import this certificate bundle into your ISA servers. Before you do this, check the computer account’s personal certificate store and make sure any root or intermediate certificates that got accidentally imported there are deleted.
• Using the Certificate MMC snap-in, validate that the certificate now shows as valid when browsing the certificate on your ISA server, as shown in Figure 2.

Figure 2: A validated server certificate signing chain on ISA Server

• IMPORTANT STEP: restart the ISA Firewall Service on your ISA server (if you’re using an array, you have to do this on each member; you’ll want to drain the connections before restarting, so it can take a while to complete). Even though the Certificate MMC snap-in validates the certificate, the ISA Firewall only picks up the changes to the certificate chain on startup. This is annoying and stupid and has caused me pain in the past – most recently, with 3Sharp’s own Exchange 2010 deployment (thanks to co-worker and all around swell guy Tim Robichaux for telling me how to get ISA to behave).

Also note that many of the commercial CAs specifically provide downloadable packages of their root CA and intermediate CA certificates. Some of them get really confusing – they have different CAs for different tiers or product lines, so you have to match the server certificate you have with the right CA certificates. GoDaddy’s CA certificate page can be found here.

Offloading FBA to ISA

As I discussed in part 1, ISA Server includes the option of performing FBA pre-authentication as part of the web listener. You aren’t stuck with FBA – you can use other pre-auth methods too. The thinking behind this is that ISA is the security server sitting in the DMZ, while the Exchange CAS is in the protected network. Why proxy an incoming connection from the Internet into the real world (even with ISA’s impressive HTTP reverse proxy and screening functionality) if it doesn’t present valid credentials? In this configuration, ISA is configured for FBA while the Exchange 2010/2007 CAS or Exchange 2003 front-end server are configured for Windows Integrated or Basic as shown in Figure 1 (a figure so nice I’ll re-use it):

Figure 1: Publishing Exchange using FBA on ISA

Moving FBA off of ISA

Having ISA (and Threat Management Gateway, the 64-bit successor to ISA 2006) perform pre-auth in this fashion is nice and works cleanly. However, in our Exchange 2010 deployment, we found a couple of problems with it:

The early beta releases of Entourage for EWS wouldn’t work with this configuration; Entourage could never connect. If our users connected to the 3Sharp VPN, bypassing the ISA publishing rules, Entourage would immediately see the Exchange 2010 servers and do its thing. I don’t know if the problem was solved for the final release.

We couldn’t get federated calendar sharing, a new Exchange 2010 feature, to work. Other Exchange 20120 organizations would get errors when trying to connect to our organization. This new calendar sharing feature uses a Windows Live-based central brokering service to avoid the need to provision and manage credentials.

Through some detailed troubleshooting with Microsoft and other Exchange 2010 organizations, we finally figured out that our ISA FBA configuration was causing the problem. The solution was to disable ISA pre-authentication and re-enable FBA on the appropriate virtual directories (OWA and ECP) on our CAS server. Once we did that, not only did federated calendar sharing start working flawlessly, but our Entourage users found their problems had gone away too. For more details of what we did, read on.

How Calendar Sharing Works in Exchange 2010

If you haven’t seen other descriptions of the federated calendar sharing, here’s a quick primer on how it works. This will help you understand why, if you’re using ISA pre-auth for your Exchange servers, you’ll want to rethink it.

In Exchange 2007, you could share calendar data with other Exchange 2007 organizations. Doing so meant that your CAS servers had to talk to their calendar servers, and the controls around it were not that granular. In order to do it, you either needed to establish a forest trust and grant permissions to the other forest’s CAS servers (to get detailed per-user free/busy information) or set up a separate user in your forest for the foreign forests to use (to get default per-org free/busy data). You also have to fiddle around with the Autodiscover service connection points and ensure that you’ve got pointers for the foreign Autodiscover SCPs in your own AD (and the foreign systems have yours). You also have to publish Autodiscover and EWS externally (which you have to do for Outlook Anywhere) and coordinate all your certificate CAs. While this doesn’t sound that bad, you have to do these steps for every single foreign organization you’re sharing with. That adds up, and it’s a poorly documented process – you’ll start at this TechNet topic about the Availability service and have to do a lot of chasing around to figure out how certificates fit in, how to troubleshoot it, and the SCP export and import process.

In Exchange 2010, this gets a lot easier; individual users can send sharing invitations to users in other Exchange 2010 organizations, and you can set up organization relationships with other Exchange 2010 organizations. Microsoft has broken up the process into three pieces:

1. Establish your organization’s trust relationship with Windows Live. This is a one-time process that must take place before any sharing can take place – and you don’t have to create or manage any service or role accounts. You just have to make sure that you’re using a CA to publish Autodiscover/EWS that Windows Live will trust. (Sorry, there’s no list out there yet, but keep watching the docs on TechNet.) From your Exchange 2010 organization (typically through EMC, although you can do it from EMS) you’ll swap public keys (which are built into your certificates) with Windows Live and identify one or more accepted domains that you will allow to be federated. Needless to say, Autodiscover and EWS must be properly published to the Internet. You also have to add a single DNS record to your public DNS zone, showing that you do have authority over the domain namespace. If you have multiple domains and only specify some of them, beware: users that don’t have provisioned addresses in those specified domains won’t be able to share or receive federated calendar info!
2. Establish one or more sharing policies. These policies control how much information your users will be able to share with external users through sharing invitations. The setting you pick here defines the maximum level of information that your users can share from their calendars: none, free/busy only, some details, or all details. You can create a single policy for all your users or use multiple policies to provision your users on a more granular basis. You can assign these policies on a per-user basis.
3. Establish one or more sharing relationships with other organizations. When you want to view availability data of users in other Exchange 2010 organizations, you create an organization relationship with them. Again, you can do this via EMC or EMS. This tells your CAS servers to lookup information from the defined namespaces on behalf of your users – contingent, of course, that the foreign organization has established the appropriate permissions in their organization relationships. If the foreign namespace isn’t federated with Windows Live, then you won’t be allowed to establish the relationship.

You can read more about these steps in the TechNet documentation and at this TechNet topic (although since TechNet is still in beta, it’s not all in place yet). You should also know that these policies and settings combine with the ACLs on users calendar folders, and as is the typical case in Exchange when there are multiple levels of permission, the most restrictive level wins.

What’s magic about all of this is that, at no point along the way other than the initial first step, do you have to worry consciously about the certificates you’re using. You never have to provide or provision credentials. As you create your policies and sharing relationships with other organizations – and other organizations create them with yours – Windows Live is hovering silently in the background, acting as a trusted broker for the initial connections. When your Exchange 2010 organization interacts with another, your CAS servers receive a SAML token from Windows Live. This token is then passed to the foreign Exchange 2010 organization, which can validate it because of its own trust relationship with Windows Live. All this token does is validate that your servers are really coming from the claimed namespace – Windows Live plays no part in authorization, retrieving the data, or managing the sharing policies.

However, here’s the problem: when my CAS talks to your CAS, they’re using SAML tokens – not user accounts – to authenticate against IIS for EWS calls. ISA Server (and, IIRC, TMG) don’t know how to validate these tokens, so the incoming requests can’t authenticate and pass on to the CAS. The end result is that you can’t get a proper sharing relationship set up and you can’t federate calendar data.

What We Did To Fix It

Once we knew what the problem was, fixing it was easy:

1. Modify the OWA and ECP virtual directors on all of our Exchange 2010 CAS servers to perform FBA. These are the only virtual directories that permit FBA, so they’re the only two you need to change:Set-OWAVirtualDirectory -Identity “CAS-SERVER\owa (Default Web Site)” -BasicAuthentication $TRUE -WindowsAuthentication $FALSE -FormsAuthentication $TRUESet-ECPVirtualDirectory -Identity “CAS-SERVER\ecp (Default Web Site)” -BasicAuthentication $TRUE -WindowsAuthentication $FALSE -FormsAuthentication $TRUE
2. Modify the Web listener on our ISA server to disable pre-authentication. In our case, we were using a single Web listener for Exchange (and only for Exchange), so it was a simple matter of changing the authentication setting to a value of No Authentication.
3. Modify each of the ISA publishing rules (ActiveSync, Outlook Anywhere, and OWA):On the Authentication tab, select the value No delegation, but client may authenticate directly.On the Users tab, remove the value All Authenticated Users and replace it with the value All Users. This is important! If you don’t do this, ISA won’t pass any connections on!

You may also need to take a look at the rest of your Exchange virtual directories and ensure that the authentication settings are valid; many places will allow Basic authentication between ISA and their CAS servers and require NTLM or Windows Integrated from external clients to ISA.

Calendar sharing and ISA FBA pre-authentication are both wonderful features, and I’m a bit sad that they don’t play well together. I hope that future updates to TMG will resolve this issue and allow TMG to successfully pre-authenticate incoming federated calendar requests.

For those keeping track at home, yes, I still owe you a second post on the Exchange 2010 calendar sharing. I’m working on it! Soon!

I must confess – I’m not a Vista fan. I grudgingly used it as the main OS on my work MacBook Pro for a while, but I never really warmed up to it. SP1, in my opinion, made it barely useable. There were some features about it I grew to like, but those were offset by a continued annoyance at how many clicks useful features had gotten buried behind.

So when I finally got busy getting these systems ready – thanks to Steph’s system suddenly forgetting how to talk to USB devices – I decided to use Windows 7 RC instead. What I’d seen of Windows 7 already made me believe that we’d have a much happier time with it. So far, I’d have to say that’s correct. Steph’s new machine was slightly tricky to install – the built-in network interface on the motherboard wasn’t recognized so I had to bootstrap with XP drivers – but otherwise, the whole experience has been flawless.

Want to try Windows 7 for yourself? Get it here.

One of my favorite experiences was migrating our files and settings from the old machines. Windows 7, like Vista and Server 2008 before it, includes the Easy Transfer Wizard. This wizard is the offspring of XP’s Files and Settings Transfer Wizard but has a lot more smarts built in. As a result, I was able to quickly and easily get all our files and settings moved over without a hitch. With the exception of a laptop, we’re now XP free in my house.

Today, I ran across this blog post detailing Seven Windows 7 Tips. There were a couple of them I had already figured out (2, 4, and partial 3), but I’ll be trying out the rest this evening!

So, imagine my surprise when my Linux geek friend Nick told me smugly that he now had a new Palm Pre and was synching it to his Linux-based email system using the Pre’s EAS support. “Oh?” said I, trying to stay casual as I was mentally envisioning the screwed-up mail forwarding schemes he’d put in place to route his email to an Exchange server somewhere. “Did you finally break down and migrate your email to an Exchange system? If not, how’d you do that?”

Nick then proceeded to point me in the direction of Z-Push, which is an elegant little open source PHP-based implementation of EAS. A few minutes of poking around and I became convinced that this was a wicked cool project. I really like how Z-Push is designed:

• The core PHP module answers incoming requests for the http://server/Microsoft-Server-ActiveSync virtual directory and handles all the protocol-level interactions. I haven’t dug into this deeply, but although it appears it was developed against Apache, folks have managed to get it working on a variety of web servers, including IIS! I’m not clear on whether authentication is handled by the package itself or by the web server. Now that I think about it, I suspect it just proxies your provided credentials on to the appropriate back-end system so that you don’t have to worry about integrating Z-Push with your authentication sources.
• One or more back-end modules (also written in PHP), which read and write data from various data sources such as your IMAP server, a Maildir file system, or some other source of mail, calendar, or contact information. These back-end modules are run through a differential engine to help cut down on the amount of synching the back-end modules must perform. It looks like the API for these modules is very well thought-out; they obviously want developers to be able to easily write backends to tie in to a wide variety of data sources. You can mix and match multiple backends; for example, get your contact data from one system, your calendar from another, and your email from yet a third system.
• If you’re running the Zarafa mail server, there’s a separate component that handles all types of data directly from Zarafa, easing your configuration. (Hey – Zarafa and Z-Push…I wonder if Zarafa provides developer resources; if so, way to go, guys!)

You do need to be careful about the back-end modules; because they’re PHP code running on your web server, poor design or bugs can slam your web server. For example, there’s currently a bug in how the IMAP back-end re-scans messages, and the resulting load can create a noticeable impact on an otherwise healthy Apache server with just a handful of users. It’s a good thing that there seems to be a lively and knowledgeable community on the Z-Push forums; they haven’t wasted any time in diagnosing the bug and providing suggested fixes.

Very deeply cool – folks are using Z-Push to provide, for example, an EAS connection point on their Windows Home Server, synching to their Gmail account. I wonder how long it will take for Linux-based “Exchange killers” (other than Zarafa) to wrap this product into their overall packages.

It’s products like this that help reinforce the awareness that EAS – and indirectly, Exchange – are a dominant enough force in the email market to make the viability of this kind of project not only potentially useful, but viable as an open source project.

No, seriously. _O_ M _G_.

Potato guns/canons? Pretty wicked cool.

But a potato gatling gun?????

Frakking YES.

• The parameter name
• Whether it is a required or optional parameter
• The .NET variable type the parameter expects
• A description of the behavior the parameter controls

Let’s focus on two particular types of parameters, the Switch (System.Management.Automation.SwitchParameter) and the Boolean (System.Boolean). While I never really thought about it much before reading a discussion on an email list earlier, these two parameter types seem to be two ways of doing the same thing. Let me give you a practical example from the Exchange 2007 Management Shell: the New-ExchangeCertificate cmdlet. Table 1 lists an excerpt of its parameter list from the current TechNet article:

Table 1: Selected parameters of the New-ExchangeCertificate cmdlet

On quick examination, both parameters control either/or behavior. So why the two different types? The mailing list discussion I referenced earlier pointed out the difference:

Boolean parameters control properties on the objects manipulated by the cmdlets. Switch parameters control behavior of the cmdlets themselves.

So in our example, a digital certificate has a property as part of the certificate that marks whether the associated private key can be exported in the future. That property goes along with the certificate, independent of the management interface or tool used. For that property, then, PowerShell uses the Boolean type for the -PrivateKeyExportable property.

On the other hand, the –GenerateRequest parameter controls the behavior of the cmdlet. With this property specified, the cmdlet creates a certificate request with all of the specified properties. If this parameter isn’t present, the cmdlet creates a self-signed certificate with all of the specified properties. The resulting object (CSR or certificate) has no corresponding sign of what option was chosen – you could just as easily submit that CSR to another tool on the same machine to create a self-signed certificate.

I hope this helps draw the distinction. Granted, it’s one I hadn’t thought much about before today, but now that I have, it’s nice to know that there’s yet another sign of intelligence and forethought in the PowerShell architecture.

An FBA Overview

FBA was introduced in Exchange Server 2003 as a new authentication method for Outlook Web Access. It requires OWA to be published using SSL – which was not yet common practice at that point in time – and in turn allowed credentials to be sent a single time using plain-text form fields. It’s taken a while for people to get used to, but FBA has definitely become an accepted practice for Exchange deployments, and it’s a popular way to publish OWA for Exchange 2003, Exchange 2007, and the forthcoming Exchange 2010.

In fact, FBA is so successful, that the ISA Server group got into the mix by including FBA pre-authentication for ISA Server. With this model, instead of configuring Exchange for FBA you instead configure your ISA server to present the FBA screen. Once the user logs in, ISA takes the credentials and submits them to the Exchange 2003 front-end server or Exchange 2007 (or 2010) Client Access Server using the appropriately configured authentication method (Windows Integrated or Basic). In Exchange 2007 and 2010, this allows each separate virtual directory (OWA, Exchange ActiveSync, RPC proxy, Exchange Web Services, Autodiscover, Unified Messaging, and the new Exchange 2010 Exchange Control Panel) to have its own authentication settings, while ISA server transparently mediates them for remote users. Plus, ISA pre-authenticates those connections – only connections with valid credentials ever get passed on to your squishy Exchange servers – as shown in Figure 1:

Figure 1: Publishing Exchange using FBA on ISA

Now that you know more about how FBA, Exchange, and ISA can interact, let me show you one mondo cool thing today. In a later post, we’ll have an architectural discussion for your future Exchange 2010 deployments.

The Cool Thing: Kay Sellenrode’s FBA Editor

On Exchange servers, it is possible to modify both the OWA themes and the FBA page (although you should check about the supportability of doing so). Likewise, it is also possible to modify the FBA page on ISA Server 2006. This is a nice feature as it helps companies integrate the OWA experience into the overall look and feel of the rest of their Web presence. Making these changes on Exchange servers is a somewhat well-documented process. Doing them on ISA is a bit more arcane.

Fellow Exchange 2007 MCM Kay Sellenrode has produced a free tool to simplify the process of modifying the ISA 2006 FBA – named, aptly enough, the FBA Editor. You can find the tool, as well as a YouTube video demo of how to use it, from his blog. While I’ve not had the opportunity to modify the ISA FBA form myself, I’ve heard plenty of horror stories about doing so – and Kay’s tool is a very cool, useful community contribution.

In the next day or two (edit: or more), we’ll move on to part 2 of our FBA discussion – deciding when and where you might want to use ISA’s FBA instead of Exchange’s.

In my (limited) experience with the military, there’s still quite a bit of public resistance to the idea of allowing gays to openly serve. There are many reasons that one may take this stance, ranging from deeply principled to deeply homophobic and covering all points in between. If the objection comes from deeply held religious or moral convictions, I choose to respectfully disagree with you, but I understand and value the fact that you do have your beliefs on this issue.

From my anecdotal experience, though, the people who are usually the loudest about this issue (“I ain’t lettin’ no queer next to me with a gun; I’ll shoot his ass first!” is a representative sample I’ve heard recently) tend to be strongly grounded in the “mindlessly homophobic” rationale. This isn’t just confined to the military, though. I have plenty of memories of the charming functional illiterates at my rural high school indignantly asking me if I was gay, harrassing me for my presumed homosexuality, and making not-so-subtle meant-to-be-overheard comments about my lack of “real manliness”. These were the people who would always get in your face and confront you on your disgusting life choices — as long (of course) as you weren’t big enough or mean enough to be perceived as capable of handling the violence they always threatened to dish out.

Let’s take a representative example of this kind of person — we’ll call him Bubba. (Don’t assume that it’s only guys who do this; I’ve heard plenty of women who do too. ) Down at the bottom of it all, though, these guys and gals have one common flawed assumption, deeply rooted in raging sense of entitlement:

If that person is gay, they want to have sex with me.

I think the appropriate response here is a quote from Megan Fox’s character of Mikaela:

Oh God, I can’t even tell you how much I’m not your “little bunny.”

In other words, Bubba has committed the logical fallacy of assuming that just because a gay man is sexually attracted to some men, they must like all men — including, necessarily, Bubba. In other words, the defining characteristic of a gay man’s sexuality, according to Bubba, is the orientation; once a man is gay, they automatically must like all men even if those men are otherwise unattractive. Bubba, sad to say, thinks that being gay overrides any sense of taste or choice or other form of preference.

Bubba is a dumbshit. Bubba is, however, all too common — I’ve heard plenty of people independently reproduce this exact line of reasoning.

My thought and theory is: that for the Bubbas of the world, the objection to knowingly associating with someone who is gay comes down to projection of their own inner characteristics: Bubba wants to nail pretty much every female, or in the event that he has some self-restraint, is deluded enough to think that every woman wants to have sex with him. Being a paragon of self-control and discernment, Bubba is naturally are unable to conceive of someone who could in theory be attracted to them but isn’t.

What Bubba objects to, I believe, is not the gay person’s lack of taste and self control, but his own. It’s the same as the liar who in turn is convinced that everyone lies to him and is unable to see a truthful response without looking for the “real” answer, or the person who continually cheats others in big and small ways and in turn expects everyone to cheat her.

Do I think that everyone who objects to military service for gays and lesbians falls into this trap? Not at all. I just tend to think that the more vocal someone is about it, the more likely they are to have this motivation simmering at the bottom of it all. People who suffer from this attitude tend to have the crudest, most violent responses to homosexuality; they tend to be the loudest slanderers, the meanest and most illogical protesters. They argue from a well-deserved fear, because if everyone was just like them, all the sick, dark scenarios they fantasize would of course happen.

God knows that my gay and lesbian friends and acquaintances are no saints. Some of them are people I don’t willingly spend time around — but then, there are plenty of straight people I don’t want to spend a lot of time around either. Frankly, I’ve found that brushing off determined advances from a guy who likes me is no better and no worse than those from a gal who likes me — orientation having less to do with it than does their fundamental ability to hear and accept, “Thanks, but I’m not interested.”

Mind you, typically the Bubbas of the world are at heart hypocrites, because almost all of them have absolutely no problems with lesbians. Oh, no. They’re in favor of lesbians. Mainly because, along with all their other stinking thinking, they are under the delusion that those lesbians still secretly want them — so they’ll be able to score with the lesbian and her girlfirend at the same time.  Because of this, it’s easy to spot a Bubba and identify his objection for what it really is.

Community Server and WordPress store their content in very different ways, and so they generate the URLs for blog posts using different algorithms. I know there are a fairish number of links out there in blog land to various posts I’ve done, and for vanity sake, I’d rather not orphan those links to the dreaded 404 not found error. The solution was to find the time to buy the lastest edition of O’Reilly’s Apache Cookbook and bone up on the Apache web server directives.

So, I think all the relevant old URLs should now automatically redirect to their proper new places — there’s not much point in keeping all the old posts if you don’t do this. The nice thing, for those of you who are web geeks, is that I’m issuing permanent redirections so Google and other search engines will update their links as they re-trawl my web site, thus pointing to the new URLs. For those of you who are humans, you might want to take a minute to check your bookmarks and make sure they’re updated to the new links.

One note: some commenter data didn’t make the import successfully. I could probably dig into it and find out why, but frankly, at this point, it’s more important to get the site (and Steph’s blog) back up and running. So, sorry — if you were one of those commenters, I apologize. Future comments should be preserved properly, and I really don’t see moving away from WordPress anytime soon.

If you’re reading this, then the necessary DNS updates have finished rolling out and we’re back live to the world. Thanks for your patience!

This discussion has of course gone back and forth within the Exchange community. I think part of the pushback comes from the fact that MCM is the next evolution of the Exchange Ranger program, which felt very elitist and exclusive (and by many accounts was originally designed to be, back when it was only a Microsoft-only evolution designed to provide a higher degree of training for Microsoft consultants and engineers to better resolve their own customer issues). Starting off with that kind of background leaves a lot of lingering impressions, and the Exchange community has long memories. Paul has a great discussion of his point of view as a new MCM instructor and shares his take on the “is it worth it?” question.

Another reason for pushback is the economy. The typical argument is, “I can’t afford to take this time right now.” Let’s take a ballpark figure here, aimed at the coming May 4 rotation, just to have some idea of the kinds of numbers folks are thinking about:

• Imagine a consultant working a 40-hour week. Her bosses would like her to meet 90% (36 hours) billable. Given two weeks of vacation a year, that 50 weeks at 36 hours a week.
• We’ll also imagine that she’s able to bill out at $100/hour. This brings her minimum annual revenue to $180,000. They set her opportunity cost (lost revenue) at $3,600/week.
• We’ll assume she have the pre-requisites nailed (MCITP Enterprise Messaging, the additional AD exam for either Windows 2003 or Windows 2008, and the field experience). No extra cost there (otherwise it’s $150/test, or $600 total).
• Let’s say her plane tickets are $700 for round-trip to Redmond and back.
• And we’ll say that she needs to stay at a hotel, checking in Sunday May 3rd, checking out Sunday May 24th, at a daily rate of $200.
• Let’s also assume she’ll need $75 a day for meals.

That works out to $18,500 (class fee) + $700 (plane) + 21 x $275 (hotel + meals) + 3 x $3,600 (opportunity cost of work she won’t be doing) — $18,500 + $700 + $5,775 + $10,800 = a whopping total of $35,775. That, many people argue, is far too much for what they get out of the course – it represents just over 10 weeks of her regular revenue, or approximately 1/5th of her year’s revenue.

If those numbers were the final answer, they’d be right.

However, Paul has some great talking points in his post; although he focuses on the non-economic piece, I’d like to tie some of those back in to hard numbers.

• The level of training. I don’t care how well you know Exchange. You will walk out of this class knowing a lot more and you will be immediately able to take advantage of that knowledge to the betterment of your customers. Plus, you will have ongoing access to some of the best Exchange people in the world. I don’t know a single consultant out there who can work on a problem that is stumping them for hours or days and be able to consistently bill every single hour they spend showing no results. Most of us end up eating time, which shows up in the bottom line. For the sake of argument, let’s say that our consultant ends up spending 30% instead of 10% of her time working on issues that she can’t directly bill for because of things like this. That drops her opportunity cost from $3,600/week to $2,520, or $7,560 for the three weeks (and it means she’s only got an annual revenue of $126,000). If she can reduce that non-billable time, she can increase my efficiency and get more real billable work done in the same calendar period. We’ll say she can gain back 10% of that lost time and get up to only 20% lost time, or 32 hours a week.
• The demonstration of competence. This is a huge competitive advantage for two reasons. First, it helps you land work you may not have been able to land before. This is great for keeping your pipeline full – always a major challenge in a rough economy. Second, it allows you to raise your billing rates. Okay, true, maybe you can’t raise your billing rates for all the work that you do for all of your customers, but even some work at a higher rate directly translates to your pocket book. Let’s say she can bill 25% of those 32 hours at $150/hour. That turns her week’s take into (8 x $150) + (24 x $100) = $1,200 + $2,400 = $3,600. That modest gain in billing rates right there compensates for the extra 10% loss of billing hours and pays for itself every 3-4 weeks.

Let’s take another look at those overall numbers again. This time, let’s change our ballpark with numbers more closely matching the reality of the students at the classes:

• There’s a 30% discount on the class, so she pays only $12,950 (not $18,500).
• We’ll keep the $700 for plane tickets.
• From above, we know that her real lost opportunity cost is more like $7,560 (3 x $2,520 and not the $10,800 worst case).
• She can get shared apartment housing with other students right close to campus for more like $67 a night (three bedrooms).
• Food expenses are more typically averaged out to $40 per day. You can, of course, break the bank on this during the weekends, but during the days you don’t really have time.

This puts the cost of her rotation at $12,950 + $700 + (21 x $107) + $7,560, or $23,457. That’s only 66% – two-thirds – of the worst-case cost we came up with above. With her adjusted annual revenue of $126,000, this is only 19%, or just less than 1/5th of her annual revenue.

And it doesn’t stop there. Armed with the data points I gave above, let’s see how this works out for the future and when the benefits from the rotation pay back.

Over the year, our hypothetical consultant, working only a 40-hour work week (I know, you can stop laughing at me now) brings in 50 x $2,520 = $126,000.  The MCM rotation represents 19% of her revenue for the year before costs.

However, let’s figure out earning potential in that same year: (47 x $3,600) – ($13,650 + $700 + $2247) = $152,603. That’s a 20% increase.

Will these numbers make sense for everyone? No, and I’m not trying to argue that they do. What I am trying to point out, though, is that the business justification for going to the rotation may actually make sense once you sit down and work out the numbers. Think about your current projects and how changes to hours and billing rates may improve your bottom line. Think about work you haven’t gotten or been unwilling to pursue because you or the customer felt it was out of your league. Take some time to play with the numbers and see if this makes sense for you.

If it does, or if you have any further questions, let me know.

Background

It turns out that the problem has to do with with changes that were made to the default SSL algorithm negotiations made in Windows Server 2008. If you deployed OCS 2007 R2 Edge roles on Windows Server 2003, you’d be fine; if you used Windows 2008, you’d see problems.

When an HTTP client and server connect (and most IM protocols use HTTPS or HTTP + TLS as a firewall-friendly transport[1]), one of the first things they do is negotiate the specific suite of cryptographic algorithms that will be used for that session. The cipher suite includes three components:

• Key exchange method – this is the algorithm that defines the way that the two endpoints will agree upon a shared symmetric key for the session. This session key will later be used to encrypt the contents of the session, so it’s important for it to be secure. This key should never be passed in cleartext – and since the session isn’t encrypted yet, there has to be some mechanism to do it. Some of the potential methods allow digital signatures, providing an extra level of confidence against a man-in-the-middle attack. There are two main choices: RSA public-private certificates and Diffie-Hellman keyless exchanges (useful when there’s no prior communication or shared set of trusted certificates between the endpoints).
• Session cipher – this is the cipher that will be used to encrypt all of the session data. A symmetric cipher is faster to process for both ends and reduces CPU overhead, but is more vulnerable in principal to discovery and attack (as both sides have to have the same key and therefore have to exchange it over the wire). The next choice is streaming cipher or cipher block chaining (CBC) cipher? For streaming, you have RC4 (40 and 128-bit variants). For CBC, you can choose RC2 (40-bit), DES (40-bit or 56-bit), 3DES (168-bit), Idea (128-bit), or Fortezza (96-bit). You can also choose none, but that’s not terribly secure.
• Message digest algorithm – the message digest is a hash cipher used to create the Hashed Message Authentication Code (HMAC), which is used to help verify the integrity of the cipher. It’s also used to guard against an attacker trying to replay this stream in the future and fool the server into giving up information it shouldn’t. In SSL 3.0, this is just a MAC. There are three choices: null (none), MD5 (128-bit), and SHA-1 (160-bit).

Problem

Windows Server 2003 uses the following suites for TLS 1.0/SSL 3.0 connections by default:

1. TLS_RSA_WITH_RC4_128_MD5 (RSA certificate key exchange, RC4 streaming session cipher with 128-bit key, and 128-bit MD5 HMAC; a safe, legacy choice of protocols, although definitely aging in today’s environment)
2. TLS_RSA_WITH_RC4_128_SHA (RSA certificate key exchange, RC4 streaming session cipher with 128-bit key, and 160-bit SHA-1 HMAC; a bit stronger than the above, thanks to SHA-1 being not quite as brittle as MD5 yet)
3. TLS_RSA_WITH_3DES_EDE_CBC_SHA (you can work out the rest)
4. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
5. TLS_RSA_WITH_DES_CBC_SHA
6. TLS_DHE_DSS_WITH_DES_CBC_SHA
7. TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
8. TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
9. TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
10. TLS_RSA_EXPORT_WITH_RC4_40_MD5
11. TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
12. TLS_RSA_WITH_NULL_MD5
13. TLS_RSA_WITH_NULL_SHA

Let’s contrast that with Windows Server 2008, which cleans out some cruft but adds support for quite a few new algorithms (new suites bolded):

1. TLS_RSA_WITH_AES_128_CBC_SHA (Using AES 128-bit as a CBC session cipher)
2. TLS_RSA_WITH_AES_256_CBC_SHA (Using AES 256-bit as a CBC session cipher)
3. TLS_RSA_WITH_RC4_128_SHA
4. TLS_RSA_WITH_3DES_EDE_CBC_SHA
5. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 (AES 128-bit, SHA 256-bit)
6. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384(AES 128-bit, SHA 384-bit)
7. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521(AES 128-bit, SHA 521-bit)
8. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256(AES 256-bit, SHA 256-bit)
9. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384(AES 256-bit, SHA 384-bit)
10. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521(AES 256-bit, SHA 521-bit)
11. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 (you can work out the rest)
12. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
13. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
14. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
15. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
16. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
17. TLS_DHE_DSS_WITH_AES_128_CBC_SHA
18. TLS_DHE_DSS_WITH_AES_256_CBC_SHA
19. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
20. TLS_RSA_WITH_RC4_128_MD5
21. SSL_CK_RC4_128_WITH_MD5 (not sure)
22. SSL_CK_DES_192_EDE3_CBC_WITH_MD5 (not sure)
23. TLS_RSA_WITH_NULL_MD5
24. TLS_RSA_WITH_NULL_SHA

Okay, so take a look at line 20 in the second list – see how TLS_RSA_WITH_RC4_128_MD5 got moved from first to darned near worst? Yeah, well, that’s because AES and SHA-1 are the strongest protocols of their type likely to be commonly supported, so Windows 2008 moves those to the default offered. Unfortunately, this causes problems with PIC to AOL.

Solution

Now that we know what the problem is, what can we do about it? For the fix, check out Scott Oseychik’s post here.

[1] HTTPS is really Hop Through Tightened Perimeters Simply – aka the Universal Firewall Traversal Protocol.

If you follow along my blog, you probably already know that I think this is a good thing, so I won’t comment extensively on it here. However, there’s one section in the article I linked to above that just reeks of so much stupidity that I have to respond:

Maggie Gallagher, president of the National Organization for Marriage, a New Jersey group, said “once again, the most undemocratic branch of government is being used to advance an agenda the majority of Americans reject.”

“Marriage means a husband and wife. That’s not discrimination, that’s common sense,” she said in a press release. “Even in states like Vermont, where they are pushing this issue through legislatures, gay marriage advocates are totally unwilling to let the people decide these issues directly.”

Really? Ms. Gallagher, did you really just stoop to the “30 billion flies eat shit” argument to justify your position? You lose.

Okay, to unpack that for anyone who didn’t follow that train of thought:

Ms. Gallagher is relying on the tactic of telling people “the government is ignoring your opinion.” By telling people this, she’s playing on a fundamental ignorance of the design and intent of the American government system, which is the tired old myth that America = democracy = the will of the people = only tolerating Christian values. Let’s see what our founding fathers had to say about that:

It is, that in a democracy, the people meet and exercise the government in person; in a republic, they assemble and administer it by their representatives and agents. A democracy, consequently, will be confined to a small spot. A republic may be extended over a large region.
Federalist No. 14

Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote!
Benjamin Franklin

Remember, democracy never lasts long. It soon wastes, exhausts, and murders itself.
John Adams

It cannot be emphasized too strongly or too often that this great nation was founded, not by religionists, but by Christians; not on religions, but on the Gospel of Jesus Christ. For this very reason peoples of other faiths have been afforded asylum, prosperity, and freedom of worship here.
Patrick Henry

I know no safe depository of the ultimate powers of the society but the people themselves, (A)nd if we think them not enlightened enough to exercise their control with a wholesome discretion, the remedy is not to take it from them, but to inform their discretion by education. This is the true corrective of abuses of constitutional power.
Thomas Jefferson

I have always thought that all men should be free; but if any should be slaves, it should first be those who desire it for themselves, and secondly those who desire it for others. Whenever I hear anyone arguing for slavery, I feel a strong impulse to see it tried on them personally.
Abraham Lincoln

I could go on all day and find tons of quotes, but the key threads that I’m weaving here are these:

America is not and was never intended to be a pure democracy. Remember the phrase “the tyranny of the majority”? Basically, it’s great to be in a democracy if you’re part of the 51%. Not so much to be in the 49% Our democratic functions are not set up to allow citizens to directly decide upon laws and legislation and the handling of day-to-day governance; they are set up to elect responsible leaders who do that for us, and to give us mechanisms to take those leaders out of the picture when they fail to discharge their responsibilities. That’s the “democratic republic.” Remember the Pledge of Allegiance? “I pledge allegiance to the flag of the United States of America and to the Republic for which it stands…”

By electing responsible leaders (including legislators and judges), we are in fact giving those leaders the mandate to act in the fashion they see as best. If we don’t like what they do with that mandate, then we’d better pay attention and give them feedback. You can’t leave the people out of the equation, but you can’t directly hand them the keys to the kingdom, either. That’s why we have checks and balances, including the judicial branch of government. It is their job to say, “No, these laws are causing harm and cannot be used, even though they are popularly supported.”  The exercise of democracy should never come at the expense of depriving others of their liberties. How long did popular opinion support and uphold slavery, and how much damage did that do to our country (and continue to do today)? How long was racism enshrined in our laws? Sexism? If you’re counting upon the will of the people to make the correct choice every time, you’ve got a pretty grim track record of results.

America was designed to be a refuge for all religious belief systems, not just a narrow stripe of fundamentalist Christianity. This includes religious systems that directly challenge basic beliefs of Christianity. It was never designed to be a system that promoted Christianity over all others, even though the majority of founders were Christians, espoused Christian ideals, and wanted to see this country continue to be based on a set of morals not completely incompatible with Christianity. When push came to shove, most of the founders espoused liberty and freedom *over* Christian principles as a guiding principle for the government. They reasoned, correctly, that Christianity could flourish in an environment where liberty was pursued, but the reverse was not true (as had been graphically demonstrated). That is, the proper place for Christian values is on the individual level and in our relationships with others, not hard-wiring our specific interpretations into our functions of government. Religion + bureaucracy + power = corruption of values and lessening of liberty.

Let me leave you with this final challenge if you’re still thinking that it’s your religious duty to enshrine your notion of marriage into the laws of our nation:

Show me a comprehensive case in Scripture for collective Christian political activism. Remember the specific accusations the Pharisees made against Jesus to Pontius Pilate and his answers to Pilate in return. Remember his response to the commercialism in the Temple, how his fiercest criticisms were reserved for those who used religion to gain and maintain power. And then take a look at the agenda and funding of groups like National Organization for Marriage and Focus on the Family who are leading this fight to preserve marriage (whatever that really means) and tell me how they’re not gaining power and money from their collective activism.