Exchange 2010

A Closer Look

Henrik Walther

The recently released Microsoft Exchange 2010 Release to Manufacturing (RTM) version, like its predecessors, includes a wealth of new features and improvements over existing ones. As a matter of fact, with this release, Exchange now consists of approximately 21 million lines of code.

Exchange developers had five main goals in mind for Exchange 2010: to help organizations achieve new levels of reliability, better performance, simplified administration, improved protection of communications and greater business mobility for users. In short, and with the global economic crisis in mind, they aimed to create a more flexible and optimized product that would lower the costs of running an Exchange 2010 infrastructure.

Since April 2008, I have spent a good deal of time testing Exchange 2010 beta and release candidate builds in my labs, as well as in two enterprise customer environments. In this article, I will take you on a tour through the most exciting changes and improvements in this latest and—without doubt—greatest Exchange version we have seen so far.

Management Architecture

With Exchange 2007, Microsoft introduced a management architecture based on Windows PowerShell 1.0 and the Microsoft .NET Framework 2.0 runtime. Once Exchange administrators learned to use the shell, they quickly realized new opportunities for optimizing operational efficiencies. Without surprise, Microsoft uses the Windows PowerShell (version 2.0) and the .NET Framework (3.5) runtime in the Exchange 2010 management architecture, too. Among the Windows PowerShell 2.0 advances used in Exchange 2010 is the PowerShell Remoting feature. This feature uses WS-Management (WS-Man), a Windows component for easing the management of servers, devices and applications across an organization.

With Exchange 2007, the Exchange Management Shell allows administrators to manage all Exchange 2007 servers from a single management server; the cmdlets run in the host/process of the management server itself. The management server then establishes remote procedure call (RPC) connections to the Exchanges that are being manipulated. With the Windows PowerShell 2.0 Remoting feature, management is further simplified. Remoting provides standard protocols for managing Exchange 2010 servers through firewalls and explicitly separates “client” and “server” portions of the cmdlet processing. On top of that, WS-Man makes integration with the Windows OS more seamless than it was with Windows PowerShell 1.0.

Whether using the local Exchange management tools or a dedicated management server, you establish a “remote” connection when launching the Exchange Management Console or Exchange Management Shell. Exchange 2010 connects to the local Windows PowerShell virtual directory, created under IIS Manager’s Default Web Site, when Exchange 2010 management tools are installed on a machine (see Figure 1).

 

Figure 1 Windows PowerShell 2.0 Virtual Directory in IIS Manager

When the Exchange Management Console or Shell connects to the Windows PowerShell virtual directory, it imports the necessary cmndlets—or, more specifically, references to these cmndlets—from the server-side (aka runspace) to the client-side session. Once the cmdlet references have been imported, you can manage Exchange 2010 just like you normally would Exchange 2007 servers.

When using the Exchange Management Shell, you can create a Windows PowerShell session that establishes a new connection against a remote Exchange 2010 server. When doing so, any commands you run from the shell on the local server execute directly on the remote Exchange 2010 server to which you are connected.

Because the Exchange Management Console is built on top of the management shell and executes Windows PowerShell commands in the background, the management console behaves the same way as the shell. You can even use the console to connect to and manage an Exchange 2010 server in another Exchange forest (see Figure 2).

In fact, not only can you add additional Exchange organizations to the console, but also move mailboxes between two Exchange organizations (see Figure 3).

 

Figure 2 Multiple Exchange Forests in the Exchange Management Console

 

Figure 3 The New Remote Move Request Wizard in Exchange 2010

Cloud-Readiness
Ultimately you also will be able to manage Exchange Online, one of Microsoft’s software plus services solutions, from the Exchange Management Console and Exchange Management Shell. This will be possible once Microsoft updates Exchange Online to Exchange 2010; currently it’s based on Exchange 2007. This will give organizations the opportunity to choose an on-premises solution, a hosted service or mix of both—and manage them seamlessly.

Microsoft already has made this possible for educational institutions involved in the Microsoft Live@edu program, as well as for Microsoft employees who host their personal domains in Microsoft Exchange Labs, which host more than 10 million mailboxes to date.

Permissions Model

Exchange 2010 extends the access control entry (ACE)-based permission model Microsoft offers with Exchange 2007 to include a new authorization layer using role-based access control (RBAC). RBAC lets you define broad or precise permissions based on the roles of administrators and special end users. This means that you can define your permissions model in Exchange 2010 to match an organizational model without increasing complexity. The default role groups in Exchange 2010 should actually be sufficient for most enterprises, although you can create custom role groups if you like.

Said another way, RBAC now controls operational administrative and special user tasks and the extent to which users can self-administer their mailboxes, distribution groups and so forth.

Middle-Tier MAPI and Directory Access

In Exchange 2007, the Client Access server provides the connection endpoint for all clients except Outlook (Messaging Application Programming Interface, or MAPI) and Entourage (Web-Based Distributed Authoring and Versioning, or WebDAV ). This offloaded a significant amount of processing handled by back-end mailboxes in earlier Exchange 2007 versions.

Microsoft takes this a step further in Exchange 2010 with the introduction of RPC Client Access service, which moves MAPI and directory access connections to middle-tier Client Access servers. As a result, MAPI clients no longer connect directly to the Mailbox server when opening a mailbox. Instead they connect to the RPC Client Access service, which in turn talks to the Active Directory and Mailbox servers. For directory information, Outlook connects to a Name Service Provider Interface (NSPI) endpoint on the Client Access server; NSPI then talks to Active Directory via the Active Directory driver. The NSPI endpoint replaces the DSProxy component we know from Exchange 2007.

This differs from Outlook Anywhere (RPC over HTTP) clients that connect to a mailbox in Exchange 2007 in that those clients link to the RPC proxy component on the Client Access server. In addition, they talk MAPI over RPC directly with the Mailbox server and with the NSPI endpoint in Active Directory.

The RPC Client Access service has several benefits. First, with MAPI and directory connections moved to the middle-tier Client Access server role, Exchange now has a single common path through which all data access occurs. This not only improves consistency when applying business logic to clients, but also provides a much better client experience during switchovers or failovers using the new database availability group (DAG) feature (more on this feature later). Disconnections for Outlook clients might last 30 seconds versus the several minutes—heck, even up to 30 minutes—common in complex Active Directory topologies with Exchange 2007 Cluster Continuous Replication (CCR) clusters deployed.

Last, having a single common path for all data access allows for more concurrent connections and mailboxes per Mailbox server. In Exchange 2007, a Mailbox server could handle 64,000 connections. This compares to a 250,000 RPC context handle limit in Exchange 2010. With reliance on Client Access servers increasing with Exchange 2010, clients need quick reconnections from one Client Access server to another in response to planned or unplanned downtime. Say hello to Exchange 2010’s new Client Access array. As the name implies, this is an array of Client Access servers. More specifically, an array comprises all Client Access servers in the Active Directory site for which it is created. Instead of connecting to a Fully Qualified Domain Name (FQDN) of a Client Access server, an Outlook client connects to the FQDN of the array (such as outlook.contoso.com). This ensures that Outlook clients connecting via MAPI over RPC are connected all the time. The array also exists as an attribute on Mailbox server databases in the Active Directory site. This ensures that the array knows to which Mailbox server and database a user should be directed. If you protect the mailbox databases using the new DAG feature, and a copy of the respective database in another Active Directory site becomes the active one, Client Access server will talk directly with the Mailbox server storing the database copy via RPC. This is an important detail.

You can use Windows Network Load Balancing (WNLB) in conjunction with a Client Access array as long as the Mailbox server role is neither installed on the server nor protected by a DAG. Of course, you also can use a Client Access array in conjunction with an external hardware load balancer. But remember the array is only for Outlook RPC clients; you still use traditional WNLB or an external load balancer for services such as Outlook Web Access, Autodiscover, Exchange ActiveSync and the availability service.

Storage Optimization

With the use of a 64-bit architecture and reduced per-second I/O—up to 70 percent—Exchange 2007 created a far more efficient storage environment than possible with its predecessors. In Exchange 2010, Microsoft focused its storage optimization efforts on delivering large (+10GB), fast mailboxes while taking advantage of cheap storage.

With changes in the Extensible Storage Engine (ESE), with Exchange 2010 you now have the option of using such low-performance disks as the desktop-like SATA disks (aka Tier 2 disks). Yes, I am talking about the 7200 SATA disks similar to those in your workstation. If you use the DAG feature for high availability and have three or more database copies, you can even use, say, a single 7200 RPM disk for storing a database copy and the associated log stream. In other words, you no longer have to use small and fast disks in a RAID. Instead, you can store your databases on large and slow disks in a JBOD configuration.

Microsoft has achieved such significant storage performance improvements mainly by making a major change to the store schema as we know it. Essentially, Exchange 2010 developers wanted to move away from many, random, small I/Os to fewer, sequential, large I/Os. Moving from random to sequential I/Os required dramatic changes to the store table architecture.

In Exchange 2007 and earlier, each database had a mailbox table (stored all mailboxes in the database), folders table (stored mailbox folders for all mailboxes in the database), message table (stored messages), attachment table (stored attachments for all mailboxes in the database), and message/folder table (stored folder views for all mailboxes in the database). In this architecture, which hasn’t changed much since Exchange 4.0, a lot of random I/Os have to perform against the database. One of the benefits with this architecture is single-instance storage (SIS) in which only one copy of a message is kept—a big advantage back when relatively small disks were par for the course. But today, with 500GB SAS disks and 2TB SATA disks at our disposal, this architecture no longer makes sense.

In Exchange 2010, all data in a mailbox gets stored in tables close to each other in the database. Actually, each mailbox has its own folder, message header, body and view tables. So, SIS no longer exists in Exchange databases. As a side effect of removing SIS from Exchange, a database bloats by approximately 20 percent. To solve this problem, Exchange developers compressed the databases (more specifically, the message headers and text or HTML bodies). By giving each mailbox its own set of tables, I/Os performed against a database are mostly sequential.

Other interesting changes include: the database space is allocated in a contiguous manner; database contiguity is maintained over time; the database page size is now 32KB, up from 8; and asynchronous read capability has been improved. The Exchange product group also has increased the cache effectiveness significantly by changing the checkpoint depth to 100MB for high-availability configurations, using cache compression and database cache priority.

As a result of all the changes in Exchange 2010, you can expect up to a 70 percent reduction in I/O compared to Exchange 2007. Now that’s what I call ESE optimization.

Evolution of Exchange Continuous Replication

Prior to Exchange 2007, Microsoft offered only extremely limited high availability and disaster recovery features. IT managers could use Microsoft Cluster Server for redundancy at the hardware level; the storage subsystem was a single point of failure. In order to achieve redundancy at the storage level, organizations had to invest in third-party replication products.

With Exchange 2007, Microsoft improved on this situation with a whole sleeve of high availability and disaster recovery features, including the hugely successful CCR. This cluster replication technology combines asynchronous replication technology with Windows Failover Clustering to provide hardware and storage redundancy, high availability and no single point of failure.

Microsoft addressed the need for resiliency across sites with the Standby Continuous Replication (SCR) feature introduced with Exchange 2007 SP1. SCR enables the shipping of log files to and from clustered and non-clustered Mailbox servers. SCR allows IT to specify a log replay lag time of up to seven days, which means you can fix most database/store-related issues before they hit the SCR target in another data center.

Microsoft has improved CCR and SCR even further in Exchange 2010, combining the two into the DAG, the new continuous availability feature I mentioned earlier. A DAG is like CCR still dependent on a limited set of the Windows Failover Clustering component—mainly the cluster database, file share witness and the heartbeat functionality. DAGs provide protection at the database, server and site levels, and make deploying a site-level high availability/disaster recovery solution substantially easier than with previous Exchange versions.

DAG uses asynchronous replication just like CCR and SCR. With a DAG, you can create up to 16 copies of a mailbox database. One copy of a given mailbox database is active at a time. Should this database become unavailable, a DAG component called Active Manager automatically makes one of the other copies active. Because Outlook clients now connect to the Client Access servers (directly or via a Client Access array), users rarely will notice a failover or switchover to another database copy in the DAG.

Now protected, databases in Exchange 2010 reside at the organizational level (see Figure 4).

 

Figure 4 Database at the Organization Level Protected by DAG

This means that the storage groups we know from Exchange 2007 and earlier do not have a place within Exchange 2010. However, each database in Exchange 2010 has an associated set of log files because this new version uses the Atomicity, Consistency, Isolation and Durability (ACID) model like its predecessors.

With Exchange 2010, Microsoft also has upped the number of database on an Exchange 2010 enterprise edition server to 100 compared to 50 in Exchange 2007. Also worth mentioning is that even though DAG members require Windows 2008 enterprise edition (because of the dependency on some of the Windows Failover Clustering features), you can use the Exchange 2010 standard and enterprise editions with DAGs. Keep in mind, however, that the standard edition is limited to five databases per mailbox server.

Deploying and managing a DAG is much easier than a CCR cluster, for instance, because all required steps are performed from within either the Exchange Management Console or Exchange Management Shell. Clustering is directly integrated with Exchange and transparent to the administrator. So you can say goodbye to clustering skills and separate administration tools for managing your Exchange continuous availability solution. Even multi-site DAG scenarios are easier to deploy and administer, and now you can—unlike with CCR—locate DAG member servers in different Active Directory sites. This means you no longer have to stretch the Active Directory site across physical locations—something you couldn’t do with multi-site CCR clusters in Exchange 2007.

Mobility Enhancements

With each Exchange iteration, Microsoft has brought exciting changes to Exchange mobility, more specifically Outlook Web App (OWA)—formerly called Outlook Web Access—and Exchange ActiveSync. Exchange 2010 is no exception.

Outlook Web App
In fact, Microsoft has made so many changes to OWA that the technology deserves an article of its own. Here are some examples:

Presence is built into OWA (see Figure 5). This means that you can see and change your presence status as well as view the presence of others using the Office Communications Server solution (you can also integrate third-party solutions). Users can even IM each other from within the OWA interface. Users can manage their Office Communicator contact list, viewable in the left pane, from within OWA.

• Premium browser support now extends to Mozilla Firefox 3+ and Safari 3+ for Mac, as well as—of course—Internet Explorer (version 7 or later).
• Users can send and receive Short Message Service (SMS) messages directly in OWA (and Outlook 2010 for that matter) rather than entering them on a mobile device. OWA sends the SMS via your mobile device, where responses are received. You can even synchronize SMS messages to user mailboxes so they’re stored and backed up centrally.
• Exchange 2010 introduces a new conversation view with OWA (and Outlook 2010 and Windows Mobile with the new Outlook Mobile version installed). The idea with conversation view is to reduce the overload of information in a user’s inbox. With this feature, all messages in a conversation thread appear together in a simple and logical view, enabling users to identify unread messages quickly and understand the series of responses in the thread. The conversation view is kept intact even as messages move out of the Inbox and into other folders. A user can manage, ignore, move and delete conversations as a whole rather than react to each individual message.
• An Exchange Control Panel replaces the Options page we know from previous OWA versions (see Figure 6). From this panel, users can manage traditional OWA settings but also perform message tracking for their own messages, create and moderate distributions with required RBAC permissions and the like. In addition, users can now update personal Active Directory information such as name, title, department and phone number.

Figure 5 The OWA 2010 User Interface

 

Figure 6 OWA 2010 Exchange Control Panel

Exchange ActiveSync
Exchange ActiveSync is considered the de-facto standard specifying how mobile devices synchronize with a mailbox. Exchange 2010 introduces several exciting new features to ActiveSync-based clients:

• Exchange administrators can now approve devices by type or by user, block unsupported phones and quarantine unknown phones. Blocked phones will not be able to synchronize with a mailbox while quarantined phones may be allowed to synchronize based on administrator approval. Users can look up free/busy information via the new Outlook Mobile version included with Windows Mobile 6.5. When opening a contact’s property page, a timeline similar to the one we know from OWA 2007 will be visible. The timeline is even color-coded.
• Exchange 2010 also includes support for nickname cache on Windows Mobile devices as the cache is now stored centrally in the user’s mailbox.
• In a nifty move, Microsoft now allows Windows Mobile devices that run Windows Mobile 6.1+ to download the new Outlook Mobile client (the one included with Windows Mobile 6.5) as a .CAB file. When users first synchronize their Windows Mobile 6.1 devices with their mailboxes, they automatically will receive an e-mail message with a link to the new Outlook Mobile version. This allows the users within the enterprise to take advantage of the new Exchange/Outlook Mobile features introduced with Exchange 2010 without having to invest in new Windows Mobile 6.5 devices.

Unified Messaging

Although the architecture remains the same, Microsoft has improved and enhanced Unified Messaging with Exchange 2010. Among the deep investments are voicemail preview, protected voicemail, message waiting indicator, call answering rules and support for additional language packs.

• Voicemail preview provides users voice-to-text translation directly in Outlook and OWA. This means users no longer need to listen to traditional voicemail messages, which is a cumbersome task for many. They can instead see the voicemail as a text message in their e-mail client. When using Outlook 2010, the text of the voice message even becomes actionable, meaning that names, contacts and phone numbers will be recognized and are clickable. Voicemail preview also is possible via Windows Mobile devices. Voicemail preview initially supports the U.S. and Canadian English, French, Portuguese, Italian and Polish languages. When Exchange 2010 SP1 becomes available sometime next year, it will add support for more languages.
• Protected voicemail uses Active Directory Rights Management Services to protect voicemails. For instance, users can mark voicemails as private so they cannot be forwarded to other recipients. Although users can do so themselves, this setting also can be controlled via an administrative policy.
• The message-waiting indicator notifies users of the presence and number of new/unread voicemails on their supported desk phones. With this feature, users can even receive voicemail previews as SMS messages.
• Call-answering rules, another new feature of Exchange 2010, works similarly to traditional inbox e-mail message rules but for incoming user calls. Users can create a kind of personal auto attendant that includes a menu for incoming call flow control. For instance, users could set up rules for what to do with calls based on criteria such as time of day, caller ID, their own schedule and so on. Call-answering rules also allow users to create a custom set of menus for incoming callers.
• The Exchange 2010 RTM version has support for 16 language packs, with 10 more forthcoming soon.

Archiving and Retention

Over the years, the ability to preserve business records efficiently has become more and more critical. This especially includes e-mail, which for most enterprises is the principle source of data in legal discovery and other compliance-related investigations.

Managing e-mail for compliance has long challenged enterprises, even though Exchange 2007 introduced several protection- and compliance-related features such as messaging records management (MRM), transport rules and journal rules. Exchange 2010 introduces the concept of retention policies. Retention policies are part of the MRM feature set in Exchange 2010 and a direct replacement of managed folders.

Exchange 2010 also solves the mailbox-size limitation that forces users of earlier versions to move e-mail messages to local .PST files for archiving—and making compliance management difficult for administrators.

To solve the .PST issue, Exchange 2010 delivers a new personal archiving feature. The Exchange administrator can now enable online archive mailboxes for users, eliminating the need for offline .PST files. The new online archive is visible via Outlook 2010 and OWA 2010, and Outlook 2010 even supports drag and drop of .PST content to the online archive. Exchange administrators also can configure retention policies that automatically move messages—mail that is older than one year, for example—to the online archive.

Exchange 2010 also includes new functionality that allows users within the legal and compliance departments to perform multimailbox searches and immediate legal hold, which enables immediate preservation of a user’s deleted and edited mailbox items.

With these new features, taking control of enterprise information is easier and more flexible than possible with earlier Exchange implementations.

New Organization Federation Model

With Exchange 2007 and earlier, federating between multiple Exchange forests in the same enterprise or in separate enterprises has been a somewhat inconvenient and at times complex task. In order to share free/busy information between Exchange 2000/2003 organizations, you had to first replicate all required mail users from one organization to the other as contact objects using the GALSync management agent included with Forefront Identity Manager (FIM), formerly known as Microsoft Identity Integration Server and ILM. Then you had to use a tool such as Inter-Organization Replication (IOREPL) to replicate free/busy information via public folders. With Exchange 2007 things improved a little. You can share free/busy information between Exchange 2007 organizations using the new Availability service. More specifically you use the Add-AvailabilityAddressSpace cmndlet to set up free/busy sharing between organizations. Unfortunately, when no trust relationship is established between the involved organizations, cross-forest free/busy sharing is limited.

With the new federation features included in Exchange 2010, you can share free/busy, user calendars and contacts between forests. However, bear in mind that the Exchange 2010 federation features require that all involved organizations have Exchange 2010 deployed. It doesn’t need to be a pure Exchange 2010 organization; because of some down-level proxy improvements in Exchange 2007 SP2, you can benefit from the new federation features between Exchange 2010 and 2007 SP2 organizations that have at least one Exchange 2010 Client Access server deployed.

The federation features in Exchange 2010 use a new Windows Live-based service known as the Microsoft Federation Gateway (MFG). The MFG, located in the cloud, basically acts as a trust broker between Exchange 2010 organizations that want to share data (see Figure 7). It’s important to stress that even though a Microsoft gateway is used to establish federation trusts between Exchange 2010 organizations, no data from any of the involved Exchange organizations is shared with Microsoft. Organizations simply use the MFG to assure security when publishing information about their domain and enabling domain access to data.

 

Figure 7 The new Federation TrustWizard in the Exchange 2010 Management Console

The new federation features don’t require any trust relationships or data replication between the involved organizations. To view the free/busy status for a user at the other organization, an Outlook 2010 or OWA 2010 user simply types in that person’s e-mail address in the scheduling assistant. (In Outlook 2007, the mail users from the opposite organization must be replicated so they appear in the local global address list.) The calendar and contacts sharing features both require OWA 2010 or Outlook 2010.

You can specifically set what data you want to share using sharing policies and at what level that data should be shared. And with the organizational sharing policy, you can create a sharing policy. Here you can specify how much information users should be able to share and with which domains (see Figure 8).

 

Figure 8 The New Organizational Relationship Wizard in the Exchange 2010 Management Console

Miscellaneous Coolness

In short, here are other cool things available with Exchange 2010:

Online Mailbox Moves Exchange 2010 replaces the Move Mailbox wizard with the Local Move Request and Remote Move Request wizards, which bring several benefits with them. For instance, administrators can now move mailboxes during working hours as the source mailbox that is moved isn’t taken offline during the process. As a matter of fact, users can send and receive e-mail, access the GAL, schedule meetings and so forth during the mailbox move. In addition, you can use the Exchange Management Console to move mailboxes between Exchange forests.

MailTips MailTips allow a sender of an e-mail to view informative messages while composing a mail in either Outlook 2010 or OWA 2010. Microsoft has created several default MailTips, but you also can add your own. Default MailTips include invalid internal recipient (if the user or group you enter in the To: or CC: fields doesn’t exist in Active Directory), mailbox full (mailbox of the recipient is full), automatic replies (shows out of office and other automatic replies), restricted recipient (based on policy), oversize message (message larger than send or receive size, message size or request length setting), and large audience (when sending messages to groups larger than 25 members).

Transport Resiliency Also known as shadow redundancy, this new functionality makes sure a message isn’t deleted from a sending Hub Transport server before the destination Hub Transport server acknowledges message delivery. With Exchange 2007, if you lost the message queue database then messages within it would be lost. With the redundancy feature, this doesn’t happen in Exchange 2010. This means you can easily replace a failed Hub Transport server simply be removing it from the production environment without emptying queues. It also eliminates the need for storage hardware redundancy, which has a direct effect on costs.

Dynamic Signatures You can now (via transport rules) deploy personal or corporate signature or disclaimers that contain HTML, specific fonts, company logos (even animated GIFs), and use the DisplayName, FirstName, LastName, Department and Company values for a user in Active Directory when creating them.

Distribution Group Moderation It’s now possible to configure moderated distribution groups that require a moderator to accept a message before it’s sent to group members. You also can manage group membership from the new OWA 2010 Exchange Control Panel (ECP). Users can be assigned permissions so they can create their own distribution groups within the ECP.

Bulk Recipient Management in the Exchange Management Console You can now perform bulk recipient management from within the Exchange Management Console. For instance, you can now move, remove, disable and enable user mailboxes in bulk. You can even edit recipient properties if the same type of recipients is selected.

Send Mail When Outlook is installed on the same machine as Exchange Management tools, you can send mail to a user mailbox, mail contact, mail user or distribution groups.

Manage folder permission With Exchange 2010, you can manage Outlook folder permissions using the new Add-MailboxFolderPermission, Get-MailboxFolderPermission and Remove-MailboxFolderPermission cmdlets.

Exchange 2010 introduces many new and exciting features and improvement over existing ones. No doubt you’ll find Exchange 2010 a comprehensive, integrated and flexible messaging solution for enterprises of all sizes.

Related Content

• Exchange Queue A: Load Balancing, Edge Transport and More
• Exchange Queue A: Aligning Disk Partitions, Planning for SCR and More
• Exchange Queue A: New Features and Improvements in Exchange 2010

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a technology architect for Timengo Consulting (a Microsoft Gold Certified Partner based in Denmark) and as a technical writer for Biblioso Corp. (a United States-based company that specializes in managed documentation and localization services). You can reach him at exqa@microsoft.com.