** July 30, 2010 Update **: It appears that the reported CU6 problems have been attributable to either the back end database update not being installed first, or [...]]]> There has been a new round of updates for Communicator 2007 R2, OCS 2007 R2, and OCS 2007 R2 Group Chat – known as Cumulative Update 6 (CU6).

** July 30, 2010 Update **: It appears that the reported CU6 problems have been attributable to either the back end database update not being installed first, or the OCS 2007 R2 .NET Framework 4.0 issue. Having said that, there was at least one report (on this blog) of the “mismatch error” even after the database install was applied first.

** July 26, 2010 Update **:  There have been several reports of problems (failure of the Front End Service to start) after applying the CU6 updates on the server. Consider holding off applying this update until more information is known.  It is important to install the CU 6 update to the back end database role first (see Description of the cumulative update package for Office Communications Server 2007 R2 database: July, 2010).  So far, the problems appear to be related to this, but more information to come.

Client Updates

Communicator 2007 R2:

• The July, 2010 update for Communicator 2007 R2 can be found here:  Description of the cumulative update package for Communicator 2007 R2: July 2010. This update brings the Communicator version up to 3.5.6907.206 from the last update in April 2010 (3.5.6907.196).
• Note: the links to the knowledge base article for the individual fixes do not work right now, or not ready yet, on the Microsoft support site.
• The update can be downloaded here.

Communicator 2007 R2 Phone Edition:

• The July, 2010 update for Communicator 2007 R2 can be found here: http://support.microsoft.com/kb/2267962/.
• The update can be downloaded here.

Communicator 2007 R2 Mobile:

• This was update was released about 2 weeks ago, but the knowledge base article has been updated. The description can be found here: http://support.microsoft.com/kb/969816.
• You can download the Smartphone update here.
• You can download the Pocket PC packager here.

OCS 2007 R2 Group Chat Client:

• The July 2010 update can be found here: Description of the update for Office Communications Server 2007 R2 Group Chat Client: July 2010.
• The update can be downloaded here.

Server Updates

OCS 2007 R2 Server:

• Note: the update for the SE/EE Back End Database is here: Description of the cumulative update package for Office Communications Server 2007 R2 database: July, 2010.  This update (OCS2009-DBUpgrade.msi) SHOULD BE RUN FIRST.
• All of the Cumulative 6 server updates can be found here: Updates for Communications Server 2007 R2.
• The updates can be downloaded here.
• It looks like the update includes new hotfixes for the following server roles: Audio/Video Conferencing, Web Conferencing Server, Core Components, Communicator Web Access, Conferencing Attendant, Standard/Enterprise edition Server Back End, and the UCMA Managed API 2.0 Core Redist 64-bit.
• Note: the links to the knowledge base article for the individual fixes do not work right now, or not ready yet, on the Microsoft support site.

OCS 2007 R2 Group Chat Server:

• The Cumulative 6 updates for the Group Chat Server can be found here: Update package for Office Communications Server 2007 R2 Group Chat Server: July 2010.
• The Group Chat Server update can be downloaded here.

OCS 2007 R2 Group Chat Admin Tool:

• The update can be found here: Description of the update for the Office Communications Server 2007 R2 Group Chat Administration Tool: July 2010.
• The update can be downloaded here.

1) QoE and CDR Database [...]]]> The Call Detail Record (CDR) and Quality of Experience (QoE) data available through the OCS 2007 R2 Monitoring Server role enables very good usage and quality of experience reporting.  This blog post covers how to estimate the size of the database, and how to manage the database data rentention and purge time.

1) QoE and CDR Database Sizing
Based on a sample Microsoft OCS feature usage model (the same one used for the OCS 2007 R2 Capacity Planning), the CDR database grows 8.8 KB per day, and the QoE database grows 16.8 KB per day.  Once we know this, we can estimate the database size using this formula:

            > Database size (KB) = (DB growth per user per day) * (Number of users) * (Number of days)

For example, the CDR and QoE database in a 3500 OCS user organization would consume a total of 5.3 GB in 60 days ((8.8+16.8) * 3500 * 60).

2) Setting the Data Retention
The default data retention for both CDR and QoE data is 60 days. Every night the purge process will delete any records which are older than this value. The retention setting can be viewed and set in the OCS Administrator Console by doing a right-click | Properties on particular monitoring server in the left-hand tree. The property page looks like the following:

Set the Maximum Days Logged to the number of days that you wish to retain the respective data sets.

Note:

• To purge everything, use a value of zero.
• Leave the checkbox unchecked to turn-off purging all together.
• You can also manage these settings through WMI.

3) Setting the Purge Time

Specifying the time of day that the SQL database purges the data cannot be set through the OCS Administrative Console. You need to use WMI to make this setting. The WMI classes to set the QoE and CDR purge times are shown below:

1. QoE:  use the MSFT_SIPQoESetting class and set the PurgeJobStartTime property.  The value is an integer representing the number of hours after midnight to start the purging (i.e the hour based on a 24 hour clock).  For example, a value of “1” will start the purging at 1am.
2. CDR:  use the MSFT_SIPCDRServiceSetting class and set the PurgeTime property. This also is an integer value representing the number of hours after midnight to start the purging of outdated records. 

These classes are only installed and available on the Monitoring Server. However, you can use the “-computername” parameter in WMI provider to remotely view and set value.

For example, the following two lines of Powershell, can be used to remotely set the Purge Time for the CDR database to be 4am:

Note: if you are using multiple monitoring servers connected to one monitoring database, it is important to not start the purging on each server simultaneously.  See the TechNet article Microsoft Office Communications Server 2007 R2 Configuring Retention of QoE and CDR Data for more information

Addition Information

• Microsoft Office Communications Server 2007 R2 Configuring Retention of QoE and CDR Data (TechNet)
• Key high-level information about the OCS 2007 R2 Monitoring role: OCS 2007 R2 Monitoring Role FAQ (InsideOCS post)
• Microsoft Office Communications Server 2007 R2Monitoring Support (TechNet)
• MSDN MSFT_SIPQoESetting (New)
• MSDN MSFT_SIPCDRServiceSetting (New)

The element [...]]]> I recently discovered the concept of ‘Trust Level’ with OCS federated partners (I thought all partners were treated equal once they were added as a federated partner).  It turns out that one partner can be ‘trusted’ more than another partner depending on how the federation is configured on the OCS 2007 R2 Access Edge.

The element of trust comes into play when the Access Edge evaluates the federation traffic.  Here are the important points:

• The Edge evaluates all federation activity for all partners.
• The Edge detects ‘suspicious’ activity by looking at the ratio of successful to failed responses.
• If the Edge server detects suspicious traffic it can limit the activity to 1 message per second throughput for that federated partner.
• The Edge limits federated partner activity to 20 messages per second unless the federated SIP domain is explicitly added to the Allow List.
• The Edge also limits any one federated partner to send requests to “no more than 1000 Uniform Resource Identifiers (URIs) (either valid or invalid)” to your local SIP domain unless they are explicitly on the Allow list. I interpret this limit as traffic to 1000 unique SIP addresses, and over what time period, I am not sure, but the rule to follow is to add the federated partner to the Allow list if you trust them, to avoid hitting this limit. You can see which federated domains are on the watch list by viewing the “Open Federation” tab in the 2007 R2 Access Edge management console. 
• If a traffic from a federated partner does hit the 1000 limit, traffic from this domain will be dropped. This is to prevent potential attacks on your SIP domain.
• Explicitly specifying an Access Edge along with a federated partner SIP domain on the Allow list grants the highest level of security - the partner is trusted from the persective of the Edge evaulating that partner’s traffic and explicitly specifying the FQDN of a federated partner’s Access Edge Server reduces the chances of a security breach such as a man-in-the-middle attack via DNS poisoning.
• If you are adding an audio conferencing provider (ACP) as a federated partner, you need to specific both the SIP domain and the FQDN of the ACP as the associated Partner Access Edge.

If you are new to federation, there are two ways to configured federated communication with an external OCS deployment:

1) “Allow automatic discovery of federated partners”.

On the “Access Methods” tab on the Access Edge server | Properties (in the OCS 2007 R2 Access Edge management console):

2) Explicitly specify the SIP domain of the federated partner in the allow list (on the “Allow” tab):

Note: Specific SIP domains can be BLOCKED by adding them in the Domains section of the Block tab.

References

• Microsoft TechNet Microsoft Office Communications Server 2007 R2 Configure Federation

The thought of changing an important attribute like the [...]]]> If the left-hand side of your users’ SIP addresses contain a common user attribute in Active Directory such as first name, last name (or both) there is a good chance the SIP address will need to be updated to match any change in the corresponding user attribute(s).

The thought of changing an important attribute like the SIP address made me a bit uneasy and wondering what the impact would be. Specifically, after the SIP address change, would communication still work with another Communicator user who had previously added the old SIP address into their contact list?

After being involved in a deployment that did a few SIP address changes, I am pleased to report that there were no major issues. The seamless communication is made possible by OCS storing user contact lists by unique-id instead of SIP address. Here are some important points to consider however:

1. One of the biggest issues that could arise is that Office Communicator integration with Outlook will break if the user’s SIP address does not match the primary SMTP email address in their Outlook profile (see previous post “Office Communicator 2007 and Outlook 2007 Integration Errors”), so the primary email address will need to be updated to avoid this error. If you do update the primary email address to match the new SIP address, ensure that the user’s Outlook profile gets updated. The Microsoft Exchange Autodiscovery service can auto-update the profile if you have Exchange 2007 or 2010 deployed.
2. Users will need to restart Communicator after the SIP change. Outlook should also be restarted to ensure integration functions correctly.

Note, the SIP address change was not tested with the OCS Group Chat functionality. If anyone has experience with this, your feedback is appreciated.