DNS Records and Office Communicator Automatic Client Sign-In

Office Communicator client signs into OCS in one of two ways:

1) The OCS server hostname is manually specified in Communicator, or,
2) "Automatic Sign-In" via a DNS query on the SIP domain (the domain portion of the user's SIP address) which returns the OCS server (or pool).

This is true for clients running both inside and outside your internal network ('outside' meaning outside the firewall, on the Internet).

The DNS records for automatic sign-in are always front-and-centre when trouble-shooting any Communicator sign-in issues, so I'll recap the format of the DNS SRV records most commonly needed:

1. _sipinternaltls._tcp.<sip domain> (Internal TLS)
   
2. _sipinternal._tcp.<sip domain> (Internal TCP)
   
3. _sip._tls.<sip domain> (External TLS)
   
4. _sip._tcp.<sip domain> (External TCP *)
   

From a DNS sign-in perspective, Communicator does not know or care whether it is on an internal or external network – it queries for the DNS SRV records in the order listed above, and will attempt a connection on the first match (the hostname specified by the SRV record).

* Although Communicator will search for the external TCP SRV record of the format "sip._tcp.<sip domain>" external connections must use TLS (on the Edge Access).

The DNS SRV record returns a hostname representing the OCS Enterprise Pool or Standard Server. A DNS A record lookup is then performed to get an IP address to connect to.

If no records DNS SRV records are found, Office Communicator performs an explicit DNS A record lookup up in the following order (until it gets a successful match):

1. sipinternal.<sip domain>
   
2. sip.<sip domain>
   
3. sipexternal.<sip domain>
   

Note: In the Communicator R2 client, it appears that the format "sip.<sip domain>" (#6 above) is tried before "sipinternal.<sip domain>", and #7 is not attempted at all.

InsideOCS has a free downloadable tool, the Automatic Sign-In Troubleshooting Tool, that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used.

For more details all the automatic sign-in process and it's requirements, see:

• Automatic Office Communicator Sign-In (Part 1 – The Correct DNS Service Location (SRV) Record)
  
• Automatic Office Communicator Sign-In (Part 2 – ensuring the correct Subject Name on the Certificate)
  
• Automatic Office Communicator Sign-In (Part 3 – ensuring the client trusts the issuing Certificate Authority)
  

Note: the manual configuration of Office Communicator clients can be automated through the Microsoft Office Communicator Group Policy.

For additional information, see the following links:

• Microsoft OCS 2007 TechNet Library – Required DNS Records for Automatic Client Sign-In
  
• Microsoft OCS 2007 R2 TechNet Library – Office Communicator Sign-in and Discovery
  
• Microsoft TechNet Office Communications Server 2007 – 3.2 Configure DNS for Your Pool
  
• Microsoft TechNet Article on DNS Records for an OCS Pool and How to Create Them
  
• Jeff Schertz – OCS 2007 – DNS Lookups with OCS Automatic Configuration
  

Implementing App-V – Part IV: Sequencing Applications

January 18, 2010 at 3:50 am | In App-V | 18 Comments

Tags: App-V, application virtualization, Virtualization

 
 

Other posts in this series:

Implementing App-V – Part I: Introduction to Application Virtualization

Implementing App-V – Part II: Choosing and Preparing the Environment

Implementing App-V – Part III: Integrating Clients

Ok, we had a good look about the entire App-V platform so far: Explanation about application virtualization and the components involved in App-V (Post I); installation of the App-V Server including some troubleshooting tips (Post II); integrating App-V client components, testing the default application and some troubleshooting about this process as well (Post III).

Now it is time to sequence some real applications and deliver them to clients. As always, I'm going to start with an easy one, so you can see all the tricks involved to get the things working. But first, we must prepare the App-V Sequencer machine.

As we've seen in Post I, the main component involved in the sequencing process is the App-V Sequencer.

Sequencer Quick Checklist

• Use the same base operating system for both, Sequencer and Target (client) machines. Microsoft does not support using different type of OS between these two. Off the record: I've used many applications that worked perfectly when this requirement was not fulfilled.
  
• The Sequencer machine must have a second partition available. The common use for this one is to assign the Q:\ drive letter.
  
• Sequencer and Client machine must have the same Windows Installer version.
  
• In the Sequencer machine ensure that the directories %TMP%, %TEMP% (user temporal data) have sufficient space, since the application use this directory to store temporal sequencing data.
  
• Before sequencing an application you should close all other programs, including Antivirus.
  
• As a recommended best practice, use VirtualPC or any other type of virtual machine for the App-V Sequencer. Combine this using snapshots or differencing disks to always have available a fresh OS to deploy applications. 
  

For more information about the sequencing process and requirements, check the Sequencing Guide from Microsoft and also the Sequencing Best Practices.

App-V Sequencer Setup

Once you've checked all the requirements mentioned above, the installation process is quite simple and straight forward.

App-V Sequencer main window:

Sequencing Applications Step-by-Step

As I mentioned earlier my first pick will be a simple application, this will allow us to get familiarized with the sequencing process. I want to start showing the App-V compatibility with some non-Microsoft applications, I'll be using Mozilla Firefox.

1. In the App-V Sequencer program window select "New Package".

2. A new wizard will start, select the package name "Firefox".

3. In the next window you are ready to get started with the applications installation and capture, so you can start creating the installation folder in the
Q:\ drive.

Within this folder, the application will store all the program files and the sequencer will use them to package the application.

Note: You don't need to place the installer inside this folder.

4. Click on "Begin Monitoring" to start the installation process.

5. The capture process will start by selecting the folder in the Q:\ drive.

6. Once you've selected the folder, the virtual environment will start to load, wait for the "Monitoring started. Please begin installation" message appears.

7. Locate the installer and start the installation process.

8. In the installation process, the main step will be in the destination folder option that the program use to place the program files. Select the folder you've selected to be monitored. In my case: Q:\Firefox.

9. Once the installation is complete and you verified that the program was installed correctly, get back to the sequencer window and click on "Stop Monitoring" and click on "Next".

10. In the next window you can add some more files inside the package. This can help you if you are using customized applications, that need to load local files.

In my case I don't need any.

11. In the next window, the sequencing process detects the applications that compose Mozilla Firefox, in my case the Firefox standard app and the Firefox safe-mode.

You can add new ones, remove the detected and modify the components involved: File type associations and icons.

For every application shown here, we will need to make a small change. Click on each application in the right list, and select the "Edit" option. In the "OSD File Name" you will probably see a long name, like "Mozilla Firefox 1.9.1.3523.osd".

You need to change this one removing all the spaces in the name, like "Firefox.osd".

Change this in all applications involved and click on "Next".

12. The next step is optional, where you can launch the applications for a final check that they are working properly. Click on "Next".

13. Sequencing process is complete. Click on "Finish".

14. The package is ready for the final customization regarding the application deployment.

In the App-V Sequencer window, select the "Deployment" tab and change the Protocol option to "RTSP" (this will automatically change the Port to 554), and in the Hostname option select the name of the App-V Server, in my case "appv-server".

In the Operating System list, you can add all the baselines where this application can become available. And note also the option to generate an MSI package, that you can use it with the App-V Stand Alone mode (explained in Post I of this series) and/or System Center Configuration Manager (SCCM) integration with App-V.

15. Before saving the package, you can explore other options within the Sequencer, like the registry files that are modified by the application.

Once you are done, click on save this package locally.

With the project saved, you can check on the files created and verify that the OSD files were not created with names composed by blank spaces.

Adding the Package to the Server

Now that the package has been sequenced and created, it is time to add it to the server.

1. Copy the files created in the App-V Sequencer to the "content" folder in the App-V Server.

2. In the App-V Server, open the App-V console. Right click in Applications and select "Import Applications".

3. Select the SPRJ file for the Mozilla Firefox and click "Open".

4. In the General Information window, accept the default options and click on "Next".

5. In the "Published Shortcuts" select the shortcuts that the clients will have created.

6. In the "Access Permissions" select the group that will load this application. In my case, I'm using Domain Admins.

7. In the "Summary" window, click on "Finish".

And now you have the application ready in your App-V Server to be deployed.

Testing the Application

After completing the importing wizard, the application is ready to be deployed in the client machines.

Access the client machine, and if you want to avoid the process of log-off and log-on to test it, locate the App-V Client console (C:\Program Files\Microsoft Application Virtualization Client\SftCMC.msc), select "Publishing Server" and click on "Refresh Server".

The new icons will appear in the desktop or in the places you've selected.

Mozilla Firefox starting

Troubleshooting App-V Published Applications

The most common error about App-V applications I've experienced are regarding the firewall exceptions discussed in the Post III of this series. But, there's also another problem that appears related to the package it self.

If the package that you've created, the OSD file name uses spaces between, like "Mozilla Firefox 1.9.1.3523.osd":

Then most likely when you try to deploy this application, after importing it in the server, you'll get these errors:

"The package requested could not be found in the system data store or the files associated with this package could not be found on the server". "Error code: 4513CDC-1690150A-20000194"

To fix this, you'll need to regenerate the sequenced application as shown above, editing the application information and remove any blank spaces in the OSD file name.

More Resources

• Microsoft Application Virtualization 4.5 Resource Kit Tools
  
• [Case Study] Sequencing Applications for Deployment at Microsoft
  
• App-V Sequencing Guide
  

Other posts in this series:

Implementing App-V – Part I: Introduction to Application Virtualization

Implementing App-V – Part II: Choosing and Preparing the Environment

Implementing App-V – Part III: Integrating Clients

Understand Microsoft Volume Licensing and Activation Management Tool 2.0

Microsoft Volume Licensing Service Center (VLSC) User Guide

This user guide shows step-by-step instructions for how to register, view account details, download products and more from the Microsoft Volume Licensing Service Center (VLSC). It also includes screenshots, technical support information, and a glossary. Microsoft Volume Licensing Service Center (VLSC) User Guide.

Download Microsoft Volume Licensing Service Center (VLSC) User Guide [.pdf format]

Download Volume Activation Management Tool 2.0 (Beta)

Volume Activation Management Tool (VAMT) 2.0 (Beta) is a managed MMC plug-in with support for Office 2010 Beta. Administrators may use it to manage volume editions of Windows and Office 2010 Beta installed with a Key Management Service (KMS) client key or a Multiple Activation Key (MAK). A convenient command line interface (CLI) allows automated, scheduled VAMT tasks without UI interaction.

Download Volume Activation Management Tool 2.0 (Beta) [.msi format]

Manage Activation Using VAMT 2.0

VAMT can be an important tool to help you centrally manage and automate a range of activities related to Windows activation. Core benefits of VAMT include:

• The ability to protect product keys by retaining them only in the VAMT console, vs. including a key in an image or distributing it in plain text
  
• Perform activations without each system having to connect and activate with Microsoft activation services
  
• Inventory and monitor systems in the environment from an activation and licensing standpoint VAMT enables you to remotely activate managed systems. You can perform MAK, KMS host, KMS client, and retail activations. VAMT uses WMI to remotely manage activations and other related tasks on managed systems. VAMT also can assist with license compliance, letting you monitor license state for the systems under management
  

Download Manage Activation Using VAMT 2.0 White Paper here[.docx format]

Product Activation Using VAMT 2.0

This document explains how to perform the following activation-related tasks using VAMT 2.0: 1. Discover computers and installed products 2. Remotely install a product key on those products 3. Remotely complete typical product activations that you might use in your environment—online, proxy, and Key Management Service (KMS) client activation 4. Save the Computer Information List, and perform local reactivations using that list These tasks can be performed for Windows 7, Windows Vista, Windows Server 2008 R2, Windows Server 2008, Office 2010 client suites and applications, Visio 2010 and Project 2010 clients.

Download the Product Activation Using VAMT 2.0 [.docx format]

Manage Product Keys Using VAMT 2.0

VAMT helps adminsitrators to manage keys acquired through a Microsoft volume license agreement, subscription programs such as MSDN, TechNet or Microsoft Partner Network, or the retail channel. VAMT 2.0 enables management of the following product key types, for Windows 7, Windows Vista, Windows Server 2008 R2, Windows Server 2008, Office 2010 client suites and applications, Visio 2010 and Project 2010:

• Key Management Service (KMS) host keys (CSVLK)
  
• KMS client setup keys
  
• Multiple Activation Key keys (MAK)
  
• Retail keys
  

Download the Manage Product Keys Using VAMT 2.0 Guide [.docx format]

Reporting Activation Information Using VAMT 2.0

VAMT 2.0 can be used to track and report activation data for Windows operating systems activated using Key Management Service (KMS), Multiple Activation Keys (MAK), and retail keys. VAMT 2.0 supports Windows 7, Windows Vista, Windows Server 2008 R2 and Windows Server 2008, Office 2010 client suites and applications, Visio 2010 and Project 2010 clients. VAMT can provide information on license status, and whether installed software is genuine. This information also can help you with license compliance. VAMT can be used in addition to any tool you already may be using for the purpose of software asset management or license management.

Download the Reporting Activation Information Using VAMT 2.0 guide [.docx format]

Also read – New Volume Activation Management Tool (VAMT) to manage Multiple Activation Key(MAK)

Hyper-V: Disk2vhd Free Physical Disk Conversion tool

Well dual boot just went obsolete. At least installing to two different directories it did. Now you can achieve true isolation. Mark Rusinovich wizard extraordinaire and the Microsoft Sysinternals team launched a great new tool. Disk2VHD excerpted from the Sysinternals site:

 Download Disk2vhd (704 KB)

Introduction

Disk2vhd is a utility that creates VHD (Virtual Hard Disk - Microsoft's Virtual Machine disk format) versions of physical disks for use in Microsoft Virtual PC or Microsoft Hyper-V virtual machines (VMs). The difference between Disk2vhd and other physical-to-virtual tools is that you can run Disk2vhd on a system that's online. Disk2vhd uses Windows' Volume Snapshot capability, introduced in Windows XP, to create consistent point-in-time snapshots of the volumes you want to include in a conversion. You can even have Disk2vhd create the VHDs on local volumes, even ones being converted (though performance is better when the VHD is on a disk different than ones being converted).

The Disk2vhd user interface lists the volumes present on the system:

It will create one VHD for each disk on which selected volumes reside. It preserves the partitioning information of the disk, but only copies the data contents for volumes on the disk that are selected. This enables you to capture just system volumes and exclude data volumes, for example.

Note: Virtual PC supports a maximum virtual disk size of 127GB. If you create a VHD from a larger disk it will not be accessible from a Virtual PC VM.

To use VHDs produced by Disk2vhd, create a VM with the desired characteristics and add the VHDs to the VM's configuration as IDE disks. On first boot, a VM booting a captured copy of Windows will detect the VM's hardware and automatically install drivers, if present in the image. If the required drivers are not present, install them via the Virtual PC or Hyper-V integration components. You can also attach to VHDs using the Windows 7 or Windows Server 2008 R2 Disk Management or Diskpart utilities.

Note: do not attach to VHDs on the same system on which you created them if you plan on booting from them. If you do so, Windows will assign the VHD a new disk signature to avoid a collision with the signature of the VHD's source disk. Windows references disks in the boot configuration database (BCD) by disk signature, so when that happens Windows booted in a VM will fail to locate the boot disk.

Disk2vhd runs Windows XP SP2, Windows Server 2003 SP1, and higher, including x64 systems.

Thanks Dieter Rauscher for the heads up,

Jamil Rashdi

wasl

Office Communications Server 2007 R2 – Unified Communications

Supported Topologies

Office Communications Server 2007 R2 offers three general topologies:

• Office Communications Server Enterprise Edition in a consolidated configuration.
  This topology is recommended for most organizations of any size. It provides performance, high availability, and scalability. For details, see Enterprise Edition Consolidated Topology.
  
• Office Communications Server Standard Edition.
  This topology is for small or midsize deployments, such as branch and pilot deployments, that do not have high availability and performance requirements. For details, see Standard Edition Topology.
  
• Office Communications Server Enterprise Edition in an expanded configuration.
  The Enterprise Edition in an expanded configuration continues to be supported in Office Communications Server 2007 R2. However, the recommended configuration in Office Communications Server 2007 R2 is the consolidated configuration. The primary advantage offered by the expanded configuration in Office Communications Server 2007 was its ability to scale in very large deployments. In Office Communications Server 2007 R2, the limitations for scaling have been removed from the consolidated configuration, making it the preferred solution both in terms of scaling and simplified administration. For details about the expanded configuration, see Enterprise Edition Expanded Topology.
  

The following figure is a reference topology that illustrates the server roles and components in a consolidated configuration. The topics that follow describe the various topologies, components, and configurations that are supported for the internal network and the perimeter network.

 

Supported Active Directory Topologies

Office Communications Server relies on Active Directory Domain Services (AD DS) to store global settings and groups necessary for the deployment and management of Office Communications Server. Office Communications Server 2007 R2 supports the same Active Directory topologies as Office Communications Server 2007.

Office Communications Server can be deployed in a locked-down Active Directory environment. For details about the special considerations involved in deploying Office Communications Server in a locked-down environment, see Preparing a Locked Down Active Directory Domain Services in Preparing Active Directory Domain Services for Office Communications Server 2007 R2 in the Deployment documentation.

This section identifies the Active Directory topologies supported by Office Communications Server 2007 R2. For details about operating system and domain functional level requirements for AD DS, see Environmental Requirements.

For details about supported Active Directory topologies, see Active Directory Domain Services Requirements in the Planning and Architecture documentation.

For details about preparing AD DS for Office Communications Server installation, see Office Communications Server 2007 R2 Active Directory Guide in the Deployment documentation.

Office Communications Server supports single-forest and multiple-forest Active Directory environments.

The Active Directory topologies supported by Office Communications Server are as follows:

• Single forest with single domain
  
• Single forest with a single tree and multiple domains
  
• Single forest with multiple trees and disjoint namespaces
  
• Multiple forests in a central forest topology
  
• Multiple forests in a resource forest topology
  

Office Communications Server User Model

Office Communications Server User Model

The following table describes the user model for Office Communications Server.

Table 1. User Model for Office Communications Server

Category	Description
Client distribution	30% of clients running Office Communicator 2007 clients, including Communicator Web Access (2007 release) or Communicator Mobile (2007 release) 70% of clients running Office Communicator 2007 R2, the 2007 R2 version of Communicator Mobile, or Communicator Web Access; 100% of clients running the Live Meeting client
Remote user distribution	90% of users connecting internally 10% of users connecting through an Edge Server, and (recommended) a Director
Contact distribution	Average of 80 contacts on mobile devices Average of 50 contacts on all other devices 70% of contacts within the organization 10% of enterprise users are remote 10% of contacts are federated 10% of contacts are public IM contacts
IM sessions	2 IM sessions per user per hour 10 instant messages per session 400 byte average message size Three-person average for multiparty IM sessions

The following table describes the conferencing model used as the basis for capacity planning requirements and recommendations described later in this section.

Table 2. Conferencing Model

Category	Description
Scheduled meetings versus "Meet now" meetings	50% of each category.
Meeting concurrency	5% of users will be in conferences during working hours.
Meeting media distribution	15%: PSTN audio through a third-party audio conferencing provider, PowerPoint. 10%: PSTN audio through a third-party audio conferencing provider, application sharing. 15%: Group IM with distribution group integration. 10%: PSTN audio dial-in conferencing only. 10%: VoIP audio, PSTN dial-in conferencing, PowerPoint. 25%: VoIP audio, PSTN dial-in and video, application sharing. 5%: VoIP audio, PSTN dial-in, IM, and application sharing. 10%: VoIP audio, PSTN dial-in, video, IM.
Meeting participant distribution	In meetings where Conferencing Attendant is used with a combination of VoIP audio and PSTN dial-in audio, the ratio of VoIP users to dial-in users is 2:1. For application sharing, two types of application sharing exist: Persistent Shared Object Model (PSOM) based application sharing using the Web Conferencing Server and Remote Desktop Protocol (RDP) based application sharing based on the new Application Sharing Server. The user model assumes 80% of all ad hoc meetings use RDP-based application sharing and 20% PSOM. For scheduled meetings, the user model assumes that application sharing uses 50% PSOM and 50% RDP. Assumptions: Meetings with one participant use no RDP application sharing. For scheduled meetings with two participants, the model assumes 20% RDP application sharing. For ad hoc meetings, the model assumes 10% RDP application sharing. 25% remote access. 15% anonymous. 10% federated. 50% internal.

The following table describes the meeting content size model used as the basis for capacity planning requirements and recommendations described later in this section.

Table 3. Meeting Content Size Model

Content type	Average size	Number of instances
Multimedia Content (Flash, Windows Media player)	50 megabytes (MB)	1
PowerPoint	20 MB	2
Other Microsoft Office Document Imaging (MODI) documents	10 MB	3
Handouts	5 MB	1

Communicator Web Access Model

The Communicator Web Access usage model is based on the Office Communicator usage model, and it includes the following assumptions.

Table 4. Communicator Web Access Usage

Description	Value
Total number of users	5,000 plus 120 users doing desktop sharing
Users doing desktop sharing	120 (20 conferences)
Percentage of internal users in contact list	70%
Percentage of legacy users	30%
Average number of contacts per user	50
Maximum number of contacts per user	260
Minimum number of contacts per user	1
Hours logged on per day per user	12
Presence updates per day per user	82
Instant message conversations per day per user	12
Instant message conferences per day per user	1
Instant messages sent per user per conference (peer-to-peer)	10
Instant message sent rate	1 per minute
Instant message sessions per hour	2
Average number of participants in a multiparty session	3
Concurrent conference users at a given point of time	5% of total users
Number of presence queries per user per day	60
User searches per day	12
Contact changes per user per day	13
Percentage of concurrent desktop sharing users	2%
Maximum number of users in a desktop sharing conference	6
Duration of desktop sharing conference	1 hour

The following table lists information about the desktop sharing model.

Table 5. Desktop Sharing Model

Description	Value
Users viewing shared desktops	100
Users sharing their desktops	20
Number of conferences	20
Small conference size	2
Medium conference size	3
Large conference size	6
Largest conference size	6
Percentage of small conferences	10
Percentage of medium conferences	15
Percentage of large conferences	70
Percentage of largest conferences	5
Conference duration	1 hours
Conversations per day	24

The usage model in the previous table is based on testing on a Proliant.

Response Group Service User Model

The following table describes the proposed user model for Response Group Service used as the basis for capacity planning requirements and recommendations described later in this section.

This model assumes:

• The default music-on-hold file is being used.
  
• English is being used.
  

Table 6. Response Group Service User Model

Component	Per Enterprise deployment	Per Standard Edition server
Agents – formal	800	500
Agents informal in hunt groups	5,000	1,000
Number of standard Response Groups	450	150
Number of queues used	One unique queue for each hunt group, two for the One-Level Interactive response group	One unique queue for each hunt group, two for the One-Level Interactive response group
Distribution of routing methods on groups	Parallel routing: 40% Longest idle: 40% Serial: 10% Round robin: 10%	Parallel routing: 40% Longest idle: 40% Serial: 10% Round robin: 10%
Percentage of workflows that use speech recognition in their interactive voice response (IVR) versus workflows that use only dual tone multi-frequency (DTMF) in their IVR	Speech recognition/Text-to-speech (SR/TTS) + DTMF: 50% DTMF: 50%	SR/TTS + DTMF:50% DTMF: 50%
Number of hunt groups (mix of 50% simple and 50% complex hunt groups)	600	300
Average number of agents per group	10 agents	10 agents
Average number of groups an agent is a member of	Two groups	Two groups
Number of groups per queue (average)	90%: One group 10%: Two groups	90%: One group 10%: Two groups
Number of simultaneous response group calls	480	60
Average call duration (IVR portion + music on hold)	30 seconds	30 seconds
Average call duration with the agent	3 minutes	3 minutes
Number of sign-in/sign-out cycles for formal agents in a day (based on an 8-hour day)	4	4

 Capacity Planning Requirements and Recommendations

The following tables provide information to facilitate capacity planning for your organization.

Table 7. Maximum Supported Users for Each Topology

Topology	Servers required	Maximum users supported
Standard Edition server	One Standard Edition server	5,000
Enterprise pool, consolidated configuration	Eight Enterprise Edition Front-End Servers running all server roles One Back-end SQL Server	100,000 Note: If deploying only IM and presence, Office Communications Server 2007 R2 supports 200,000 client end points, where each end point is a client program, such as Communicator, based on eight Front End Servers and a 16-core computer running the Microsoft SQL Server database software. The back-end database must run on a 4-way processor, quad core, or 8-way, dual core, 2.0 GHz+ computer.
Archiving Server	One Archiving Server	300,000
Monitoring Server	One Monitoring Server	200,000
Group Chat Server	Two Group Chat Servers	20,000 (10,000 per server)

Edge Server topologies assume 10% of the total user base will be connected from outside the intranet. The following table shows the maximum number of client connections supported by each of the following Edge Server roles and topologies.

Table 8. Maximum Supported Clients for Edge Server Topologies

Topology	Supported performance
Edge Server	Access Edge service: 5,000 client connections Web Conferencing Edge service: 1,000 client connections A/V Edge service: 500 concurrent audio/video (A/V) sessions

Deployment of a Director is recommended for external access.

Table 9. Communicator Web Access Capacity

Performance metric	Communicator Web Access presence and IM, Communicator Mobile for Java, search, and desktop sharing
Number of users	5,000 users 120 concurrent desktop sharing users

 

Note:

Computer configuration: 2.3 GHz CPU, 8.0 GB memory, 8 processors, Kernel SSL disabled, ASP NET 1.5 request queue limit of 1.5 * the number of concurrent users of the server, HTTPS connection, no collocation with other virtual server or Office Communications Server, 16 GB virtual memory, Communicator Web Access logging (retail tracing) set to off

Note:

Computer configuration: 3.0 GHz CPU, 1.0 GB memory, 100 Mbps network, 80 GB hard drive, Internet Explorer 7.0 browser, Microsoft Windows XP SP2 operating system, 1280x1024 display

Table 10. Storage Disk Capacity Planning

Storage drive	Average disk bytes per read and average disk bytes per write (for 100,000 users)	Disk reads and writes (per second, for 100,000 users)
Enterprise pool backend data drive	Read: 0 Write: 2,180	Read: 0 Write: 158.3
Enterprise pool RTC log	Read: 0 Write: 832	Read: 0 Write: 216.2
Enterprise pool RTCdyn log	Read: 996 Write: 2,289	Read: 0.002 Write: 561.3
Archiving log file drive	Read: 0 Write: 3,783	Read: 0 Write: 110.1
Archiving data file drive	Read: 761 Write: 3,532	Read: 0.091 Write: 38.7
Monitoring (QoE and CDR) data log drive	Read: 8,192 Write: 6,213	Read: 85.5 Write: 193.1

Table 11. Archiving and Monitoring Database Storage Capacity Planning

Component	Average growth of database per hour	Usage assumptions
Archiving database	636 MB per hour per 100,000 endpoints	Based on 320 messages per second, 400 bytes per message
Monitoring database	CDR: 162 MB per hour for 100,000 endpoints QoE: 482 MB per hour for 100,000 endpoints	Assumes that clients do not create QoE data for video calls

Table 12. Group Chat Capacity Planning

Chat room usage	User connection rate	Message rate
Each user participates in 30 chat rooms Each chat room has 30 participants	Two user connections initiated per second, per server	40 messages per second (all chat rooms)

 

Note:

Chat rooms can support more than 30 participants, and the Group Chat client is capable of supporting more than 30 chat rooms. However, large numbers of participants in a chat room may impact server performance. The maximum tested configuration for chat rooms is 1,000 participants. Use of chat rooms with large numbers of participants should be limited to no more than 10% of all chat rooms created.

Note:

Updated Group Chat capacity planning documentation, as well as a capacity planning spreadsheet, is available as a free download from the Microsoft Download Center: Capacity Planning for Microsoft Office Communications Server 2007 R2, Group Chat Server with QFE1 documentation: http://go.microsoft.com/fwlink/?LinkId=178622 Spreadsheet for Capacity Planning for Microsoft Office Communications Server 2007 R2, Group Chat Server with QFE1: http://go.microsoft.com/fwlink/?LinkId=178624

Table 13. Application Sharing Capacity Planning for Persistent Shared Object Model (PSOM) Applications

Application sharing usage	Sent and received (KBps)	Processor time	Average bandwidth usage per user (Kbps)
15 conferences, 90 users	Received: 1,370 (2,728 peak) Sent: 6,370 (12,315 peak)	Average: 8.5 Peak: 24.4	Sent per sharer: 713.57 Received per viewer: 552.92

Table 14. Mediation Server Capacity Planning

Computer	Maximum number of calls	T1	E1
90% internal users , 10% external/remote users
Dual processor, dual core, 3.0 GHz CPU, with 4 GB memory and 2 x 1 Gbps network adapter card	360	15	11
Dual processor, quad core, 2.3 GHz CPU, with 4 GB memory and 2 x 1 Gbps network adapter card	480	20	15
100% external/remote users
Dual processor, dual core, 3.0 GHz CPU, with 4 GB memory and 2 x 1 GB network adapter card	240	10	7
Dual processor, quad core, 2.3 GHz CPU, with 4 GB memory and 2 x 1 GB network adapter card	320	13	10

 

Note:

In the preceding table, CPU utilization is assumed to be 75% of capacity. Scaling numbers for Mediation Server depend on the location of the users, primarily how far the user is from the Mediation Server. For users outside the internal network, the media stack uses a lower bit rate, which can significantly impact performance.

Capacity planning for Address Book Server requires that you plan for the size of the Address Book Server database and Address Book Web query service database, the size of the download files, and the number of Office Communicator Mobile for Windows clients that will access the Address Book Web query service.

The size of the disk used for the Address Book Server database and the file server where Address Book Server creates download files depends largely on the number of contacts that must be stored. (The file server can be used to store other data as well. For details, see the "Folders" section in Storage Requirements.) One way that you can estimate the number of contacts that Address Book Server will store in the database and in the download files is to assume that each user has two Contact objects. As a result, you can estimate storage requirements for Address Book Server by multiplying the number of users in your organization by two.

• General Address Book download file size assumptions:
  
  • 100,000 contacts, 2.5 GB storage for download files (based on two contacts per employee)
    
  • 100,000 employees, 5 GB storage for download files
    
• General Address Book Web Query database size assumptions:
  
  • 100,000 contacts, 1.5 GB storage
    
  • 1 GB for database log
    

Table 15. Address Book Web Query Service Performance for an Enterprise Pool

Number of users	Maximum number of mobile devices	Number of entries in Address Book database	Queries per second	Usage notes
Total: 100,000 Voice-enabled: 30,000	18,000 (60% of Voice-enabled users)	300,000	Average: 17.7 Peak hours: 26.55	Eight Front End Servers 30% of users are enabled for unified communications. 100 queries per second has a minimal impact on performance.

Table 16. Audio/Video Capacity Planning

Media	Codec	Average bandwidth (Kbps)	Estimated activity (%)	Maximum bandwidth (Kbps)
Wideband Audio	RTAudio	34.8	61	57
Wideband Audio	Siren	22.2	43	51.6
Narrowband Audio	RTAudio	25.9	65	39.8
Video	RTVideo	258.3	82	350
Panoramic Video	RTVideo	220.5	70	350

• Bandwidth numbers quoted for media streams include all overhead for framing, encryption, and IP routing information in addition to actual encoded media.
  
• Average codec bandwidth values are based on measurements and derived from the maximum theoretical bandwidth based on typical activity level values. Audio activity levels take into account voice activity in the stream. Video activity levels take into account the amount of motion within the video images.
  
• Activity levels for RT Audio Narrowband is slightly higher to allow for less optimal Voice Activity Detection in PSTN Gateways for Office Communications Server VoIP-to-PSTN calls. This number should be increased by another 15% if no Voice Activity Detection is enabled on the deployed PSTN Gateway.
  
• Activity level of Panoramic Video is lower than for regular video streams because there is a higher relative proportion of background area within panoramic images.
  

 Media Bandwidth Requirements and Recommendations

For basic media gateways, the bandwidth requirement between gateway and Mediation Server is 80 Kbps for each concurrent call. Multiplying this number by the number of ports for each gateway is a fair estimate of the required bandwidth on the gateway side of the Mediation Server. On the Office Communications Server side, the bandwidth requirement is considerably lower.

When configuring Mediation Server, you should accept the default media port gateway range of 60,000 to 64,000. Reducing the port range greatly reduces server capacity and should be undertaken only for specific reasons by an administrator who is knowledgeable about media port requirements and scenarios. For this reason, altering the default port range is not recommended.

High-bandwidth traffic such as voice and video tends to stress networks that are not appropriately provisioned. Limiting media traffic to a known range of ports makes troubleshooting such problems easier.

 Mobile Data Bandwidth Requirements

Approximately 1 MB of bandwidth is required for mobile access for an 8-hour work day. This is based on the following usage:

• One distribution group, with 15 users
  
• 80 members in contacts list, with four presence updates per user per hour
  
• One tagged contact with four presence updates in one hour
  
• 12 phone calls per day, with 1 phone call per hour (1 incoming and 1 outgoing every two hours)
  
• Two minutes per call
  
• User is logged into one additional end point (such as Office Communicator or a desk phone)
  
• One IM session every two hours
  
• Outgoing and ingoing IMs are equal (1:1)