Skype for Business 2015 Migration Step by Step

If you want to upgrade to Skype for Business Server 2015, and don't have a purely Lync Server 2013 environment, you will have to follow the migration path. The recommended path is to migrate from OCS or Lync Server 2010 to Lync Server 2013, then complete an in-place upgrade.

If you already have a purely Lync Server 2013 environment, you can skip straight to an in-place upgrade.

See the following links for more information on the other deployment options:

• Skype for Business Deployment Step by Step (Greenfield Deployment)
• Skype for Business In-Place Upgrade Step by Step

To learn how to migrate to Lync Server 2013 see the following links:

• Step by Step Deployment and Migration of Lync Server 2013
• Lync 2013 RTM migration from Lync 2010 Step by Step - Part 1 | Part 2
• Migration to Lync 2013 (Technet)

Lync 2013 Deployment and Migration Step by Step

This is a step by step guide to assist those new to Lync in deploying an Enterprise or Standard Edition topology (its still a draft at the moment).

Hardware Prerequisites

Microsoft recommends the following minimum requirements for Front End Servers, Back End Servers, Standard Edition Servers, Persistent Chat Servers, and Persistent Chat Store and Persistent Chat Compliance Store (Back End Server Roles for Persistent Chat Server):

• Dual CPU with 6 Cores, 2.26GHz
• 32Gb Ram
• 72Gb Disk Space
• 1GHz Network adapter

For Edge Servers, Standalone Mediation Servers, and Directors Microsoft's recommendations are slightly less:

• Dual CPU with 4 Cores, 2GHz
• 16Gb Ram
• 72Gb Disk Space
• 1GHz Network adapter

In reality these can be much less depending on the number of users and activity. To give you an example for a deployment of 500 users, a Lync Front End will happily run as follows:

• Single CPU with 4 Cores, 2.26GHz
• 12Gb Ram
• 72Gb Disk Space
• 1GHz Network adapter

Software Prerequisites

Before you get started you will need to decide on and operating system and install some prerequisits. Lync 2013 is supported on Server 2008R2, 2012, and recently 2012R2 with the October 2013 cumulative update.

To make your life easier you can use Pat Richards prerequisites script for Server 2012 and 2012R2 - http://www.ehloworld.com/1697

Server 2008R2

• Apply all Windows Updates
• Microsoft .NET Framework 4.5 - http://go.microsoft.com/fwlink/p/?LinkId=268529
• Windows PowerShell 3.0 - http://www.microsoft.com/en-us/download/details.aspx?id=34595
• Windows Identity Foundation 3.0 - http://go.microsoft.com/fwlink/p/?linkId=204657

Standard and Enterprise Edition Front Ends

• .NET 3.5 (installed by default with Server 2008 R2)
• SilverLight (Required from Lync Control Panel)
• KB2646886 for IIS 7.5 - http://support.microsoft.com/kb/2646886/en-us *Install after PowerShell below is Run as it requires IIS to be installed

PowerShell for pre-req's:

Persistent Chat

PowerShell for pre-req's:

Director

PowerShell for pre-req's:

• KB2646886 for IIS 7.5 - http://support.microsoft.com/kb/2646886/en-us *Install after PowerShell below is Run as it requires IIS to be installed

Edge

No additional prerequisites are required.

Mediation

No additional prerequisites are required.

Server 2012

• Apply all Windows Updates
• Microsoft .NET Framework 4.5 - http://go.microsoft.com/fwlink/p/?LinkId=268529
• After Installation ensure WCF Activation and HTTP Activation are enabled
• Windows PowerShell 3.0 (installed by default with Server 2012)
• Windows Identity Foundation 3.5 (install from Server Manager)

Standard and Enterprise Edition Front Ends

• .NET 3.5
• SilverLight (Required from Lync Control Panel)

PowerShell for pre-req's:

Persistent Chat

PowerShell for pre-req's:

Director

PowerShell for pre-req's:

• KB2646886 for IIS 7.5 - http://support.microsoft.com/kb/2646886/en-us *Install after PowerShell below is Run as it requires IIS to be installed

Edge

No additional prerequisites are required.

Mediation

No additional prerequisites are required.

Active Directory Preparation

Schema Update - Enable-CsAdServerSchema
Schema Check – Get-CsAdServerSchema

Forest Prep - Enable-CsAdForest -GroupDomain <domain to create security groups>
Forest Check - Get-CsAdForest

Domain Prep - Enable-CsAdDomain –Domain <domain to prepare>

Domain Check - Get-CsAdDomain

NOTE: After Active Directory preparation has completed it’s a good time to add the CSadministrator role to user account that will be performing the installation as well as any other account that will require full access to Lync. It is also worth adding RTCUniversalServerAdmins to the installation account.

DNS Records

Create the DNS records required to support the topology.

*Ensure that DNS round robin is enabled for DNS load balancing.

Lync File Share

The folder must be shared, however when the Topology is published the required NTFS permissions will be added.

Topology

Create your Lync Topology using the Topology Builder.

If you already have Lync 2010 installed select “Download Topology from existing deployments”, otherwise create a “New Topology”.

Standard Edition

Run “Prepare First Standard Edition Server” to install SQL Express and populate RTC databases. This step is only required for new deployments, and does not apply to migrations from Lync 2010.

Enterpise Edition

TBC

Install Backend Databases (this can be completed when publishing the topology)

Pre-req’s:

• SQL sysadmin role is required to install Lync databases
• Remote access to SQL must be configured and the relevant ports opened
• If SQL mirroring has been defined then the SQL share and permissions must have already been created

Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn <SQL Server FQDN>

NOTE: The databases can also be installed using the topology builder, however if the databases are not in the default path it is better to use PowerShell.

Publish the Lync Topology
When you publish the topology for the first time the backend databases are created. One if these databases, named XDS, holds data for the Central Management Store (CMS). This is an important database because it holds Lync Servers Topology, policy and configuration information.

• Topology - Topology information that was generated by the Topology Builder tool
• Policy - All of the policies that you configure in Lync
• Configuration - Configuration information such as certificate and dial-in conferencing access numbers.

A replica copy of the XDS database is located locally on each Lync Server role as an instance of SQL Server Express named "RTCLOCAL"'.

Permissions required to publish the topology:

• Publish the Topology - http://technet.microsoft.com/en-us/library/gg425880.aspx  
• Delegate Setup Permissions (if you do not want to grant the setup account Domain Admin rights) - http://technet.microsoft.com/en-us/library/gg412735.aspx

What should you check after the topology has been published successfully?

• Check that the Lync Share has been populated

• Check that the following Db’s have been created
• LIS (Local Information Server)
• XDS (Configuration Database)

Install Server Roles

Once the topology has been published you are ready to install the Lync Server roles on the pre-built servers. One of the nice things about Lync is the ease in which this is done. All you need to do is run the installer and work through the wizards. Each server will contact the Central Management Store (CMS) to learn the role it lays in the topology. With this information the required components will be installed.

For each server role the Lync Deployment Wizard needs to be run, here are the steps:

1. Install Local Configuration StoreEdge Server
   
   Export-csconfiguration -filename c:\topology_export.zip
2. Setup or Remove Lync Server Components
   
   Tip: The Edge Server requires that you add a DNS suffix to the computer name so that it matches the FQDN defined in the topology
3. Request, Install or Assign Certificates
   
   Depending on your security requirements you may wish to create a certificate template that has a validity period equal to the period you expect the current version of Lync to be in service.
• FE Certificate
• SN: FQDN of Pool
• SAN: FQDN of FE, meet, dialin, admin, lyncdiscoverinternal, lyncdiscover, web services internal, sip, sipinternal
• OAuth – Lync servers use this to communicate between themselves
• Mediation Certificate
• SN: FQDN of Mediation server
• Edge Server Certificate
• Internal SN: FQDN of Edge server
• External SN: Access FQDN
• External SAN: Access FQDN, Conferencing FQDN, sip, sipexternal, xmpp

4. Start Services

After Lync server roles have been installed there is an additional step if you have deployed monitoring. From the Lync Deployment Wizard select “Deploy Monitoring Reports”. When asked for a read only group normally RTCUniversalReadOnlyAdmins would be selected.

Hope this helps, if you have any questions just leave a comment below.

Understanding how Lync establishes audio/video paths using ICE

The real time aspects of Lync require a different approach to SIP signally to ensure a quality of service. SIP signalling can be delayed without causing too many issues, however audio/video this is much more important, and to do this Lync uses Interactive Connectivity Establishment (ICE). ICE is the overall process that helps discover and exchange candidates to finds most optimal media path.

Definitions

• SIP signalling - allows clients to send invites to other parties.
• Interactive Connectivity Establishment (ICE) - Process used to discover and exchange candidates in order to find the most optimal media path.
• Candidates – A list of possible IP addresses that could be used to establish a media path.
• Reflective/Session Traversal Utilities for NAT (STUN) - STUN reflects or returns the public NAT address to the Lync client e.g. a home based user sends a packet to edge server, which discovers the public IP address (a candidate) , and returns it to the client.
• Relay/Traversal Using Relays around NAT (TURN) - TURN allows the media traffic to be relayed/proxied by the Edge server to the client by providing the client a relay addresses to send media.
• ICE endpoints – An ICE endpoint is anything that is involved in media e.g. Lync Clients, Lync Web App, Lync Phone, FE Server (App Sharing MCU, RGS, Call Park A/V Conf etc), Mediation Server, SBA, Exch UM. Session Border controllers and the director role would not be considered as ICE endpoints. Edge server is doing STUN and TURN but not an ICE endpoint, more and ICE server.

The 5 Phases of Media Path Establishment

1. TURN provisioning and credentials (MRAS)

The Lync client does an SRV lookup to find an Edge server to register against and then performs a SIP register. The server provides a 200 OK which includes in band provisioning details, including MRAS (media relay authentication services) which tells the client there is an Edge server service deployed. With this the client sends SIP service request to Front End which includes the client’s location (internal or external). Because the Edge is not on the domain it can’t authenticate client directly, so the Front End server requests the credentials on behalf of the client. The AV Edge service creates credentials using AV Edge certificate for the Front End which sends a 200 OK back to client with the Edge server it should connect to, ports and username and password. Credentials are valid for 8 hours and for this period the client can now go straight to Edge server. In conferencing scenario the same thing happens, however because can join anonymously the Front End checks to see if a meeting exists, and then gets and passes the credentials to meeting participant.

Tip - Always make sure you use the same external certificate for all Edge servers. The certificate is used to create credentials for the client to connect. If an Edge server goes down, and the client try’s to connect to another Edge server using a different certificate, it will not be able to validate the credentials and authentication will fail.

Search for “MRAS” in Snooper to find authentication messages. There should be 3 messages per request. Port 5062 for MRAS.

2. Address Discovery (Allocation)

Address discovery is the process the client goes through to determine what IP addresses it might be reached on. These IP addresses are the client’s candidates.

Audio/Video

• Discover local UDP candidate for every network card (peer to peer so UDP is best)
• Connect to media relay (Edge server) to discover reflexive address (the address the Edge server sees the client connect from) and allocate a candidate on the media relay for UDP then TCP

File Transfer and Desktop Sharing (RDP over RTP) - Both require TCP

• Discovers local TCP candidate
• Media Relay TCP only

3. Address Exchange (SIP Invite/200OK)

Address exchange is the process of sharing candidates with other endpoints that will be part of the call (peers). This is achieved by sending a SIP invite to the peer, who in turn will discover their own candidates, and send them back as part of a SIP 183 Session Progress.

4. Connectivity Checks

This is the process of taking the provided candidates and determining a possible media path. The Lync client validates the list of candidates by opening connections to all entries in the list simultaneously. The first to respond is used to establish the “Early Media” connection, however the media path may change during the call using a process called candidate promotion. When the called party picks up it will again send its candidates to the caller, but this time part of a 200OK.

• Connect directly (peer to peer)
• Connect to reflective address
• Connect via media relay by connecting to the Edge and asking it to contact a candidate and establish a connection on its behalf.

**If there is no Edge server it only does local candidates.

5. Candidate Promotion

This is the process of determining the best possible candidate for the session. If a better path is found the then media path can change during the call.

• Host/Local Candidate (UDP) – The most preferred candidate is always a local candidate and is the reason that peer media sessions between clients on the same network will never use the Edge server.
• Reflexive/STUN Candidate (UDP) – The next preferred option is to use the server reflexive candidate which is provided by the Edge Server using STUN. This scenario involves attempting to connect to the reflexive IP addresses for each externally connected user. The reflexive IP address is the public IP address of the external user e.g. a home router.
• Relay/TURN Candidate (UDP) – In the event that STUN fails then the final option is to utilise the Edge Server as a media relay. The calling client will establish a media session directly with the A/V Edge Server as will the receiving client. This connectivity is relayed through the public IP address of the Audio/Video Edge service.
• Relay/TURN Candidate (TCP) – when connectivity is not available on UDP. TCP Relay is a last resort.

SIP Messages in Media Path Establishment

• Out INVITE (SDP session description protocol – tells other party what I can do e.g. codecs). First set of candidates is ICE v6 (ms-proxy-2007fallback) second set is ICE V19. OCS r2 + uses V19 includes both for back compact. Candidates come in peers - one for RTC and one for RTCP.
  
  A=candidate 1 1 Protocol(UDP/TCP Passive – candidate they I expect to send traffic to /TCP Active – candidate that sends me traffic) priority (high best) IPAddress Port Typ(host/relay/server reflective)
  
  A=candidate 1 2 UDP priority(high best) IPAddress Port Typ(host/relay/server reflective).

• In SIP 183 Peer sends its candidates. You may see multiple – one for each end point.
• In SIP 200 OK Peer picks up the call. This still includes a full candidate set as the best have not been negotiated yet.
• Out INVITE Re-invite which will include the 1 chosen candidate peer as decided in the earlier process.
• In SIP 200 OK Includes other party’s final candidates.

NOTE: The Edge server is used in discovery process, but not necessarily once media path has established. This is why it can be important for internal clients to be able to access the internal NIC for edge. If the candidate list doesn’t include UDP and TCP reflective then it probably can’t talk to Edge server. If you see only UDP or only TCP then firewall might be blocking ports.

Call Scenarios and Connections Options

Inside <-> Inside

• Peer to Peer

Inside <-> Outside

• Peer to peer will not work
• Outside connects to reflective candidate UDP or TCP
• Outside connects to own edge server (relay) which hairpins traffic to internal user

Outside <-> Outside

• Peer to peer might work if clients are on the same network
• Reflective candidate UDP or TCP
• Relay via Edge server

Federation OCS 2007

• Edge servers connect to each other on the 50k port range directly and relay the call. Ports need to be open in both directions.

Federation 2007 R2 (tunnel mode introduced)

• The Edge server sends a special packet to UDP port 3478 on the other Edge to find out if it is OCS 2007 R2 or above. If it is then tunnel mode can be used, and all UDP traffic can be sent on these ports. Candidate data still includes the 50k ports, but the Edge server just contacts the other Edge server to share this information and connect.
•  TCP is very similar, but because a connection to a source IP/port and destination IP/port can only be in use at one time, the Edge server allocates a port in 50k range as a source port, and then opens a connection to the other Edge server on port 443. This gets around having to have 50k ports open which is required for OCS 2007.

While the 50k port range is not required for OCS 2007 R2 and above, there are still benefits to opening it. In a situation where 2 Edge servers would normally be involved in relaying media, this situation allows both clients to connect to the same Edge server. The initiating client connects to its home Edge server, gets candidates and passes those to the other party. The other party then attempts to connect to the 50k range directly on the initiators home Edge server. Without these ports open this would not work, and the client would need to involve its own Edge server and ask that it connects to the initiating Edge to relay on its behalf. This introduces a longer media path.

Troubleshooting Media Connectivity

• Get client login from fresh sign in – is there MRAS? If no it can’t talk to edge.
• Check if FE can telnet to FQDN on internal edge
• Check logs for STUN and TURN candidates. If none then there is an issue between client and edge
• User port query to test UDP
• When edge sends candidates in NAT situation, edge uses external IP configured in topology and sends this to client – make sure it’s correct.
• Search Snooper logs for MRAS for authentication
• Search a=candidate to see candidate
• Search a=remote-candidate to find final candidates that are chosen
• After call pickup it can take several seconds before final candidates are chosen, and media path might change. Final re-invite will include this but the result may not be in logs for a few seconds after connection.

Thanks to Thomas Binder for this excellent deep dive as well as Jeff Schertz for his summary.

Lync call accounting for user or departmental billing

Lync Call Accounting and Departmental Billing now has its own page - http://www.lync.geek.nz/p/call-accounting.html

Wondering if there is a great demand out there for free solution to Lync call accounting? I have been playing around with SQL queries to see what I can do, and if there is a demand will spend some more time putting together something to share with the Lync community.

One of the difficulties in accounting for Lync calls is when a call is forwarded. Lync passes the A-Party caller ID through to the C-Party, and lists the B-Party who forwarded the call as the "referrer". This is included in the SIP header as Referred-By, and also included in the Lync monitoring server reports.

All the SIP providers I have dealt with here in New Zealand don't seem to cater for this situation. Instead I get call records that show A-Party called C-Party, with no indication of who actually initiated the call to the C-Party, and therefore should be charged to that leg of the call.

Its pretty crude, but here's what I am getting straight out of SQL so far:

Example output can be downloaded here.

Leave a comment and let me know what you think.

Lync Mobility DNS Records

The DNS records required for Lync mobility can be a little confusing due to the fact that mobile clients will always connect to the external web services FQDN. In Lync 2010 the URL's returned by the Lync Discover service for internal and external are the same external web services URL. In Lync 2013 the client is hard coded to look for a a single purpose built URL which is also the external web services URL.

Here is how I would recommend that DNS is configured:

Internal DNS

The internal DNS records cause the most confusion, and are often the reason internally connected mobile devices fail to connect.

lyncdiscoverinternal.sipdomain.com
A record or CNAME pointing to the Front End pool.

This requires that devices have installed the internal CA certificate, or a public certificate has been used that is already trusted by the device.

lyncdiscover.sipdomain.com
A record pointing to the external web services IP address. Using this record internally is not the recommend configuration.

In Lync 2010 you can actually get away with not including lyncdiscoverinternal.sipdomain.com in internal DNS; instead you just create lyncdiscover.sipdomain.com (a record that would normally only be included in external DNS) and resolve it to the external web services IP address. By doing this you get around the need to install the internal CA certificate. In Lync 2013 all clients now use the Lync Discover service, so it is not advisable to use this workaround. The reason being that you don't want all Lync clients on your internal network connecting to the external Lync Discover service.

Using this configuration requires that traffic can hairpin out the firewall and back in again, which is also a requirement of the next mentioned and required DNS record. One trick that can be applied to both these records, is rather than pointing them to the external ISA interface, you point them to the internal interface, and enable the "local host" interface on the web listener associated to the Lync external web services rule. This enables ISA to receive the inbound request and process it locally, applying the rule and sending it back via the internal interface.

lync-web-external.domain.com

A record pointing to the external web services IP address. 

This one confuses a lot of people because it doesn't normally make sense to point an internal DNS record, to a services external IP address when that service is local. Regardless of whether you have used lyncdiscoverinternal or lyncdisover, the fact remains that this service will still always return the external web services URL, and it is for this reason we need to include the external IP address in internal DNS. If you don't, because your internal DNS is authoritative for your domain, it will not return an IP address to internally connected mobile devices. I still don't really understand Microsoft's logic here but this is the recommended configuration.

External DNS

External DNS is much more clear cut and doesn't require a heck of a lot of explaining.

lyncdiscover.sipdomain.com
A record pointing to external the external web services IP address.

This will normally be the external ISA server interface.

lync-web-external.domain.com

A record pointing to the external web services IP address. 

This will normally be the external ISA server interface. 

For more information about LyncDiscover URL's see this post.

Lync Edge Port Tester Tool

Tool developed by James Cussen over at My Lync Lab to assist in testing firewall rules for the Lync Edge server. Goodbye to my port test list!

Features:

• One tool for testing both ends of the connection. Run the Lync Edge Port Tester on your Edge server and on an internal and external network machine.
• Test both UDP and TCP ports are open in both directions.
• Select a profile from the list (Edge Outside, Edge Inside, Front End, Client Outside, Client Inside) to check all the relevant ports for that connection type.
• Open all the required firewall ports temporarily with the press of a button.
• Can be used to test connections to a live Edge (or Front End) server. If you run the tool on a live edge server it will automatically learn which ports are currently in use and only allow you to Listen on unused ports.
• Can be used on a Consolidated Edge configuration or on an Edge running with a single external IP address (ie. all 443 services running on different ports). The Single External IP check box allows for this configuration.
• Tool Tips to provide you with contextual help.
• All in one interface. (Over 100 interface objects! Yep, that was a lot of typing...)

For more information check it out here -
http://www.mylynclab.com/2014/02/lync-edge-testing-suite-part-1-lync.html

Lync and UM Licence Reporting Script

This script will report on the number of CAL/SAL licences that are in use for Lync and Exchange for a specified Active Directory OU.

Licence Summary Report

User Summary Report

Download Lync Licence Reporting v2.0.ps1

Lync Script - Get All Assigned Numbers

This script queries Lync for all assigned numbers and displays in a formatted table with the option to export to CSV. During processing LineURI's are run against a regex pattern to extract the DDI/DID and the extension to a separate column.

Numbers Queried: LineURI, Private Line, Analouge Lines, Common Area Phones, RGS Workflows, Exchange UM Contacts, Trusted Applications and Conferencing Numbers.

http://gallery.technet.microsoft.com/Lync-Get-All-Assigned-8c1328a0

Configuring Snom UC Edition for Lync

I have had a lot of success with the snom UC Edition software for snom phones. Currently the snom 300, snom 370, snom 710, snom 720, snom 760 and snom 821 are officially qualified for Lync 2013. The snom UC600 is a traditional IP desk phone especially designed for use with Microsoft Lync.

It is still possible to install the UC edition software on phones that are not officially qualified, the most recent for me being a snom PA1. Obviously there are no guarantees that all functionality will work, but so far I haven't had any issues. The snom PA1 is a PA switch which picks up incoming calls automatically and outputs the audio to the built in 4 Watt amplifier, or to a line out connector if you want to connect it to a building PA system. In my case I have configured it as a Lync endpoint and connected to the speaker system throughout the building. Calling the configured Lync user enables staff make announcements.

The following guide has been generalised to assist with configuring any snom UC device. If you have not already installed UC edition then you will need to visit the Snom website and register, then copy the URL to the download file:

Once you have logged in to the phones web interface discussed below, navigate to "Software Update" - "Manual Software Update", then paste the URL in and select "Load". The phone will reboot and install the UC firmware.

Once you have plugged in and powered up the device, browse to the web management portal.

Finding the phones IP:

• Snom PA1 - The default address is 192.168.0.2/16, otherwise if you have DHCP the device will get an address this way. On the PA1 you can get its IP address by pushing the IP/Reset button and it will read it out. 
• Snom 710  - Press and hold the "X" at the welcome screen, then find it under "System Info" - "IP Adr". 

e.g. https://192.168.0.2

Snom has a user mode and admin mode. When logged in in user mode you won’t see any of the advanced options. To access the advance options select “Setup”-“Advanced”, enter the default admin password “0000” then “Apply”:

There is no username and password out of the box. To set the admin password and the HTTP web interface password navigate to “Setup”-“Advanced”-“QoS/Security”:

Select “Apply” then log back on using the HTTP server credentials you just set. Note that in some cases you may need to select "Save" at the top of the settings page.

Account Setup

Click on any identity from the left navigation panel of the snom web interface:

Important settings

Identity active: ON
Display Name: Name to display on phone where applicable
Account: SIP sign-in address NOT including @sipdomain.com e.g. peter.pan
Password: your lync password
Registrar: SIP domain e.g. neverland.co.nz
Authentication Name: Username e.g. peter.pan@neverland.co.nz or NEVERLAND\Peter.Pan

Note: If no Authentication Name is provided, the Account setting is used in place of the Authentication Name

Optional Settings

Outbound Proxy: SIP server e.g. front end pool or access edge (lyncpool.domain.com/sip.domain.com)

Note: It is also possible to specify the port and transport layer:
sip.domain.com:5060;transport=tcp  (Use TCP/Port 5060)
sip.domain.com:5061;transport=tls (Use TLS/Port 5061)

Note: Leaving out the Outbound Proxy will result in automatic DNS lookup for Lync (Auto Device Sign-in)

Ensure that “Server Type Support” is set to OCS/UC:

RTP Encryption should be set on “ON”:

Check that the user account has logged in successfully: 

If you have any issues check out the SIP Trace and Log, unlike a lot of products these logs are very useful in finding the problem.

Lync Phone Edition Device Updates

This is my understanding of the device update process and how to troubleshoot. This whole process could be a lot smoother in my opinion, I find it a right pain!

Devices use Domain Name System (DNS) to determine the address of the server that is running the Device Update Web service, which is hosted on Web Services. For internal communications, the Web Services IP address must be available in DNS, as must the SRV record for SIP

The device uses DNS to find the SIP domain portion, by querying the SRV record. The SIP domain is extracted from the resulting fully qualified domain name (FQDN), and ucupdate S-R2 is prepended. If the device is internal, :443/requesthandlerInt/ucdevice.upx is appended. If the device is external, the hardware load balancer should replace the port 443 with port 4443.

While it is not a critical problem if the Device Update Web service cannot be found by using DNS, the device will log on and then use the in-band value to locate the service. If the update itself is something critical to successful logon, this can result in device connectivity failures.

External Devices

If the device is outside the organization’s firewall, and the user is signed in, the Device Update Web service returns a response indicating that anonymous access is not supported. The device then sends an HTTPS update request over port 443 to the Device Update Web service. The Device Update Web service returns one of the responses listed previously in the internal case.

In the Configure a Reverse Proxy step, configure the reverse HTTP proxy to use the Device Update Web service virtual directory https://<web services external Server FQDN>:443 for the external URL for Web Services and the Device Update Web service.

DNS Records for External Devices

SRV

Edge Server: _sip._tls.<sip domain> (External TLS)

Allows external devices to connect by using SIP over TLS to the Registrar internally.

A

Reverse proxy FQDN:<server name>.<SIP domain>

Allows external devices to connect by using TLS over HTTP to the Device Update Web service.

URL to Updates

Lync 2010
https://lyncexternal.domain.com/RequestHandlerExt/Files/UCPhone/

Lync 2013
https://lyncexternal.domain.com/RequestHandlerExt/Files/UCPhone/

/RequestHandlerExt/Files/UCPhone/ is the IIS web path to the following file share:

Lync 2010
\\Lync2010FileShare\1-WebServices-1\DeviceUpdateStore\UCPhone

Lync 2013
\\Lync2013FileShare\1-WebServices-1\DeviceUpdateStore\UCPhone

To test that update files are available via the web services URL navigate to the file share and find the update that you want to test. Then browse to the URL and append the file path on the end.

e.g.

https://lyncexternal.domain.com/RequestHandlerExt/Files/UCPhone/AASTRA/6725ip/Rev-2/ENU/4.0.7577.4397/CPE/CPE.cat

https://ucupdates-r2.domain.com/RequestHandlerExt/Files/UCPhone/AASTRA/6725ip/Rev-2/ENU/4.0.7577.4397/CPE/CPE.cat

By browsing to such a URL you can confirm that the updates are available for download. You will be prompted for authentication which requires a Lync user account.

References:
http://technet.microsoft.com/en-us/library/gg412864(v=ocs.14).aspx
http://technet.microsoft.com/en-us/library/gg398745(v=ocs.14).aspx

Finally a dedicated Lync client for meeting rooms!!

Just back from a demo at Microsoft of the new Crestron Lync meeting room system. I was seriously impressed!! Until now there was no seamless way to deliver Lync conferencing to a meeting room so this is great news.

The software was actually developed by Microsoft with hardware partners Crestron, SMART and Polycom (LifeSize dropped out of the program). I am sure there will be more to come as time goes by.

Check it out here - http://blogs.technet.com/b/lync/archive/2013/02/19/the-lync-room-system-lrs.aspx

Also SMART has a really good video - http://www.youtube.com/watch?v=bbNSlhsDOdY

Only one of DistributionGroupAddress and AgentsByUri must be set" during Move-CsRgsConfiguration

Somehow a bunch of our RGS Agent Groups had values for both "DistributionGroupAddress" and "AgentsByUri" properties. This was causing the Response Group migration to stop dead in its tracks! Thankfully Russ over on the MS forums had a solution:

http://social.technet.microsoft.com/Forums/lync/en-US/d712b09c-606b-4a1e-abba-146948ba83d9/only-one-of-distributiongroupaddress-and-agentsbyuri-must-be-set-during-movecsrgsconfiguration?forum=lyncdeploy

Migrate UM contact objects from Lync 2010 to Lync 2013

There is a very easy way to get this done - one line of PowerShell actually:

Get-CsExUmContact -Filter {RegistrarPool -eq “pool01.domain.com”} | Move-CsExUmContact -Target pool02.domain.com

Microsoft's migration documentation actually misses this step, so hopefully this will save you some time recreating them all on your new Lync 2013 pool. Unfortunately for me I found this after the fact!

Migrate un-assinged numbers from Lync 2010 to Lync 2013

Following the Microsoft documentation for migrating between Lync 2010 and Lync 2013 I noticed there was nothing on how to migrate un-assigned numbers. I did a quick Google search but nothing came up so I wrote a PowerShell script that copies existing un-assigned numbers to a new Lync pool.

I have since found that the Lync 2013 Resource Kit includes a tool that migrates all un-assigned numbers from one pool to another.

While this renders my script nearly useless I thought I would still make it available to everyone. This could be useful for anyone that would prefer not to migrate all, and would rather copy then delete, or maybe modify the script to copy with an improved naming convention etc.

The script also includes a section that creates a new announcement and links it to a new un-assigned number range.

Get the script here.

CAPITAL SIP: Causes RGS Queue Errors

If you see any of the below errors in your Lync 2010 Front End servers event log, changes are you may have used capitalisation in the "SIP:" notation pre-pended to the SIP address.

e.g. SIP: first.last@lync.com

The Lync control panel will tell you when you forget to add "sip:" but fails to inform you the "SIP:" will cause issue.

EventID: 31012
A valid URI was not specified for the queue time out destination.

EventID: 31161
The Match Making service could not transfer the call because of an error in the queue configuration.

EventID: 31117
The workflow runtime encountered a critical error.

Lync 2010 - Announcement Service

View Current Announcements
get-CsAnnouncement


Remove Announcement
remove-CsAnnouncement

EG
remove-CsAnnouncement -Identity: ApplicationServer:Lync2010.company.com/b5c9c298-ad14-4b28-a6
87-fc2b811cf262

Find Identity using get-CsAnnouncement command


Create New Announcment
new-CsAnnouncement

EG's

New-CsAnnouncement -Parent service:ApplicationServer:lync2010.company.com -Name "Main Number" (RGS_MainNumber@company.com)" -TargetUri sip:RGS_MainNumber@company.com




For more information on these commands use the -? command.

EG - new-CsAnnouncement -?

Lync 2010 - Manually Updating the address book

Run the follwing command in the Lync Power Shell:


Update-CsAddressBook

Lync 2010 - Error when changing Lync users settings

When you try and change a users settings you get "Active Directory Operation Failed on..." "You do not have the appropriate permissions to perform this operation..."

This happens because the user is a member of a Windows Builtin group, such as Domain Admins.  When a user is a member of one of the special Windows built-in groups, Windows will automatically remove security inheritance on that user.

To fix this you must reapply inheritance.
• Open Active Directory Users and Computers and locate the user object
• Right-click the user and select Properties
• Click the Security tab and then the Advanced button
• Check the Include inheritable permissions from this object's parent check box
• Click OK twice. Now try again.

Be aware that Windows will automatically remove the inheritance setting again within a few minutes as long as the user remains a member of the Windows built-in group.