Storage Requirements
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: 2016-12-01
To plan for storage, you need to determine the storage components you want to deploy, including the type of storage, the location for storing database and log files, and decisions about components to be used for scalability and high availability.
Storage Components
Data Types and Storage
Planning a storage solution for Office Communications Server 2007 R2 requires knowing what types of data are generated and where each type is stored. The following table lists this information.
Table 1. Data Types and Storage
| Type of data | Name of data store | Location |
|---|---|---|
Persistent user data (for example, ACLs, contacts, home server or pool, scheduled conferences) |
RTC |
Enterprise Edition, back-end database; Standard Edition, Microsoft SQL Server 2005 Express with SP2. |
Persistent Office Communications Server 2007 R2 settings |
RTCConfig |
Enterprise Edition, back-end database; Standard Edition, SQL Server 2005 Express with SP2. |
Transient user data (for example, endpoints and subscriptions, and transient conferencing state) |
RTCDyn |
Enterprise Edition, back-end database; Standard Edition, SQL Server 2005 Express with SP2. |
Database containing global address information used by Address Book Web query service to support Address Book search queries from Communicator Mobile for Windows clients |
RTCab |
Enterprise Edition, back-end database; Standard Edition, SQL Server 2005 Express with SP2. |
Address Book download files created by Address Book Server and downloaded by Office Communicator, Office Communicator Phone Edition, and Office Communicator Attendant clients |
User-specified UNC path |
For Enterprise Edition, download files are stored in a user-created shared NTFS folder located on a dedicated file server on a separate computer (recommended) from the Enterprise Edition Front End Server. For Standard Edition, files are stored in <Microsoft Office Communications Server 2007 R2 installation folder>\Web Components\Address Book Files on the local Standard Edition server. |
Meeting content (for example, Microsoft Office PowerPoint presentations, question and answer logs, polling, chat, and uploaded content) |
User-specified UNC path |
For Enterprise Edition, download files are stored in a user-created shared NTFS folder located on a dedicated file server on a separate computer (recommended) from the Enterprise Edition Front End Server. For Standard Edition, files are stored in <Microsoft Office Communications Server 2007 R2 installation folder>\Web Components\Data MCU Web\Web on the local Standard Edition server. |
Meeting content metadata (XML data that describes the meeting content, such as date and time a PowerPoint presentation is uploaded) |
User-specified UNC path |
For Enterprise Edition, download files are stored in a user-created shared NTFS folder located on a dedicated file server on a separate computer (recommended) from the Enterprise Edition Front End Server. For Standard Edition, files are stored in <Microsoft Office Communications Server 2007 R2 installation folder>\Web Components\Data MCU Web\Non-Web on the local Standard Edition server. |
Meeting content compliance log (XML data that records content upload activities, along with the uploaded meeting content) |
User-specified UNC path |
For Enterprise Edition, download files are stored in a user-created shared NTFS folder located on a dedicated file server on a separate computer (recommended) from the Enterprise Edition Front End Server. For Standard Edition, files are stored in a default folder on the local Standard Edition server. |
Application data files that are used internally by the application server component for the pool |
User-specified UNC path |
For Enterprise Edition, download files are stored in a user-created shared NTFS folder located on a dedicated file server on a separate computer (recommended) from the Enterprise Edition Front End Server. For Standard Edition, files are stored in <\Microsoft Office Communications Server 2007 R2 installation folder>\Application Host\Application Data on the local Standard Edition server. |
Update files used by the client version control mechanism to update Office Communicator clients and by the Device Update Service to update unified communications (UC) devices |
User-specified UNC path on Enterprise Edition Installer-created folder on Standard Edition |
For Enterprise Edition, update files are stored in a user-created file share located on a separate computer (recommended) from the Enterprise Edition Front End Server. For Standard Edition:
|
Monitoring Server Quality of Experience (QoE) data |
QoEMetrics |
Monitoring Server QoE database normally deployed on a separate computer (recommended) from the back-end database. This database is always deployed on the same server, in the same instance, as the CDR database. |
Monitoring Server CDR data |
LcsCDR |
Monitoring Server CDR database normally deployed on a separate computer (recommended) from the back-end database. This database is always deployed on the same server, in the same instance, as the QoE database. |
Archiving data |
LcsLog |
Archiving service database normally deployed on a separate computer (recommended) from the back-end database. |
Group Chat data |
User-specified database name |
SQL Server 2005 or SQL Server 2008 database deployed on separate computer from the Group Chat Server. |
Group Chat Web and compliance folders (to store files uploaded to the Group Chat Web service) |
User-specified UNC path |
A file share that can be accessed by all of the Group Chat Servers and services in the pool. |
Group Chat compliance data |
User-specified database name |
SQL Server 2005 with SP2 or SQL Server 2008 database deployed on separate computer from the Compliance service. This can be the same database instance that is used for Group Chat data. |
Transient Response Group Service data |
ACDDyn |
Enterprise Edition, back-end database; Standard Edition, SQL Server 2005 Express with SP2. |
Storage Considerations
Planning an effective storage strategy, particularly if you are deploying an Enterprise pool with a back-end database, is essential to the success of your Office Communications Server 2007 R2 deployment. Failure to accurately assess your storage requirements and implement strategies optimizing data access and security can be inconvenient at best and catastrophic at worst.
As you plan your storage strategy for Office Communications Server 2007 R2, you need to balance three criteria: capacity, availability, and performance. The choices you make as you plan and implement your storage solution affect the cost associated with administration and maintenance of your Office Communications Server 2007 R2 environment:
Capacity. In Office Communications Server 2007 R2, your total capacity for the Enterprise Edition back-end database is approximately 10 gigabytes (GB) for a large deployment. By traditional standards, a database of this size is not considered to be large.
Availability. The availability of your database can be increased by redundancy. Redundancy can mean that you should cluster applications to provide CPU redundancy or implement a redundant array of independent disks (RAID) solution to provide data redundancy.
Performance. Performance requirements are also unique to each organization. This refers to performance as it relates to throughput. With regard to storage technology, throughput is measured by how many reads and writes per second a storage device can perform.
Before you design your storage solution for Office Communications Server 2007 R2, determine how your company prioritizes these three criteria, especially when considering a balance between availability and performance. The following sections discuss the factors you should consider regarding storage.
General Storage Principles
Regardless of the application that you are running, consider the following storage principles to help maximize capacity, availability, and performance:
Decrease the processing required from the CPU by implementing a specialized hardware solution, such as a RAID or a storage area network (SAN) that incorporates RAID technology. In this scenario, it is assumed that you use a hardware solution rather than a software (host-based) RAID solution.
Decrease the overall time it takes to complete a transaction by separating files that are accessed sequentially from files that are accessed randomly. Storing sequentially accessed files separately keeps the disk heads in position for sequential I/O, which reduces the amount of time required to locate data.
Use multiple disks, because they perform better than a single large disk. In general, more disks result in faster performance.
Use the information in the following sections to compare and contrast these storage technologies.
RAID Solutions
By using a RAID solution, you can increase the fault tolerance of your Office Communications Server 2007 R2 deployment. In a RAID configuration, part of the physical storage capacity contains redundant information about data stored on the hard disks. The redundant information is either parity information (in the case of a RAID-5 volume) or a complete, separate copy of the data (in the case of a mirrored RAID1 or striped and mirrored RAID 0+1 volume). The redundant information enables data regeneration.
Considerations for Office Communications Server 2007 R2
When planning your storage solution, consider the following features of Office Communications Server 2007 R2:
Office Communications Server can support up to 100,000 concurrent users on a pool in the consolidated configuration. The back-end database of each Enterprise pool and the SQL Server 2005 with SP2 database on a Standard Edition server each has a set of transaction log files and database files.
Not all data stored on Office Communications Server is managed in the same way. A single storage solution for all data types is not the most efficient. For example, both transient and static data reside on the back-end database. The RTCDyn database stores conference state information and other information that is transient in nature. Because of its temporary nature, this information does not need to backed up or saved regularly for restoration purposes. However, it is important to plan for redundancy and ongoing availability of the following data:
Persistent data stored in the RTC (user settings) and RTCConfig (configuration settings) databases on a Standard Edition server and in an Enterprise pool.
The Archiving Server database, which contains compliance information that is important for archival purposes.
In Office Communications Server 2007 R2, transaction log files are accessed sequentially, and databases are accessed randomly. In accordance with general storage principles, you should separate the transaction log files (sequential I/O) from databases (random I/O) to maximize I/O performance and increase fault tolerance. Specifically, you should move the transaction log files to separate disks from database file storage.
To further enhance system performance, store the transaction log files for the RTCDyn database on a separate dedicated device. This helps ensure transaction throughput.
SQL Server 2005 Enterprise Edition with SP2 or SQL Server 2008 Enterprise can be configured as failover clusters to provide high availability support. For example, to provide support in case of an operating system failure or a planned upgrade, you can configure one node in the failover cluster to fail over to any other node in the failover cluster configuration. This ability helps to minimize system downtime, thereby providing high server availability. Additionally, if you decide to implement archiving in critical mode, which means that the Office Communications Server shuts down if archiving is not available, you may want to use a failover cluster because a SQL Server failure can potentially bring down the entire Office Communications Server infrastructure.
Regardless of whether you use Direct Attached Storage (DAS) or a Storage Area Network (SAN) solution for storage, your storage solution requires proper planning and design to ensure that appropriate capacity and throughput can be delivered for Office Communications Server 2007 R2.
Storing Transaction Log Files and Database Files
As previously mentioned, to provide fault tolerance in the event of a hard disk failure, keep your Office Communications Server 2007 R2 transaction log files and database files on separate physical hard disks. Furthermore, if you keep these log files and database files on separate disks, you significantly improve performance of hard disk I/O. For the data and transaction file access, select separate I/O channels on the RAID controller and, if possible, place each I/O channel on a separate RAID controller.
If the hard disk containing the transaction log files fails, but not the disk containing your databases, you do not have to restore any Office Communications Server 2007 R2 data from backup. SQL Server transaction logs for Office Communications Server 2007 R2 are collapsed on a periodic basis and are kept within a limited size. You should also enable write caching if the controller supports this capability. Enabling write caching increases throughput significantly.
Important
If you keep your Office Communications Server 2007 R2 databases and transaction log files on the same physical hard disk, performance is impacted and, if that disk fails, you can recover only the data that existed up to your last backup.
Ensure that you have adequate hard disk capacity for your Office Communications Server 2007 R2 servers. You should have enough space on your hard disk to restore both the database and the log files. If you do not, you could have backup files that are too large to restore to their original location.
Using Server Clustering
Failover clustering (formerly known as server clusters or as MSCS) is a Windows Server feature that you can use to achieve scalability and high availability for the Office Communications Server 2007 R2 back-end database. A cluster consists of individual computers (also called nodes) that function cohesively in a cluster service. These computers act as network service providers or as reserve computers that take over server operations for another node if it experiences problems. Clustering provides fault tolerance and reliability. Furthermore, depending on how you configure your cluster, clustering can simplify the process of recovering a single server from disasters.
In a clustering environment, SQL Server runs as a virtual server (not as a stand-alone server), because any node in a cluster can assume control of a virtual server. If the node running the SQL Server virtual server experiences problems, the SQL Server virtual server goes offline for a brief period until another node takes control of the damaged node.
Office Communications Server 2007 R2 supports multiple-node active/passive clusters for the back-end database. Active/active clusters are not supported. 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 must be familiar with failover clustering concepts before you plan and deploy Office Communications Server 2007 R2 clusters.
For details about clustering, see Technical Overview of Windows Server 2003 Clustering Services at the Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=139792.
For details about failover, see Windows Server 2008 High Availability at the Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=139793.
For details about designing database storage for SQL Server, see Physical Database Storage Design at the Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=139794.
SQL Server, Windows, and Office Communications Server Version Requirements
Specific versions of SQL Server and Windows are required to create an Office Communications Server 2007 R2 cluster. The following table outlines these requirements.
Table 2. SQL Server, Windows, and Office Communications Server Version Requirements
| SQL Server version | Windows versions | Office Communications Server version | Cluster nodes available |
|---|---|---|---|
SQL Server 2008 Enterprise (32-bit or 64-bit) (recommended) |
The 64-bit edition of Windows Server 2008 (Standard or Enterprise) (recommended) |
Office Communications Server 2007 R2 Enterprise Edition |
Maximum of 16 |
SQL Server 2008 Enterprise (32-bit or 64-bit) (recommended) |
Windows Server 2003 R2 Standard x64 Edition with SP2 or Windows Server 2003 R2 Enterprise x64 Edition with SP2 Windows Server 2003 Standard x64 Edition with SP2 or Windows Server 2003 Enterprise x64 Edition with SP2 |
Office Communications Server 2007 R2 Enterprise Edition |
Maximum of 8 |
SQL Server 2008 Standard (32-bit or 64-bit) |
The 64-bit edition of Windows Server 2008 (Standard or Enterprise) (recommended) Windows Server 2003 R2 Standard x64 Edition with SP2 or Windows Server 2003 R2 Enterprise x64 Edition with SP2 Windows Server 2003 Standard x64 Edition with SP2 or Windows Server 2003 Enterprise x64 Edition with SP2 |
Office Communications Server 2007 R2 Enterprise Edition |
Maximum of 2 |
SQL Server 2005 Enterprise Edition with SP2 (32-bit or 64-bit) |
The 64-bit edition of Windows Server 2008 Enterprise (recommended) Windows Server 2003 R2 Enterprise x64 Edition with SP2 Windows Server 2003 Enterprise x64 Edition with SP2 |
Office Communications Server 2007 R2 Enterprise Edition |
Maximum of 8 |
SQL Server 2005 Standard Edition with SP2 (32-bit or 64-bit) |
The 64-bit edition of Windows Server 2008 Enterprise (recommended) Windows Server 2003 R2 Enterprise Edition x64 Edition with SP2 Windows Server 2003 Enterprise x64 Edition with SP2 |
Office Communications Server 2007 R2 Enterprise Edition |
Maximum of 2 |
SQL Server 2005 Enterprise Edition with SP2 (32-bit or 64-bit) SQL Server 2005 Standard Edition with SP2 (32-bit or 64-bit) |
The 64-bit edition of Windows Server 2008 Standard Windows Server 2003 R2 Standard x64 Edition with SP2 Windows Server 2003 Standard x64 Edition with SP2 |
Office Communications Server 2007 R2 Enterprise Edition Office Communications Server 2007 R2 Standard Edition (for monitoring database or archiving database)* |
None |
Note
*SQL Server 2005 Express with SP2 is provided with Office Communications Server 2007 R2 Standard Edition.
Server Partitioning Best Practices
To increase fault tolerance and provide for easier troubleshooting, do the following:
Partition your disks so you can start with a command prompt in an emergency. Partitioning your disks in this way increases your recovery options. For example, you can start with a command prompt and modify or replace any damaged startup files that prevent you from starting Windows.
Set up your disks so Office Communications Server 2007 R2 application files, database files, and transaction log files are all on separate physical disks to increase performance.
If you partition your hard disks by using these recommendations, each set of files is assigned a separate physical disk with a separate drive letter. Having each set of files represented by its own drive letter helps you keep track of which partitions you must back up in accordance with the data recovery method you choose.
Folders
Before you deploy Enterprise Edition servers, determine your storage needs and create five shared folders on a dedicated file server, using either the suggested folder names or your own folder names, where you can store the following:
Presentations: Meeting presentations to be downloaded or streamed by conference attendees, but not content from desktop sharing sessions.
Metadata: Meeting information (metadata) that is used internally by the Web Conferencing Server component for the pool.
Note
Grant access to the Metadata file share to the service account that is used to run the Web Conferencing Server as well as to any necessary administrator accounts. Remove access to the Metadata file share from all other user accounts.
ABS: Address Book files written by the Address Book Server, which is installed with the Front End Server, to provide global address list user and contact information to Office Communicator 2007 R2, Office Communicator 2007, Office Communicator 2005, Office Communicator 2007 R2 Phone Edition, Office Communicator Phone Edition 2007, and the 2007 version of Office Communicator Mobile clients on a daily basis. (The 2007 R2 version of Office Communicator Mobile for Windows client uses a separate Address Book Web Query service to obtain address book information.)
Applications: Application files that are used internally by the application server component for the pool.
Updates: Files used by the client version control mechanism to update Office Communicator clients and by the Device Update Service to update devices.
Grant Full Control on each of these shared folders to the administrator, the RTCUniversalServerAdmins group, and any other user or group responsible for creating pools. Remove Read permission from the Everyone group. If these shared folders inherit permissions from parent folders or drives, ensure that you manually change the permissions on the shared folders.
For details about and requirements for the Updates folder, see Device Update Service.
Note
If you use a shared cluster for the file shares in your deployment, use the Cluster Administrator to create the file shares. For details about using the Cluster Administrator, see Microsoft Knowledge Base article 284838, “How to Create a Server Cluster File Share with Cluster.exe” at https://go.microsoft.com/fwlink/?LinkId=140899.
If your organization must comply with regulatory requirements for the archiving of meeting content, you can enable meeting compliance. To administer meeting compliance, you must first create a shared folder on a dedicated file server in order to store the meeting logs. You can use the suggested name or your own folder name where you can store the following:
- MeetingCompliance (optional): Meeting activities and content uploaded during meetings
Grant the RTCComponentUniversalServices group Full Control on this shared folder and any other user or group responsible for creating pools. Remove Read permission from the Everyone group.
If you plan to install the Archiving Server, consider storage needs for archiving files. For details, see Archiving Support.