Back-End Database Topology
Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2013-06-26
A Back-End Database is required for any Enterprise Edition or Standard Edition configuration. For details about supported versions of the Microsoft SQL Server database software for the Back-End Database, see Internal Office Communications Server Component Requirements.
In a Standard Edition topology, all server roles, including the Back-End Database, are collocated on a single computer.
In an Enterprise Edition topology, the Back-End Database cannot be collocated with any other server role in a pool. However, the Back-End Database can be collocated with other Office Communications Server 2007 R2 databases. Specifically, the Back-End Database can run in a shared SQL Server instance with Archiving, Monitoring, Group Chat, and Compliance (for Group Chat) databases. The Back-End Database can run on a shared server with the Director database, but it must run in a separate SQL Server instance.
Published performance test results assume that the Back-End Database runs in a dedicated SQL Server instance.
Enterprise Edition topologies, both consolidated and expanded, support the following Back-End Database configurations:
One Front End Server without a load balancer and one Back-End Database on a separate computer.
One Front End Server connected to a hardware load balancer and one Back-End Database on a separate computer.
Two or more Front End Servers connected to a hardware load balancer and one Back-End Database on a separate computer.
In an Enterprise pool, the Back-End Database can be a single SQL Server computer. Alternatively, two or more dedicated SQL Server computers can optionally be clustered in a multiple-node active/passive configuration. A SQL Server cluster for the Back-End Database improves availability by providing failover capabilities. In a multiple-node cluster, the Office Communications Server SQL instance must be able to failover to a passive node that, for performance reasons, should not be shared by any other SQL instance. You can migrate a Back-End Database from nonclustered to clustered by using the DbImpExp.exe tool. For details about the DBImpExp.exe tool for Office Communications Server 2007 R2, see the DBImpExp-Readme.htm file in the <drive>:\Program Files\Microsoft Office Communications Server 2007 R2\Server\Support folder of a server on which Office Communications Server 2007 R2 is installed.
In configurations that have more than one SQL Server instance, an Enterprise pool can use either the default instance or a named instance. In either case, either default port 1433 or a nondefault port is supported. To use a port other than 1433, use one of the following methods:
Run the SQL Server Browser service on the computer running SQL Server. No configuration is required on the client.
Instead of running the SQL Server Browser service on the computer running SQL Server, configure the client by creating an alias for the SQL Server instance and specifying the port number. To create an alias on a computer running the Front End Server, use the SQL Server Configuration Manager (a Microsoft Management Console (MMC) snap-in). You must create the alias on each computer running the Front End Server.
For details, see your SQL Server documentation.
Hosting Third-Party Application SQL Server Databases
Office Communications Server 2007 R2 databases (that is, Back-End Database, Archiving database, or Monitoring database) can run on a shared server with third-party application databases, but those databases should run in a different SQL Server instance. Running Office Communications Server 2007 R2 databases in a shared SQL Server instance with third-party application databases is not supported.
Hosting third-party application databases in separate instances on a shared server is supported, but it is not recommended for performance reasons.
If you choose to run third-party application databases on the same server as your Office Communications Server database, keep the following in mind:
The Office Communications Server database must have separate physical disks for its databases and for its transaction logs.
The server must have enough memory to cache the entire instance that is used by Office Communications Server.