REMINDER: AOL Federation Changes

WHEN AND WHAT? –

On June 30 2014, Lync’s IM connectivity to AIM though Microsoft’s current service will no longer be available.

WHAT TO DO? –

Between now and June 30, 2014, you do not need to do anything to continue to support federated communications between your organization and AIM.

For customers requiring connectivity between Lync and AIM beyond June 2014 or your organization requires provisioning for additional domains in the interim, a substitute service is available directly from AOL. For more information on this, see AOL’s dedicated site: http://aimenterprise.aol.com/pic.php.

Lync for Mac 14.0.9 Released!

One for the Mac users out there:

Here are some of the issues addressed within 14.0.9 (Please read the release KB for more information):

  • E-911 support implemented
  • Location Awareness (LIS server for location) implemented
  • Substantial improvement in Desktop Sharing (~10x throughput improvement)
  • Ability to select video camera for calls (can change camera while in a      call/meeting)
  • Bug fixes:
    • Warn users that contact list can’t be edited for UCS contacts
    • File transfer now works in all scenarios
    • Audio stutter fix when using 44100 sampling rate devices
    • Fix QOE blob so that QOE metrics are captured correctly at server
    • Bridge ACP calls so that Lync for Mac meeting experience will see ACP users in roster
    • Anonymous join now works
    • Top few Watson crashes fixed
    • CVC version now has consistent numbering in Lync for Mac

Check out the Office Blog for more information!

Lync Backup Service Cmdlets fail to run

I have recently been supporting a fault that a friend of mine (new to Lync) was experiencing in his lab environment but thought it would be a useful blog post!

The configuration was as follows;

  • 1x Lync Server 2013 Standard Edition, deployed on host 1 – LYNCSE01.domain.local
  • 1x Lync Server 2013 Standard Edition, deployed on host 2 – LYNCSE02.domain.local
  • 1x Office Web Apps, associated with both of the aforementioned pools – OWA01.domain.local
  • Clients homed on each pool connected successfully and consuming all communication modalities

The next step in his environment was for Pool Pairing to be configured, which is a great new addition to Lync Server 2013.

The topology can be see below, published successfully:

 Untitled

The next steps, as per the post installation ‘to do list’ were to:

Update Lync Server with the changes defined in the topology by running local Setup on each server in the following list.
Server FQDN: LYNCSE01.domain.local, Pool FQDN: LYNCSE01.domain.local
Server FQDN: LYNCSE02.domain.local, Pool FQDN: LYNCSE02.domain.local

Run the Invoke-CsBackupServiceSync cmdlet to ensure conferencing data is replicated.
PoolFqdn LYNCSE01.domain.local

Invoke-CsBackupServiceSync –PoolFqdn LYNCSE01.domain.local

PoolFqdn LYNCSE02.domain.local

Invoke-CsBackupServiceSync –PoolFqdn LYNCSE02.domain.local

Setup was ran on both standard edition servers, no errors there – but when it came to running the command ‘Invoke-CsBackupSyncService’, the following error was presented

pairedpools_backupcmdletfail1

Once quick look at the services running on the machine would identify the problem, the LyncServerBackupService  was not running. Starting this allowed the command to be run:

pairedpools_backupcmdletfail6

Next up, confirming the status of the pool pair. Running the command ‘Get-CsBackupServiceStatus -PoolFQDN LYNCSE01.domain.local’ now presented a new error:

You don’t have required permission to perform Windows Communication Foundation (WCF) call to backup service instance on computer

One key point to remember, that is often overlook, is to always check the ‘to do list’ following topology changes being published. If this had been done, the account being used to deploy Lync would have been a member of RTCUniversalServerAdmins (this is also identified as a requirement when running Get-CsBackupServiceconfiguration (see below))

pairedpools_backupcmdletfail

Once added to the RTCUniversalServerAdminsGroup, the cmlets were successful ran, and the ready state was output!

pairedpools_backupcmdletfail3

pairedpools_backupcmdletfail4

Citrix VDI Now Supported, Lync 2013

There has been a very (welcomed) recent addition to the Microsoft Open Interoperability Program, in particular, the ‘Infrastructure’ section.

Citrix VDI is now supported by Microsoft (and Citrix) in a Lync 2013 environment!

http://technet.microsoft.com/en-us/lync/gg131938

Citrix VDI now listed and supported by Microsoft

Citrix VDI now listed and supported by Microsoft

I have many clients that have held back on Lync due to the lack of Microsoft support for Citrix deployments, so this is definitely been an overdue requirement.

Lync 2010 Client now supported in LyncOnline

Microsoft has recently updated it’s client support for Lync Online, which now includes the Lync 2010 Windows Client. This is a significant piece of Information, particularly for migration scenarios and the client rollout process. A lot of demand has been made within the community for this, so I’m sure it will be very much welcomed!

Client Requirements

Microsoft Lync 2010 desktop client must be version 4.0.7577.4419 (or later) released in January 2014, as described here: http://support.microsoft.com/kb/2912208.

Microsoft Federation Edge Changes

I recently received information that I thought would be useful to share with the community, also in attempt to prevent a lot of support threads asking why federation is no longer working with Microsoft! 🙂

“The federated edge server that supports Instant Messaging and conferencing with external companies will be migrated on Friday, May 9, 2014.

After the server migration, the IP address for the sipfed.microsoft.com SIP domain will change to 131.107.255.86. External companies who are federated with Microsoft may need to make changes to their infrastructure outlined under Instructions below in order for the federation to continue to function successfully.”

SUMMARY

Customers that originally configured their federation route with Microsoft to use an IP address will have to modify that entry and possibly firewall rules to ensure communications continue successfully.

INSTRUCTIONS

Depending on how their infrastructure is configured, they may need to make one of the following changes:

  1. Companies configured as direct federations using IP address (not sipfed.microsoft.com) will need to update their configuration to the new IP address.
  2. Companies using their firewall(s) to filter by IP address will need to update their Access Control List (ACL) to the new IP address

Note: External companies that are configured as an Enhanced federation and have configured their firewall(s) to Allow All (inbound and outbound) on TCP:5061 according to Microsoft’s recommendations will not need to make any changes.