UC Expo is on again this year on the 6th and 7th of March at Olympia in London. It’s the premier UC event in the UK/EMEA for vendors and end-user customers to come together and see the latest developments in the industry along with lots of informative seminars. I’ve attended the last 2 years (including manning our Modality stand last year) and enjoy meeting new people, catching up with old ones and learning about the new and exciting tech coming out.

This year however, Tom, Adam and I have teamed up with UC Expo to present our own little MUCUGL seminar on Lync Mobility. We’ll be talking about the new client and how it can fit in with your existing or new Lync deployment, as well as getting in front of a few new faces and talking about how awesome our user group is.

When: 6th March, 3:50 PM – 4:20 PM

Where: Mobility Track

For more info and to add our seminar to your MYVISIT planner, check out the seminar page on the UC Expo site here.

Look forward to seeing you there!

Migration Pains

So when it comes to actually migrating your existing Group Chat environment from OCS 2007 R2 to Lync Server 2010, the whole process can be fraught with danger. The Microsoft TechNet library article does a decent job of explaining how to do this, but when it comes to running a SQL query to replace the necessary table entries it can become a bit of confusing.

The Process

In this post, I’ll show you a quick and easy way to get your data across and your GC up and running on Lync.

Moving the database

When you approach this, you might think “ok, let’s deploy a new Group Chat environment and then migrate the data over”, but this is where I stumbled first time also. Contrary to judgement, you don’t provision any new Lync Server 2010 Group Chat servers or databases at all. The first thing you need to do is move the database from OCS 2007 R2 before you do anything on the Lync side by following this process:

1. Open Group Chat Server Configuration on the old Group Chat server/s and stop the Channel and Lookup services on all servers. This will stop any changes being made to the database like new chats in chatrooms.
2. Log onto the old SQL server and open the instance that contains the Group Chat database.
3. Backup the Group Chat database to file and move it to the new SQL server.
4. Open SQL Server Management Studio on the new SQL server and restore the backup into the new instance you’re using.

Preparing SQL and modifying the database

Next, you need to make sure your new SQL server is setup for the Group Chat database and that your Lookup and Channel service accounts have the necessary access. Following that, you need to manually edit a table to allow a new configuration to be made:

1. Assign your Group Chat Lookup, Channel and Web service accounts to the instance using this process and make sure they have dbowner rights on the database.
2. Make your Group Chat Lookup, Channel and Web service accounts a member of the local Administrators group on your Group Chat server.
3. Find the table called tbl.Config and remove all the rows that reference both your old OCS Group Chat servers and your OCS Front End pool or Standard Edition servers.

This will allow you to populate the table with new data when you install Lync Server 2010 Group Chat. Once you’ve removed all these rows, the fields in the Group Chat Server Configuration Wizard are free to be edited (and are no longer greyed out if you just point the wizard at the database without modifying these rows).

Installing Group Chat

Now that we’ve prepped our database, we can log onto the new Lync Server 2010 Group Chat server and begin a new installation as documented here. When prompted to specify a server and database name, you’ll put in the FQDN and database name of the server and database you just worked with i.e. the new one. The GC Server Config Wizard will pick up some config (from the tbl.Config table), but it will mostly be blank so you can config new settings like your Lync 2010 Front End pool as the next hop.

Once the wizard is complete and you start your services for the first time, you’ll be prompted to upgrade the database from OCS 2007 R2 to Lync Server 2010. Press OK on this and let the wizard do it’s thing. Following this, your services should (hopefully) start (and stay started) OK. If they don’t, check the event log for database access or certificate related issues.

In Summary

As always, make sure you backup and make a copy of your database before you do this, just in case. If you have the resources, test this in a non-production environment beforehand so you don’t incur unnecessary downtime.

Hope this helps you understand Group Chat migration a bit better. I know it was a steep learning curve for me when I first attempted it.

Lync comes with an IE add-on by default which is supposed to enable you to dial any number from within Internet Explorer, but we frequently find that it only allows you to dial US formatted numbers, case in point:

 Lync picks up the US number ok, but..

When it comes to UK numbers, no dice.

This kind of behaviour is actually acknowledged by Microsoft and the resolution is that “Phone-number detection in Internet Explorer is not enabled when the phone number is not a United States number and does not start with a “+”.” and that there is “currently no workaround for this issue”.

Until now. Tom has written an accelerator for Internet Explorer that allow you to dial any number within IE easily and quickly.

How does it work?

First we install the IE accelerator from Tom’s blog over here and click on Install Accelerator. After that, we’re ready to go, it’s that simple.

Now when we find a number on a webpage we want to dial, all we need to do is highlight it, right-click it and click Call using Lync.

I’d only just installed the accelerator which is why I add to hover over All Accelerators, but you can move it to the left column by setting it as a default accelerator in the Manage Accelerators options in IE.

After we hit Call via Lync, Lync pops up with a conversation window, ready to dial the number. Notice that Lync has applied our company normalisation rules also? Pretty neat.

Once I click the yellow highlighted part, the call dials and I’m good to go.

It does display a new tab in IE that says “Smile! You’re in a Lync call!” but according to Tom it’s an unavoidable side effect:

“It’s a little finicky because in an accelerator you can only make an HTTP call. So, I’m making an call to a page, passing the selected number, then using JavaScript to invoke to call. That works fine, but the downside is that you’re left with a new page open in the browser. There’s really nothing I can do about that so I’ve stuck a big smiley face on it.”

But hey, it works right? Go and download it now from Tom’s blog and follow him on twitter as well.

Previously the hard limit was always 250 participants per meeting. That was increased not too long ago to 1000, but there was no guidance regarding how you could plan or scale your environment for this, until now.

The catch is, you need a dedicated Front End pool for the meeting, and only one meeting can occur at a time. No users, no other services on it at all. I can see the reasoning behind this to achieve the best user experience but personally, I’d probably be sticking to the Live Meeting service if I needed to host meetings of this size.

When it comes to what can be presented in the meeting, we’re talking about most functionality. PowerPoint, application sharing, audio and video. No mention of application/desktop sharing though, so it sounds like that’d hit your resources hard in a huge conference like this.

The document also includes some interesting stats Microsoft found around how conferences are used on Lync. To find out more, download the document here from the Download Center.

The Problem

If we just had say, https://meet.contoso.com as our global meeting join URL (defined in the Lync Topology Builder) and pointed this to say, the EMEA Lync Front End pool, it would mean all users worldwide would be hitting that pool when they click the link in Outlook to join the meeting. Not ideal and not scalable.

The Solution

To ensure only EMEA users connect to the EMEA pool (and not the APAC users as well, for example), we need to create site level simple URLs to ensure users only connect to the pool in their region and that these URLs take precedence over the default global level simple URLs.

For this scenario, I selected Simple URL Naming Option 2 from the Planning for Simple URLs article on TechNet, which gives me a bit of flexibility and means my simple URLs for EMEA for this scenario look like this:

https://lyncemea.contoso.com/meet
https://lyncemea.fabrikam.com/meet
https://lyncemea.contoso.com/dialin

and my APAC URLs for example, would look like this:

https://lyncapac.contoso.com/meet
https://lyncapac.fabrikam.com/meet
https://lyncapac.contoso.com/dialin

and so on per global region. Note that you can only have one dialin simple URL per site – you can’t have a different dialin simple URL for each SIP domain.

For this article, I’ll only be covering the meet and dialin URLs, not the admin URL for LSCP access.

Creating a new Simple URL Configuration

First we need to create a new simple URL configuration that we will end up applying new simple URLs to.

1. The first command we need to run is Get-CsSite. This cmdlet retrieves the list of Lync sites in the topology.
2. After we’ve identified the site name (EMEA), we run the New-CsSimpleUrlConfiguration cmdlet against the site e.g.
   New-CsSimpleUrlConfiguration -Identity site:EMEA

$urlEntryContosoMeet = New-CsSimpleUrlEntry -url “https://lyncemea.contoso.com/meet”

$urlEntryFabrikamMeet = New-CsSimpleUrlEntry -url “https://lyncemea.fabrikam.com/meet”

$urlEntryAllDialIn = New-CsSimpleUrlEntry -url “https://lyncemea.contoso.com/dialin”

Simple URLs

Next, we need to actually create the new simple URL in Lync, set which component (meet or dialin) it will apply to, which SIP domain it’s set for, which simple URL entry it will use and then (phew!) bind it to the variable we specify at the start of the cmdlet. Run each cmdlet per simple URL you need to create:

$simpleURLContosoMeet = New-CsSimpleUrl -Component meet -Domain contoso.com -ActiveUrl https://lyncemea.contoso.com/meet -simpleurl $urlEntryContosoMeet

$simpleURLFabrikamMeet = New-CsSimpleUrl -Component meet -Domain fabrikam.com –ActiveUrl https://lyncemea.fabrikam.com/meet -simpleurl $urlEntryFabrikamMeet

$simpleURLAllDialIn = New-CsSimpleUrl -Component dialin -Domain * -ActiveUrl https://lyncemea.contoso.com/dialin -simpleurl $urlEntryAllDialIn

Bringing it all together

So now we have a bunch of variables floating around in our current PowerShell session, we need to apply them to something. To make it real, we need to add the variables of all our simple URLs from the previous step to the new site level simple URL configuration we created earlier by running this cmdlet:

Set-CsSimpleUrlConfiguration -Identity “site:EMEA” -SimpleUrl @{Add=$simpleURLContosoMeet,$simpleURLFabrikamMeet,$simpleURLAllDialIn}

Once that’s applied successfully, we need to run Enable-CsComputer to apply the configuration to IIS on the Front End server/s in the pool.

To review the changes committed, run the cmdlet Get-CsSimpleUrlConfiguration to retrieve the Global Simple URL configuration and the new Site level Simple URL configuration, each with the individual URLs we created.

Last Words

Make sure you take note of the difference between a Simple URL entry and a Simple URL, as they are different things in Lync Server Management Shell that are brought together to create a configuration.

To reiterate, note that you can only have one dialin simple URL per site – you can’t have a different dialin simple URL for each SIP domain.

Hope this makes it (a bit) clear on how to setup site specific simple URLs in Lync. As Lync grows in maturity and market share, we will see larger, more widespread organisations adopting it which means you’ll need to know how to get this kind of configuration going.

Just as we were about to kick off at 6pm, a fire alarm went off and we all had to evacuate the building. Some half an hour later we were allowed back upstairs and kicked off proceedings with Adam talking about Lync Mobility Architecture first.

Next up, I presented on Lync Mobility Deployment with Tom including a step by step guide and how the sign-in process works. You can check out our slides below.

The other slides from the night including Adam’s and Steve Hopkins from AudioCodes’ slides are on our SlideShare account and you can check out some photos from the night on the MUCUG London blog post.

When’s our next one?

We’re pleased to announce that our next MUCUG London event will be on April 19th at Eight Club in London so make sure you save the date now.

Many thanks to all that came, we really enjoyed having you along and for a few pints at the pub after. Your feedback was great and always we’ll take it on board to make future events even better.

I’m not going to harp on about a particular vendor’s product, but I want to wax lyrical a bit here on why a gateway is a valuable and sometimes critical, part of your Lync voice deployment. It can mean the difference between a smooth migration and coexistence period, and a nightmare scenario where you have islands of voice kit that can’t talk to each other.

I’ll focus on an upstream deployment of a gateway in this post, meaning that the PSTN (ISDN and/or SIP trunk) is terminated at the gateway. Lync, the PBX and any other telephony infrastructure then sit behind the gateway, like in this diagram:

Any to Any Routing

Deploying a gateway capable of taking one signalling protocol (e.g. ISDN, SIP, H.323) and translating it into another is invaluable in an interoperability scenario. An example is when you find yourself needing to route calls from Lync (signalling in SIP/TLS and SRTP media in G.711 aLaw) to your 10 year old Ericsson PBX (over an ISDN E1 trunk), a gateway is the only device that can do this transcoding and feed the PBX the signal it needs.
Or maybe your old Cisco Call Manager only accepts SIP over UDP? No problems, the gateway can translate the signalling for you.

Calling/called number translation is a gateway’s bread and butter also. Taking full E.164 numbers from Lync and manipulating them into 4 digit extensions a PBX can use or a format the PSTN can understand is where a gateway makes life easy.

Migrating Users

If you’re not doing a “big bang” migration from your PBX, chances are you want to maintain a period of coexistence so you can slowly migrate your users to Lync. Gateways that can cache AD user information enable you to route calls based on whether a user is enabled for Lync or not. This means that the only thing you as an administrator needs to is enable the user for Lync and the gateway takes care of the rest.

Supporting SIP Phones and Fax Services

Say you have a big bunch of SIP phones (Cisco, Polycom, snom, etc) left over from your old PBX that you still want to use. A gateway with built-in SIP registrar functionality can keep them alive by registering your old SIP phones straight on the gateway and assigning phone numbers to them. They’re not Lync enabled, but at least you provide a dial-tone to them for basic voice functionality.

Faxing is ubiquitous in the enterprise and still plays a role today, so both analogue and server-based fax functionality needs to be maintained in a UC environment. Fax machines talking to an ATA device can talk SIP straight into a media gateway, or a fax server (Facsys, Goldfax, Rightfax, GFI etc) will easily talk straight SIP into the gateway as well and onto the PSTN.

Terminating PSTN Connectivity

SIP trunks from UCOIP qualified vendors are great and can plug straight into your Lync Server, but sometimes you may want to try out another vendor’s SIP trunk that can’t talk to a Mediation Server directly. A gateway can take this SIP trunk and turn it into the flavour of SIP that Lync requires, giving you a lot more choice in services.

Voice resiliency is a key requirement in most deployments, so multiple SIP trunks from different vendors or a backup ISDN line will typically be scoped. A gateway makes it easy to deploy all of these and manage the primary and secondary routing in and out in the event of failover.

A lot of SIP trunk providers deliver their services over a VPN, which a gateway can typically terminate also. Or if the trunk is provided encrypted over the internet, you’ll usually need to NAT it into your internal network. Media gateways are typically NAT capable, which means you can make the gateway aware of your public IP and ensure outgoing SIP packets are marked with it so traffic can route back in successfully.

The core of your Voice Infrastructure

When you have a dependency on other voice components, a gateway really becomes the heart of your environment. Sure they can be costly, but you’re investing in making your migration as smooth as possible and providing a considerable degree of flexibility into your environment.

I’m really excited about being published on a TechNet blog, expect to see more contributions from me there in 2012.

I identified some behaviour on the mobile client that could impact how you provision photos in Lync in your environment, here’s what I discovered.

How do photos display on mobile?

As I mentioned in my previous post about photos, the full blown PC client can display photos from AD/SharePoint, a URL you specify, or no photo at all. You can control this using a client policy to ensure your users all get the same experience.

On mobile, you have no control over how photos are displayed. Lync Mobile can only display photos retrieved from Active Directory or SharePoint, it cannot display a photo from a URL.

If a user is displaying a photo from a URL and there is a photo in AD, it will display the photo from AD. If there is no photo in AD, it will display no photo at all. Let me show you what I mean:

Tom’s photo when I use the desktop client. Tom has a photo from a URL defined.

Tom’s photo on Lync Mobile on iPhone. Because Lync Mobile cannot display photos from URLs, it displays no photo at all.

Implications

This has implications to your deployment because you may encounter scenarios where users are accustomed on the desktop client to seeing a photo of a user from a URL the user has specified. Once they start using the mobile client, they will either see no photo of the user/s at all (if no photo is in AD/SharePoint) or they will see the photo that is stored in AD (typically from Exchange) or SharePoint. This leads to an inconsistency in experience, which may generate calls to your helpdesk.

Not a huge one, but worth looking out for if photos are a big value point for your Lync deployment (and they should be).

I am going to call this out here first and foremost, directed at people giving the apps a 1 star rating on the marketplaces – If Lync Mobile doesn’t sign in for you, check with your IT helpdesk that your Lync environment has been updated to support mobile clients.

Launch and Sign In

When you open up the app, you’re first greeted with a splash screen followed by the login screen where you can put in your login details.

After you’ve entered your credentials, and hit Sign In, you’re greeted with the Signing In screen.

The first thing I need to do is specify a phone number for Lync to simultaneously ring me on:

My Info

Once I’m signed in, I’m greeted with the My Info page where I can see my photo, status and call forwarding settings.

When I tap my status, I can change it to Available, Busy, DND etc.

Going into Options gives me a few things I can change – the number I’m simring’d on, whether to show photos or not, turning on/off logging and showing the version info of Lync.

Contacts and Chats

When I tap on the Contacts tab, I’m greeted with my full Lync contact list and can expand out each group I have.

Tapping a contact brings up their contact card and displays all their phone numbers and options to IM, call and send them an email.

Tapping on the Chats tab shows me all the IMs I have in progress in the session:

Takeaways

Basically this is just the Android mobile client stretched to fit the tablet, it doesn’t know it’s running on a tablet like the iPad client does. This is evident when you setup the number to simring on because it says “Enter your Android phone number”.

Good to see that the option is there if you have Android tablets floating around your organisation (ASUS, Samsung, etc..)