Worms, in the context of computer security, are small programs that are self-replicating and spread rapidly to other computers over a network. One of the most famous, the Morris worm of 1988, took out an estimated 10% of the computers on the Internet which, fortunately, was much smaller and less critical to most of us at the time.
You may be surprised to learn that some of Microsoft's licensing policies bear a strong resemblance to a computer worm. Similarities include:
- A single instance of a license instantly infects many other computers on a corporate network with a comparable licensing requirement
- No user action is required: in most cases, the organization may feel it needs only one license, for one or a few instances of the software, but the worm infects a far larger community of devices
- The behavior of host computers is unaffected by the worm and a systems administrator cannot detect it
- While it does not affect the normal operation of the host computers, a licensing worm can have other profound impacts, primarily to the host corporation's budget.
Exchange Worms
Microsoft Exchange is particularly prone to licensing worms and hosts a couple of them.
Neither is well documented. Even a licensing expert perusing Microsoft's core licensing documents, such as the Product Use Rights document, the Product List, or customer volume licensing contracts, will not find them. I came across them by accident—sometimes alerted by customers, in other cases finding a curious notation in a sales document.
The existence of undocumented worms (those that customers told me about) was confirmed by further conversations with Microsoft.
The External Connector Worm
Sometimes an organization wants to give outsiders secure access to its e-mail system. For example, it might want its public relations agency or perhaps a human resources contractor to have access to its global address list so that these outsiders can easily and securely communicate with the company's employees without having to work their way through voice-mail jail or a company phone operator.
With Exchange, a Microsoft customer has a couple of options. If just a few named individuals are involved, the host organization can purchase Exchange Client Access Licenses (CALs) for the outsiders, who are then licensed to access the organization's Exchange servers.
Another option, which might be used where an organization has multiple sets of outsiders who need access to the system—maybe an office supplies vendor, HR contractors, a PR agency, and software development partners—an Exchange External Connector might seem the obvious choice. Instead of buying individual CALs (which cost between $53 and $68, depending on how many you buy), they purchase an External Connector for somewhere between $40,000 and $50,000. An External Connector permits an unlimited number of external users to access the system without requiring individual CALs. The benefit is that the organization doesn't have to track who has a CAL, who needs one, what to do with the CAL if they take another job, etc. If they need to give access to hundreds of external users, it may even appear to be less expensive.
But the company that goes this route will unearth the budget-eating Exchange External Connector Worm.
According to Microsoft, you can't buy an Exchange External Connector for just one of your Exchange Servers. You have to buy it for every single instance of Exchange in your organization.
It's not uncommon for an organization to have 100 or more Exchange servers, particularly if they implement a high-end Exchange system with multiple roles, such as clustered mailbox servers, specialized client access servers, hub transports, edge servers, and the like. A company of that size probably has relationships with some external users who can benefit from access to its Exchange servers, but it will need to purchase 100 Exchange External Connectors, at a cost of about $4 million. That, by the way, is more than an organization with 100 Exchange servers and 60,000 employees will spend on every other Exchange license that it owns, including other licenses for all of its Exchange servers and Exchange CALs for all of its users.
Microsoft helpfully suggests a partial remedy: the customer can virtualize its Exchange infrastructure as much as possible. The reason is that External Connectors are licensed by device, rather than by Exchange instance, and the more instances of Exchange the customer can pile on one device, the fewer External Connectors they need to buy.
This advice will seem ironic to customers who remember that just a few years ago Microsoft recommended against virtualizing Exchange. Furthermore, an organization implementing a multirole Exchange infrastructure is probably trying to eke out the last bit of Exchange performance and scalability. Consolidating a bunch of roles on one piece of hardware will sabotage performance and reduce availability, which is why the customer implemented a multirole architecture in the first place.
My advice to customers who have more than one Exchange instance running would be to stay as far away from Exchange External Connectors as possible. If you want to give external users access to your e-mail system, consider alternatives such as hosted Exchange servers that are licensed by named user (easier to track than CALs), that can be synchronized with your on-premises Active Directory to give external users access to your global address list, and that don't dig up any worms (that I know of).
The Exchange CAL Worm
Root around in the same pile where the Exchange External Connector Worm burrows, and you will find the Exchange CAL Worm.
CALs are how an organization licenses users who need to access an Exchange (or SharePoint, Windows, et al) server. CALs have been called “the most evil thing Microsoft has ever done,” a point with which I sympathize, although, given the existence of the Exchange External Connector and other licensing worms, it's a point I would challenge.
A CAL always must match (or be more recent than) the server to which it licenses access. You can access an Exchange 2003 server with a CAL for Exchange 2010, but you can't access an Exchange 2010 server with a CAL for Exchange 2003 or 2007, for example.
That's the clue to how this worm works.
You're a global organization with thousands of users that has standardized on an older version of Exchange, such as Exchange 2003, and while the older system is working okay, the siren call of Exchange 2010 awakens the mating instinct in your Exchange administrator in Budapest, who wants this baby, badly.
So he buys a license for Exchange 2010, installs it, and shows it off to his pals elsewhere in the company.
The worm awaketh.
Even though no one outside of Budapest may access this Exchange server directly, they are now required to upgrade all their Exchange CALs to 2010 versions. In a company with 10,000 users, they're on the hook for a half-million dollars worth of new Exchange CALs, even though only 10 of their users might actually have mailboxes on the new server in Budapest.
Now, Microsoft has an explanation for this, although in spite of wrestling with it for a few years now, I still don't get it. The explanation is that everyone who doesn't have the right Exchange CAL is using “multiplexing” or “pooling” to get at the Exchange 2010 server.
Microsoft defines multiplexing or pooling as hardware or software that reduces the number of users who are directly accessing a server. There are good examples of this: it's not uncommon to install hardware or software to manage pooled connections to a database, for example. Setting up a connection to a database takes a certain amount of resources, so if a programmer or database administrator can create a pool of persistent connections that can be easily recycled as user queries come and go, performance will improve.
Microsoft says it's OK to use multiplexing or pooling, but it doesn't change the number of CALs you need: every person accessing the server even indirectly needs a CAL.
What this explanation is missing is what obvious pooling or multiplexing hardware or software is installed between one version of an Exchange server and another version of an Exchange server. This pooling hardware or software does not exist between two servers of the same version. But installing a later version—any later version; remember, this is a licensing concept, not a software feature—of the server magically creates a pooled architecture and a licensing liability for every user of the software, no matter which server they actually use.
Again, Microsoft suggests a workaround: if instead of using Microsoft's Messaging Application Programming Interface (MAPI) to connect users to the new server, it is configured to communicate using the Simple Mail Transfer Protocol (SMTP), the pretty-well-universal protocol for transporting Internet mail, to connect to the rest of the corporate network, the multiplexing/pooling rule doesn't apply.
I can't explain that either. It sounds like Microsoft is actually licensing not Exchange, but MAPI.
The Windows Server CAL Worm
I've asked Microsoft how far this goes. What if the server in Budapest was also the first server in the organization to use Windows Server 2008, and perhaps the latest version of a System Center management tool, like Operations Manager? Do these trigger requirement to update Windows Server CALs for every user and to also update management licenses for every other server?
I didn't get an answer on that but recently saw a PowerPoint slide from a Microsoft sales representative that confirmed that, yes, Windows Server has the same worm-like power as Exchange. The slide, sent to a customer, said that updating a single instance of Windows server in a networked environment requires that the customer immediately purchase new CALs for every device on the network. If they have Software Assurance (SA) on a CAL Suite, like the Core CAL Suite, they're automatically covered for this, but if they aren't in this situation, that single installation of an updated Windows Server triggers a substantial CAL upgrade requirement.
(Note also that CALs can be applied to users, so although the Microsoft rep referred to purchasing new CALs for every device, it could mean for every user instead.)
Fortunately, Windows Server CALs aren't hugely expensive. They run for about $31 or less in the United States. Still, organizations that want to “try out” a new version of Windows Server need to be aware that the experiment will trigger a licensing worm, unless they already have CALs to which they have added SA.
The SharePoint Worm
SharePoint is Microsoft's collaboration server, and with SharePoint 2010, Microsoft has made a few licensing changes, particularly for external users.
SharePoint has never had an External Connector, odd for a server that basically runs a Web site and could make a great platform for corporate Web sites. But the 2007 version of the product had a substitute, called SharePoint for Internet Sites, that ran between about $35,000 and $50,000. It can be accessed by external users without CALs. Why not use an External Connector for this like every other product group? Because the SharePoint team wants more revenue: one External Connector covers every instance on a server, but each instance of SharePoint for Internet Sites requires its own license, even if you run several instances on the same device.
With SharePoint 2010, Microsoft split the 2007 SharePoint for Internet Sites into Standard and Enterprise editions and offered what at first glance looked like a steal: SharePoint for Internet Sites Standard, which cost about $9,000 to $12,000. The Enterprise edition is closer to the old price, running $32,000 to $41,000.
Both products have worm characteristics. Microsoft says that not only must the server that external users are accessing be licensed with SharePoint for Internet Sites, but any SharePoint server that contributes any content or applications to this server must have the same license. The rule, spelled out much more explicitly in a licensing brief than in Microsoft's official rule book, the Product Use Rights document (where the rule is all but invisible), specifically cites the need to license “staging, application, front-end, or index” servers with the same SharePoint 2010 for Internet Sites license.
A large customer with a complex SharePoint environment that wants to share it with the outside world might put out $9,000 for one of these puppies, then realize that they need to license at least one each of the other four types of servers (staging, application, etc.) mentioned in the brief. Now they're at $45,000 and actually paying more than they did for the 2007 model. And since the Standard Edition is limited to a single domain (where the 2007 Internet Sites product was not), if they add a domain they need to add at least one more license.
The alternative is to license the Enterprise edition, which can host multiple domains, but don't assume you're going to save much money there. At a minimum of $32,000 a pop, it also needs to be licensed on all of the servers that contribute content, applications, or indexing, so the same set of servers that cost you $45,000 with the Standard edition will set you back more than $150,000 with the Enterprise edition.
The best workaround for the budget conscious would be to simply not use SharePoint to run an external server. The rules don't appear to forbid transferring content, such as Web pages, graphics, etc. that you've posted on internal SharePoint sites, to an external Web site built on something else, such as a custom-built Web site or even an open source solution. Any apps built specifically for SharePoint, however, will need to be rewritten before external users can touch them, to avoid calling forth any licensing worms.
