Scott Oseychik

Summary:

Using Microsoft Office Communications Server 2007 R2, Federation may fail against organizations that are using Lotus Sametime.

Resolution:

IBM has a hotfix which addresses this issue within Lotus Sametime.

More Information:

Please refer the following IBM support document; Ref #1389588

Summary:

Windows Live/MSN Messenger defines both Minimum and Maximum values for Presence subscriptions. If the SUBSCRIBE method uses a value out of this range, it may result in a SIP failure.  The minimum value is 3600 seconds and the MAX value is 13000 seconds.

More Information:

MinPresenceSubscriptionExpiry

·         Stored in the Active Directory as "msRTCSIP-MinPresenceSubscriptionTimeout"

·         The default value is 1200 seconds (20 minutes)

·         The minimum value for this property is 300 and the maximum value is 86340

MaxPresenceSubscriptionExpiry

·         Stored in the Active Directory as "msRTCSIP-MaxPresenceSubscriptionTimeout"

·         The default value is 43200 seconds (12 hours)

·         The minimum value for this property is 300 and the maximum value is 86340

Workaround:

If you are encountering SIP interoperability failures via PIC against Windows Live/MSN Messenger, please modify your msRTCSIP-MaxPresenceSubscriptionTimeout and msRTCSIP-MinPresenceSubscriptionTimeout values (either via ADSIEDIT or LDP) in accordance with their guidance (min: 3600, max: 13000)

If you have installed OCS into the System container in the Active Directory, these attributes will be stored at the following location:

CN=Global Settings,CN=RTC Service,CN=Microsoft,CN=System,DC=yourdomain,DC=com

If OCS is installed in the Configuration container, you can locate these values in the Active Directory here:

CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=yourdomain,DC=com

Summary:

Our Real Time Collaboration (RTC) Sustained Engineering Team has recently released two updates:

Communicator 2007 R2 hotfix rollup package: June 2009

http://support.microsoft.com/kb/972042

Update package for Office Communications Server 2007 R2: June, 2009

http://support.microsoft.com/kb/972041

The Office Communicator R2 hotfix rollup package (972042) will be made available via Microsoft Update, the Microsoft Update Catalog Server, as well as Windows Software Update Services (WSUS).  This release is scheduled to be available today (June 15, 2009) through these distribution channels shorly after 10:00am Pacific time.

The Office Communications Server R2 hotfix rollup package (972041) will be made available via Microsoft Update, the Microsoft Update Catalog Server, but not through Windows Software Update Services (WSUS).  This release is scheduled to be available tomorrow (June 16, 2009) through these distribution channels shorly after 10:00am Pacific time.

Issue:

The update package for Office Communications Server 2007 R2 will only be made available via Microsoft Update and the Microsoft Update Catalog Server, but not through WSUS.  The reason for this absence on WSUS is due to the fact that this package contains a change to a kernel-mode binary, which will cause a prompt (thereby interrupting the automated installation process).  For this reason we are not publishing this particular update to WSUS.  Moving forward, we are exploring various approaches to suppress these prompts on future updates.

In the meantime, for customers who intend on installing the Update package for Office Communications Server 2007 R2 (972041) and are using WSUS, they would need to import this from the Microsoft Update Catalog server if they want to deploy this update through Microsoft Update.

More Information:

For more information on how to import this update into WSUS using Microsoft Update, please refer to:

http://technet.microsoft.com/en-us/library/cc708583.aspx

Update: As of June 25, 2009, the KB article 897567 has been updated, and now is accurate.

Summary:

As of June 13, 2009, the content of the KB article 897567 contains an inaccuracy.  The last octet for the second MSN IP address was improperly transposed.  It’s published as 64.4.9.254, but that should be .245. 

We are working on getting the Knowledge Base article updated, but in the meantime, wanted to make our customers aware of this matter sooner rather than later.  Unfortunately, Microsoft cannot change the infrastructure to remedy this, as the "incorrect" IP address is already in use for another service in the Messenger cloud.

I will update this blog entry once the KB article has been updated to reflect the correct information.

Summary:

America Online will be performing scheduled maintenance on their SIP Access Gateways during the following maintenance window:

Confirmed Maintenance Start Date: 06/04/2009 04:00 ET (24 Hour Time)

Projected Maintenance End Date: 06/04/2009 06:00 ET (24 Hour Time)

There may be sporadic access service availability and users may experience service disruption.

User Action:

No action needs to be taken by your Office Communications Server administrator(s).  Additionally, there will not be any further notification regarding this maintenance activity unless there is a broad disruption of service.  In such cases, we will relay outage communication accordingly.

Symptoms:

LCS 2005, OCS 2007, and/or OCS 2007 R2 fail to establish PIC connectivity to MSN after changes were made to the MSN infrastructure on May 9, 2009

Data:

In the logs, you'll see the following data:

TL_ERROR(TF_CONNECTION) [1]08B4.146C::05/12/2009-15:32:27.115.00004bcf (SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(157))$$begin_record

LogType: connection

Severity: error

Text: Receive operation on the connection failed

Local-IP: 167.207.100.260:2540

Peer-IP: 65.54.227.249:5061

Peer-FQDN: federation.messenger.msn.com

Connection-ID: 0x375D101

Transport: TLS

Result-Code: 0x80072746 WSAECONNRESET

$$end_record

TL_ERROR(TF_CONNECTION) [1]08B4.146C::05/12/2009-15:32:27.115.00004bde (SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(157))$$begin_record

LogType: connection

Severity: error

Text: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?

Local-IP: 167.207.100.260:2540

Peer-IP: 65.54.227.249:5061

Peer-FQDN: federation.messenger.msn.com

Connection-ID: 0x375D101

Transport: TLS

$$end_record

Cause:

The old VIP is being cached in your environment somewhere.   If you look at the logs, connections are still trying to be made against 65.54.227.249, yet this VIP has been turned off on the MSN side.

Federation.messenger.msn.com is currently being directed to 64.4.9.181, though per Microsoft KB 897567, there are 5 possible IP addresses.  At this time the 64.4.9.181 IP address is the only one in service (and the other IP addresses listed in the article will be brought online as load/capacity deems necessary).

Resolution:

Clear the DNS cache (or HOSTS file), as they are resolving to the wrong IP address.

Credit:

Nathan Novak (in MSN; he rocks!)

Short & sweet ...

http://getcomo.com

Enjoy!

p.s. thx to robpit for sharing

We're actively debugging this, and I'll update this post once we have this resolved.

UPDATE (6pm, Eastern): We have identified the issue, and will be making changes this evening to rectify the issue.  Things should be resolved by tomorrow morning.

UPDATE 2 (9pm, Eastern): Huge thanks to the RTC Ops, RTC SE, and Core Dev Teams for diving in and helping nail this.  In the interest of transparency, this issue is also preventing Microsoft from communicating to our PIC providers (Yahoo, AOL, MSN). 

UPDATE 3 (8am, Eastern, 4/08/09): Federation & PIC is now back up and running at Microsoft.

Issue:

Microsoft Office Communicator 2007 R2 in conjunction with Office Communications Server 2007 R2 would intermittently fail to communicate with AOL AIM clients via PIC.  Note that this would only reproduce if your OCS 2007 R2 Edge role is running Windows Server 2008 (x64); not Windows Server 2003 (x64).

Resolution:

Essentially, it boils down to tweaking the Windows Server 2008 Edge role to initially establish the SSL dialog using the TLS_RSA_WITH_RC4_128_MD5 cipher suite.

In order to change the cipher suite order, do the following on your Windows Server 2008 (x64) Edge server:

1.       Start -> Run -> gpedit.msc -> OK

2.       Within the Group Policy Object Editor, expand Computer Configuration, Administrative Templates, Network

3.       Under Network, select SSL Configuration, and then double-click on SSL Cipher Suite Order (by default, the SSL Cipher Suite Order is set to "Not Configured")

4.       Select the “Enabled” radio button, and in the in the SSL Cipher Suites text box, copy the entire string into Notepad.  It should look like the following:

TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_MD5,TLS_RSA_WITH_NULL_SHA 

5.       The objective here is to move TLS_RSA_WITH_RC4_128_MD5 to be a the front of the list.  So, in your Notepad document, find TLS_RSA_WITH_RC4_128_MD5, cut it, navigate to the beginning of your notepad document, and paste TLS_RSA_WITH_RC4_128_MD5.  The new order should look like the following:

TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_MD5,TLS_RSA_WITH_NULL_SHA 

6.       Paste the newly-formatted string back into the text field in the GPO Editor, click OK, then restart your Windows Server 2008 (x64) Edge server for these changes to take effect.

We have verified (and re-verified) these steps work, and can now successfully communicate with AOL AIM clients using Office Communicator 2007 R2 via PIC.

SOLVED!

Customers running Office Communicator 2007 + Office 2007:

This issue is fixed by applying the hotfix referenced in KB 961752 (http://support.microsoft.com/kb/961752), and although the KB article does not specifcally call out this issue, we are working on both creating a new KB to address this, as well posting this blog entry to increase its visibility.

Customers running Office Communicator 2007 + Office 2003:

Our Office Development Team is moving forward with creating corresponding official hotfix for Office 2003.  Although it’s a bit early to discuss timeframes in terms of when you can expect the public hotfix, we have a private copy of the fixed MSMAPI32.DLL.  If you would like to test this build, please engage Microsoft Customer Support Services via http://support.microsoft.com.  Premier customers: please leverage your Technical Account Manager to initiate the case creation process.

Notification

In an effort to provide enhanced capacity and service reliance, Windows Live Messenger will soon be adding additional IP addresses used for PIC/Federation traffic.  Some organizations have chosen to restrict this type of traffic to specific IP addresses, as referenced in Microsoft KB 897567 (http://support.microsoft.com/kb/897567).  With this in mind we want to give you advanced notice of our intended change if you have configured your enterprise network in this manner.

Please ensure your enterprise firewall configuration is updated with the full list of Windows Live Messenger addresses below on or before Friday, May 8, 2009.  Windows Live Messenger will NOT enable any of the additional IP addresses until on or after May 9th (Pacific Time) to ensure your services will not be disrupted by this change.

IP address for Windows Live Messenger PIC/Federation:

65.54.227.249

64.4.9.181

64.4.9.245

65.54.52.53

65.54.52.245

For more information please reference Microsoft KB 897567, or for further assistance, please engage Microsoft Customer Support Services via http://support.microsoft.com.

Summary:

America Online will be performing scheduled maintenance on their SIP Access Gateways during the following maintenance window:

Confirmed Maintenance Start time:        2009-02-03 04:00 ET

Projected Maintenance End time:            2009-02-03 06:00 ET

There may be sporadic access service availability and users may experience service disruption.

User Action:

No action needs to be taken by your Office Communications Server administrator(s).  Additionally, there will not be any further notification regarding this maintenance activity unless there is a broad disruption of service.  In such cases, we will relay outage communication accordingly.

Summary:

You cannot connect to an Office Communications Server 2007 using an Office Communicator 2007 R2 client.

Details:

There are architectural changes introduced into Office Communicator 2007 R2 that are only compatible with Office Communications Server 2007 R2.

Workaround:

On Office Communications Server 2007, you can select to block Office Communicator 2007 R2 clients from connecting.

Summary:

After installing or renewing your DigiCert public certificate for your OCS 2007 Edge server(s), PIC stops functioning properly (however, Remote Access still works correctly).

Cause:

This issue occurs if the certificate issued uses the Certificate Authority listed below:

Root: DigiCert Global CA (2048), Intermediate Root: Entrust.net Certificate Authority (2048)

It will work if DigiCert issues certificate from the Certificate Authority below:

Root: Entrust.net Secure Server Certificate Authority, Intermediate Root: DigiCert Global CA

More Information:

DigiCert is aware of this issue, and is collaborating with Microsoft to ensure our mutual OCS customers experience minimal to no impact. DigiCert has made a change on their end to solve this problem moving forward.

If you are encountering this issue, you will need to reissue and replace any certificates which are issued from the "DigiCert Global CA (2048)" certificate.  DigiCert has made a change so your replacement certificate(s) will descend from the correct Entrust.net root certificate for PIC.  For help with any part of this process, please engage DigiCert support, either via web chat, phone, or e-mail at support@digicert.com.

After re-applying this certificate to your Edge server, and you still find that your PIC-related issues are still occurring, please restart Edge Front-End services first.  Allow me to apologize for this up front; I understand this will require an “emergency service restart change request” for some of you.

If all this fails to resolve the PIC issue, please engage Microsoft Customer Support Services.  Premier customers: please leverage your Technical Account Manager to initiate the case creation process.

Please be prepared to supply Edge Server logs, remote access via our EasyAssist applications from MSFT, and we will do our best to investigate and resolve this in a timely manner.

Kudos to Paul Tiemann @ DigiCert for his tenacity & helpfulness ...

Summary:

Yahooo! will be undergoing an emergency maintenance from 4:30pm to 4:30am PST. During this period, users will see intermittent presence issues.  All other functionality will not be impacted.

More Information:

After the maintenance window expires, if you find you are still having issues, please first log out & then back into your Communicator client.

If the issue still reproduces/occurs for you, please restart Edge Front-End services first.  Allow me to apologize for this up front; I understand this will require an “emergency service restart change request” for some of you.

If all this fails to resolve the PIC issue between your LCS/OCS deployment and Yahoo!, please engage Microsoft Customer Support Services.  Premier customers: please leverage your Technical Account Manager to initiate the case creation process.

Please be prepared to supply Edge Server logs, remote access via our EasyAssist applications from MSFT, and we will do our best to investigate and resolve this in a timely manner.