From [...]]]> The ability to transfer files in Office Communicator is an effective collaboration feature (and is often underused). A file can be shared in the context of a discussion by dragging-and-dropping it directly in the Communicator conversation session window. It is real time, and you avoid the storage headaches and application-context-switch that email attachments can bring.

From experience here the facts that matter most about file transfers and solutions to some common problems.

 Key Facts

1. The actual data transfer in a file transfer is peer-to-peer. Several SIP transactions are used to setup the session with the OCS server, but the data transfer is then carried out peer-to-peer between the Communicator clients. One exception to this rule is when Microsoft ForeFront Security for Office Communications Server is installed on the OCS server. In this case, all communication goes through the OCS server.
2. Ports 6891-6901 are used on the client machines to transfer the files. A random port is chosen between 6891 and 6900 (6891 us used to advertise the randomly chosen port).
3. File Transfers across a firewall is not supported in OCS 2007 R2.  See the post “Communicator File Transfers Across a Firewall Are Not Supported” for more information.
4. File transfers between internal users (i.e. clients inside the firewall) do not involve the Edge server.
5. The protocol used to do the transfer is TFTP (Trivial File Transfer Protocol).

Common Problems & Solutions

The best diagnostic to a failed file transfer between two Communicator clients is the usually the error message returned directly in the Communicator client. Here are the most likely reasons for a file transfer failure and what to do about it:

1) Is the File Transfer Going Across a Firewall?  For example, if one Communicator client is inside a corporate firewall, and another is logged in externally through the OCS Edge Access role (with no VPN), attempting to transfer a file will fail. This is not a supported scenario in OCS 2007 R2. See the post “Communicator File Transfers Across a Firewall Are Not Supported” for more information.

2) Ensure that File Transferring is Enabled on the OCS server and Check which File Extensions it is Configured to Block.

By default OCS installs with the Intelligent IM Filter activated. You can then configure it to block or allow certain file extensions. By default .zip, .doc, and .xml are allowed, but executable binaries and script extensions are blocked. To see this setting in the OCS management console, navigate to:

• OCS 2007 R2: Front-End or Pool | Filtering Tools | Intelligent Instant Message Filter | File Transfer Filter tab.
• OCS 2007: Front-End or Pool | Application Properties | Intelligent Instant Message Filter | File Transfer tab.

3) Is Either Client Running VMWare Workstation?

If a user has VMware Workstation installed (not just running) on their client machine, Office Communicator file transfers tend to fail. If you disable the extra NICs that VMware creates in your Network Connections folder they should be able to send and receive successfully (thanks to Tom Pacyk for that nugget of information which I have verified as true). Basically the extra network adapters that VMware Workstation or VMWare Server Console create cause Communicator trouble when it is trying to figure out which network adapter is best to use for the file transfer.

4) Is there Network Access Between the Two Client Machines?

A variety of network architectures or DNS settings can prevent two machines from seeing or accessing each other on the network. A simple ping or attempted access to a network share will let you know whether this is an issue.

5) Is any Anti-Virus or Firewall Software Restricting Ports 6891-6901 on either Communicator Client?

Client-side port filtering or intercepting on either client will cause a failure. The most likely candidates for this is anti-virus software or firewall software.

6) Are File Transfers Explicitly Disabled on either Client Machine via Group Policy?

File transfers can be disabled through a Group Policy setting (or registry setting). The setting is documented in the Microsoft Office Communications Server 2007 R2 Client Group Policy Documentation.

7) Are ports 6891-6901 Accessible on any OCS Servers with Forefront Security for OCS Installed on it?

Forefront Security for OCS  can be used to scan Communicator file transfers for viruses. For external file transfers, the firewall needs to be configured to allow inbound connections for the default Communicator file transfer ports. These default ports can be changed via registry keys. See Introduction to Forefront Security for Office Communications Server for more information.

Are the Communicator Clients Up-To-Date?

Communicator clients with the latest updates minimize the chances of a known issue causing a problem.

Read more about the April 2010 updates here: http://blog.insideocs.com/2010/04/15/april-2010-updates-for-communicator-2007-r2-and-live-meeting/.

If all else fails, enabling event logging in the Communicator client  (Options | General | Turn on Logging in Communicator) and checking the event logs after a failed file transfer is usually helpful.  If you want to try to debug the actual file transfer SIP session, a great article on digging deeper into that is available here: A deep dive into the Office Communicator 2007 R2 file transfer process.

You can choose to manually enter your Edge Access hostname and port (normally 443), or by using auto-discovery (via DNS records). The auto-discovery option is good because it inherently [...]]]> Microsoft has recently made available a Beta version of a web tool that can be used to test the external connectivty of your OCS Edge deployment: https://www.testocsconnectivity.com/.

You can choose to manually enter your Edge Access hostname and port (normally 443), or by using auto-discovery (via DNS records). The auto-discovery option is good because it inherently tests that the correct external DNS entries exists which allow remote clients to automatically logon.

You need to provide a valid SIP user and password to the test the external SIP login through the Edge. Testing the complete login process is beneficial because the SSL Certificate configuration is validated.

Here is the results of a sample test run (domains and user details ommitted):

Attempting to Resolve the host name lcs.example.com in DNS.
Host successfully Resolved
Additional Details: IP(s) returned: xxx.xxx.xxx.xx

Testing TCP Port 443 on host lcs.example.com to ensure it is listening/open.
The port was opened successfully.

Testing SSLCertificate for validity.
The certificate passed all validation requirements.validation checks.
Additional Details: Subject: CN=lcs.example.com, OU=example, O=”Example, Inc.”, L=Example City, S=Example State, C=Example country, Issuer CN=<Certificate Authority>, OU=<CA URL>, O=<CA Organization Name>, C=<CA Country>

Testing OCS remote sign in through Access Edge Server: Port Number (lcs.example.com:443), for SignInAddress (exampe_user@example.com).
The specified user successfully signed in remotely through the Access Edge Server.
Additional Details:  Registration is successfully completed.

In the last few years, several options have been made available for [...]]]> Offering software as a service (aka SaaS, “in the cloud”, or “Software+Services” as Microsoft calls it) has started to gain real traction, and the benefits and potential issues are well documented (i.e. lower initial and on-going costs, and a pay-as-you-go subscription based cost model).

In the last few years, several options have been made available for service providers to offer OCS as a service that is consumed by on-premise clients (e.g. Office Communicator). Below I recap the 3 major flavors available today for on-line OCS:

1) Hosted – Dedicated

• A complete OCS deployment is available in a third-party hosted data center for the exclusive use of the consumer (i.e. a company or organization).
• This is similar to an on-premise OCS deployment, but OCS lives on-line outside the company firewall in a hosted data center.
• This model doesn’t typically scale well for the hosting provider because dedicated OCS deployments for each customer is costly.
• A dedicated offering usually offers better service for the consumer because the entire deployment is dedicated to their usage.
• Dedicated offerings typically require a minimum number of users to justify the cost to the provider. 

2) Hosted – Shared (Multi-Tenant Offering)

• A shared, or multi-tenant, hosted offering partitions one hosted OCS deployment (along with its dependencies such as Active Directory), into distinct client organizations (e.g. tenants), such that each tenant can be used and licensed to a specific consumer (company). OCS still lives on-line outside of the company firewall, and for the most part appears the same as a dedicated offering to the on-premise clients.
• Microsoft multi-tenant offerings are build on Microsoft’s Hosted Messaging and Collaboration (HMC). HMC includes a separate Provisioning Framework (MPS) and application specific API’s for managing and provisioning hosted Microsoft applications. Details on the Hosted Office Communications Server Namespace API can be found here.
• The current shipping version of HMC is 4.5, is the first version to offer support for OCS 2007, including Live Meeting audio and video conferencing. It also includes the ability to offer support for Exchange Server 2007 SP1 and Windows SharePoint Services 3.0 SP1.
• OCS with HMC 4.5 cannot provide any QoE data, so your hosted provider will not be able to provide that.

A quick Google search for Microsoft Office Communications Server hosted solutions will give you a feel for OCS hosted service levels and costs.

3) Microsoft Business Productivity Online (BPO)

Microsoft has recently begun offering both dedicated and shared on-line OCS offerings. These are similar to #1 and #2 above, except Microsoft is the hosted provider. You can purchase the service through a re-seller Service Provider, or through Microsoft directly.

a) Microsoft BPO Standard Suite

• Provides shared hosted Exchange, SharePoint, Live Meeting and OCS.
• The latest version of the Standard BPO Suite is 9.1, and it offers Exchange Online, SharePoint Online, Office Live Meeting, and OCS Online.
• Currently this is offered for $15 USD per user, per month.
• Microsoft standard BPO offering today does not include any OCS audio or video features. The primary features are Instant Messaging and Presence.  Support for audio and video will likely be added in the future. The Standard offering does include the hosted Live Meeting functionality however, which including audio and video for Web conferences.

b) Microsoft BPO Dedicated

• Identical to the dedicated hosted description above, except that OCS is hosted in one of the Microsoft’s worldwide data centers. Directory synchronization is available from the on-premise Active Directory which enables a single sign-on capability.
• You require a minimum of 5,000 enrolled users.
• Peer-to-peer audio and video is available. Optional services include Federation, PIC, Content Archiving and Web Access.

Although a hosted OCS solution looks appealing, there are still issues of compliance, content archiving, security, and service level agreements which are organization specific. If you are considering moving to this model, be sure to cover those potential issues beforehand.

1. At a minimum, 2 NIC’s are required (one internal and one external). Unless you are a TCP/IP expert, trying to configure TCP/IP for both internal [...]]]> There is plenty of information available about configuring the 3 OCS Edge Roles (Access, A/V, and Web Conference), however many common problems arise from not adhering to 4 key requirements.

1. At a minimum, 2 NIC’s are required (one internal and one external). Unless you are a TCP/IP expert, trying to configure TCP/IP for both internal and external traffic on one NIC will introduce problems. Some network cards with multiple ports expose multiple separate interfaces – these are supported as long as they are seen as separate interfaces on the network).

a. If you are deploying just the Access Edge role (for PIC or Federation), one NIC with multiple IP addresses (for internal and external) in a different IP subnetwork apparently works (but I have never verified this).

b. Any internal and external network routes need to be on separate IP subnetworks.

2. The Edge A/V must have a Publicly Routable IP address (this means the NIC must be directly connected to the Internet, or your firewall must have the ability to directly route public IP addresses through it – i.e. dedicated ports to route IP addresses). The Edge Access and Web Conferencing can have IP addresses behind a NAT.

3. You require a separate IP address for each Edge Role (each IP can be homed on a separate NIC or multi-homed on one NIC if all external IP address are on a separate IP subnetwork – see next point).

4. It is typical to deploy a consolidated Edge (with all 3 Edge roles collocated) and 2 NIC cards. This is a supported configuration but a key requirement is that all external IP addresses must on a separate public IP subnetwork.

There are a various combinations of NIC’s bound to IP address and subnets that may or may not work, but if your deployment adheres to the above 4 configurations, your Edge deployment will be supported and will save yourself a lot of potential trouble.

Excellent Resources

Designing Your Perimeter Network for Office Communications Server 2007 White Paper

Office Communications Server 2007 Document: Edge Server Deployment Guide

Jeff Schertz has several excellent blog postings on this subject:

• OCS Edge Server Requires Separate Internal and External Interfaces
• Clarification on OCS Edge Interface Support
• OCS Edge Server Configuration Topologies

The tool generates 6 reports that are useful for a current Edge server deployment, or in the planning stage for deploying an Edge server.

You can read more about the tool here. You can download the tool here.

The answer depends on which Edge functionality (and the associated Edge Role), being exposed to the Internet.  Below is a concise recap of the default Ports that need to be opened to expose specific [...]]]> The first question often asked when exposing OCS functionality to the Internet is “what ports do I need to open on my firewall?”.

The answer depends on which Edge functionality (and the associated Edge Role), being exposed to the Internet.  Below is a concise recap of the default Ports that need to be opened to expose specific OCS functionality to external users (on the Internet).

Step 2.3 in the Office Communications Server 2007 Edge Server Deployment Guide as more details.

If you are deploying the Communicator Web Access 2007 R2 role and want remote Desktop Sharing, port 49152 through 65535 must also be open (http://blog.insideocs.com/2009/11/10/communicator-web-access-top-10/).

This Microsoft TechNet article provides a handy summary of the ports and protocols used by the OCS 2007 R2 and the Clients.