If you have previously established direct federation connections between OCS and many federated partners that you explicitly allow, the thought of having to manually re-enter these federation settings [...]]]> During the edge migration stage of an OCS to Lync migration, you will likely need to re-establish existing OCS federated partner settings on the new Lync Edge pool.

If you have previously established direct federation connections between OCS and many federated partners that you explicitly allow, the thought of having to manually re-enter these federation settings in Lync isn’t very appealing.

Whenever a lot of manual administration is required, PowerShell comes to mind. Indeed, in this case it can be used to ease the pain of having to manually retype the federated partner domain, and optionally, the associated edge server FQDN.

In this post I provide a small PowerShell script that you can run on your OCS 2007 R2 Edge server that can be used to export your existing federated partner settings in the format of another PowerShell script that can be run to re-import those settings into Lync.

Caveat – your existing OCS partner federation settings could differ slightly. It is important to understand what this script is doing (it is straightforward) and tweak it to your configuration.

The following script runs on the OCS 2007 R2 edge and utilizes WMI – specifically the OCS 2007 R2 MSFT_SIPFederationPartnerTable class – to export a list of the federated partner domains:

Get-WmiObject -class MSFT_SIPFederationPartnerTable | ForEach-Object

{

   $domain = [System.String]$_.Domain

   $edgeProxy = [System.String]$_.EdgeProxyAddress

   if ($edgeProxy -eq "")

   {

      write-output "New-CsAllowedDomain -Identity `"$domain`" -MarkForMonitoring `$True"

   }

   else

   {

       write-output "New-CsAllowedDomain -Identity `"$domain`" -ProxyFqdn `"$edgeProxy`" -MarkForMonitoring `$True"

   }

}

Save the above script to a PowerShell .ps1 file (e.g. EdgeFed.ps1). To run it in Powershell you will likely first need to set the ExecutionPolicy to allow scripts to run:

> Set-ExecutionPolicy Unrestricted

Invoking this script on the OCS Edge server (e.g. run “.\EdgeFed.ps1” in a PowerShell command window) will produce output similar to the following:

New-CsAllowedDomain -Identity "contoso.com" -MarkForMonitoring $True

New-CsAllowedDomain -Identity "fabrikam.com" -ProxyFqdn "im.fabrikam.com" -MarkForMonitoring $True

.

.

The script exports each federated partner setting and formats it into a Lync PowerShell “New-CsAllowedDomain” cmdlet which will add the partner as a new allowed federated domain in Lync.

Pipe the output of this script to another .ps1 file that can used on your Lync Edge (i.e. run “.\EdgeFed.ps1 > LyncFedSettings.ps1”).

To import the allowed federated partners into Lync, put the output file (e.g. LyncFedSettings.ps1) on your Lync Front-End or Edge server and run it in the Lync Management Shell.

You can see the new federated partner allow list with the Get-CsAllowedDomain cmdlet, or in the Lync Control Panel (External User Access | Federated Domains).

If your OCS federated partner settings differ from the explicit allow list method, and you need an automated solution, take a look at the WMI Classes for Office Communications Server. There is probably a WMI class that exposes these settings and can be scripted, and you can just modify the script above.

Addition OCS to Lync Migration Articles

• Microsoft TechNet – Migration from Office Communications Server 2007 R2 to Lync Server 2010
• InsideOCS – Lync & OCS Migration Top 10
• InsideOCS – Quick Tip – External Contacts with Lync Coexistence

Everything worked as planned except the [...]]]> I was involved in a recent Lync migration where a new Lync pool was deployed side-by-side with an OCS 2007 R2 pool. Several pilot users were moved to the new Lync pool and the OCS 2007 R2 edge server was still being used for external Lync and OCS user services.

Everything worked as planned except the Lync users on the new Lync pool were getting the infamous “Presence Unknown” for both Public IM (PIC) contacts and their Federated Contacts.

All the basics were checked – connectivity between the new Lync pool and the OCS 2007 R2 edge, certificates, etc…, and everything looked okay.

What solved the problem in the end was rebooting the OCS 2007 R2 edge server.  After the OCS edge server was rebooted, all of the PIC and Federated contacts for the new Lync pool users started to work.  I am not sure exactly what effect rebooting the edge had, but wanted to pass it along in case it helped someone else.

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

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

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

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

1) “Allow automatic discovery of federated partners”.

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

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

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

References

• Microsoft TechNet Microsoft Office Communications Server 2007 R2 Configure Federation

Functionality Available for Communication with Public IM Contacts

A reminder that communication with Public IM [...]]]> OCS and Communicator have the ability to communicate with the Public IM contacts – specifically users on MSN (now Windows Live), AOL, and Yahoo!. There are a few known issues and limitations that I wanted to recap for the benefit of others.

Functionality Available for Communication with Public IM Contacts

A reminder that communication with Public IM Connectivity (PIC) contacts today is limited to peer-to-peer (no multi-party), and Instant Messaging and Presence information only – no audio, video, desktop sharing, or file sharing (see Known issues that occur with public instant messaging and Communications Server for more information).

Special Format to Use when Adding an MSN Contact that has a Non-MSN Domain

When a Communicator user is adding an MSN contact with a non-MSN domain, the user needs to add the contact using the special format: user_name(domain.com)@msn.com. See “Communicate with MSN, AOL and Yahoo! users” for more information.

Issue with the ‘Add Contact’ Wizard when Adding an MSN Contact with a non-MSN Domain

There is an issue in the Office Communicator client such that when a user attempts to use the “Add Contact” Wizard to add an MSN Messenger contact who has a non-MSN domain, they receive an “Address is not valid” error:

The workaround is to use the Communicator contact Search text box to add the contact.

Other Public IM Usage Reminders

• If you do not add your public IM contact to your Contacts list, the contact’s presence status is always displayed as Status Unknown.
• More Public IM Connectivity issues are described in Microsoft KB article 897567: Known issues that occur with public instant Known issues that occur with public instant messaging and Communications Server.

Lastly, recently Additional Windows Live Messenger PIC/Federation IP Addresses (as reported on the Microsoft OCS team blog) have been added to increase federation capacity. You should read the above blog entry if your organization federates with MSN via specific IP addresses.

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.

Another good resource is this TechNet article: Why Are My Users Unable to Use Communicator 2007 R2 to Transfer Files?

November 2011 Update: Microsoft has publicly announced and is still on track to release a Lync client for the iOS (iPhone/iPad), Android, [...]]]> December 2011 Update: Microsoft has released the server-side components and accompanying documentation for the new Lync mobility clients that will be available shortly. See Lync 2010 Mobility Service and Documentation Available for more information.

November 2011 Update: Microsoft has publicly announced and is still on track to release a Lync client for the iOS (iPhone/iPad), Android, and other smartphone’s by year end 2011.

November 2010 Update:  Microsoft announced at the Lync Launch event that a Lync client for the iPhone will be available within the next year.

Several readers of my blog have asked about the availability of an OCS client for the iPhone. I recently tried iDialog from Modality Systems (http://www.modalitysystems.com/idialog/) and wanted to share my experience. iDialog is an iPhone (and iTouch) application providing OCS contact list presence information and 2-party instant messaging (see here for the full list of features including the ability to search the corporate GAL).

In general, it worked as advertised, and I love getting OCS presence on my iPhone! In addition to seeing Presence and IM, it is useful to see current free-busy information for several of my contacts (e.g. “Free for the next 2 hours”) and having access to GAL details.

There were some minor nuisances such as initially having to manually expand the “All Contacts” group to see my contacts, and a periodic small delay when typing in an IM session.

Here are some other key notes:

1. There is no ability to do VoIP audio calls (aka Communicator calls). I didn’t really miss this though because I am on a mobile device and can call through the cellular network. I could see some users wanting to take advantage of a WiFi connection and do a VoIP call though.
2. It works for OCS 2007 and OCS 2007 R2 (corporate and hosted) via the OCS Communicator Web Access server, so an external facing OCS 2007 CWA must be available for it to work.
3. Given that presence can be a chatty protocol, one of the first questions I had was “How much data does it use?”. Modality Systems told me that approximately 1.2 kpbs is used over a 5 minute interval of “normal” usage. This is not broken down into presence and IM, but it gives a ballpark approximation.
4. It does not support running in the background, so having persistent chat’s while you do other things on your iPhone is an issue.

iDialog can be purchased via the Apple iTunes Application Store. I purchased mine for $9.99 Cdn (from the Canadian App Store). I have been told that an update is coming shortly which address some outstanding issues (including the IM typing delay).

All-in-all it was an iPhone application worth purchasing but I would like to try a couple of other options to get the run-in-the-background functionality.

You can read more about OCS mobility options in my “Mobile Options for OCS” blog post.

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.