Some time back I was asked to pull together a video presentation for a “Virtual” Microsoft event – 24hrs in a Private Cloud. The event began this morning and runs for…you guessed it 24hrs

Most of the content is Microsoft System Center 2012 orientated, but I thought I’d deliver an introduction to the various types of Microsoft Cloud (also incorporating a Lync twist i.e. Lync Online and LHP).

The event is still open to registrations and you can also access my video presenetation below.

Almost a year ago I wrote a post on the differences between Lync On-Premise and Lync Online, since then Lync Online has gone through a series of updates and I have become more aware of Lync Online for dedicated customers.

Let me cover off some basics for those unaware:

• The Office 365 which can be purchased by individuals, small businesses and medium to large sized Enterprises via the Microsoft Office 365 website – this version of Office 365 is Shared or S and is a shared or multi-tenanted Microsoft Cloud platform aimed at the mass market.
• For large Enterprise businesses (typically 5000+ users), Microsoft offers a dedicated version (or D), which has more similarities between the On-Premise version of Lync Server 2010, the features and deployment characteristics are however not identical. In this dedicated model Microsoft hosts dedicated servers for a specific customer, there is also a more personalised service with enhanced SLA

So back to the matter at hand, I have updated the feature table, the original being sourced from the Office 365-S Lync Online service documentation, with the new features available within the Shared platform and now included the Dedicated version of Lync Online. I hope this helps!

Next Thursday 19th April Justin, Tom and I along with Geraint Evans from Acme Packet will be hosting the Spring MUCUGL, at this event we’ll be focusing on Lync Call Flow.

First up I’ll be speaking about Fixed-to-Mobile Convergence (FMC), a way in which businesses of any size can extend out an existing UC strategy into the mobile space whilst saving on communications spend. Next up Justin will dig into some Lync call traces and explain the ins-and-outs of Microsoft SIP. After the break Geraint Evans from Acme Packet will explain how Acme performs SIP session management for Microsoft Lync. Last but not least Tom has been performing his usual ducking and diving within the Lync scene, he’ll give us all an update on the latest going’s on.

So if you are in London on Thursday, come and join us – for more details and registration head here 

Whilst this information is not new,  I thought it would be good to cover XMPP and PIC-based capabilities available within Lync 2010, as more often than not the different modalities are misunderstood.

This was the case when I attended a customer meeting this week where I discussed the benefits of Federation within Lync, this stemmed from the need for their business to ustilise voice and video with 3rd parties.

We also touched on the capability to Federate with existing public social networks like MSN and Skype, the latter not being available. Today there are two methods of integration, Extensible Messaging and Presence Protocol or (XMPP) an Open technology used for real-time communications and/or Public IM Connectivity also known as (PIC) – dependent upon which networks you desire to communicate with (see list below).

N.B. Whilst voice and video is only offered via PIC, this is not due to the limitation of the XMPP protocol. XMPP is capable of handling instant messaging, presence, multi-party chat and voice/video calling.

To interface Lync with XMPP-based networks an additional component (and server, in addition to Edge) needs to be deployed, unlike PIC which can be configured directly within Lync once provisioning is completed. Back in December XMPP capability was announced for the MSN network via the Windows Live Blog, at this point this permits 3rd party clients to be developed – Federation is still achieved via PIC.

Below is a break down of protocols and networks used for connectivity with Lync Server today:

*Voice & Video is only available for Lync Server 2010 (and not Communicator/previous versions)

Taken from Justin Morris’ Blog:

UC Expo is back 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!

TechNet forums, blogs and tech news sites are ablaze with plenty of Lync Mobility related tips and news. Even I’m a UC Blog has seen a daily increase in traffic (circa 150-250 visits) primarily targeting mobile related content. So I thought it would be useful to pull together some potential solutions on how to address common push notification issues.

First off lets cover some basics:

• Push notifications are only available for Windows Phone 7 and iOS-based devices (iPad/iPhone).
• Push notifications are sent via Microsoft’s Lync Push Notification Clearing House or PNCH. (see diagram below)
• To send push notifications via PNCH you will need a Lync Edge Server that has dynamic federation with Office 365 or push.lync.com. Setup instructions are available here

Now some common problems and solutions/workarounds:

• URL Filtering Policy – at this time URL filtering blocks push notifications, until further notice from Microsoft a workaround has been published here
• Missing SRV record – an SRV record must be configured for the Edge Server that initiates the outbound connection to push.lync.com. For more information check out this article from fellow MVP Randy Whintle.
• Sub-domains - for organisations that have a SIP domain and Federation record mismatch. For more information check out this article from fellow MVP Kevin Peters.
• Connectivity – ensure port 5061 is open (this will already be open if you have an already established Edge Server).
• Default SIP domain is incorrectly specified – To display existing domains type “get-csSIPDomain” within the Lync Management Shell, to correct this type “set-csSIPDomain <SIP.FQDN> -isDefault $true”
• Public Certificate – for any kind of federation to work certificates need to be provisioned via an external certificate authority. For more on approved certificate authorities, read this TechNet article.

If you can think of anything I have missed off, let me know and I’ll add it!

Just quick heads-up, fellow MVP Tom Arbuthnot ran across an issue whereby Office Communications Server 2007 R2 or Lync Server 2010 Edge Servers URL filtering for IMs disrupts push notifications for both iOS and Windows Phone 7 clients. This is caused by:

Taken from Microsoft KB2664650

The Lync Server 2010 Mobility service sends SIP messages that contain active hyperlinks in their Message-Body header that define the XML namespace information for the push notification to the Lync Server Push Notification service.
Lync Server 2010 Front End Pool Using the URL Filter page in the IM and Presence group in Lync Server Control Panel to enable the Hyperlink prefix option Send warning message, will precede the active hyperlink with a user defined warning message in the SIP packet that contains the push notification message. The Lync Server Push Notification service will reject the modified push notification information and send an error response back to the Lync Server 2010 Mobility service.
Office Communications Server 2007 R2 Access Edge server Using the URL Filter tab of the Office Communications Server 2007 R2 Intelligent IM Filter dialog to:

• Allow instant messages that contain hyperlinks, but convert the hyperlinks to plain text
• Allow instant messages that contain hyperlinks. Enter a warning that you want to insert at the beginning of each containing hyperlinks

Will precede the active hyperlink with a user defined warning message and convert the active hyperlink to text by preceding it with an underscore or precede the active hyperlink with a user defined warning message in the SIP packet that contains the push notification message. The Lync Server Push Notification service will reject the modified push notification information and send an error response back to the Lync Server 2010 Mobility service.

For workarounds and more information refer to the Microsoft KB now live here

For some time now I have been arguing debating that the benefits of Lync Edge Services (specifically client access without the need for a corporate VPN) out-weigh the security concerns around exposing NTLM-based authentication over the web – we already have a lock-out policy defined within group policy and some times you need to take a more risk-based approach right?

Unfortunately I was fighting a losing battle, I knew that the only way I could ever win this debate was if I somehow managed to replicate the incumbant two-factor VPN authentication that was already being deployed, in our case RSA – I know don’t get me started right?

My thoughts have always been swayed towards computer-based certificates, this would be the most seamless way of reproducing a two factor scenario (i.e something you know – in my case succesful Windows logon to an encrypted Laptop and something you own – the locally installed cert), much the same as the network access protection setup we had deployed a year earlier. In essence this consisted of:

(a) authentication with Active Directory + (b) a valid computer certificate = (c) an enabled network switch port

This would be great for Lync!

There was a realisation today that I must have been sleeping under a rock as I came across an interesting “tweet” from Rui Maximo, specifically regarding a Lync Security Filter he had developed.

This add-on (which is installed on your Edge Server) offers the following:

• A soft lock-out policy you can enforce independently of your internal group policy settings (for value here you would need to set this below your internal lock-out threshold)
• UPN to Netbios normalisation (i.e. where your domain is contoso and your SIP FQDN is contoso.com)

Last but not least…

• The ability to disable NTLM v.2 authentication altogether, failing back to TLS-DSK-only authentication!

So what’s TLS-DSK?

Taken from the Lync Security Filter Documentation:

“Lync Server 2010 introduces support for an additional authentication protocol called TLS-DSK. This requires users to supply a client certificate for authentication. The Lync client requests certificates from Lync Server. This is an automatic process that happens the first time the user signs in to Lync Server from within the corporate network where the user is authenticated using Kerberos.

This client certificate is used for authentication with any subsequent log-in attempts. This is a self-signed certificate issued by Lync Server, not a Certificate Authority. If that same user tries to sign in to Lync from a different computer, he’s authenticated using Kerberos (if inside the corporate network) or using NTLM v2 (if outside the corporate network). The process of obtaining another client certificate starts all over.

TLS-DSK provides a level of security that’s very close to two-factor authentication. When combined with Windows BitLocker, the computer or laptop acts as the equivalent of a smartcard (something you have). The password that BitLocker requires to boot your computer is equivalent to the pin required to authorize the use of the smartcard (something you know).

There’s the remote possibility someone could steal the client certificate from the user’s computer, but you can mitigate this risk. Make sure corporate-issued computers are locked down to prevent users from downloading unauthorized applications.

You can force the Edge Server to negotiate the authentication protocol down from TLS-DSK to NTLM v2. In this case, the attacker can still target the user’s account, as discussed earlier. To prevent this scenario, the security filter provides an option to reject all NTLM v2 authentication requests, forcing TLS-DSK-only authentication. This doesn’t affect federated partner connections or PIC connections.”

In essence this Edge Server add-on completely mitigates the risk of allowing NTLM v.2 authentication over the web, burn turning it off. The only draw back here is that initial client logons will need to take place inside your corporate network (or directly between the Lync client and the Lync Front End Server).

Download: here

Nice one Rui!

Related Content:

For more on Lync Edge Server Security I’d recommend you read Rui’s guide on TechNet here

If the answer is YES, then why not make your way to the January MUCUGL meet-up!

Justin, Tom and I have spent the festive season tinkering with the all-new Lync Mobility Service or MCX and look forward to sharing best practice/do’s and don’ts at our Mobility themed get together on January 19th @ Bow Bells House, London.

There are still spaces available, agenda and registration details can be found below:

Registration: here

Location:

Bow Bells House 1 Bread Street EC4M 9BE London United Kingdom

So the waiting (as of writing) is almost over and the server-side bits for shiny new Lync Mobility Service (MCX) have been released!

The client-side bits are likely to be released next week and in the meantime there is nothing stopping you from prepping your Lync Servers. All clients have been released and can be downloaded via your Smartphone’s respective AppStore/Marketplace etc…

For those that are keen to get this up and running quickly, I have put together a short step-by-step guide, for official Microsoft documentation head here. I will however caveat one minor thing at this early stage, with the clients still unreleased this guide is still very much in beta! With all clients RTW’d this guide is officially v.1.0

Configuration of Lync Mobility Autodiscover Records

First up you’ll need to create the internal (lyncdiscoverinternal.<SIPFQDN>) and external (lyncdiscover.<SIPFQDN>) MCX discovery records, mine can be seen below:

As this is being configured within a test lab environment my internal discovery DNS is pointed at my Lync Standard Edition Server, for a larger deployment this is likely to be your Front End Pool or Director.

I have also configured the external discovery record, which can be verified using NSLOOKUP (see below). This is pointed toward the external listener address of my TMG reverse proxy.

Next we need to ensure that the November Lync Cumulative Update  (CU4) is installed – see more on this here, once this is complete we need to open up some internal MCX ports via the Lync management shell.

First the internal listening port: (my Lync Front End is lyncserver.jacobs.local, you will need to substitute this for your own front end/pool/director name)

Set-CsWebServer –Identity lyncserver.jacobs.local -McxSipPrimaryListeningPort 5086

Second the external listening port: (as stated in the prior step, my Lync Front End is lyncserver.jacobs.local, you will need to substitute this for your own front end/pool/director name)

Set-CsWebServer –Identity lyncserver.jacobs.local -McxSipExternalListeningPort 5087

Finally you will need to enable the topology, within the same shell type:

Enable-CsTopology –verbose

MCX Service Installation

Now we’re ready to install the MCX server components, this can be downloaded here. Before you can run the installation a few changes need to be made to IIS.

Within the Lync management shell run, ensure shell is run as admin if UAC is enabled (Windows Server 2008 R2):

Import-Module ServerManager

Add-WindowsFeature Web-Server, Web-Dyn-Compression

Or the following within the Windows command line, ensure command is run as admin if UAC is enabled (for Windows Server 2008):

ServerManagerCMD.exe –Install Web-Dyn-Compression

One complete you will be presented with the following

If you are running Window Server 2008 (IIS7.0) then you need to make a minor ASP.Net change (follow Microsoft procedure included below) – I’m running Windows Server 2008 R2 (IIS7.5) so I skipped this.

To change ASP.NET settings in IIS 7.0

Now we’re ready to run the MCXStandalone.msi

First you’ll need to copy the McxStandalone.msi to C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup, then execute C:\Program Files\Microsoft Lync Server
2010\Deployment\Bootstrapper.exe

During the installation you will be presented with “Installing MCXStandalone…” (see below)

Certificate Update

Now we need to update our internal SAN certificate, this needs to include the newly created lyncdiscoverinternal
record our internal certificates and first up we have to find the correct certificate identifier or thumbprint for this to be completed successfully. To display all certificates type the following within the Lync Management Shell:

Get-CsCertificate

This will return all certificates and their corresponding thumbprints, in my case all certificates are the same, so I can run the following command to update the cert for all uses.

Set-CsCertificate –Type Default,WebServicesInternal,WebServicesExternal –Thumbprint <Certificate Thumbprint>

During this process I was presented with a warning, upon further investigation neither Lync Discovery addresses were within my internal or external SAN certificates. To re-generate, I ran the following command within the Lync Management Shell

The easiest method for re-generating certificates is by re-running the Lync Deployment Wizard, going to Install or Update Lync Server System and executing Step 3 Request, Install or Assign Certificates

For more information on this the Microsoft MCX deployment guide details alternate certificate scenarios i.e. where you have a unique cert per usage type, refer to the section – Modifying Certificates for Mobility

Forefront TMG Configuration for Lync Mobility

There are two approaches here, one uses SSL for setup the other does not. The main reason for allowing a re-direction from port 80 (http) to 443 (https) is to avoid the need of replacing your existing SAN.

The recommended approach is to only permit the Lync mobility client to communicate on port 443, so I replaced the certificate within my existing Lync web listener within Forefront TMG – so we’re going to run you through this setup below (you could also add the additional public name “lyncdiscover.SIPFQDN” to an existing Lync website rule, but I’m going to run through this as an independent rule).

First we need to create the new web publishing rule (see below)

Give it a name (see below)

Select Allow (see below)

Select Publish to a single Web site or load balancer (see below)

Select Use SSL to connect to the published web server or server farm (see below)

Specify your internal site name, this will be the name of your Front End Pool (see below)

Path should be “/*” and select the check box for Forwarding the original host header (see below)

Add the public lyncdiscover address (see below)

Select your existing Lync web listener, with the new SAN certificate that now includes the lyncdiscover address. Select No delegation, but client may authenticate directly (see below)

Finally allow requests from All Users and Finish

You will now need to go into your newly created web publishing rule and go to the to tab, in the section Proxy requests to published site, ensure that Requests appear to come from Forefront is checked for a single Front End server or Standard Edition server. Alternatively select Requests come from the original client if you have a Front End Pool (see below) This statement is incorrect, and unlike the single Front End server scenario was not tested directly and was taken directly from the official documentation - in both scenarios requests should appear to come from TMG.

Finally go to the Bridging tab and change the default ports from 80 -> 8080 and 443 -> 4443 (this is the external web site on your Lync Front End). Once complete ensure you apply the new rules.

Your TMG rule is complete!

Push Notifications Configuration

Push notifications are handled by Microsoft Office 365 or Lync Online, so you need to have federation deployed and run the Set-CsPushNotificationConfiguration cmd-let

First let’s enable push notifications within the Lync Management Shell by running:

Set-CsPushNotificationConfiguration

Next we should enable federation with Office 365 (if not completed already), within the Lync Management Shell type: (this will add a new Hosted Provider)

New-CsHostingProvider –Identity "LyncOnline" –Enabled $True –ProxyFqdn "sipfed.online.lync.com" –VerificationLevel UseSourceVerification

Then add the Lync Push federated domain type:

New-CsAllowedDomain –Identity "push.lync.com"

That’s it!