The Archiving Report* is meant to provide an easy way to pull information out of the archiving database.  It builds on the functionality provided by the Archiving PowerShell script that was written (http://communicationsserverteam.com/archive/2009/09/28/584.aspx) and adds a GUI interface, the ability to filter by date, and message formatting.  It has been tested against OCS 2007 R2 and SRS 2005.

Installation

1.       Open Report Manager – http(s)://<SRS Server>/Reports

2.       Click on New Folder

3.       Give the folder a name – i.e. OCSArchivingReport

4.       Click OK

5.       Click on the folder you just created

6.       Click on Upload File

7.       Browse to the location where you downloaded OCSArchivingReport.rdl and select the file

8.       Click OK to upload the report

9.       Click on New Data Source

10.   Enter LcsLog for the Data Source name

11.   Enter Data Source=<SQL Servername>;Initial Catalog=LcsLog for the Connection String

a.       Replace <SQL Servername> with your SQL server\instance

12.   Select the Windows integrated security radio button

13.   Click OK

14.   Click on OCSArchivingReport

a.       You will see the following error: The report server cannot process this report. The data source connection information has been deleted. (rsInvalidDataSourceReference).  This is normal, since we haven’t linked the report to the data source we just created.

15.   Click on the Properties tab

16.   Click on Data Sources in the left-hand column

17.   Make sure A shared data source radio button is selected

18.   Click the Browse button

19.   Expand OCSArchivingReport and click on LcsLog

20.   Click OK

21.   Click Apply

The report is now linked to the data source and ready to be used.

Using the Report

The report allows you to enter the SIP URI of any 2 users that you want to view archived messages from.  If you enter “Any User” (case sensitive) for either of the user input boxes, you are able to view any message from any user to a specific user as well as any user to any other user.  You can use the Start Date and End Date to narrow down the search to a specific date range.  Once you have entered all of the inputs, click on View Report.

The results of the search are shown.  The First User column represents the sender of the message and the Second User column represents the recipient of the message.  The Message column shows the message that was sent as well any formatting on the message.  Changing Show Toast to Yes will show the toast messages as well as the Toast column.

A big Thank You to Rich Thorp for helping me put together this report!

Doug Deitterick
PFE

* This is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of Use (http://www.microsoft.com/info/cpyright.htm).

Microsoft Certified Master (MCM) Program:  Recognizes, Develops, Certifies Technical Excellence

How do senior IT professionals differentiate themselves from the competition?  The MCM program, through intensive training by world class experts, plus extensive written and lab-based testing, certifies only the most qualified.  As an MCM you’ll join an elite community of Microsoft software and technology experts, and you’ll be recognized as one of the top Microsoft technology experts in the world. Learn more about the Microsoft Certified Master Program  

Do you have end users that need Office Communicator training? Are your users maximizing the basic features of OC? Microsoft now offers a free instructor-led session that introduces key Office Communicator usage scenarios through live demonstrations and hands-on activities.

This live course is held in a virtual classroom via Office Live Meeting. It will allow hands-on experience to build knowledge, skills, and confidence to use Office Communicator more effectively.

These features will be covered in this high-level overview:

• Instant Messaging
• Presence
• Contact Management
• Audio and Video
• Desktop Sharing
• Office Application Integration
• Add a Live Meeting
• Communicator Web Access

Click here to register: https://events.livemeeting.com/967/15027/reg.aspx?pc=05

We hope to see your users at an upcoming session!

This information was originally posted by Terry Lyons on his blog.

Feb 12 update from Terry's blog:

=====================================================

POSTPONED: Additional Windows Live Messenger PIC/Federation IP Address

Reference my original blog on an Additional Windows Live Messenger PIC/Federation IP Address

Tomorrow’s planned added capacity has been postponed for technical reasons and to provide additional time for administrators to update their firewall settings if necessary to reflect the additional IP address.  The new date that this work is scheduled to go into place is Friday, March 26, 2010.  For organizations that have chosen to restrict this traffic to specific IP addresses, you must have the list in KB 897567 in place prior to Friday, March 26, 2010 or PIC connectivity with MSN will fail.

897567    Known issues that occur with public instant messaging and Communications Server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;897567

===================================================== 

Notification

In an effort to provide enhanced capacity and service reliance, Windows Live Messenger will soon be adding an additional IP address 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, February 12, 2010.  Windows Live Messenger will NOT enable the additional IP addresses until on or after February 12, 2010 (Pacific Time) to ensure your services will not be disrupted by this change.

IP address for Windows Live Messenger PIC/Federation:

64.4.9.181
64.4.9.245
64.4.50.110 (Additional new IP address)
65.54.52.53
65.54.52.245
65.54.227.249

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

Have you ever installed an Office Communication Server and wanted to verify your remote access was setup and configured properly? Or what if you get a call or an escalation regarding a service or connection not working? How do you verify whether the issue is with an individual user or with everyone throughout the company? And if there is a problem, where do you start troubleshooting? Is it a DNS problem? Is it a certificate problem? Is a port not open on the firewall?

The Office Communications Server Remote Connectivity Analyzer is a great tool for performing testing, troubleshooting, and diagnostics on OCS 2007 & OCS 2007 R2 deployments. The tool will assist you in finding answers to the before mentioned scenarios.  You should use the RCA as your initial stop when attempting to troubleshoot an OCS edge server connectivity issue.  

The Office Communications Server Remote Connectivity Analyzer is a web site for IT Administrators to validate and diagnose end-to-end Office Communications Server scenarios. The site simulates multiple Office Communications Server client access scenarios from outside the customer's infrastructure and reports whether the test was successful.  If the test fails, we inform the IT Admin exactly where in the process it failed as well as provide troubleshooting tips on resolving the issue.

The OCS Remote Connectivity Analyzer is found here: https://www.testocsconnectivity.com/

Right now the tool is in its BETA release. This release allows you to either manually specify your server settings or have the server attempt to autodiscover your settings. Future tool enhancements will include deeper diagnostic information, detailed troubleshooting information, and other tests. If you encounter any issues with the tool or would like to provide suggestions/feedback, please do so using the email: ocsrca@microsoft.com

Cisco and Microsoft are competitors in the unified communications space, with very different visions and product approaches – I don’t think that’s going to come as a surprise to anyone.   Nor should it be a surprise that many customers have Cisco networking and telephony gear along with desktop, messaging and collaboration software from Microsoft and want our products to interoperate together well in the customer’s environment. 

To Microsoft, that means we want to offer customers software that runs great on Cisco networks.  With Office Communications Server’s support for the Cisco ISR platform, great support for DSCP packet marking to deliver QoS, VLAN tagging, and many more technologies, we are delivering a lot of capabilities so customers can get the most out of their Cisco network investments. 

We also look to interoperate broadly using open standards with Cisco products in unified communications.   As part of both companies’ commitments to our customers and shareholders, we’ve recently published a joint statement of interoperability for our products in unified communications, specifically addressing how Microsoft Office Communications Server and Cisco Unified Communications Manager work together across three different deployment scenarios, and what each company supports.  You can download that statement on the Microsoft site and yes the same document from the Cisco site.

The statement was drafted specifically with regard to Cisco of course, but an important point to remember is that Microsoft looks at interoperability across all of the vendors in a particular space – we don’t provide preferential treatment to support Cisco products or scenarios uniquely.  So the support statements we’ve crafted with Cisco, while applying directly to Cisco products, are founded on principles that can be applied to any vendor’s products in a given scenario.

The first scenario is Direct SIP, where Office Communications Server is a peer telephony platform to an IP-PBX and exchanges calls using SIP, without the use of an intermediate gateway.  A number of IP-PBXs have qualified for Direct SIP support with Office Communications Server by engaging through our Unified Communications Open Interoperability Program (UCOIP) to provide joint support.  In addition to that effort, Microsoft also tests IP-PBXs that have not engaged in the program, based on customer demand.  As such, we delineate between products that have been “qualified”, where the IP-PBX vendor engages through the UCOIP and both companies support the integration, and those that have been “tested”, where Microsoft solely does the testing and supports the configuration.  This is why you see some versions of Cisco Unified Communications Manager supported by Microsoft for Direct SIP, but not by Cisco.  Our customers have clearly told us it’s important to provide both programs, as many have older IP-PBXs that vendors may not choose to come through the UCOIP.  Those models Microsoft can test and potentially support (based on the IP-PBXs adherence to standard-based SIP), allowing customers to get more value out of their existing investments.

The second scenario is Remote Call Control (RCC), where the PBX station set (doesn’t have to be IP in this case) is controlled by Office Communicator.  Here, we don’t have a testing or qualification program – there are many PBXs and Gateways that support the ECMA TR/87 standard used by RCC and those products will work with Office Communicator, as we support the TR/87 interface.  Many PBX vendors will have a specific testing matrix for which middleware layer or CTI link is supported with Office Communications Server.  In addition, there are a variety of RCC gateways in the market from companies like CoreBridge, Estos and Genesys that further expand the diversity of PBX models and versions available.  Microsoft has announced the deprecation of the RCC feature for the next release of Office Communications Server, so new deployments of RCC will not be supported with the coming release.   However, customers who have existing deployments of RCC can upgrade to the next release and will continue to be supported through the lifecycle of that release – a good long time.

Finally, look forward to the dialogue - I’ll hound the blog for comments, or you can contact me directly at [sip | smtp] : jastark (at) microsoft.com

1) Search; 2) Ask; 3) Contact Microsoft from the revised Office Communications Server and Client Troubleshooting and Support page.

You know it; we know it: Stuff happens. There are times when an unforeseen confluence of circumstances causes problems in your deployment (which only an hour ago was running perfectly): Interaction with some piece of new hardware or software, the need for some atypical set of system configurations, some update in settings that seems likes it should just work, or some set of recent network or other events--not to mention, some very "creative" end user behaviors.

When stuff happens, you want answers. We want to help. The revised Office Communications Server and Client Troubleshooting and Support page design is streamlined to make the process of finding an answer faster and easier:

1) Search to find out quickly whether your issue, event, or error message has been addressed in a KB article or other documentation.

2) Ask community experts (both inside and outside of Microsoft) who may have experienced similar issues or can provide insight.

3) Contact Microsoft Support if you still cannot get the answer you need.

Adam Dudsic

Site Manager

We’ve just published a new Updates Resource Center for Office Communications Server 2007 R2 and Clients on the OCS TechCenter.

And we’ve gone one step further: Our Sustained Engineering and support teams* have created a Cumulative Server Update Installer tool to help simplify the application of the updates. The Cumulative Server Update Installer applies all updates for the appropriate server role in one click!

     *Kudos to our Sustained Engineering and support team members.

Each link text on the Updates Resource Center page contains the release date for the update so that you can easily recognize whether you have the most recent updates. Each link leads to a Knowledge Base article that lists the contents of the updater, describes the issues fixed, and provides other important installation information–in addition to pointing to the actual downloadable file.

Adam Dudsic

Site Manager

Office Communications Server 2007 and Office Communications Server R2 have two multi forest topologies that have been tested by and are supported by Microsoft. One of these topologies is the Office Communications Server Resource forest \ User forest topology and the other is the Office Communications Server Central forest and User forest topology. The focus of this document will be to discuss the implementations of the Office Communications Server Resource forest \ User forest topology.

The Office Communications Server Resource forest \ User forest topology allows resources like Exchange 2007, Exchange 2003, Sharepoint services and Office Communications Server which will reside in the Resource forest to be accessed by the users that reside in the User forest. The configuration of the Resource forest \ User forest topology requires that the following prerequisites be completed prior to the configuration of the domain user account information that will be hosted in the local Active Directory of each forest that is part of this topology.

Here are the prerequisites that are required to accomplish the task of creating the office Communications Server Resource forest \ User forest topology.

Firewall configurations

Depending on the two forests intra / inter active directory topology the usage, placement and configurations of firewalls can vary. Configuring any firewalls to securely manage the needed network connectivity can be a challenging task. If necessary this operation will have to take place first to allow the creation of the needed forest trust between the Resource and User forests.

The Microsoft KB article listed below will describe the Server 2003 domain services protocols / ports that will need to pass through the organizations firewalls that separate the Windows Active Directory locations which host the Resource servers and the user domain accounts that will be enabled for Office Communication Server sign on.

Service overview and network port requirements for the Windows Server system

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

Please take into consideration the version of Office Communications Server and Microsoft Exchange that you will be deploying when planning your firewall configurations. Office Communications Server 2007 R2 UC client connectivity requires a wider range of port connectivity for client access to the larger range of services that Office Communications Server 2007 R2 hosts, when compared to Office Communications Server 2007. Exchange 2007 uses its web hosted Exchange Web Service for client mailbox access and Free \ Busy data access this requires the use of TCP port 443 from the UC clients in the User forest. Exchange 2003 will allow MAPI client mailbox access through the use of RPC and the Endpoint Mapper management of TCP ports in the ephemeral range. The Office Communicator client will also have to have access to the Exchange 2003 public folders using a range of TCP ephemeral ports. The use of Virtual Private Network technologies to manage the needed network communications between the network endpoints that separate the server deployment in the Resource forest from the domain user accounts in the User forest is a preferred method for secured communications between the two.

For information on how Office Communicator accesses free busy data please read

Communicator 2007 does not update the free/busy information as scheduled

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

The following KB article discusses how to limit the amount of TCP ephemeral ports that are managed by the domain's RPC Endpoint Mapper Service. This may help network administrators provide more security at the level of inter and intra forest firewalls.

How to configure RPC to use certain ports and how to help secure those ports by using IPsec

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

To test domain service port access and all TCP port connectivity between to IP endpoints please download and use the Microsoft tool PortQryUI.exe which can be down loaded the Microsoft downloads web site.

PortQryUI - User Interface for the PortQry Command Line Port Scanner

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=8355e537-1ea6-4569-aabb-f248f4bd91d0

How to use Portqry to troubleshoot Active Directory connectivity issues

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

The following Microsoft KB article provides information on the various VPN technologies that Microsoft has to offer.

Virtual Private Networks

http://technet.microsoft.com/en-us/network/bb545442.aspx

DNS resolution

The active directory forests / domains that participate in any multi forest topology will require name resolution. The Resource forest / User Forest design requires at least DNS resolution for the Users in the User forest to access the server resources in the Resource forest. This one way DNS solution will work with the manual deployment method (which is described below) when you do not have to use a scripting tool in the Resource forest to access the domain user account information in the User forest. When using the automatic method (which is described below) the Exchange Linked Mailbox wizard will have to be able to access the active directory in the User forest. This will require DNS resolution from the User forest to the Resource forest and the User forest will require DNS resolution from the Resource forest to the User forest. Also, the type of DNS infrastructure that is required will be instrumental in the implementation of the required Server 2003 forest level trust relationship.

The Outlook 2007 and Office Communicator clients that will be hosted in the Users forest will require an additional HOST record in the DNS zone that represents the active directory domain which hosts the Exchange 2007 resource. This record will allow the Outlook 2007 client access to the Exchange Web Services for autodiscover and availability. The host record should be entered in the following format e. g. autodiscover.domain.com. This additional FQDN will be used to make secure requests to the Exchange Web Services folders that are hosted on the Exchange 2007 CAS such as https://autodiscover.domain.com/autodiscover/autodiscover.xml. These secure requests to the Exchange 2007 server on TCP port 443 require the use of an additional Web Server certificate that will be hosted locally on the Exchange 2007 server's computer certificate store and assigned to the local IIS Default web server. This certificate will have a Subject Name value that matches the FQDN of the Exchange server and it must contain the autodiscover FQDN in the SAN list e. g. autodiscover.domain.com.

Forest Level Trusts

The type of Server 2003 forest level trust that will be required depends on whether you plan to use the manual method or the automatic method for the implementation of the Office Communications Server Resource forest \ User forest topology. The manual method will require a one way Server 2003 forest level trust where the Resource forest trusts the User forest. The automatic method will require a two way Server 2003 forest level trust relationship so both forests will trust the other forest for resource access. Please do not confuse the Server 2003 forest level trust with the Windows external trust. The external trust will function between any two forests and the Exchange 2007 Linked mailbox implementation is fully operational when using a two way Windows external trust between ant two forests, but the Office Communication Server users in the User forest will not be able to sign into Office Communicator when using the Windows external trust. The design of the Server 2003 forest level trust supports both the use of NTLM and Kerberos v5 authentication methods.

Forest Functional Level

The creation of the Server 2003 forest level trust requires a forest functional level of Server 2003. Again the Exchange 2007 Linked mailbox implementation only requires a Windows 2000 forest functional level. So Exchange could already be operational in a Resource forest \ User forest environment as per a prior deployment too Office Communication Server. This can lead to sign on issues with the Office Communicator client in the User Forest.

Here are the steps you will need to take to implement the automatic and manual methods for creating the Office Communications Server resource forest \ User forest topology:

1. Manual method: make sure that the User forest can perform DNS resolution to the Resource forest. Automatic method: Make sure that each forest can perform DNS resolution for the resources in the other forest. If you are using a Microsoft Server 2003 DNS infrastructure then you will be able to use the DNS manager which is located on the Server 2003 DNS server or servers in either forest to create the needed secondary DNS forward lookup zones that will allow domain name resolution to the other forest in the multi forest topology.

2. The forest functional level has to be set to Server 2003. This can be confirmed by using the Active Directory Domains and Trusts MMC on the domain controller in the forest root domain that holds the PDC emulator role. This step requires research in a mixed domain forest. Please read the following Microsoft KB article before proceeding with this step.

How to raise domain and forest functional levels in Windows Server 2003

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

3. Creating the forest trust relationships can be done by using the Server 2003 trust wizard that can be accessed in the Server 2003 Active Directory Domains and Trusts MMC. Please read the following Microsoft Technet information before proceeding with creating the needed forest trust relationship between the Resource forest and the User forest.

Creating Domain and Forest Trusts

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

Certificates

The Exchange server and the Office Communications Server will require their certificates to be managed as per the PKI deployments that are described in their deployment documentation. Please read the available certificate documentation for these products. Certificate design can vary to meet the needs of the different hardware configurations that Exchange and Office Communications Server can be deployed using. If the services that are hosted in the Resource forest use a Windows PKI for certificate level security, then be sure to assign that trusted Root CA certificate to the Windows clients in the Users forest that will require secure access to these services. If you are using Exchange 2007 with Outlook 2007 clients please read the information about certificate design listed above under the DNS sub title.

Resource \ User Forest Deployment Methods

There are two methods that can be used to ensure access to Office Communications Server in the Resource forest by domain user accounts that exist in the User forest. The first is the manual method. The manual method will be typically used when Exchange 2003 or Exchange 2007 is not installed in the Resource forest or user mailboxes are not configured yet and Office Communications Server is deployed in the Resource forest. The manual method requires that you manually create user accounts in the Resource forest that match the domain user accounts that you want to be Office Communications Server enabled in the User forest. These accounts must have at least matching first and last name, sign on name, and password information. These domain user accounts must be homed to the local Office Communications Server front end server or pool that is located in the Resource forest. The domain user accounts should be disabled in the Resource forest domain that they are hosted in for security purposes. The most important step is the manual mapping of the objectSID attribute from the user account in the User forest to the disabled user account in the Resource forest. The second method known as the automatic method is the more preferred method, preferred because it incorporates the extensibility of Microsoft Exchange 2003 or Microsoft Exchange 2007 along with the use of Office Communications Server services. This design can include the integration features of Office Communications Server and Exchange 2007 Unified Messaging for a richer user experience. The use of either version of Exchange will ensure the integration of the enhanced presence features of Office Communications Server for use with the Office Communicator and Outlook 2007 SP1 clients. The automatic method will use the Linked Mailbox enablement procedure to create the Exchange 2007 mailbox for the domain users in the User forest. This procedure will also create the matching disabled user accounts in the Resource forest. This step will not enable the use of Office Communications Server for users in the User forest. First, the disabled user accounts have to be enabled for Office Communications Server in the Resource forest and homed to the Office Communications Server Pool or FE server. The automatic method allows the use the Office Communications Server Resource Kit tool sidmap.wsf to locate the Exchange mailbox enabled / Office Communications Server enabled account and map the objectSid attribute from the user object in the User forest to the correct attributes of the matching disabled user object in the Resource forest.

Manual Method

The manual method does not require that Exchange 2007 or Exchange 2003 be installed into the Resource forest. However Office Communications Server does have to be installed in the Resource forest and the Office Communications Server enabled for sign on user accounts must exist only in the Users forest. The manual method provides us with a good way to test the Office Communications Server functionality of the Office Communications Server Resource forest / User forest deployment prior to adding other server resources to the Resource forest. This method will allow the Office Communications Server enablement of a few user accounts so administrators can test instant messaging and other built in functionality of the Office Communicator client. The result of this implementation is basically the same as the automatic method just less the availability of Exchange services. Here's how it’s done:

1. In the User forest create a user account in one of the active directory domains that will be hosting Office Communication Server services. The Domain user account can simply be defined with a username, first name, last name, and a password.

2. Now move to the Resource forest and from a domain controller in the active directory domain that is hosting Office Communications Server create a domain user account using the same information that was used to create the domain user account in the User forest. Please remember to disable the new domain user account in the Resource forest for security purposes.

3. Now on the Office Communications Server in the Resource forest open the dsa.msc (AD Users & Computers). Locate the domain user account that you just created and then open its properties dialog. Use the Communications tab to associate the account with a SIP URI and the Office Communication Server pool or server that the user will be homed to.

4. Now all we have to do is use adsiedit.msc on a domain controller that hosts the new domain user account in the User forest and access that domain user account's properties. Browse the attributes of the domain user account and locate the objectSID attribute. Edit the attribute and then copy the SID value to notepad and save it to a shared location on the server. Make sure that the SID value does not get accidentally updated in either location, then exit out of adsiedit.msc without saving any changes.

5. Now from a domain controller in the active directory domain that hosts the Office Communications Server installation use adsiedit.msc to locate the new domain user account that you want to use with Office Communications Server in the User forest. Open the properties dialog of this domain user account and then search the attribute listing for the msRTCSIP-OriginatorSID attribute. Edit the msRTCSIP-OriginatorSID attribute, and paste the SID value from the objectSID of the user forest / domain user account into the SID value window in adsiedit.msc. Apply the changes and close adsiedit.msc.

a. msRTCSIP-OriginatorSID = objectSID of the User Forest User

msRTCSIP-OriginatorSID

This attribute is used in resource and central forest topologies to enable single sign-on when a user’s ObjectSID from the Windows NT principal account is copied into this attribute of the corresponding user or contact object in the resource or central forest. Communicator Web Access searches for a user in Active Directory using this attribute or the user’s ObjectSID. This attribute is marked for global catalog replication.

6. Now from a client in the Resource forest you can sign into Office Communicator using the domain user account that is enabled for Office Communications Server in the Resource forest.

7. Perform this task with two or three domain user accounts to test the basic usages of Office communicator in the User forest.

Automatic Method

The automatic method requires the installation of Exchange 2007 or Exchange 2003 in the Office Communications Server resource forest. This method will also require the installation of the Office Communications Server Resource Kit tools on a server in the Resource forest.

1. In the User forest create a user account in one of the active directory domains that will be hosting Office Communication Server services. The Domain user account can simply be defined with a username, first name, last name, and a password.

2. Exchange 2007 SP1 allows the Administrator to create mailboxes for domain users in remote forest by using the New Mailbox wizard option called appropriately "Linked Mailbox".

a. The wizard will prompt you to create a new user or use an existing one. Using these steps you can create a new domain user account in the Resource forest using the same information that was used to create the domain user account in the User forest.

b. Choose the mailbox database for the new account. Click Next

c. Choose the trusted User forest.

d. Enter the credentials for the Administrator in the Resource forest and choose the specific Domain Controller that you can authenticate to in the User Forest which hosts the user account for mailbox creation.

e. Choose the user account in the User forest that you want to create the mailbox for.

f. Click Next / Next / Finish to create the mailbox

6. Upon the creation of the mailbox user in the User forest you will have created a matching disabled user account in the Resource forest. The new disabled user account will contain all the MSEXCH* attributes along with User forest and Resource forest accounts will contain different objectSID attribute values.  However, the msEXCHMasterAccountSID attribute of the Exchange enabled domain user in the Resource forest will have been updated in the following manner.

a. msEXCHMasterAccountSID = objectSID of the User Forest User

msExchMasterAccountSid

If the mailbox is owned by a user that is outside of the local Windows 200x forest, msExchMasterAccountSid should contain the SID of that external user account. In this case, the disabled user account is also not used to log on directly, but instead this configuration allows a user outside of the forest to own an Exchange 200X mailbox within your organization. The foreign user account may be either a Windows 200X user from a separate forest, or a Windows NT 4.0 user account. If the value of msExchMasterAccountSid is the SID of an external account, the value must be unique. You may not have more than one disabled user account with the same SID in msExchMasterAccountSid in the entire forest. The msExchMasterAccountSid attribute should not point to a security principal (User or group) that is in the local forest, with the exception of foreign security principals. The external account specified in the msExchMasterAccountSid attribute should also have "Full Mailbox Access" rights granted in the Mailbox Security Descriptor. The SID must be written in a binary format, not security descriptor definition language (SDDL) format.

7. The next step is to Office Communications server enable the disabled domain user or users accounts. If the domain user's SIP address matches their SMTP address then you can use the AD U & Cs Office Communications Server Enable Users wizard to SIP enable the domain user accounts in their OU or the Users container. If not then you can use the manual method in AD U & Cs, by first accessing the property dialog of the domain user account in its OU or Users container and then from the Communications tab assign the domain user’s SIP URI and home them to the Office Communications Server Pool or FE server.

8. Now you can use the Office Communication Server Resource kit tool sidmap.wsf to populate the following disabled domain user account's attributes in the Resource forest as follows:

a. msRTCSIP-OriginatorSID = objectSID of the User Forest User

msRTCSIP-OriginatorSID

This attribute is used in resource and central forest topologies to enable single sign-on when a user’s objectSID from the Windows NT principal account is copied into this attribute of the corresponding user or contact object in the resource or central forest. Communicator Web Access searches for a user in Active Directory using this attribute or the user’s objectSID. This attribute is marked for global catalog replication.

The objectSID attribute for the user account in the resource forest and the user forest retain their original and unique SID values.

Here’s the how to information on using the Office Communications Server Resource Kit tool sidmap.wsf

Microsoft Office Communications Server 2007

Populating the Required Attributes for Office Communications Server

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

Our Microsoft Technet documentation mentions the use of other user object attributes, such as:

telephoneNumber

displayName

givenName

surname

physicalDeliverofficeName

l (city)

st (State)

Title

Company

Country

Mail (SMTP Address)

Except for the Mail attribute which is added at the creation of the user's mailbox, the use of all other attributes in the list above is arbitrary. However, they do add descriptive factors to the user account that will help distinguish the difference between to Office Communications Server enabled accounts when the Office Communicator user performs s a AD search for a contact using the Add Contact Wizard.

When a domain user in the Users forest performs a AD search using the Add Contact wizard the search will take place in the Resource forest and not in the users forest. Please remember since the domain user objects will reside in two separate forests achieving consistent active directory searches based on these attributes, will require that the domain user attributes in the Resource forest match the domain user attributes in each separate active directory Users forest.

Exchange 2003 does support the use of Resource forest. In Exchange 2003 this was called the Dedicated Exchange forest as noted in the linked Microsoft Technet article listed below.

Exchange Server 2003

Using a Dedicated Exchange Forest

http://technet.microsoft.com/en-us/library/aa997312(EXCHG.65).aspx

In this topology MIIS 2003 could have been used to provision user attributes to the manually disabled duplicate account in the Resource forest or these attribute values such as the msExchMasterAccountSid could have been manually mapped from the objectSID of the enabled sign on account in the User forest. The Dedicated Exchange forest topology does not use MIIS to synchronize Exchange information as it would in the Exchange 2003 Cross Forest topology where Exchange 2003 could be hosted in multiple forests.

I would like to say that deployments that are hosting this type of Exchange 2003 Resource forest / User forest topology are using a legacy deployment that was intended for just the Exchange 2003 Resource. They may want to add Office Communications Sever to their Resource forest though.

1. If so then all the prerequisites should already be in place
2. They will have to add Office Communications Server to their Resource Forest and then Office Communications Server enable the disabled user accounts in the Resource forest.
3. Next they would use the Office Communication Server Resource kit tool sidmap.wsf to populate the following disabled user account's attributes in the Resource forest as follows:
4. msRTCSIP-OriginatorSID = objectSID of the User Forest User
5. The msEXCHMasterAccountSID should already be populated with the correct SID information from the Exchange 2003 mailbox enabled account in the user forest. I have not tested this yet, but the resource kit information does not specify a required version of Exchange Server.

Mike Adkins

We've been working on the Downloads page on the Communications Server TechCenter! Check out the improvements:

·         Separate pages devoted to 2007 R2 Downloads and 2007 Downloads;

·         Clearer categorization of available 2007 R2 downloads;

·         And most importantly…more of the good stuff: More listings!

Find even more links than before to all the tools and resources that our team produces, including new links to Office Communications Server 2007 R2:

·         Best Practices Analyzer (for both 2007 and 2007 R2 versions)

·         Capacity Planning Tool

·         Edge Planning Tool

·         Planning Tool

·         Resource Kit Tools (64-bit)

·         Web Scheduler

…as well as links to:

·         Agent Communications Panel for Microsoft Dynamics CRM 4.0

·         Language packs for CWA, Response Group Service, and Speech

·         Communicator Multilingual User Interface

·         Management packs

·         Communicator Mobile (for Pocket PC, Smartphone, and Java)

The new 2007 R2 page now also includes links to all downloadable, technical product documentation for 2007 R2, including:

·         Collections of the full IT Pro library

·         Pointers to the various topic-focused documentation downloads

·         Pointers to the indices of the server, client, and end user documentation downloads

Let us know whether the new pages help you find what you need, or if there are additional resources that you cannot find there!

Adam Dudsic

Site Manager

We are pleased to announce that the Microsoft Office Communications Server 2007, Speech Server (a.k.a. Speech Server (2007)) runtime is now officially supported on Windows Server 2008, in addition to the originally supported Windows Server 2003 Platforms(listed at http://msdn.microsoft.com/en-us/library/bb813400.aspx).

Microsoft will support application deployments, Administrative tools and Data Processing Utilities like the MssLogToDatabase and MssLogToText tools. However Microsoft will not support installation and usage of the Development Tools that include Speech Server (2007) application development, call data analysis and grammar tuning running on Windows Server 2008. For those tools please refer  back to the original list of supported Platforms for development at http://msdn.microsoft.com/en-us/library/bb662074.aspx.

To illustrate the above, the following screenshot shows the Speech Server (2007) components that are officially supported to run on Windows Server 2008. Please note that the installation wizard will not block you selecting the "Development Tools" option automatically, when you run the setup on the Windows Server 2008 operating system, so you will have to make sure that you do not select the Development Tools option during the installation process.

We expect that Windows Server 2008 support will benefit many customers who are deploying Windows Server 2008 today!

Microsoft is still investigating potential support for Windows Server 2008 R2 for Speech Server (2007). We will inform you via this blog in case we have more to announce on that topic. Till then customers are advised not to deploy Speech Server (2007) on Windows Server 2008 R2.

October 24 Update - The MS09-56: Vulnerabilities in CryptoAPI could allow spoofing article has been updated with a Known Issues section and FIX for the LCS and OCS product. That article is the authorized content as it requires the proper groups to coordinate and confirm the data published. We thank those of you who both reported this issue to us as well as helped blog/tweet to help reduce the number of customers deploying the patch until this issue is resolved.

We also want to note that for future issues with security fixes should be reported through support in order to be properly tracked and escalated and that it will be the official communication vehicle.

<Deleting original text of blog message as it duplicates the information in the KB article>

Hooray! Office Communications Server 2007 R2 XMPP Gateway Has Been Released

This article walks you through setting up the XMPP Gateway and configuring it to work with Jabber XCP 5.4. For those who have been anticipating this release, I am happy to say, here it is, and it’s been worth the wait if you require Jabber or GMail connectivity.

You will be required to complete the following steps to successfully configure Office Communications Server 2007 R2 XMPP Gateway with Jabber XCP 5.4.

1.   DNS Configuration

2.   Office Communications Server Edge Configuration

3.   Office Communications Server XMPP Gateway Configuration

4.   Jabber XCP (s2s Configuration)

Environment Requirements

• Enable your current environment to work with the new Office Communications Server 2007 R2 XMPP Gateway
• Office Communications 2007 R2 Edge Server
• Permissions to request a server certificate from a private or public certification authority.
• Permissions to create DNS records in your internal Enterprise, as well as public DNS servers
• Windows 2003 x64 or Windows 2008 x64 for your new XMPP Gateway
• Jabber XCP 5.4

To help you visualize the environment, Figure 1 shows how you could implement the XMPP Gateway. This design will change depending on where your Jabber server is deployed in your environment. I am assuming that your Jabber server is deployed in your network perimeter.

Figure 1   XMPP Topology

If you have firewalls in the network perimeter that will prohibit communication between your Edge Server and Jabber server, you must open TCP port 5269 in both directions for communication to be successful. 

DNS Configuration

Most of this configuration has already been done when deploying your Office Communications Server 2007 R2 pool and Edge Server. Therefore, I will just go over the recommended DNS SRV records and what records are required for the XMPP Gateway.

• SRV record: _sipinternaltls._tcp.contoso.com
  • Host record: pool.contoso.com
  • Port number: 5061
• SRV record: _sip._tls.contoso.com
  • Host record: edge.contoso.com
  • Port number: 443
• SRV record: _sipfederationtls._tcp.contoso.com
  •  Host record: edge.contoso.com
  • Port number: 5061

The previous three records are the standard records used when deploying Office Communications Server for internal automatic configuration, external automatic configuration, and enhanced federation. To configure the XMPP Gateway requires the following additional DNS records.

• SRV record: _xmpp-server._tcp.contoso.com
  • Host record: xmpp-gw.contoso.com
  • Port number: 5269
• SRV record: _sipfederationtls.tcp.jabber.contoso.com
  • Host record: sip-xmpp.jabber.contoso.com
  • Port number: 5061

Let me try and explain these records in more detail. Only one record is required. The required record is xmpp-server._tcp.contoso.com. This SRV record is used for TCP Dialback. 

The basic idea behind TCP Dialback is that a receiving server does not accept XMPP traffic from a sending server until it has “called back” the sending server. This is accomplished with the _xmpp-server SRV record.

 Think about it this way: When the Contoso XMPP Gateway attempts to connect to the Jabber server, it first needs to locate it. This is performed by resolving the DNS SRV record for _xmpp-server._tcp.jabber.contoso.com. DNS returns the A record associated with this SRV record, in this case, jabber.contoso.com. The XMPP Gateway then proceeds to connect the Jabber server who’s FQDN is jabber.contoso.com. Then the Jabber server must “call back” the XMPP Gateway by looking at the domain of the request, which in our example is contoso.com, and then performing a DNS lookup for the SRV record, _xmpp-server._tcp.contoso.com. This will resolve to the XMPP Gateway (xmpp interface) from where the request originated.

In Figure 2, you will find the same image as shown in Figure 1, but this time it shows the DNS SRV records. Only the _xmpp-server SRV records are required for TCP Dialback.

Figure 2   XMPP Topology with SRV Records

Office Communications 2007 R2 Edge Configuration 

Edge Server configuration is fairly simple. The process is the same as adding another federated partner.  You can use enhanced federation if you have the SRV records created for that domain. In our example, jabber.contoso.com, we will need a record of _sipfederationtls._tcp.jabber.contoso.com that points to the SIP interface of the XMPP Gateway. Again this can be done with manual configuration as well.

Figure 3   Edge Server Allow List

In Figure 3, I used manual configuration. The Edge Server must be able to resolve sip-xmpp.jabber.contoso.com to the SIP Interface of the XMPP Gateway. If you do not have any DNS in the network perimeter, you can add an entry in the local host file of the Edge Server for this record.

Example of local host file:

sip-xmpp.jabber.contoso.com            172.16.10.253

OCS XMPP Gateway Configuration

I am not going to walk you through the process of installing the XMPP Gateway. However, I will spend some time on how to configure the gateway. Install the XMPP Gateway on a Windows 2008 or Windows 2003 x64 workgroup server in the network perimeter. The XMPP Gateway requires only a single NIC (network interface card). Your SIP and XMPP interfaces can share a single IP address. You can use multiple IP addresses if you want to, but it is not required for the XMPP Gateway configuration.

Figure 4   XMPP Gateway Server IP Configuration

Configuring the XMPP Gateway IP address is different. This is done in a configuration file. Everything else we will do will be from the XMPP Gateway MMC. This configuration file can be located on the server running the XMPP Gateway, in the following directory.

I am using the IP address assigned to the XMPP Gateway in the TGWConsoleGUI.dll.config file for the SIP & XMPP Interface:

“%ProgramFiles%\Microsoft Office Communications Server 2007 R2\XMPP Gateway\TGWConsoleGUI.dll.config”

Figure 5   XMPP Gateway IP Configuration File

There is one issue that you should watch out for: the DNS suffix of the server. The FQDN of the server should be the same as the certificate assigned to the SIP interface of the XMTP Gateway.

Figure 6   DNS Suffix

If you skip the step shown in Figure 6, you will see the following TLS failures between the Edge Server and the XMPP Gateway. 

TL_ERROR(TF_SECURITY) [0]085C.0AA4::08/24/2009-19:39:02.063.0000b52f
(SIPStack,SIPAdminLog::WriteSecurityEvent:SIPAdminLog.cpp(413))$$begin_record
LogType: security
Text: Message cannot be routed because the peer's certificate does not contain a
matching FQDN
Result-Code: 0xc3e93d67 SIPPROXY_E_ROUTING_MSG_CERT_MISMATCH
Connection-ID: 0x700
Peer-IP: 172.16.10.253:5061
Peer: sip-xmpp.jabber.contoso.com:5061
SIP-Start-Line: INFO sip:sip-xmpp:5061 SIP/2.0
SIP-Call-ID: 00783283efb94bd6bb9a4dcd80c5a2ba
SIP-CSeq: 2 INFO
Data: Peer certificate with name [sip-xmpp.jabber.contoso.com] does not contain any expected FQDN(s): sip-xmpp
$$end_record

Here’s what happens:  When the XMTP Gateway responds with a 200 OK to our INVITE, it populates a Contact header of the XMPP Gateway FQDN. You will encounter two separate issues. First, you will be unable to resolve “sip-xmpp”. Second, if you can resolve the host name, you will see the above error, because the host name is not on the certificate assigned to the SIP interface.

Now that the DNS suffix is updated and IP addresses are assigned to the XMPP Gateway, we can move on to SIP configuration. Again, this can be done by using SRV records or manual configuration. 

Depending on DNS resolution, this might be easier to do with manual configuration and host files. The XMPP Gateway can support only a single SIP domain per server but is able to support multiple XMPP or Jabber domains. On the SIP configuration screen, you will specify the SIP domain and the Access Edge FQDN.

Figure 7   XMPP SIP Domains

The TLS certificate is fairly simple to set up. We will not be going through how to request a certificate, as we only need a server EKU certificate. This is an internal server, so you do not need to use a public certificate. After the certificate has been requested and installed on the XMPP Gateway, we can select the certificate that was installed on the TLS Certificate tab.

Figure 8   SIP TLS Certificate

Now that the SIP configuration is complete, we can move to the XMPP configuration. The first screen you will see is the Allow List. In most cases, you will not specify the server name and will use the SRV records we discussed and created above.

Figure 9   XMPP Allow List

We will now configure a domain for the allow list. Again, we are using TCP Dialback, there is not a password required, and the username is auto populated from the SIP domain that you configured in the previous steps. In my Jabber setup, I am not using TLS, but if you are, you will select the appropriate option for your configuration and assign a certificate to the XMPP interface on the TLS Certificate tab.

We will cover TLS configuration between XMPP Gateway and Jabber XCP 5.4 in another article.

Figure 10   XMPP Domain Configuration

Jabber XCP 5.4 Configuration

We have now configured the XMPP Gateway and Edge Server. The next steps are to configure the server to server (s2s) Jabber XCP 5.4 configuration. There are only two steps to configure. 

From the main Jabber XCP System Controller Page, we will concentrate on the Components section.  First, edit the Connection Manager and add the s2s component.

Figure 11   Jabber XCP Components

In Connection Manager, click Edit. Then, under Connection Manager Configuration, in the Add a new drop-down box, select S2S Command Processor, and then click Go.

Figure 12   Jabber XCP Connect Manager Configuration

On the S2S Command Processor Configuration screen, click Submit. No changes are required to this screen. The default configuration is correct for our example. Make note of the Processor ID for the next step. In my configuration, it is “cm-1_s2scp-1”.

Figure 13   Jabber XCP S2S Command Process Configuration

This returns you to the Connection Manager Configuration screen. Click Submit, and you are returned to the main XCP Main Controller page.

Figure 14   Jabber XCP Components – Save Changes

Click Apply, and then click Restart the System Link. After the system restarts, it will move to the last step. At this point, if you skip the next step, you can add Jabber contacts from the Office Communications Server clients. However, Jabber will be unable to see your presence or participate in any IM conversations. This next step is important to complete the setup. This is what allows the Jabber server to route connections to other servers.

Under the Components section, from the Add a new drop-down box, select Open Port, and then click Go.

Figure 15   Jabber XCP Components – Add OpenPort

You will be prompted to enter the Processor ID that was created during the s2s configuration.

Figure 16   Jabber XCP OpenPort – S2S Processor ID

On this page, you must change Configuration view to Intermediate before continuing. Then add * to Hostnames for this Component, and then click Submit.

Figure 17   Jabber XCP OpenPort Configuration

Again, click Apply, and then click Restart System Link on the Open Port component.

Figure 18   Jabber XCP Components – Save Changes

Adding Jabber Contacts

The last step is for users to add Jabber users to their Contact list in Office Communicator. Ensure that the Office Communicator users are configured for federation, as shown in Figure 19. Otherwise, Office Communicator users will not be able to communicate with external users.

Figure 19   User Configuration Federation

Geoff Clark, Sr. Support Engineer

Important edit October 7- the original post stated Windows 2008 R2. This is incorrect we do not support that version at this time. The correct version should be Windows 2003 or Windows 2008.

Check out the following figure. That's no illusion-it's an Office Communicator user communicating with a Gmail user.

If you can't wait to try this, you have come to the right place. Before you start, ensure that the following requirements are met:

1. You organization has a properly configured Office Communications Server 2007 R2 environment.
2. There is a properly configured Edge Server in your Office Communications Server environment.
3. You have permissions to request a server certificate from a public or private CA.
4. You have permissions to create DNS SRV and A records on the Internet.
5. There is a server that is running Windows Server 2008 on which to install the XMPP Gateway in your network perimeter.

The rest of this article assumes that you have an environment running Office Communications Server 2007 R2 complete with an Edge Server (see requirements 1 and 2 in the previous list) that is configured to allow internal users to federate with external domains. You will have to request a certificate for your XMPP Gateway (requirement 3). For Gmail to locate your XMPP Gateway, you will have to create SRV and A records on your public facing DNS (requirement 4). To install the XMPP Gateway, you must have a separate server running Windows Server 2008 (requirement 5).

Figure 1 illustrates the topology of the configuration that you will be setting up. Because the XMPP Gateway connects directly to your Edge Server and the Gmail gateways on the Internet, it should be deployed in the network perimeter. Let's get started!

Figure 1   XMPP Topology

Configure Firewall Rules

To allow the Gmail gateway to communicate with your XMPP Gateway, you must open port 5269 on your external firewall and map incoming and outgoing TCP traffic on that port to your XMPP Gateway FQDN or IP address. Gmail uses port 5269. If you do not configure your firewall to allow incoming traffic on port 5269 to your XMPP Gateway, Gmail users will not be able to send instant messages to Office Communicator users.

Configure XMPP Gateway

Because your XMPP Gateway connects directly to your Edge Server and your Edge Server is located in your network perimeter, your XMPP Gateway also must be located in the network perimeter. It must be accessible to the Gmail gateway. This placement of your XMPP Gateway means that you will have to be mindful of the security implications and take appropriate action to secure your XMPP Gateway.

To configure the XMPP Gateway, do the following:

1. Set up a server that is running Windows Server 2008. Ensure that the latest security updates are installed. This computer will be referred to as the XMPP Gateway.
2. Install Office Communications Server 2007 R2 XMPP Gateway software.
3. Define the FQDNs to the XMPP Gateway.
4. Configure the domain name on the XMPP Gateway.
5. Request and install a server certificate in the computer's Personal store for the XMPP Gateway.
6. Create SRV record and A records for the XMPP Gateway on your public facing DNS server.
7. Configure the XMPP Gateway.

Step 1: Set Up a Server that Is Running Windows Server 2008

Microsoft requires that the XMPP Gateway be installed on a separate server. Unless you use a separate Active Directory in your network perimeter to manage the servers in your network perimeter, configure this Windows server in a stand-alone workgroup. Under no circumstance should this server be joined to your internal Active Directory domain.

Because this Windows server is in your network perimeter, ensure it is hardened against attack. Reduce the attack surface area by turning off unnecessary services and allowing incoming traffic to the XMPP Gateway only on ports 5061 (used by the Edge Server) and 5269 (used by the Gmail gateways).

Step 2: Install Office Communications Server 2007 R2 XMPP Gateway Software

This article does not cover the installation process in detail because this process is very simple. However, the following are two things to keep in mind:

• First, your XMPP Gateway needs only a single network interface (NIC). When I think of a gateway, two NICs automatically come to mind. I had originally configured my Windows server to have two network interfaces, but it is not necessary. You can keep things less complicated by using a single NIC.
• Second, after you complete the installation wizard, make sure that you specify the IP address of your network interface in the following file:

"%ProgramFiles%\Microsoft Office Communications Server 2007 R2\XMPP Gateway\TGWConsoleGUI.dll.config"

This is the configuration file used by the XMPP Gateway service. Because Setup does not prompt for this information during installation, it can be easily overlooked. The example shows the contents of the config file. Assuming your XMPP Gateway uses a single network interface, specify the server's IP address as the value for the SipIP and XmppIP fields.

<?xml version="1.0" standalone="yes"?>

<configuration>

<appSettings>

<add key= "cultureName" value = "en-US"/>

<add key= "SipIP" value= "XXX.XXX.XXX.XXX"/>

<add key= "XmppIP" value="XXX.XXX.XXX.XXX"/>

</appSettings>

</configuration>

In our example, the XMPP Gateway's IP address, 192.168.1.20, is entered in the SipIP and XmppIP fields in the preceding example.

Step 3: Define the FQDNs to the XMPP Gateway

Define the FQDNs for the XMPP Gateway. I recommend using two FQDNs. One of the FQDNs is internal and is used by your Edge Server to connect to your XMPP Gateway. This internal FQDN is not exposed to the Internet and maps to the actual IP address of the XMPP Gateway. This FQDN is used by the Edge Server to validate the XMPP Gateway's server certificate when establishing an MTLS connection. In this example, the internal FQDN is called srv_xmpp.litwareinc.com.

The other FQDN is for external use by the Gmail gateways to locate your XMPP Gateway. This external FQDN is exposed to the Internet and maps to your firewall's public IP address, which you have configured to route TCP traffic for port 5269 to your XMPP Gateway. This external FQDN is called xmpp.litwareinc.com in our example.

You might be wondering why not use a single FQDN instead of two? And you're correct. You can use a single FQDN. If you use a single FQDN, you must use the public FQDN. In this configuration, the Edge Server connects to your XMPP Gateway through the public FQDN. This results in the traffic between your Edge Server and XMPP Gateway going across your external firewall. However, if your firewall does not allow loopbacks, the connection will fail.

Step 4: Configure the Domain Name on the XMPP Gateway

After you define an FQDN for your XMPP Gateway, you must configure the domain name portion of this FQDN on your XMPP Gateway. (This assumes that the server running the XMPP Gateway is configured in a stand-alone Workgroup).

In our example, the internal FQDN of the XMPP Gateway is srv_xmpp.litwareinc.com. The domain name portion of this FQDN is litwareinc.com. You must configure this value in the Primary DNS suffix of this computer field of the XMPP Gateway.

To do this:

1. Click Start, right-click Computer, and then click Properties.
2. Under Computer name, domain, and workgroup settings, click Change settings.
3. On the Computer name tab, click Change.
4. In the Computer Name/Domain Changes dialog box, click More as shown in Figure 2.
5. In the Primary DNS suffix of this computer field, enter the domain name.

Figure 2   Configuring computer's DNS suffix

Step 5: Request and Install a Server Certificate in the Computer's Personal Store for the XMPP Gateway

Your XMPP Gateway requires a server certificate to communicate with your Edge Server. This certificate with its corresponding private key must be installed in the local computer's Personal store.

Without a certificate, the authentication will fail and the MTLS connection will be refused. This can often be a source of frustration and can be caused by a variety of reasons such as an untrusted root CA or a mismatch between the XMPP Gateway's FQDN and the certificate's CN in the Subject Name field. If you run into issues, use the ocslogger.exe tool to help you troubleshoot. It's a great tool. If you run into problems, let us know and we'll produce an article on this topic.

Everyone has their favorite way of requesting certificates, so I will not cover all the ways this can be done. However, there are two things to keep in mind: First, make sure the Common Name (CN) of the certificate is identical to the internal FQDN that is assigned to the XMPP Gateway. Second, use at least 2048 encryption strength. For more information, a great resource about certificates for Office Communications Server is the Microsoft Office Communications Server 2007 R2 Documentation: OCS Deploying Certificates.

If your sole purpose for setting up an XMPP Gateway is to connect to Gmail, this certificate will be used only to authenticate to your Edge Server. In this case, you can use a certificate from your private CA. Make sure that your XMPP Gateway trusts the root of your Edge Server's certificate and vice versa.

Step 6: Create SRV and A records for the XMPP Gateway on Your Public Facing DNS Server

For this step, you must publish the external FQDN of your XMPP Gateway so that the Gmail gateways can locate your XMPP Gateway. Remember your XMPP Gateway's external FQDN should be mapped to your external firewall's IP address unless you expose your XMPP Gateway directly on the Internet (not recommended). In our example, the external firewall's IP address is 207.46.197.32.

After you name your XMPP Gateway's external FQDN (we picked xmpp.litwareinc.com for our example), you must create an A record in your public DNS to map this FQDN, <server name>.<domain>.com, to your external IP address. In our example, xmpp.litwareinc.com maps to 207.46.197.32.

In addition to creating this A record, you must create an SRV record in the following form:

_xmpp-server._tcp.<domain>.com

This is the service record locator that is used by Gmail gateways to discover the external FQDN of your XMPP Gateway. Figure 3 shows how to create this SRV record for Litware Inc.

Note   The protocol must be set to _tcp, and the port number must be set to 5269. The domain name of both the A record and the SRV record must match your SIP domain.

If you own your own domain names and use godaddy.com, you might recognize Figure 3. The at sign (@) translates to your domain name. This is litwareinc.com in our example.

Figure 3   DNS SRV record for XMPP Gateway

Step 7: Configure the XMPP Gateway

The final step is to configure your XMPP Gateway to connect to your Edge Server and Gmail gateways. On the XMPP Gateway, under Administrative tools, open the Office Communications Server 2007 R2 XMPP Gateway console.

Select the SIP Configuration node (Figure 4). Configure the connection to the Edge Server first by doing the following:

1. On the Domain tab, specify your domain name in the Domain field. For our example, this is litwareinc.com.
2. Specify the FQDN of your Edge Server in the Host Name field. In our example, the Edge Server's external FQDN is srv.litwareinc.com. See Figure 4.

Figure 4   SIP Configuration of XMPP Gateway

For the Edge Server to trust your XMPP Gateway, you must configure the certificate that you requested in step 5. To do this:

1. In the Office Communications Server 2007 R2 XMPP Gateway console, click the TLS Certificate tab (Figure 5).
2. Click Select Certificate, and then select the certificate that you requested in step 5. If you are unable to find it, you installed the certificate in the wrong certificate store.

Note   The certificate's common name must match the XMPP Gateway's FQDN as shown in Figure 5.

Figure 5 TLS Certificate Configuration of XMPP Gateway

3. After you finish the SIP configuration, click the Validate Connection tab to validate your configuration to the Edge Server.

Next, configure the connection to the Gmail gateways by doing the following:

1. In the left pane, click the XMPP Configuration node (Figure 6).
2. On the Allow List tab, click Add.
3. In the Federated XMPP Domain names dialog box, in the Domain Name field, enter gmail.com, and then select TCP Dialback (required) as shown in Figure 6. Click OK.

Figure 6   XMPP Configuration of XMPP Gateway

Because Gmail does not use any authentication or encryption (TLS), no certificate is required to be configured in the TLS Certificate tab. To validate your configuration, click the Validate Connection tab.

Configure the Edge Server

The configuration on the Edge Server is very simple. You just have to add an entry in the Allow list of the Edge Server by doing the following:

1. In the Computer Management console, right-click the Edge Server node, and then click Properties (Figure 7).

Figure 7   Edge Server Configuration

2. On the Allow tab, click Add, and then make the entry to the Allow list.

When you add a new federated partner to the Allow list, the Federated partner domain name must be set to gmail.com, and the Federated partner Access Edge Server field must be set to the internal FQDN of your XMPP Gateway. This instructs your Edge Server to route messages for the domain name, gmail.com, to your XMPP Gateway. Because you do not own the domain name, gmail.com, you must specify the next hop to direct traffic for gmail.com to your XMPP Gateway. The internal FQDN of the XMPP Gateway maps to the private IP address of your XMPP Gateway instead of its public address. If you specify the public FQDN of your XMPP Gateway, your Edge Server will connect to your XMPP Gateway through your external firewall.

If you host a DNS server in your network perimeter, you should create an A record to map the FQDN of your XMPP Gateway to the private IP address of your gateway. If you do not have a private DNS server in your network perimeter, you will have to add an entry in the local hosts file of your Edge Server. To edit the local hosts file, use local administrator's permissions. This hosts file is located in the %windir%\system32\drivers\etc\hosts directory. Use your favorite editor to add the following entry at the end of the file:

<private IP address of XMPP Gateway> <internal FQDN of XMPP Gateway>

In our example, this maps to the following entry:

192.168.1.20 srv_xmpp.litwareinc.com

Adding Gmail Contacts

The last step is for users to add Gmail users to their contact list in Office Communicator. Ensure that the Office Communicator users are configured for Federation (Figure 8); otherwise, Office Communicator users will not be able to communicate with external users.

Figure 8   User Configuration for Federation

Conclusion

Configuring your XMPP Gateway to connect to Gmail is pretty painless when you know what to do (of course). Hopefully, this article helped you get on the fast track to making this happen. I did not cover how to request the certificate for the XMPP Gateway in detail or how to troubleshoot connectivity issues. If you experience difficulties and would like help, leave DrRez a request on twitter.com.

Rui Maximo

We are excited to announce changes to the Office Communications Server Public IM Connectivity (PIC) license that provides instant messaging and presence federation to the Windows Live, AOL and Yahoo! public IM networks. Starting October 1, 2009, the following licensing changes will be made:

1. A PIC License will no longer be required for federation with American Online (AOL).  Customers qualify for federation with AOL if they have Office Communications Server 2007 R2 Standard CAL or active Software Assurance on their current LCS/OCS license. 
2. Customers who want Yahoo! federation will continue to purchase PIC licenses.  The price of PIC will be reduced by 50%, effective October 1, 2009, to reflect this change. 

We are also excited to announce the release of the OCS 2007 R2 XMPP Gateway (http://go.microsoft.com/fwlink/?LinkID=141529). The Gateway provides Presence and two-party IM interoperability with the XMPP based systems of Jabber and Google Talk.

1. The Gateway interoperability has been tested against Jabber CXP Server version 5.4 and the current version of Google Talk.  The OCS 2007 R2 XMPP Gateway is supported by Microsoft Support
2. This Gateway is licensed as Additional Software to OCS 2007 R2, meaning that there is no additional license cost associated with deploying the Gateway for OCS 2007 R2 licenses.

For more details about these two great announcements you can read the Microsoft Press Pass article with Eric Swift, General Manager of the Unified Communications Group at http://www.microsoft.com/presspass/features/2009/oct09/10-01ucinterop.mspx  or in this Channel9 interview with the responsible Product Managers Ashima Singhal and Albert Kooiman http://channel9.msdn.com/posts/jccim/Instant-Messaging-Interoperability-extended-through-XMPP-Jabber/ 

Recap of June Announcement: In June 2009, we announced a similar change for Windows Live and renamed the OCS PIC license. 

1. The LCS PIC license was renamed to Office Communications Server Public IM Connectivity. 
2. A PIC License is no longer required for federation with Windows Live. Customers qualify for federation with Windows Live if they have Office Communications Server 2007 R2 Standard CAL or active SA on their current LCS/OCS license. 

With these changes, customers qualify for IM/P federation with Windows Live and AOL with the Office Communications Server 2007 R2 Standard CAL or OCS 2007/LCS 2005 SP1 Standard CAL with Software Assurance.  http://www.microsoft.com/communicationsserver/en/us/public-im-connectivity.aspx

We are thrilled about growing the network of users for Office Communications Server. 

Following the release of Office Communications Server 2007 Sasa Juratovic posted a PowerShell script  to retrieve user IM conversations form the archiving database.  (http://communicationsserverteam.com/archive/2008/01/14/69.aspx)

With the release of Office Communications Server 2007 R2 there were changes in the archiving database schema allowing the text/html content type for storage of user instant messages.  This schema change caused the previous script to only report the first message in a conversation when reporting against an OCS R2 archiving database.  An updated script that will account for this additional content type that works for retrieving instant messages from both the OCS 2007 and OCS 2007 R2 archiving database schemas has been posted.

The updated script can be found at: http://communicationsserverteam.com/files/555/download.aspx

--Nick Smith

MCS Senior Consultant

As we all know, in the world of computers we have a binary system. Either something works (1) or it does not (0). And as all of us really know, there is another state, that we all loath, "works sometimes" (1.5).

Recently I ran into a problem with my Office Communicator 2007 Phone Edition (OCPE aka Tanjay) running on Communicator Phone Edition R2, build 3.5.6907.31 with exact such a problem:

While everything else seemed to work without problems, the call logs (missed calls, incoming calls, outgoing calls, waiting voice messages) were only working sometimes. At random points of time - between 20 minutes and not at all - they were updated, however not instantly as they are supposed to (instantly means here, that it can take up to 3 minutes, because this is the poll interval).

We took the usual troubleshooting step, the Office Communicator 2007 Phone Edition (OCPE) logs and the server logs. On the Exchange CAS (Client Access Server), where the Office Communicator 2007 Phone Edition (OCPE) should retrieve the call logs from, we finally found something interesting: we saw there that the Office Communicator 2007 Phone Edition (OCPE) sent requests every 3 minutes and got 401 http errors instead of the call logs.

After some additional hours of troubleshooting and searching for errors, we finally decided to try the newest Office Communicator 2007 Phone Edition (OCPE) build - 3.5.6907.35. Now something wonderful happened: though not described in the knowledge base article for the hotfix (http://support.microsoft.com/default.aspx/kb/972398 ), call logs started to work.

What I have learned from this experience:

· Always use the latest updates (for Office Communicator 2007 Phone Edition (OCPE), the can be found here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=565595be-6cf3-4a61-a1e4-12555749ca64 )

· Sometimes a hotfix might fix problems, even if they are not mentioned in the knowledgebase article.

Thomas Binder

The 32 bit version of the PreCallDiagnostic tool is complete and is now live on the Microsoft Download Center.  Customers can now access the download here: http://www.microsoft.com/downloads/details.aspx?FamilyID=f16ab4c2-353f-4c9b-b353-22a656c03c9b.  The 64 bit version of PCD shipped as part of the OCS 2007 R2 Resource Kit with Office Communications Server 2007 R2 RTM.  The 32 bit version has been pulled out and repackaged on its own in order to help our customers on 32 bit machines. 

For those of you unfamiliar with the PreCallDiagnostic Tool:

The PreCallDiagTool is an application that reports expected audio quality as it relates to the network effect. The tool should be installed on any desktop or laptop PC that suffers from inconsistent network connection quality. The PreCallDiagTool can provide a quick check of the current network conditions and also preserve a history of quality data to let users profile their network performance over time or other conditions. The tool is particularly useful for home/mobile users and users using WIFI access points.

We have released a document that we believe many of you have wanted to see for quiet some time. One document that covers the certificate requirements for Office Communications Server 2007 R2.

The OCS 2007 R2 Deploying Certificates.doc can be downloaded as part of the server documentation download page, url here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9f86f96-aa09-4dca-9088-f64b4f01c703

Here is the Summary for the document:

In this document, you will learn about the properties and attributes of certificates when working with Office Communications Server 2007 and Office Communications Server 2007 R2. This document contains a walkthrough of most of the common, and some optional, tasks that you need to perform to realize the full value of the system. All roles that require certificates for deployment and operation are discussed. The properties are presented along with information to describe what they are and how they are used. This document shows you how to request the right certificate with the right parameters to make sure that you are delivering value to your users, rather than just troubleshooting problems.

Office Communications Server User Assistance Group

When a user is an agent of a Response Group, he will receives voice calls via the Response Group Service. Because calls are not originally targeted at this user in particular, no missed call notification will be generated. This behavior has been designed for two reasons:

- If parallel routing is used, an agent, even willing to accept calls, may get a lot of such notifications, such making the "missed call notification" feature less useful.

- It may be confusing for informal agents to receive such missed call notifications as their main activity is not to answer RGS calls.

Note that conversation entries will be available for RGS calls.

Stéphane Cavin

The Office Communications Server 2007 R2 team is happy to announce release of the Web Scheduler as a web download. The Web Scheduler provides a basic scheduling experience. Some of the main features of the Web Scheduler are:

• Authentication using Windows credentials
• Schedule a Live Meeting or a Conference Call
• Verify Names of Enterprise Invitees
• Specify Meeting Access Type (Open/Closed/Anonymous), Time, Location, and Message to invitees
• View List of Scheduled Conferences
• Modify/Delete Scheduled Conferences
• For Scheduled Live Meetings, choose between Computer Audio or any third party Audio Conferencing Provider

The Web Scheduler currently does not support scheduling a conference using the "assigned conference ID" (a.k.a. Reservationless Conference ID).  Support for this feature is available in the Conferencing Add-in for Microsoft Office Outlook. Conferencing Add-in for Microsoft Office Outlook continues to be the supported client for scheduling Office Communications Server 2007 R2  conferences and offers a more robust and complete experience than the Web Scheduler. Support for the Web Scheduler will be on a best-effort basis in line with our Resource Kit policies. 

Compared to the Conferencing Add-In for Microsoft Outlook, the Web Scheduler has the following limitations:

• Web Scheduler does not support scheduling recurring conferences.
• Web Scheduler lists only conferences that were organized by a specified user. It does not list all conferences that the user is invited to.
• Web Scheduler is available only in English.
• Meeting invitations that are generated by Web Scheduler meeting do not look the same as those that are generated by the Conferencing Add-In for Microsoft Outlook.

You can download the Web Scheduler from the following location: http://www.microsoft.com/downloads/details.aspx?FamilyID=6d6848ec-e7d6-41f4-82d9-5bed3526fcbd.

More than 8 months in the making, we're pleased to announce that Group Chat QFE1 is released as has the Group Chat SDK.  This is a strategically important release, as it provides key features and performance enhancements that elevate OCS Group Chat to an enterprise grade product.  This is the culmination of many late nights, tens of thousands of lines of code, several hundred bug fixes, dozens of DCRs, and lots of fire drills. :)

Key updates include:

. Scale Improvements

. Group Chat now supports up to 60,000 concurrent users

. Server Resiliency

. Support for High Availability and Disaster Recovery

. Server Side SDK

. Managed APIs to programmatically access all End User and Amin functionality

. More integrated client experience

. Co-existence with Communicator, including ability to use Group Chat as primary IM client

. User colors

. Support for custom end user colors

. Client Extensibility [Add-in]

. Ability to stitch business logic into the flow of chat rooms by serving up URLs inline using Add-in APIs.

Congratulations to the entire Group Chat team!

http://www.networkworld.com/community/blog/8631

http://jschurman.spaces.live.com/

http://www.vimeo.com/jschurman

correcting the gotucnet url http://gotuc.net/blogs/gotuc/default.aspx

Aug 25 Adding

http://blogs.technet.com/greganth/

In this post we will explain why it’s important to not ring the user’s additional number for Response Group calls, and how that is accomplished.

The main goal of the Response Group Service is to route calls to individuals. Enabling simultaneous ringing means that a user has set his forwarding settings to ring an additional phone number. Doing so means there is a chance that the call can end up on a voice mail system (for example, the voice mail of the user’s cell phone). It would not make sense to have calls routed from a Response Group to someone’s voice mail. This is the reason why simultaneous ringing is not applied for Response Group calls.

Disabling simultaneous ringing is achieved by setting a special header in the SIP INVITE sent by the service to OCS. OCS will then interpret this header and not apply the forwarding settings of the user.

Note : this also means that all of the user’s call-forwarding settings are not applied. The different forwarding settings can be seen in Figure 1.

Figure 1 Call-Forwarding Settings Dialog

If one of the following is selected:

Ring me and my team-call group
Forward to voice mail, a number, or a contact
Ring me and my delegates
Ring my delegates only
OCS won’t honor it for Response Group calls. This means the following :

In case the option "Ring my delegates only" is selected, the user (or their delegates) will never receive any Response Group calls.
The "Ring for this many seconds before redirecting" option is ignored. The call will ring as long as configured in the Response Group agent group settings (Agent alert time, see Figure 2.).

Figure 2 Response Group Service - Group's Properties

Stéphane Cavin

Federation is an important goal for the Office Communications Server team and we are excited to announce several changes to public IM federation between Office Communications Server and public IM networks, effective July 1, 2009:

· The Live Communications Sever Public IM Connectivity (LCS PIC) license will be renamed Office Communications Server Public IM Connectivity (OCS PIC) license.

· Customers with Office Communications Server 2007 R2 Standard CAL or Office Communications Server 2007/Live Communications Server 2005 SP1 Standard CAL with Software Assurance will no longer require an additional license to federate with Windows Live.  (A license will still be required for federation with AOL & Yahoo!.)

· With Windows Live federation, customers are able to add Windows Live contacts to their Office Communicator contact list, view presence and send and receive instant messages.

We will continue to work with our partners to enable more options that allow you to communicate seamlessly with customers, partners, friends and family on different networks. For more information on public IM connectivity with Office Communications Server, please go to http://www.microsoft.com/communicationsserver/en/us/public-im-connectivity.aspx

Unified Communications Group

Microsoft has just released the following Knowledge Base articles (KB972041, KB972042) to address the incorrect calculations of license expiration dates for Office Communications Server (OCS) 2007 R2 and Office Communicator (OC) 2007 R2 Evaluation Edition. The current expiration dates were calculated based on build time, causing the OCS 2007 R2 and OC 2007 R2 Evaluation Edition to expire after June 13, 2009.

Microsoft has issued the fixes below to correct the issues. By applying this fix, the expiration date will be updated to one hundred eighty (180) days after the initial installation of OCS R2 or OC R2 Evaluation Edition, as stated in the license terms for these applications.

Microsoft encourages its customers to apply necessary updates in their evaluation environment to take full advantage of the evaluation period.

To get the updates packages, please go to:

Office Communications Server 2007 R2
Office Communicator 2007 R2

Or to get your new evaluation edition, please go to:
Office Communications Server 2007 R2 Eval

Office Communicator 2007 R2 Eval

You Can Download Microsoft Office Communicator Mobile 2007 R2 from the following Link - http://www.microsoft.com/downloads/details.aspx?familyid=BC08CDB7-98E9-47E5-AA63-EB17C2CE4592&displaylang=en (CommunicatorMobile.PPC.msi) or

http://www.microsoft.com/downloads/details.aspx?familyid=93062936-F216-4D97-AA13-105A20454322&displaylang=en (CommunicatorMobile.SP.msi Form Link)

As per the Article (Installing Communicator Mobile for Windows Mobile from a Storage Card Link http://technet.microsoft.com/en-us/library/dd425083(office.13).aspx) you need to have a .CAB file, by default only .MSI is downloadable from the Microsoft Website.

You can install the Communicator Client via ActiveSync Installing Communicator Mobile Using ActiveSync 4.5 Ref Link http://technet.microsoft.com/en-us/library/dd425350(office.13).aspx. You can use CommunicatorMobile.MSI file to install CommunicatorMobile on the Windows Mobile.

However if you would Try to install ActiveSync on the Vista Machine you will getting following error:

The only option you are left with is to install the CommunicatorMobile via Cab file. Since there is no direct .cab download for CommunicatorMobile following is the workaround.

Workaround

1.    Create a Folder name COMO on the C:\ Drive

2.    Download .MSI in the COMO Folder.

3.    Open Command Prompt, and Change folder to C:\Como.

4.    Run the Following Command.

 msiexec /a CommunicatorMobile.msi

5.    It will Open Following Wizard..

Choose Next Twice and Click Finish.

Go to Path (C:\COMO\COMO\BuiltIn\Microsoft Office Communicator Mobile\Setup), you will find .cab file. Now Browse the Location on you Mobile and install the CommunicatorMobile on Windows Mobile Device.

While Installing you may encounter following Error. Ref Screen Shot (Installation of Communicator.Sp.cab was unsuccessful. The installation file is not intended for the device)

Reason:

From the Microsoft Web Site we can download two .MSI file for Communicator Mobile

1.    CommunicatorMobile.SP.msi

2.    CommunicatorMobile.PPC.msi

CommunicatorMobile.SP.msi: To install Communicator Mobile on Smart Phone

CommunicatorMobile.PPC.msi: To install Communicator Mobile on Pocket PC

We are getting this error because we are using .MSI file intended for Smart Phone on Pocket PC or vice versa.

OCS Team

In order to mark Audio and Video packets for DSCP in OC 2007 R2 – the following steps has to be performed on Vista SP1 and SP2 PCs:

1)    Create and update the following key : (32 bit DWORD set to)

a.    HKEY_LOCAL_MACHINE\Software\Microsoft\RTC\Transport\QoSEnabled

b.    Set 32 bit Dword to 1 to enable

c.    Reboot PC – (this will not take effect until rebooted)

After the reboot, RTP Media will be marked with the following default values: (which can be changed)

1)    Audio calls will be marked with DSCP 40

2)    Video will be marked with DSCP 24

These default values can be changed by going to Group Policy and changing the default value show below:

For customers who also want signaling (SIP TLS) to be marked with unique DSCP values - a group policy will have to be created. (see following steps)

1)    Under Group Management Editor – Create New Policy

2)    Set Policy Name DSCP value for SIP signaling.  We will use DSCP 40 for SIP signaling per RFC 4504.

3)    Next add exact program path and name:

(c:\Program Files\Microsoft Office Communicator\communicator.exe)

 

4)    Next all (i.e any) IPs will be used as the filter

5)    Next select TCP 5061 as the destination port.  (SIP TLS uses TCP 5061)

 

 

6)    Click finish and you are done!

 

This insight into Office Communications Server 2007 R2 was created as part of Martin Isaksen’s  participation in the Microsoft Certified Master program.

 

 

The Microsoft Certified Master Program: The Microsoft Certified Master: Microsoft Office Communications Server 2007 program provides the most in-depth and comprehensive training available today for Office Communications Server 2007. This three-week training program is delivered by recognized experts from Microsoft and Microsoft partner organizations.

Learn about new partner applications built on Microsoft Office Communications Server 2007. The Silverlight player features 3 partner applications:

·         Schlumberger’s extension of Petrel, a software program for exploration geophysics, with rich collaboration features including presence, IM, audio/video conferencing and application sharing

·         POST cti’s Live-PA , a virtual personal-assistant that records calls and takes audio notes, without the need for client machine software and hardware recording equipment.  The software operates as a hosted service in the “cloud” or on-premise within the enterprise.

·         Aspect’s integration of Active Directory, Exchange and OCS 2007 its call center application to improve companies’ customer service and sales and collections results while reducing costs.

UC Partner Marketing

There are tens of thousands of people out there developing applications on the Microsoft unified communications developer platform, yet there is little that Microsoft knows about this developer community.

For example, what applications have been developed, what other communications tools besides Microsoft’s Unified Communications, like Microsoft Office Communications Server, Microsoft Office Communicator and Microsoft Exchange have been using, and most importantly, what Microsoft could do to better help the community?

In order to get a better insights Microsoft engaged with Frost and Sullivan, an independent third party, to conduct a Unified Communications Developer survey.

If you are a developer of unified communications applications such as OCS and Communicator, please spare us 15 minutes and fill out this survey:

http://www.globaltestmarket.com/survey/s.phtml?sn=134581&lang=E&secid=9f8cbb

When you click the link you will be directed to a secured site hosted by Frost and Sullivan that will allow you to fill out the survey. Please be sure to enable cookies.

Based on the data collected in the survey, we hope to develop a set of activities to provide better assistance to you in building great enterprise solutions on the Microsoft Unified Communications platform.  We will keep you posted on such activities via this blog.

NOTE:  Frost and Sullivan will keep your individual responses confidential and anonymous.

Thanks for your time!

Albert Kooiman

We are pleased to announce official support for server virtualization for Office Communications Server 2007 R2.

We are introducing support for both a fully distributed virtualized topology across several hypervisors and for a single server virtualized topology. These topologies are supported on Windows Server 2008 Hyper-V and any Server Virtualization Validation Program (SVVP) certified partner solution (http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm).

Presence, Instant Messaging (including remote access, federation, and Public IM Connectivity) and Group Chat workloads are supported. The following server roles can be deployed:

· Front-End Servers

· Back-End SQL Server 2008 64 bits

· Group Chat Channel Servers

· Group Chat Compliance Servers

· Edge Access Servers

The virtual machines must be running on Windows Server 2008 64 bits.  Archiving Server and Monitoring Server (CDR Only) can be connected to a virtualized Enterprise pool, but they must run on a physical server.

The fully virtualized distributed topology has been tested to handle up to 40,000 users, including 10,000 group chat users.

Virtualization of the other workloads is not supported because of possible quality issues with real-time media. Specifically, voice, video, live meeting and desktop sharing workloads cannot be part of the virtualized deployment. Therefore audio/video/web conferencing servers, audio/video/web edge conferencing servers, dial-in conferencing, Communicator Web Access, enterprise voice, or Remote Call Control may not be deployed as part of the virtualized pool. If any one of these workloads is required, a new pool with physical servers must be deployed for those users. For more information about support for client virtualization technologies, please refer to the official support statement at: http://support.microsoft.com/kb/951152.

In order to plan both their physical and virtualized topologies, customers can use Microsoft® Office Communications Server 2007 R2 Capacity Planning Tool, which can simulate user load for the available workloads. This will help customers validating the hypervisor load and scalability before going to production.

Along with this announcement, a whitepaper detailing the tested architecture, performance, use of the Capacity Planning Tool, and a methodology to select a successful architecture can be found at: http://www.microsoft.com/downloads/details.aspx?FamilyID=0a45d921-3b48-44e4-b42b-19704a2b81b0

Jerome Berniere

Problem Description

Microsoft Communicator Mobile Edition 2007 R2 has introduced number of performance improvements over its predecessor related to battery power consumption and over the air bandwidth savings. In the following blog post, we’ll look at the concept of low vs. high fidelity subscription and how it helps in saving battery power in mobile devices and saving over the air traffic.

Let’s first look at the problem with traditional event subscription model. Typically, clients subscribe to an ad hoc list of contacts (buddy list) presence information at the server with non-zero expiration value. The message body of a SIP SUBSCRIBE message lists all the contacts user is subscribing to for their presence information. It conveys to the server that client is interesting in keeping up to date with the real time presence state updates of buddies. Whenever a contact’s presence state change is detected as a result of any part of user’s presence state (user devices’ machine state, calendar state, phone state, or user’s manual state) change publication, all the subscribing users get notified of the updated presence state. Essentially, it generates a notification stream from the server to the client, where every SIP NOTIFY message has to be processed by the client and acknowledged by a SIP 200 OK response.

The Communicator Mobile Edition 2007 RTM followed Office Communicator 2007 RTM/R2 running on laptop/desktop logic of subscribing to the full contact list at start up (of course not subscribing to unexpanded distribution groups in a contact list). The following scenarios prompted to look at possible improvements.

·         Communicator mobile edition runs on devices with small screens where hardly 10 or less contacts of a user’s long buddy list are visible at an instance

·         Over the air bandwidth is costly, especially when users are roaming in a GPRS network, thus notification stream wastes a lot of bandwidth

·         When back light goes off (Windows Mobile devices going into idle state), receiving every single NOTIFY causes device wake up, processing of notification, and then going back to sleep again, while user is not really paying attention to the update. It drains much needed battery power at a faster rate

Solution

It’s evident that a better subscription model is needed to fully optimize battery power and bandwidth usage. Communicator Mobile edition 2007 R2 introduced the concept of low vs. high fidelity subscriptions as described below.

·         Low fidelity subscription refers to performing a fetch/pull subscription, where a contact’s presence state is pulled from the server on an as needed basis. It doesn’t create a long lived subscription on the server, where server keeps on notifying client with an updated state. In a SIP SUBSCRIBE message a pull or fetch subscription carries an Expires value of 0. In this mode, client keep on pulling every 5 minutes, thus potentially a presence state could become stale up to 5 minutes

·         High fidelity subscription refers to a persistent subscription on the server, where a contact’s presence state is continuously synchronized at the client by server sending updated notification whenever contact state is updated. Before expiration of subscription, if user is still logged in, these subscriptions are refreshed with new expiration time

The Communicator Mobile Edition 2007 R2 performs usually low fidelity subscription in most of the scenarios. For example, low fidelity subscription happens for only the visible contacts on the buddy list. To account for a scrolling down/up of a rich buddy list viewing experience, it also subscribes to 3 contacts above and below the currently viewed contacts in the buddy list window. Therefore, it avoids subscribing to a complete buddy list of a user for no good reason and end up wasting bandwidth over the air and processing power on the client.

There’re following scenarios where still high fidelity subscriptions are performed to provide a rich user experience in the Communicator Mobile 2007 R2 client.

·         When a user tags a contact, it creates a high fidelity subscription. Thus, user gets a notification whenever tagged contact becomes available, hence providing real time presence information for tagged contacts

·         When a user opens a contact card of a contact, it again performs high fidelity subscription

·         When a user is in an active conversation with other user(s)

Thus, in above scenarios it makes perfect sense to perform high fidelity subscription for real time presence updates.

When the device goes idle (back light goes off) and user is still signed in to Communicator Mobile Edition 2007 R2, it further optimizes by suspending both low and high fidelity subscriptions, where:

·         Client stops fetching/pulling presence state every 5 minutes for low fidelity subscriptions

·         All high fidelity subscriptions are terminated at the server, therefore server doesn’t keep on sending updated notifications. Only exception is the tagged subscription, which still receives updated notifications to keep user informed of tagged contact’s availability

Therefore, Communicator Mobile Edition 2007 R2 provides rich user experience at the same time consumes much less battery power and over the air bandwidth.

This insight into Office Communications Server 2007 R2 was created as part of Mohammed Vakil’s participation in the Microsoft Certified Master program.

The Microsoft Certified Master Program: The Microsoft Certified Master: Microsoft Office Communications Server 2007 program provides the most in-depth and comprehensive training available today for Office Communications Server 2007. This three-week training program is delivered by recognized experts from Microsoft and Microsoft partner organizations.

DrRez on Twitter is the micro-blogging voice of the Microsoft Insider team (programmers, writers, and field consultants) that produced Microsoft Office Communications Server 2007 R2 Resource Kit and Programming for Unified Communications Using Office Communications Server 2007 R2. DrRez aims to build and support the OCS community on Twitter by evangelizing and broadcasting the latest Office Communications Server information and solutions.

DrRez

April provided a substantial number of updates for the R2 server roles and the first place to start is with this KB - http://support.microsoft.com/kb/968802. The plan of record is to have these available on Microsoft Update during the week of May 12.

UC-RTC Sustained Engineering

There is a new capability in R2 CWA to initiate or join an audio conference.  Here’s how it works.

Vivian is logged onto CWA as a remote user.  Amy and Hao are on her buddy list – they’re both logged onto Communicator either inside or outside the corporation:

Vivian begins with an IM to Amy:

In the resulting IM dialog Vivian has an audio conference option above her presence icon which she now uses to initiate a call.  Vivian is using this IM session to add audio, but alternately she could do this via an existing CWA RDP application sharing session:

To join the conference Vivian can choose her published work number or she can type in another phone number.  If Vivian enters another phone number, OCS will normalize it according to her location profile and if it maps to a PBX or PSTN user it will dial out to her via the mediation server.  If Vivian is also logged on to Tanjay or OC via MPOP she can take the call that way but she must enter a number to initiate the call.

CWA uses the dial out capabilities of the AVMCU to setup this call so it is a little different from a peer-to-peer call.   Vivian selects her work number and the AVMCU calls her work phone (‘Conferencing service is calling you …’):

Vivian’s phone rings and OCS sets up a media stream from the AVMCU to Vivian’s work number.  If this was a PSTN or PBX number the media would flow through the mediation server.  Signaling or control messages for the conference are sent to CWA from Vivian’s front end server where the conference is hosted.  CWA converts the SIP signaling into HTTP which is delivered to the browser.  Logging on the front end shows shows the conference being setup through the Centralized Conferencing Control Protocol or C3P (‘CONTENT-TYPE: application/cccp+xml’).  Specifically we see C3P commands to add a conference and then add Vivian as a user on the AVMCU.  The Focus is the conferencing element on the front end server that handles conferencing setup and maintenance – below we see the C3P AddUser command issued to the Focus:

The highlighted items in the trace show in order from the top the conference ID the focus will reference for the duration of this conference – note this will be the same ID for any associated IM (IMMCU) or application sharing (RDPMCU) in this conference.  The user-agent tag shows CWA is initiating this dialog, the application/cccp+xml indicates the payload of this SIP INVITE is C3P commands over XML and finally we see the <addUser> command in the XML body.

Next we see the Focus initiating a call to Vivian at +14255032002:

Vivian now has the first leg of her conference call established so next the Focus initiates a dial-out to Amy:

This invite is to Amy’s sip: URI not a tel: URI.  If Amy was also logged in via CWA she could choose to divert the incoming audio invite to a phone number.  In this case, Amy is signed onto Communicator and takes the call from her PC:

Vivian and Amy are now on the audio conference together and note Vivian as the conference leader has capabilities to eject Amy from the conference or promote her to leader:

On the CWA server you can also see notifications going through from the Front End and out to Vivian for roster updates; this one is adding Amy as a connected attendee on her roster:

Amy and Vivian’s presence now show ‘In a conference’ since we are making this call happen via conferencing rather than peer-to-peer calling.

It’s easy for Vivian to invite someone else into the conference, here she adds Hao simply by picking him from her buddy list via the Invite control:

Now Vivian, Amy and Hao are on a conference call with both audio/video and IM MCUs servicing the conference.  If Vivian or Amy wanted to add application sharing they could easily do this via the application sharing control adjacent to the audio conferencing control. 

If you want to take a look at how this works in your environment, use OCS Logger to look at the CWA components on your CWA server as well as the MCUInfra, MCUFactory, SIPStack and S4 components on your Front End server.

This insight into Office Communications Server 2007 R2 was created as part of Andrew Sniderman participation in the Microsoft Certified Master program.

The Microsoft Certified Master Program: The Microsoft Certified Master: Microsoft Office Communications Server 2007 program provides the most in-depth and comprehensive training available today for Office Communications Server 2007. This three-week training program is delivered by recognized experts from Microsoft and Microsoft partner organizations.

This article describes the steps taken by Office Communicator to establish a Communicator call between an OC client sitting on a typical home network, connected to the Internet using a NAT router and another OC client placed on the company's internal network. The user initiating the call will be Alice and the data and logs are collected from Alice's computer.

The main problem when establishing a media connection (audio or video) between Alice and Bob is finding a way media can travel through the intermediate network, without being blocked. This is where SDP, ICE, STUN and TURN come into the picture.

SDP

Office Communicator uses SDP (Session Description Protocol) to provide initialization parameters for the media stream in an audio or audio/video session. It is a proposed standard published by IETF in several RFCs (e.g. RFC 4566) and completely based on ASCII, which makes it easy to read.

Although SDP helps initializing media flow between two entities, every client is only describing its own view of the connection. If you ever wondered, what side of the media stream the advertised IP addresses in the SDP blob belong to, remember SDP as the "Self Description Protocol".

ICE

The Interactive Connectivity Establishment (ICE) Extensions protocol is used to establish media flow between two endpoints. In typical deployments, NATs or firewalls might exist between the two endpoints that are intended to communicate. NATs and firewalls are deployed to provide private address space and to "secure" the private networks to which the endpoints belong. This type of deployment blocks incoming traffic. If the endpoint advertises its local interface address, the remote endpoint might not be able to reach it. Advertising the address exposed by the NAT or firewall is not as straightforward, because the endpoints would first need to determine the external routable mapping address created by the NAT (NAT-mapped address) for its local interface address. Moreover, NATs and firewalls exhibit differint behavior in the way they create the NAT-mapped addresses. Section 5 of [IETFDRAFT-STUN-02] provides an overview of NAT types.

ICE provides a mechanism to assist media in traversing NATs without requiring the endpoints to be aware of their network topologies. ICE assists by identifying one or more transport addresses, which the two endpoints can potentially use to communicate and ICE determines which transport address is best for both endpoints to use for their media session.

Provisioning Process During OC Sign-in

Before going into the details of call establishment, I want to explain what is happening during the sign-in of Office Communicator, regarding provisioning of OC with A/V Edge server names and credentials. Here is a brief overview of what is happening on the SIP channel, while starting a Communicator sign-in:

After successfully registering, the OC client asks for in-band provisioning information. This is done in a SIP SUBSCRIBE transaction, asking for Content-Type "application/vnd-microsoft-roaming-provisioning-v2+xml" and requesting "ServerConfiguration".

SIP SUBSCRIBE for Content-Type:application/vnd-microsoft-roaming-provisioning-v2+xml

<provisioningGroupList>

<provisioningGroup name="ServerConfiguration"/>

...

</provisioningGroupList

The OCS Frontend server returns the requested server configuration in a big XML blob. The interesting information for us gets enclosed in the "mrasUri" tag:

SIP 200 OK

<provisionGroupList>

<provisionGroup name="ServerConfiguration">

<mrasUri> sip:avauthentication.contoso.com@contoso.com;gruu;opaque=srvr:MRAS:2jRa2f1gbU</mrasUri>

...

</provisionGroup>

...

</provisionGroupList>

The GRUU in the mrasUri field provides the necessary information on where we can obtain our credentials for the A/V Edge server service. Asking for our credentials is the next step in the provisioning process. You might notice, that Alice requests credentials that are valid for 480 minutes and provide information that she is located on the external network:

SIP SERVICE avauthentication.contoso.com@contoso.com;gruu;opaque=srvr:MRAS:2jRa2f1gbU

<request requestID="128584360" version="2.0" to="sip:avauthentication.contoso.com@contoso.com;gruu;opaque=srvr:MRAS:2jRa2f1gbU" from="sip:alice@contoso.com">

<credentialsRequest credentialsRequestID="128584360">

<identity>sip:alice@contoso.com</identity>

<location>internet</location>

<duration>480</duration>

</credentialsRequest>

</request>

In return, the client gets all necessary information to connect and authenticate against the A/V Edge server for later usage:

SIP 200 OK

<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" requestID="128584360" version="2.0" serverVersion="2.0" to="sip:avauthentication.contoso.com@contoso.com;gruu;opaque=srvr:MRAS:2jRa2f1gbU" from="sip:alice@contoso.com" reasonPhrase="OK" xmlns="http://schemas.microsoft.com/2006/09/sip/mrasp">

<credentialsResponse credentialsRequestID="128584360">

<credentials>

<username>AgAAJAFTru4ByZVFx9H5de8Za9IwTrB=</username>

<password>I+hdiU3UffKdZVxy85tHmkTrx1g=</password>

<duration>480</duration>

</credentials>

<mediaRelayList>

<mediaRelay>

<location>internet</location>

<hostName>avext.contoso.com</hostName>

<udpPort>3478</udpPort>

<tcpPort>443</tcpPort>

</mediaRelay>

</mediaRelayList>

</credentialsResponse>

</response>

Starting a PC2PC Call by obtaining the Candidate List

When Alice initiates the Communicator call to Bob, before sending out any SIP INVITE, OC needs to determine what possible candidates Alice can send to Bob. This is the time for ICE, STUN and TURN and if you want to see more details on what is happening, you will have to use a network sniffing tool of your choice. Two very popular tools are Network Monitor 3 and Wireshark.

The candidate list includes the local list of IP address and port combinations (host candidates), a list of IP address and port combinations allocated by a NAT device (server reflexive candidates) and a list of TURN server IP address and port combinations (relayed candidates).

Here is a typical sequence of packets you can see while obtaining the candidate list. Please keep in mind that connection testing takes place for several different TCP and UDP port numbers. The testing for TCP and UDP candidates is done in parallel, although the following pictures implies that TCP and UDP tests are done in serial order.

The TURN Allocate Response messages from the A/V Edge server include all information Alice needs to determine whether she is sitting behind a NAT device and what IP/Protocol/Port combination to use for all candidates provided in the subsequent SIP/SDP offer.

Converting the XORMappedAddress Field

Here is an example how information for the TURN Allocate Response gets parsed:

The "MappedAddress" field contains the IP address and port combination of the A/V Edge server interface, Bob can use sending media information to.

The XORMappedAddress field contains information about Alice's IP address and port combination from the A/V Edge server's point of view. This field provides the information Alice needs for detecting a NAT device and what her internal IP address and port gets mapped to on the external side.

In its current version, the Network Monitor parser does not convert the XORMappedAddress field and you might want to manually check the content of that field.

To convert the IP address, you have to XOR it with the 32 most significant bits of the TransactionID field:

Converting the XORMappedAddress IP to a hex view:     0x75895AF6 (117.137.90.246)

XOR with the 32 most significant bits of TransactionID:    0x2112A442

                                                                                     0x549BFEB4

Convert to a human readable format:                               84.155.254.180 (NAT-mapped IP address)

Alice's local (private) IP address of 192.168.0.103 gets mapped to 84.155.254.180 through intermediate NAT devices. For the process of obtaining the list of candidates, it does not matter how many NAT devices are between Alice and the A/V Edge server. Only the NAT device closest to the A/V Edge server will be relevant for that process.

To convert the port number, you have to XOR it with the 16 most significant bits of the TransactionID field:

Converting the XORMappedAddress port to a hex view:  0xE263

XOR with the 16 most significant bits of TransactionID:    0x2112

                                                                                     0xC371

Convert to decimal format:                                             50033 (NAT-mapped port number)

You will see those IP addresses and ports later in the SIP/SDP Offer packet, sent to Bob.

Negotiating the Candidate with Bob

Generally speaking, there is a lot of SIP and candidate testing traffic, before the media channel will be established. Here is a high level overview on what is going on when Alice and Bob are both using Office Communicator 2007 R2 clients. In case of MPOP or legacy clients, the following sequence will differ.

As a first step, Alice will send out a "SIP INVITE", including her list of candidates. With Office Communciator R2, Bob will return his list of candidates in the "SIP 183 SESSION PROGRESS". After Alice received the SDP candidate list from Bob, she will start connection testing and build a matrix with possible media channels to Bob (for more details, please check the "ICE Candidate testing" section). The same process happens on Bob's side. Depending on the priority of the possible candidates, Alice will send a single SDP candidate in a second "SIP INVITE" and, as she is the controlling agent, she will ask Bob to use certain candidates from his list for this media session. Bob now has to double check the proposed candidates from Alice and will accept the candidates in his answer packet ("SIP 200 OK").

As both parties agreed on their IP, protocol and port combinations, they will now create the media channels and media information gets transmitted between both parties. Depending on the intermediate network layout, this might be a direct connection (always preferred) or a relayed connection with the A/V Edge as the data relay.

Where to find SDP information in a SIP Message Flow

The "SIP INVITE" contains an SDP block, also called the SDP Offer and provides the list of all candidates Alice identified in the previous ICE tests.

Depending on what OC client version Bob is using, the SDP Answer information can be found in different places:

-       SIP 18x provisional response       only for OC 2007 R2, supporting Early Media

-       SIP OK                                        valid for all OC client versions

MPOP differences

In case Bob is signed in to more than one OC client, you will see several "SIP 183 SESSION PROGRESS" replies. Those replies differ in the "SIP To" header. For every OC Client, you can identify a different "epid" and "tag" field. In addition to that, every MPOP client sends his list of candidates and candidate testing is done for all of them. As soon as the client receives a media packet on one of the candidates protocol/port combinations, the remaining endpoints will be dropped.

Differences with legacy clients

There is no "SIP 183 SESSION PROGRESS" and "SIP PRACK" transaction with legacy OC clients. Bob returns his candidate list with the "SIP 200 OK" and candidate testing starts after that. This is the reason, why the media channel gets established later with OC 2007 than with OC 2007 R2 and an initial greeting from Bob or Alice might get cut off.

OC 2007 R2 Additions

The candidate lists exchanged between two OC 2007 R2 clients, establishing a call between a remote party (on the Internet) and an internal party (on the corporate network) changed between Office Communicator 2007 and Office Communicator 2007 R2. We changed the SDP section, because we had to solve issues with Multiple Points of Presence (MPOP) that were not covered with the previous version of ICE. In addition, we enhanced support for Early Media and added the new modality for Application Sharing. For more details on what changed for media traversal, please check Alan Shens' post at http://www.unifysquare.com/blog/post/OCS-2007-R2-Whate28099s-new-for-Media-Traversal.aspx.

Starting with OCS 2007 R2, you will see two almost similar parts of SDP information in SIP INVITE requests from the new Office Communicator 2007 R2. There have been changes to the ICE negotiation that cannot be used with older versions of OCS. Therefore Office Communicator has to offer two SDP versions during the initial session setup.

The content for legacy clients using ICEv6 (see IETFDRAFT-ICENAT-06) starts with a section, containing the "Content-Disposition" information of "ms-proxy-2007fallback":

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional; ms-proxy-2007fallback

The content for the clients using the new ICEv19 (see IETFDRAFT-ICENAT-19) version starts with the following lines and does NOT include the ms-proxy-2007fallback attribute:

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional

The "ms-proxy-2007fallback" parameter in the "Content-Disposition" header field is used as a hint to the Proxy Server to retry the SIP INVITE with only a single body when a "415 Unsupported Media Type" response is received, indicating the remote User Agent does not accept multipart SDP messages.

You will only see the multipart SDP information in the first SIP INVITE. All subsequent SIP messages containing SDP information will only use the SDP format suitable for the clients involved.

SDP Details

Here is an example for an OC 2007 R2 client running in a private network (behind a NAT device) and using IP 192.168.100.112 on its NIC.

The next lines are from the ICEv6 candidate list:

[---------]:[---------1----------]  2  [-----3------]  [4]  [-5-]  [-------6-----]  [-7-]

a=candidate:uuK9Gym3F0zReasv+FyKCM  1  UwaQkvk5hiWgVg  UDP  0.850  192.168.100.112  50005

a=candidate:uuK9Gym3F0zReasv+FyKCM  2  UwaQkvk5hiWgVg  UDP  0.850  192.168.100.112  50031

a=candidate:9/vLJjcL+aemcsR1AxpVM0  1  6Puckob7qP8GFA  TCP  0.190  213.199.141.181  56909

a=candidate:9/vLJjcL+aemcsR1AxpVM0  2  6Puckob7qP8GFA  TCP  0.190  213.199.141.181  56909

a=candidate:iHdvoVfXm2i2IPGmfO0xa4  1  UbNAQVuHoEoHVA  UDP  0.490  213.199.141.181  52003

a=candidate:iHdvoVfXm2i2IPGmfO0xa4  2  UbNAQVuHoEoHVA  UDP  0.490  213.199.141.181  50126

a=candidate:3ECLhrmJtmDK/j3FY4O5Tw  1  c6zoXvSFIqRfcw  TCP  0.250  171.231.102.218  50025

a=candidate:3ECLhrmJtmDK/j3FY4O5Tw  2  c6zoXvSFIqRfcw  TCP  0.250  171.231.102.218  50025

a=candidate:FKVarEmvn9yEvjD5xahFa0  1  qNTE/3CmryPpGA  UDP  0.550  171.231.102.218  50015

a=candidate:FKVarEmvn9yEvjD5xahFa0  2  qNTE/3CmryPpGA  UDP  0.550  171.231.102.218  50028

1.    This is the hash of a user name

2.    This is an indicator for (S)RTP or (S)RTCP

3.    This is a hash of the user password

4.    The protocol used (UDP or TCP) on this IP and port

5.    This is a weight, indicating which of the candidates is preferred over the others. Higher numbers are preferred over lower numbers, in case a connection can be established to this IP, port and protocol combination. Generally speaking, UDP gets preferred over TCP and local candidates are preferred over NATed candidates (STUN), which are preferred over relayed IP addresses (TURN).

6.    The IP address the second party can connect to

7.    The port number the second party can connect to. If you take a closer look at the port numbers used, you will see, that UDP ports for RTP and RTCP always differ, whereas TCP ports for RTP and RTCP get multiplexed over the same port number.

The following lines are from the ICEv19 candidate list:

[---------]:1 2 [---3--] [----4---] [------5------] [-6-] [---7---] [---------------8---------------]

a=candidate:1 1 UDP      2130706431 192.168.100.112 50036 typ host

a=candidate:1 2 UDP      2130705918 192.168.100.112 50032 typ host

a=candidate:2 1 TCP-PASS    6556159 213.199.141.181 52899 typ relay raddr 213.199.141.181 rport 52899

a=candidate:2 2 TCP-PASS    6556158 213.199.141.181 52899 typ relay raddr 213.199.141.181 rport 52899

a=candidate:3 1 UDP        16648703 213.199.141.181 57309 typ relay raddr 213.199.141.181 rport 57309

a=candidate:3 2 UDP        16648702 213.199.141.181 54054 typ relay raddr 213.199.141.181 rport 54054

a=candidate:4 1 TCP-ACT     7076863 213.199.141.181 52899 typ relay raddr 213.199.141.181 rport 52899

a=candidate:4 2 TCP-ACT     7076350 213.199.141.181 52899 typ relay raddr 213.199.141.181 rport 52899

a=candidate:5 1 TCP-ACT  1684797951 171.231.102.218 50032 typ srflx raddr 192.168.100.112 rport 50032

a=candidate:5 2 TCP-ACT  1684797438 171.231.102.218 50032 typ srflx raddr 192.168.100.112 rport 50032

a=candidate:6 1 UDP      1694234623 171.231.102.218 50033 typ srflx raddr 192.168.100.112 rport 50033

a=candidate:6 2 UDP      1694234110 171.231.102.218 50039 typ srflx raddr 192.168.100.112 rport 50039

1.    The first column after "a=candidate" is called foundation. According to draft-ietf-mmusic-ice-19, the foundation is used to optimize ICE performance in the Frozen algorithm.

2.    This is the component ID, an indicator for (S)RTP or (S)RTCP

3.    This column is describing the protocol used. When the user agents perform address allocations to gather TCP-based candidates, two types of candidates can be obtained. These are active candidates (TCP-ACT) or passive candidates (TCP-PASS). An active candidate is one for which the agent will attempt to open an outbound connection, but will not receive incoming connection requests. A passive candidate is one for which the agent will receive incoming connection attempts, but not attempt a connection.

4.    This is the weight used to prioritize single candidates. Higher numbers are preferred over lower numbers, in case a connection can be established to this IP, port and protocol combination. Each candidate for a media stream must have a unique priority (positive integer up to 2^31-1).

5.    The IP address the second party can connect to.

6.    The port number the second party can connect to. The port for TCP RTP and RTCP gets multiplexed, whereas UDP ports for RTP and RTCP always differ.

7.    This is type information, describing the type of "advertised" address.

          host    This is a local address

          relay   This is the IP address from a relay (TURN) server

          srflx    Server reflexive address is the NATed IP address

8.    IP address and port combination

ICE Candidate Testing

After Alice received Bob's list of candidates, she will start building candidate pairs. The candidate pairs are ordered, based on their corresponding priorities on both sides. This makes sure that both peers are using the same list of candidate pairs in the same order.

In addition to that, the foundation from SDP Offer and Answer gets used to group pairs with similar network conditions. Candidate pairs must have the same protocol type. Mixing TCP and UDP candidates is not allowed. Candidate pairs with the same foundation are ordered by their priority and all, but the candidate pair with the highest priority is set to frozen state. This is mainly for reducing the number of connectivity tests. If, for instance, the connectivity test for the UDP/(S)RTP host candidate fails, it is most likely that the UDP/(S)RTCP candidate for the host will fail too and we will omit this test. If the connectivity test for a candidate pair succeeds, its state gets set to "Succeeded". All other candidate pairs with the same foundation are unfrozen now and will initiate their "STUN Binding Requests" for connectivity checking.

The connectivity testing for each unfrozen candidate pair will be done through a "STUN Binding Request", sent from the local candidates endpoint to the matching remote candidate. These checks are called ordinary checks. As soon as the peer receives a "STUN Binding Request", it responds with the corresponding "STUN Binding Response" and initiates his own "STUN Binding Request" on the same IP/protocol/port combination. This is called a triggered check.

Alice will serve as controlling agent, as she initiated the call. This means that Alice will be responsible for selecting the final candidates for media flow. Bob, as the called user, serves as controlled agent. Bob is responsible to validate the candidates from the final offer. If his list of candidate pairs does not contain the final candidates, the call must fail. If there is a matching candidate pair, Bob will send a final answer to enable media flow.

Here is an example of how the candidate and remote-candidate attributes might look like in a final offer:

a=candidate:3 1 UDP        16648703 213.199.141.181 57309 typ relay raddr 213.199.141.181 rport 57309

a=candidate:3 2 UDP        16648702 213.199.141.181 54054 typ relay raddr 213.199.141.181 rport 54054

a=remote-candidates:1 213.199.141.81 51721 2 213.199.141.81 58975

I hope this explains some of the details while establishing a media session between clients using SDP and ICE.

The Microsoft Certified Master Program: The Microsoft Certified Master: Microsoft Office Communications Server 2007 program provides the most in-depth and comprehensive training available today for Office Communications Server 2007. This three-week training program is delivered by recognized experts from Microsoft and Microsoft partner organizations.

The information listed below has been tested using Microsoft SQL Server 2005 and Microsoft SQL Server 2008.

Office Communications Server 2007 Enterprise Edition R2 supports the use of non default TCP\IP port configurations for network access to its pool configuration databases that are located on the backend SQL server instance. Microsoft SQL Server supports three types of configurations for the Instances that it can host. They are:

Default Instance

The Default Instance is the instance that is installed on the SQL Server that will inherit the host name of the server that SQL Server is installed on. There can only be one Default Instance installation per SQL Server. So any instances that are installed before or after the single Default Instance will have to be a SQL Server Named Instance.

Named Instance

A Named Instance can be installed onto a SQL Server at any time. Microsoft SQL Server can support many Named Instances at one time. Named Instances will use whatever meaningful name that they were given during their installation. For specifics on the number of Named Instances the your version of SQL Server can  support please query the SQL Server Books Online help tool or visit the Microsoft SQL Server website and search its technical listings.

Default Instance\Named Instance

This SQL Server installation includes an installed Default Instance along with one or more Named Instances that are installed on the Microsoft SQL Server. The Default Instance will inherit the host name of the server that Microsoft SQL Server is installed on, and any Named Instance will use whatever meaningful name that they were given during their installation. For specifics on the number of Named Instances the your version of SQL Server can  support please query the SQL Server Books Online help tool or visit the Microsoft SQL Server website and search its technical listings.

The Microsoft SQL Server Default Instance will always use the TCP Port 1433 to listen on with its initial installation. This is the default listening port for the Microsoft SQL Server service when it is installed as a Default Instance. The Default Instance can be configured to listen on a non default TCP\IP port. When configured to listen on a non default TCP\IP port the SQL Server client application will have to specify the non default TCP\IP port in their configuration string e. g. Default Instance,1501. This will allow the SQL Server client application connect to the server that is hosting Microsoft SQL Server by using its host name and specifying the non default TCP\IP port 1501.

The SQL Server Browser service is used by the Microsoft SQL Server to manage the non default port connectivity information for each of the Named Instances that are installed on the Microsoft SQL Server. The Named Instances use a dynamic TCP\IP port configuration by default, but they can have a static non default TCP\IP port configuration manually applied to them. The SQL Server Browser service will manage the TCP\IP port connectivity information for either. Please remember the SQL Server Default Instance does not ever use the SQL Browser service to manage its non default TCP\IP port configuration. The SQL Server Browser service should be enabled to start automatically when a Named Instance is installed on the Microsoft SQL Server. Use the Microsoft SQL Server services.msc to locate the SQL Server Browser service. Make sure that this service is set to start automatically and is started. The SQL Server Bowser service will automatically assign its self to UDP port 1434. Please remember to make sure that UDP port 1434 in unrestricted for bi-directional traffic between the Office Communications Server 2007 Enterprise Edition R2 Pool server and the Microsoft SQL Server back end.

SQL Server Books Online (November 2008)

Using SQL Server Browser

http://msdn.microsoft.com/en-us/library/ms165724(SQL.90).aspx

Listed below are the configuration steps that will allow the Office Communications Server 2007 R2 Enterprise Edition Pool server to access the Microsoft SQL Server Named Instance, Default Instance \ Named Instance configurations. Since the Microsoft SQL Server Default Instance configuration requires the use of a specific configuration string e. g. Default Instance,1501 it is currently not fully applicable with the Office Communications Server 2007 R2 Enterprise Edition Create Pool wizard, so at this time I will not bother to include this non default TCP\IP port configuration for the Microsoft SQL Server Default Instance configuration. For this article I will specify the non default TCP\IP port configuration for the Default Instance\Named Instance Microsoft SQL Server Instance configuration.

The Microsoft SQL Server named instance is installed with the default instance e. g. Default Instance\Named Instance. The steps listed below will also work with the implementation of the Microsoft SQL Server Named Instance configuration.

To begin with you will need to use the SQL Server Configuration Manager on the Microsoft SQL Server that will host the Office Communications Server 2007 R2 Enterprise Edition database collection to make sure that the protocols listed in the Microsoft SQL Server network configuration match each other.

SQL Server Configuration Manager

Protocols for SQL Server

Protocols for Named Instance

SQL Native Client Configuration - Client Protocols

Next the TCP/IP static listening port needs to be set on the Named Instance using the SQL Server Configuration Manager on the Microsoft SQL Server.

SQL Server Network Configuration

Highlight the Protocols for Named Instance node and then locate TCP\IP in the Details pane. Open the TCP\IP properties dialog and click on the IP Addresses tab. Three categories will be listed as IP1, IP2 and IPAll. Replace the 0 in the TCP Dynamic Ports entry with a blank space. Then add your chosen TCP port number to the TCP port entry for all 3 categories. For instance, TCP Port 1501 (as per this example).

Click on the OK button and you will be prompted to restart the Default Instance\Named Instance for the changes to take effect. The SQL Server service for each should restart without an error

From a command prompt on the Microsoft SQL Server box use c:\>netstat -ano followed by c:\>tasklist /svc. This will list the active and listening ports / process IDs on the server along with the process ID / service name. The c:\>netstat -ano output should have an entry similar to the one listed below. The SQL Server process for the Named Instance has a process ID of 2401 and is listening on all interfaces on TCP 1501.

 Proto  Local Address         Foreign Address        State              PID

 TCP    0.0.0.0:1501          0.0.0.0:0                 LISTENING       2401

The c:\>tasklist /svc entry will back end similar to the one listed above

Image Name                   PID Services

========================= ==============================================

sqlservr.exe                2401 MSSQL$NamedInstance

Now we can see that the SQL Server service for the Named Instance is listening on the TCP port that we specified earlier. At this point the SQL Server service for the Named Instance is no longer using a dynamic TCP port to listen for SQL server requests from client applications. Please remember that if the Named Instance is hosting other applications besides the Office Communications Server 2007 R2 databases that this update could cause a break in connectivity for the legacy client applications. This operation should be performed on a Microsoft SQL Server Named Instance that is dedicated to just the Office Communications Server 2007 R2 databases. The benefit of using the static TCP port for the SQL Server Named Instance is that it will allow network administrators the flexibility to choose the TCP ports that they would want their SQL Server Instances to use on their network which hosts the Office Communications Server 2007 Enterprise Edition R2 databases. Please make sure that routing or firewall rules on devices that will help route the IP traffic between the Office Communications Server 2007 R2 Enterprise Edition Pool and the Microsoft SQL Server that will host the Office Communications Server 2007 R2 Enterprise Edition back end databases.

How it works

The SQL Server native client library will query the SQL Server Browser service on the Microsoft SQL Server using an ephemeral source UDP port that has a destination of the listening UDP port 1434 on the Microsoft SQL Server box. The SQL Server browser will respond to the query for the Named Instance SQL Server service listening TCP ports with the requested information. The information in the UDP packet is in clear text and can be read using a network capture tool such as Wireshark or Network Monitor.

Testing non default port connectivity

You can install the Microsoft SQL Server workstation tools on the Office Communications Server 2007 R2 Enterprise Edition consolidated server. Though the SQL Server native library is available with the R2 installation of Office Communications Server 2007, the SQL Server workstation tools allow you to use the GUI SQL Server Configuration Manager along with the SQL Server Management Studio. This combination allows you the availability to test the connectivity between the server that will host Office Communications Server 2007 R2 Server and the SQL Server database installations. When testing is complete you can remove the Microsoft SQL Server workstation tools from the Office Communications Server 2007 R2 Pool server.

Now to test your connectivity prior to installing Office Communications Server 2007 R2 Enterprise Edition you will need to install a Network capture tool on to the Office Communications Server 2007 R2 server to back end and open the SQL Server Management Studio. Using the SQL Server 2007 Management Studio you will connect to your Default Instance\Named Instance while taking a network capture to confirm that you are connecting to the Microsoft SQL Server using port TCP 1501 (as per the example).

1. Start the network capture

2. In SQL Server Management Studio choose Connect \ Database Engine from the pull down menu

3. Enter your Default Instance\Named Instance

4. Click on Connect. You will back end able to browse the SQL server system databases in the Object Explorer. You will not back end able to view the contents of the system tables though - they are read only.

5. Stop your network capture and view the TCP traffic to the IP address of the SQL Server. Notice that your designated TCP\IP port is back ending used.

Now you are ready to:

·         Create the Office Communications Server 2007 Enterprise Edition R2 pool from the Office Communications Server 2007 R2 server and configure the Pool

·         Add the Server to the Pool

·         Create and apply the certificates to the Office Communications Server 2007 R2 pool server

·         Start the Office Communications Server 2007 Enterprise Edition R2 services

While performing the steps listed above you can take a network capture at each step so you can view the TCP traffic between the non default port on the Microsoft SQL Server backend server and Office Communications Server 2007 R2 Enterprise Edition pool server. This will allow you to confirm that the non default port configuration for the Default Instance\Named Instance is working as expected. Also, if you want you can filter the network capture for the UDP port 1434 traffic. Inspecting these packets will let you see the SQL Server instance TCP port configuration that is passed back to the Office Communications Server 2007 R2 Enterprise Edition server.

Upon completion of the install remember to reboot the Office Communications Server 2007 R2 Enterprise Edition Pool server to make sure that all the services start without an issue.

Mike Adkins

This is an update to a post I made about a year ago to help you choose the AD store OCS uses for global settings. 

Quick note on terminology

Active Directory has three stores often referred to as Naming Contexts –Schema, Domain and Configuration.  The Schema and Configuration Naming Contexts are replicated to every domain controller in the Forest.  The Domain Naming Context is replicated only to its Domain Controllers.  In OCS documentation we typically refer to the Domain Naming Context as the System container in the root domain and the Configuration Naming Context as the Configuration Partition.  Given this you can see that for a single Domain Forest this topic has no relevance to you and you should move on to a more interesting blog post J

LCS stored its configuration in the Domain Naming Context or System Container.  OCS 2007 added a choice to use the Configuration Naming Context or Configuration Partition.  OCS 2007 R2 defaults to the Configuration Partition.  We made this change in R2 to insure your OCS servers always have access to their configuration information and we have provided a script to move from the System container if you would like to do this.  This gives you the capability in case you already have installed LCS or OCS configuration in the System container, to move it to the Configuration partition before you install R2.

Here’s an updated decision tree reflecting the R2 default preference of the Configuration Partition:

If you’re considering running the migration script to switch from the system container to the configuration partition think about the following:

1.    You can only do this before you run any setup activities for R2 (notably Prep Schema)

2.    You must stop all OCS and LCS services in the forest for the duration

3.    No LCS 2005 SP1 servers can be added to the Forest after the move

4.    You’ll need to re-run Prep Forest for OCS to apply permissions

5.    You’ll need to re-run Prep Domain for LCS to apply perms

6.    You’ll need to wait for Active Directory replication so depending on the size of your Forest and AD convergence time you may sustain a significant outage.

You can download the migration script along with a how-to document here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=23236784-508e-44c9-809d-30ff245928d8&DisplayLang=en

Rick Varvel, a Microsoft Principal Consultant has just started his blog and his first post is fantastic. Here is the link to his post -

http://blogs.technet.com/rickva/archive/2009/04/03/Configuring-A_2F00_V-Edge-Service-for-NAT.aspx

OCS Team

Administrators, users and troubleshooters value the possibility in Outlook 2007 to get status about the connections: by holding the ctrl key while right clicking the Outlook icon in the notification area and choosing “Connection Status” (see also http://office.microsoft.com/en-us/outlook/HP010363941033.aspx).

With the new R2 version of the client, Microsoft introduces a similar dialog for Office Communicator 2007 R2. Hold Ctrl while right clicking the OC 2007 R2 icon in the notification area, choose “Configuration Information…” and it will open the following screen: