Contoso wants to enable IM, Presence, and On-Premise Conferencing Scenarios for all Office Communications Server 2007 users in the organization. Also all users should be given the capability to remotely log in from the Internet to the internal Office Communications Server 2007 infrastructure by using Office Communicator 2007, Office Communicator Phone Edition, or Live Meeting 2007 even without setting up a virtual private network (VPN) to the enterprise. In Chicago and Madrid, the Enterprise Voice Scenario will be enabled as well, but only for a subset of users (100) in Chicago. Communicator Web Access will not be deployed for now, but Archiving will be deployed in Madrid to capture Call Detail Records.

If you compare now the selection of scenarios by Contoso with the server role requirements presented in "Step 1: Determining Key Planning Decisions" in the "Office Communications Server 2007 Planning Guide," the server roles shown in Table 11-3 need to be deployed.

In "Step 1: Determining Key Planning Decisions" in the "Office Communications Server 2007 Planning Guide," some preliminary decisions on the core architecture (Standard Edition versus Enterprise Edition) are discussed. Because Contoso sees the need for IM, Presence, and Conferencing for all sites, Office Communications Server 2007 Standard Edition is not the right choice for any of the sites. A single server deployment always contains the risk of having a single point of failure. Because Contoso is geographically distributed—with users in Chicago, Paris, Madrid, and Singapore—it is necessary to deploy an Office Communications Server 2007 Enterprise Edition architecture on every site to provide reliable scenario availability on each site. This topology is referred to as Global Conferencing Deployment with Multisite External Access and Voice.

What you've learned from the previous planning step is that on every site an Office Communications Server 2007 Enterprise Edition deployment is necessary according to the deployment goals. However, it is not decided yet which Enterprise Edition deployment option is the appropriate one given the user numbers on each individual site.

Given the number of users on each site and the topology examples in Step 2: Select Your Topology in the "Office Communications Server Planning Guide," Contoso's global deployment needs to have the core architecture for each site as shown in Table 11-4.

At this point, the number of individual server roles needed to support the designated scenarios is not defined. This will be part of Step 5: Review System and Network Requirements. When based on the capacity numbers, the number of server roles for consolidated Enterprise Edition Server, Front End Server for expanded Enterprise Edition, as well as Web Conferencing and A/V Conferencing Server will be determined. The Edge Server roles for the Remote Access Scenario and Federation Scenario will be covered in Step 6: Plan for External User Access. The number and location of Mediation Server roles for the Enterprise Voice Scenario will be handled in Step 8: Plan for VoIP.

Step 3: Plan Your Deployment Path in the "Office Communications Server 2007 Planning Guide" covers planning considerations as well as additional information that is relevant when you start the deployment. From a planning perspective, it is necessary to concentrate on aspects of the later deployment, which cannot be changed quickly or might have a significant impact on the enterprise IT environment, delay the deployment, or even make the whole deployment impossible.

For an Office Communications Server 2007 deployment, either a Public Key Infrastructure (PKI) has to be in place or certificates issued by an external Public Certificate Agency can be used. This is necessary because Office Communications Server 2007 authenticates and authorizes any communication between clients. Furthermore, all communication is encrypted.

Therefore, certificates that can be verified against a PKI or an external Public Certificate Agency and contain the correct enterprise-specific validation information have to be issued and installed. If—as in the Contoso case—the Remote Access and Federation Scenarios will be deployed, the certificates for the Edge Server have to be issued by a Public Certificate Agency. This is necessary because it is not possible for external users or federated companies to verify certificates against an enterprise-internal PKI. Any third-party Certificate Agency can be used to issue all certificates—although a Windows 2003 Certificate Agency with auto-enrollment support simplifies Office Communicator Phone Edition deployments.

Active Directory is another prerequisite for an Office Communications Server 2007 deployment, as it is the store for user objects and user management information. For an Office Communications Server 2007 deployment, the Active Directory schema has to be extended, which usually requires following a certain enterprise-specific process and varies in preparation time from enterprise to enterprise. In the planning phase, the required administrators for Active Directory in the enterprise should be informed about the additions that need to be applied on the existing schema so that they can approve and prepare the schema expansion well enough ahead of time to avoid delay in the actual deployment. Later in this procedure, the Contoso Active Directory architecture is checked to see whether it complies with one of the supported Active Directory topologies of Office Communications Server 2007.

DNS is another key prerequisite for an Office Communications Server 2007 deployment. Throughout the Office Communications Server 2007 deployment, several DNS SRV (DNS Service) records have to be configured. If this process results in significant preparation time in your enterprise, you should read the official deployment documentation for the scenarios you want to deploy and note all required DNS SRV records. This way, you can inform the DNS administrators in your enterprise who are already in the planning phase or—if you have access to the DNS configuration—you can configure the DNS SRV records ahead of time to ensure a quick Office Communications Server 2007 deployment. Details about DNS preparation can be found in "Step 4: Prepare Your Infrastructure" in the "Office Communications Server 2007 Planning Guide" as well as in the individual deployment guides of the official Office Communications Server 2007 documentation.

Office Communications Server 2007 must be deployed on servers that comply with at least the minimum hardware and software requirements for an Office Communications Server 2007 deployment. We will discuss the server hardware requirements in Step 5: Review System and Network Requirements but do note now that the servers need to be prepared with Microsoft Windows Server 2003 SP1 (Service Pack 1) or R2 as the operating system. For the Enterprise Edition Back-End Database, we recommend Microsoft SQL Server 2005 SP2 or Microsoft SQL Server 2000 with SP4.

Another potential blocking point for an Office Communications Server 2007 deployment or a potential cause for a delay in the deployment is missing permissions. If you don't have sufficient permissions for all the required configuration steps, you need to get these rights or inform the responsible administrators what they need to configure on your behalf. A table can be found in Step 4: Prepare Your Infrastructure of the "Office Communications Server 2007 Planning Guide" that summarizes all required user accounts and access rights you need to have for an Office Communications Server 2007 deployment.

Now that we have checked the general availability and compatibility of Active Directory, DNS, and Certificates for an Office Communications Server 2007 deployment in the previous chapter, you can start with the preparation of these entities to support a smooth Office Communications Server 2007 deployment.

Step 4: Prepare Your Infrastructure in the "Office Communications Server 2007 Planning Guide" contains the prerequisites for Active Directory, as well as topologies supported by Office Communications Server 2007. You have to make sure that your designated Office Communications Server 2007 deployment follows one of the recommended topologies.

As shown previously in Figure 11-2, Contoso has a single forest architecture with multiple domains and therefore has a supported Active Directory topology. The domains in which the Office Communications Server 2007 pools will be deployed are mostly dependent on the following:

Contoso has Domain Controllers for the contoso.com domain in each of the sites. Therefore, all Office Communications Server 2007 pools will be deployed in the contoso.com domain, and no problems with the delegation of rights/tasks will be encountered. The entire enterprise-wide Office Communications Server deployment will be administered by the administrators in the United States.

The availability of certificates for all server roles is another important prerequisite for an Office Communications Server 2007 deployment. "Step 4: Prepare Your Infrastructure " in the "Office Communications Server 2007 Planning Guide" contains a table with information about where you need to have certificates installed and which information these certificates need to contain in order to allow verification by other server roles against the PKI infrastructure.

As mentioned in the previous chapter, several DNS records have to be configured for the pools as well as for the Edge Server to allow Remote Access, Federation, and PIC Scenarios. You can find in Step 4: Prepare Your Infrastructure of the "Office Communications Server 2007 Planning Guide" which DNS records have to be configured. The configuration of DNS records depends on whether the Office Communications Server 2007 topology requires Load Balancer to distribute traffic equally among a number of server roles, because these DNS records have to point to the Load Balancer instead of to the individual server roles fronted by the Load Balancer. The necessity for Contoso to deploy Load Balancer fronting Enterprise Edition Server and Edge Server will be discussed in Step 7: Plan for Deploying Load Balancers.

The following deployment decisions have an impact on the DNS requirements:

So far, the planning process for Contoso's Office Communications Server 2007 deployment was based on actual user numbers. It's not just the number of actual users that has an impact on the performance of the system; it is also the scenario usage patterns of the users. All scenarios have to be provided by the same physical servers; therefore, it is necessary to estimate the peak-hour usage of the individual scenarios as part of the planning process. This estimation might be feasible for mature forms of communication such as IM, but it can become challenging in the Conferencing Scenario to estimate the average participant structure of conferences. For instance, it's hard to estimate for Live Meeting 2007 sessions the number of internal participants from the same site, internal participants from another site, remote authenticated participants, or anonymous participants. You would also need to know how many participants joining the conference remotely are doing so over the Internet vs. across federated links. Furthermore, you would need to know the distribution between data-only conferences sharing Microsoft PowerPoint slide decks, data conferences with audio only, or data conferences with both audio and video, for instance when using Microsoft Office RoundTable.

Another dimension of complexity is that even if you would have all the above information concerning conferencing usage patterns, such usage behavior might change because of technology improvements. For example, more people might add video to a Live Meeting as the tool became easier for them to use. The same considerations apply to Enterprise Voice scenarios. For example, although it is possible to estimate the call volume based on usage data reports of the existing telephone system, it is fairly hard to estimate the number of conversations that will contain not only audio, but IM and video as well. So once users become familiar with the usage of all the different modalities to improve their workflow, the scenario usage will shift.

Based on all these considerations, the Unified Communications Product Group decided to define a usage model based on performance-testing experiences in the MSIT (Microsoft IT) environment. This usage model is presented in "Step 5: Review System and Network Requirements" in the "Office Communications Server 2007 Planning Guide."

In the case of Contoso, the presented usage model complies with the expected scenario usage that the Office Communications Server 2007 deployment has to support after the installation. The line of business of the enterprise, which is a pharmaceutical company, does not lead to expectations of unusually high numbers of remote users or extensive A/V conferencing usage. Based on the table presented in "Step 5: Review System and Network Requirements," the number of physical servers that have to be deployed for Contoso's Office Communications Server 2007 deployment is shown in Table 11-5. (The Internet Information Service, or IIS, role discussion is beyond the scope of this chapter because it is not an Office Communications Server 2007 server role.)

Now that the number of server roles has been determined, the required server hardware has to be assessed. Step 5: Review System and Network Requirements in the "Office Communications Server 2007 Planning Guide" provides the minimum requirements for server hardware for the individual server roles. Contoso orders server hardware that exceeds the minimum requirements in the "Office Communications Server 2007 Planning Guide."

As part of this planning step, the network impact of the different scenarios and their associated usage has to be estimated and, as a result of that, the network has to be prepared. With Live Communications Server 2005 SP1, it was fairly easy to estimate the network impact because mostly IM messages and Presence information had to be transmitted between clients or between clients and a server. Now with the additional scenarios—on-premises Conferencing and Enterprise Voice—IP network administrators will become more challenged to provide a compliant network infrastructure that can handle the following in a reliable and dynamic fashion:

One thing that makes the IP network administration even more difficult is that the bandwidth requirement might shift within the same conversation as media is added and retracted as the conversation flow requires. To prepare the IP network for an Office Communications Server 2007 deployment, you have to estimate the bandwidth requirements based on the scenario usage and you have to make sure that the VoIP-specific requirements—for example, low packet loss, low jitter, and low delay (that is, a delay of less than 150 milliseconds per roundtrip)—will be provided.

Media connections have the biggest impact on the IP network. Media streams flow in an Office Communications Server 2007 deployment between the components as illustrated in Figure 11-5. (Endpoints are Office Communicator 2007, Office Communicator Phone Edition—except for video—and Live Meeting 2007.)

Figure 11-5. Media flows in an Office Communications Server 2007 deployment

To calculate the bandwidth requirements, the number of concurrent connections in a peak-hour situation has to be multiplied with the bandwidth needed, which depends on the codec that is used, as presented in "Step 5: Review System and Network Requirements" in the "Office Communications Server 2007 Planning Guide."

A sample calculation for the bandwidth requirements on the Edge Server is described in "Step 6: Plan for External User Access."

Office Communications Server 2007 provides four different Edge Server topologies for Remote Access Scenarios, the Federation Scenarios, and the PIC Scenarios. You can choose the right topology based on the number of outside connections that the infrastructure has to provide.

Because Contoso's site in Madrid has no perimeter network infrastructure to place Edge Server roles in a secure way, Madrid users will use the Edge Server roles deployed in Paris for any Remote Access Scenario. For the Edge Server calculations, the Madrid user numbers have been added to the Paris user numbers. Table 11-6 shows the results (including the number of concurrent participants in Audio, A/V and PowerPoint, and Application Sharing meetings) of the spreadsheet calculations for each of Contoso's sites.

By comparing the Contoso global infrastructure to the three datacenters with the supported Edge Server topologies presented in "Step 6: Plan for External User Access," in the "Office Communications Server 2007 Planning Guide," the appropriate topology for Contoso is a Multisite Edge topology.

A Multisite Edge topology suggests having at least two load-balanced colocated Access Edge and Web Conferencing Servers with at least two separate load-balanced A/V Edge Servers in the main datacenter and single or multiple load-balanced Web Conferencing and A/V Edge Server roles on dedicated physical machines in each of the remote locations where users require remote access. The Edge Server capacity table in Step 5: Review System and Network Requirements in the "Office Communications Server 2007 Planning Guide" shows the capacity numbers for colocated and individual Edge Server roles.

Step 6: Plan for External User Access in the "Office Communications Server 2007 Planning Guide" recommends colocating the Access Edge Server with the Web Conferencing Edge Server in the main datacenter (which is Chicago for Contoso) and to have at least two load-balanced physical servers (for performance reasons and for redundancy purposes). All Access Edge connections have to be accumulated, as there can be only one single Access Edge Server location in an Office Communications Server 2007 deployment.

According to Table 11-6, the total number of connections (1 connection equals 1 remote participant of an online meeting using LiveMeeting 2007) to the Access Edge Server in Chicago is 1752 plus 765 plus 375, which equals 2892 connections in a peak-hour situation. The number of Web Conferencing connections for Chicago is 1314, as shown in Table 11-6. Neither the number of Access Edge connections nor the number of Web Conferencing connections exceeds the performance parameters for two colocated Access Edge and Web Conferencing Edge Servers according to the values presented in Step 5: Review System and Network Requirements in the "Office Communications Server 2007 Planning Guide." According to the same step, to provide sufficient performance to accommodate the number of concurrent A/V Edge Server connections in Chicago (528 according to Table 11-6), Contoso could deploy only one standalone A/V Edge Server role on a dedicated machine However, because the company sees the Remote Access Scenario as business critical and instead wants to eliminate any single point of failure, Contoso decides to deploy two separate load-balanced A/V Edge Servers. This deployment strategy also provides a sufficient buffer for future usage. The Chicago Edge Server deployment is similar to a Single-Site Edge topology.

The remote access requirements for Paris and Madrid combined is 231 concurrent A/V meeting participants and 576 Web Conferencing participants, as shown in Table 11-6. According to the performance numbers presented in Step 5: Review System and Network Requirements in the "Office Communications Server 2007 Planning Guide," this could be accommodated by a single Web Conferencing Server and a single A/V Edge Server. But because the Remote Access Scenario for Paris users is seen as business critical for Contoso, it is necessary to deploy two load-balanced Web Conferencing Edge Servers and two load-balanced A/V Edge Servers for redundancy.

According to the values presented in Table 11-6, the estimations for concurrent meeting participants in Singapore is 114 for meetings containing A/V and 282 for Web Conferencing meetings. Because Contoso does not see the Remote Access Scenario for the Singapore users as business critical and the performance numbers can be accommodated by a single Web Conferencing Edge Server and a single A/V Edge Server, one dedicated server for each Edge Server role will be deployed. It is not possible to colocate the Web Conference Edge Server with an A/V Edge Server, as this combination is not tested and therefore unsupported.

Besides the Office Communications Server 2007 Edge Server, Contoso also needs an HTTP Proxy server, which can be provided based on Microsoft Internet Security and Acceleration (ISA) Server 2006. This server has to be colocated with the Access Edge Server, and it provides the following functionalities to Office Communications Server 2007 users:

A good practice from an ISA perspective would be to use at least one ISA server, but using Caching Array of Redundant Proxy (CARP) would be an even better approach. It's possible to implement only a single ISA server or an ISA server array at the main data center, but doing so might cause performance to suffer for users at other sites. It's also possible to deploy one ISA server at each site that contains these roles, or even better to deploy two ISA servers to eliminate a single point of failure. To reduce the complexity in the Contoso example, only one ISA server at the main data center in Chicago is used.

Table 11-7 shows Contoso's final Edge Server deployment.

As part of the Edge Server planning process, not only does the Edge Server topology have to be determined, but the DNS, Certificate, and Firewall configuration requirements (as shown in "Step 6: Plan for External User Access," in the "Office Communications Server 2007 Planning Guide") also have to be prepared.

The main purpose for Load Balancer is to distribute traffic among multiple physical servers that have the same Office Communications Server 2007 server roles installed. With a Load Balancer, it isn't just scalability and extensibility that become possible in the case of a single server failure, but redundancy as well. Contoso needs Load Balancers in the following places:

The Contoso architecture now looks as shown in Table 11-8.

Step 8: Plan for VoIP in the "Office Communications Server 2007 Planning Guide" describes several individual planning steps. In this chapter, you will read only about planning steps that need to be prepared well in advance before the actual deployment takes place (including the selection of the appropriate deployment option, selection of gateways, and location of gateways), as these particular steps need some time for preparation.

The other planning steps—such as Routing and Normalization rules, location profiles, and number manipulation on gateways—will be discussed in Chapter 12, "Deployment," as they are only configuration options and can be discussed just before the actual deployment happens.

Contoso has a telephone network with multiple TDM PBX nodes on every site. These PBX nodes are not connected via a corporate telephone network. As described earlier in this chapter, Contoso has decided to deploy 100 pilot users for Enterprise Voice in Chicago and wants to enable all 500 users in Madrid. In Madrid, the existing TDM PBX is depreciated, and Madrid users will use Office Communicator 2007 or Office Communicator Phone Edition as their primary voice endpoint. By comparing these requirements with the deployment options in "Step 8: Plan for VoIP," in the "Office Communications Server 2007 Planning Guide," the Departmental Deployment option is the appropriate deployment option for the Chicago site, while the Greenfield Deployment option is the best choice for the Madrid site.

The Departmental Deployment option on the Chicago site offers the flexibility for the 100 pilot users to do one of the following two things:

Figure 11-6 shows this integration scenario for Chicago.

Figure 11-6. Departmental Deployment scenario with existing PBX environment in Chicago

To set up this integration scenario, the following prerequisites need to be prepared:

For the 100 pilot users in Chicago, Contoso decides that one PRI connection from the PBX (T1 connection = 23 channels) will be sufficient for the pilot users. This means 23 concurrent calls (inbound and outbound) between users on the Office Communications Server 2007 environment and the PBX or the PSTN can be held at the same time. This does not affect the number of concurrent calls on Office Communications Server 2007 between Office Communicator 2007 users, for example, as those IP-to-IP calls do not pass the Media Gateway and do not need audio channels from the gateway. If you want to make calls only on the IP network, you don't need a Media Gateway at all.

Contoso chooses a Basic Media Gateway that needs a separate server for the Mediation Server. The capacity numbers for the Mediation Server presented in "Step 8: Plan for VoIP," in the "Office Communications Server 2007 Planning Guide" confirm that a single Mediation Server running on appropriate hardware is sufficient for this scenario.

On the Madrid site, Contoso chooses to deploy the Greenfield Deployment option. This adds another level of complexity to the planning process, as the existing PBX in Madrid has to be assessed in a more granular way. The Enterprise Voice Scenario of Office Communications Server 2007 is the first release of its kind. Therefore, some functionalities of a traditional PBX will not be provided with this release of Office Communications Server 2007, but they will be provided in subsequent releases (for example, the Boss/Admin solution). However, features will not be provided even in subsequent releases that made sense only in the PBX world but became obsolete following the Unified Communications paradigm (for example, sending display messages on the phone display).

Ideally for an Office Communications Server 2007 deployment, all standard office information workers in the Contoso Madrid office see their daily telephone needs fulfilled with the current telephone feature set of Office Communicator 2007 and Office Communicator Phone Edition. But how about common-area phones, fax machines, elevator phones, alarm systems, and so on that are currently connected to extensions of the existing PBX?

Office Communications Server 2007 does not provide interfaces for these mostly analog extensions in the current release. One option is to configure a trunk connection off the Media Gateway and connect this PRI trunk to the existing TDM PBX or even to a new small PBX. (These PBX systems became very cheap in the past few years.) This way, there are still connections available on the TDM telephone system and not all user requirements have to be solved in the IP world, especially if they can be solved much easier in the TDM world.

Contoso decided to follow this approach, as shown in Figure 11-7, by using a Basic Media Gateway with two PRI connections (E1 connections with 30 channels each, as used previously for the PSTN connection) and one Mediation Server (sufficient according to the Mediation Server Hardware Requirements table presented in "Step 8: Plan for VoIP," in the "Office Communications Server 2007 Planning Guide").

Figure 11-7. Greenfield Deployment scenario with direct PSTN connection

If only a few analog devices have to be connected, certain Media Gateways can already be ordered with analog connections for such purposes—for example, a Media Gateway with 2 PRI connections (to the PSTN) and 8 analog connections (for analog devices).

The Contoso architecture after enabling Enterprise Voice in Chicago and Madrid looks like the architecture shown in Table 11-9.

There are mainly two aspects to cover in this planning step: to provide access to the Address Book file for remote users, and to ensure there is sufficient data storage capacity to store all files that are being produced by the Address Book Server on each Office Communications Server 2007 Front-End Server in the Enterprise Edition or on Standard Edition Server. As already described in Step 6: Plan for External User Access an HTTP Reverse Proxy such as Microsoft ISA Server 2006 has to be installed to provide access for the remote users on the Address Book Server. Step 9: Plan for Address Book Server in the "Office Communications Server 2007 Planning Guide" contains a table with size estimations for the Address Book Server data files. Considering that hard-disk capacities are still increasing from year to year, the impact on the planning process is low.

Apart from the possibility of achieving redundancy in the Office Communications Server 2007 deployment by adding redundant server roles, there are several possibilities to improve the overall system uptime. "Step 10: Plan for High Availability and Fault Tolerance," in the "Office Communications Server 2007 Planning Guide" contains useful information regarding this subject, which is beyond the scope of this chapter.

It is important to plan for database storage because the lack of sufficient storage space can result in the entire system malfunctioning. Step 11: Plan for Database Storage in the "Office Communications Server 2007 Planning Guide" provides guidance on the database storage requirements. Contoso's HW for the Office Communications Server 2007 deployment complies with the requirements provided in the "Office Communications Server 2007 Planning Guide."

Finally, Contoso wants to capture Call Detail Records for the Enterprise Voice Scenario in Madrid, Spain. However, this is not seen as business critical, meaning that according to "Step 12: Plan for Compliance and Usage Analysis," in the "Office Communications Server 2007 Planning Guide," a single-tier Archiving topology running on one physical machine including the SQL Database is sufficient. The final Contoso architecture is shown in Table 11-10.

Note

On the CD On the CD, you can find the Office Communications Server Designer tool based on Microsoft Visio 2003, which allows you to create a diagram of your topology (including validation check) before the actual deployment. (This tool is part of the Office Communications Server 2007 Resource Kit tools, which can be installed from the OCS 2007 Resource Kit Tools folder.) It also allows you to automatically retrieve and display the actual deployment by using its Auto-Discovery functionality. The following illustration shows the architecture of the Singapore pool by using the Office Communications Server Designer tool: