Increase Efficiency With Collaboration
Empower your employees by adding e-mail and instant messaging to your intranet.
by Danielle Ruest and Nelson Ruest

September 9, 2004

For This Solution: Windows Server 2003, Web, Standard, Enterprise, or Datacenter Editions, Windows SharePoint Services, Microsoft Office SharePoint Server 2003, Microsoft Content Management Server 2002, Enterprise Edition, Microsoft Content Management Server Connector for SharePoint Technologies, Microsoft Office Live Communications Server 2003, Microsoft Exchange Server 2003, Standard and Enterprise Editions Server Cluster Service, Network Load Balancing Service

Collaboration is the name of the game in today's third-generation intranet. The core technology for such an intranet based on Microsoft technologies is Microsoft Office SharePoint Portal Server 2003—an integrated collaboration portal technology. SharePoint Portal Server (SPS) builds upon the native Windows SharePoint Services (WSS)—a free add-on to Microsoft Windows Server 2003—to provide comprehensive team site management, unified portal services, and comprehensive indexing and search capabilities. However, technologies that support team sites are not the only components required in a fully collaborative environment. You also need communications systems so that your information workers can collaborate both in real time and through deferred communications. For this, you need to look at other members of the Windows Server System stack: Microsoft Office Live Communications Server (LCS) 2003 and Microsoft Exchange Server 2003.

You need more than the solid framework for collaboration and teamwork SPS and WSS provide to build your core intranet. Another core component to integrate is Microsoft Content Management Server 2002 (MCMS). MCMS provides the ability for nontechnical staff to add content to the intranet in the form of HTML documents. MCMS's best feature is that content providers can work with either Microsoft Word or HTML documents. Built into MCMS are the capabilities to support authorization workflows, automatic publishing of content based on publishing dates, and automatic removal of time-sensitive content. Along with the MCMS Connector for SharePoint Technologies, MCMS, SPS, and WSS form the core of the third-generation intranet (TGI).

Because this new collaborative and communications environment is critical to your users—you'll fast see just how critical these tools can be when team and personal sites start proliferating in your network—you should ensure its availability at all times. To do so, you'll need to integrate Windows Server's clustering technologies into the picture, providing both load balancing and business continuity to these core intranet components (see Figure 1).

This is one reason why the deployment of the TGI is separated into phases: It is simpler to focus on the provision of a few core functionalities first, and then add on to the core functionality that is already in place and running as you progress through the implementation of your TGI (see Resources). Once these core functionalities are in place, it is relatively simple to progress to the next stages. The first of these is making sure that the communications environment, most notably Microsoft Exchange, is tied into the collaboration environment.

Tying E-mail and Messaging to the TGI
Most organizations already have some core functionality in place in their network when they move to the TGI. It goes without saying that there is great advantage to having an Active Directory in place before implementing either SharePoint or Content Management Server. Besides, SharePoint only runs on Windows Server 2003. An organization eschewing Windows Server and Active Directory in favor of running with NT domains should revisit this strategy.

Another key element of the TGI is the Domain Name System (DNS), which has become closely tied to Active Directory because it is the basic element that helps the directory to work. It is also a key element for SharePoint because SharePoint is entirely Web-based. Together, DNS and AD form the core directory services of any modern Microsoft network.

Along with these core directory services, organizations will most likely have a basic e-mail communication system in place. No organization can do without e-mail today, and many have already identified the value of moving to Exchange Server 2003, especially since Service Pack 1 is now available. Exchange 2003 and its companion client, Outlook 2003, fully support centralization of services and consolidation of servers. Exchange can now support more storage groups per server, provides more flexibility for group management and distribution, provides an enhanced client experience through Outlook Web Access (OWA), and now supports RPC over HTTP, allowing more secure deployments. The client experience has been improved with its new caching mode, doing away with multiple client connectivity error messages as well as the high degree of similarity between OWA and the real Outlook client. In fact, many organizations that do not have the workstation infrastructure to support Outlook 2003 deployments use a mix of the real client with OWA to give the same look and feel to their users. This way no one is left out.

With Service Pack 1, Microsoft has enhanced the migration toolkit for Exchange, something many system administrators find wanting. Before SP1, supported migrations tended to focus much more on in-place upgrades. Now, organizations can use this opportunity to restructure their Exchange organizations, making it more streamlined. In terms of the TGI, having Exchange already in place enhances the SharePoint experience by mail-enabling Web sites and providing presence information (see Figure 2). It also fits nicely into the existing server architecture that is in place to support the TGI because it uses the same front-end/back-end service configuration. This means that a new load-balanced cluster can be created for Exchange front-end servers working as mail routers, as well as for hosting the OWA service.

A back-end server cluster is then used to manage the Exchange storage groups. This service can even be hosted in the original cluster prepared for SharePoint and Content Management Server storage. All you might need to do is add nodes. Which cluster will host this service will depend on the workload you anticipate and the number of users you have to support. But, it is profitable to place both Exchange and SQL Server on different nodes of a multinode server cluster, if only for the added advantage of being able to distribute services and failovers over a greater number of overall nodes than if each had its own cluster. One additional advantage of the Exchange front-end/back-end service distribution is licensing. Front-end servers only require standard editions of the software because they are based on NLB. Back-end servers continue to require the enterprise editions because they are running the server cluster service.

Now you're ready to add even more functionality to the TGI.

Implementing Realtime Communication
With the core TGI in place as well as e-mail services, the following technologies should be in place and integrated:

• Windows Server 2003
• Internet Information Services 6.0 including ASP.NET
• Windows SharePoint Services
• Microsoft Office SharePoint Portal Server 2003
• Microsoft Content Management Server 2002, Enterprise Edition
• Microsoft SQL Server 2000 with Service Pack 3a
• Microsoft Content Management Server 2002 Connector for SharePoint Technologies
• Active Directory with integrated DNS
• Microsoft Office 2003 on Windows XP clients
• Microsoft Exchange Server 2003

One of the best new functionalities to add at this time is realtime communications. This enhances the intranet experience by giving users instant messaging, basic conferencing, and whiteboard sharing in real time. To offer this service, you can deploy LCS 2003 and its corresponding client, Windows Messenger 5.0, to the TGI. Users will see an immediate change in the TGI, noting realtime presence information through the addition of color-coded icons and being able to launch instant communications through a right-click of the mouse in the intranet interface.

Once again, larger LCS deployments use the front-end/back-end architecture, but this time back-end services are distributed. That's because LCS uses the Microsoft SQL Server Desktop Engine (MSDE) to store contact lists, contact groups, allow/block lists, and user subscriptions for each user, and MSDE is designed for the storage of multiple, local databases, not central database storage supported by server clusters. This means that the back-end LCS architecture will differ slightly from that of the other services in the TGI. In addition, LCS requires integration to the Active Directory, much like Exchange, but with less volume, so schema changes are required both at the forest and domain level.

Because this instance of LCS is internal, you might decide against using Transport Layer Security (TLS) to secure each communication and therefore will not require an internal Public Key Infrastructure (PKI). However, an internal PKI might be required in the support of other functionalities in your network. LCS uses the Session Initiation Protocol (SIP) to publish information and connect users for dialog. The location of this service must be published through DNS. This requires the creation of special LCS records in DNS (see Resources). Of consideration is the requirement to deploy the Windows Messenger component to all workstations and the configuration of each user to enable SIP.

LCS can also archive all conversation information. If your organization has this requirement for standard conformity or for auditing purposes, you'll need to implement other instances of the SQL databases on your server cluster. Unlike user configuration data, archiving is stored in proper instances of SQL Server and can thus take advantage of the server cluster service. It will also require Microsoft Message Queuing in order to transfer data from the archiving servers to the SQL data store. Home servers will host user communications and front-end servers will act as maestros to redirect user connections to proper home servers. If your usage load is more demanding than most, you might want to use DNS Round Robin to distribute front-end loads. This way the DNS service will automatically distribute the load appropriately based on the number of servers in the Round Robin list (see Figure 3).

What the User Sees
The integration of both Exchange and LCS into the TGI will vastly improve a common user's experience because he or she can use the network to communicate with collaborators. The great advantage of building on the core intranet service and adding functionality is that the TGI is already deployed and users have already begun to become familiar with it. As a result, when new services are added, users do not see it as a traumatic experience. Compare this to the upgrade of Microsoft Office, or worse, the migration from another office automation suite to Microsoft Office. In this case, users are often traumatized because of the massive change and their fear of the unknown. Corporations must take extra steps to manage the change and reduce its impact on users. Formal instruction is required, both novice and advanced, and sometimes, even personal handholding is necessary. Not so with the addition of functionality to the core TGI.

The effect is so transparent that sometimes users don't even notice the difference and think the feature has been there all along and they just hadn't noticed it. In addition, you can use the new intranet as your change management tool, providing online tutorials, help contents, and site or page maps so that users can use their own skills to learn more. In addition, if you migrate only some users at a time, you can use the personalization capabilities of TGI to target each audience as they are integrated to new functionalities. This way, your site can be constantly presenting different content that's appropriate for each community. After all, isn't that one of its main objectives?

The benefits of the TGI become more evident with each passing day. Because of its simplicity and self-sustaining user servicing, it is its own vehicle for just-in-time help and support and information gathering.

About the Authors
Danielle Ruest and Nelson Ruest (MCSE, MCT) are multiple book authors focusing on systems design, administration and management. They run a consulting company that concentrates on IT infrastructure architecture and change and configuration management. You can reach them at .