I came across a post on the TechNet forums recently where someone was asking a lot of questions about how photos are implemented and managed in Lync. Given that there aren’t many examples around of the behaviour, I thought it was worthwhile writing this up and including some screenshots.

How are photos controlled?

All control over how photos are displayed in Lync is done via a client policy. You can control this part of a policy either by modifying the default global client policy or by creating a new client policy and assigning this to the users you want the control of pictures to apply to.

Determining what is currently configured

To find out what control of photos a policy is applying, you can run Get-CsClientPolicy to retrieve all the current configuration of a client policy. The configuration item you’re looking for is DisplayPhoto.

How do we implement this?

For this post, I’ll assume we have an existing policy called PhotosControl that we’re going to modify to achieve this. You could either modify the existing Global client policy, or create a new one using the New-CsClientPolicy cmdlet.

We’ll be using the following Lync Server Management Shell cmdlets to demonstrate this:

Set-CsClientPolicy - This will allow us to change the configuration of the client policy.
Grant-CsClientPolicy - This will allow us to assign the client policy to a user or group of users.

There are three configurable options in a Lync client policy that control how photos are displayed, and these are defined as variables of the -DisplayPhoto switch.

Allowing any photo to be shown in Lync

This setting will allow the user to either specify a URL, use the AD or SharePoint stored photo, or turn off photos altogether as illustrated below.

Set-CsClientPolicy -Identity PhotosControl -DisplayPhoto AllPhotos

This configures the client policy called PhotosControl to allow the user to display any photo in Lync (by specifying a URL, using the corporate photo, or displaying no photo at all).

To assign this to a user, we run Grant-CsClientPolicy -Identity sip:justin.morris@justin-morris.net -PolicyName PhotosControl

The results on the client endpoint are shown below.

When we open up Options in Lync, this is what we see. The user has the option to show a picture from a web address they input, the default corporate picture from AD/SharePoint, or no picture at all.

Showing photos from Active Directory only in Lync

This setting will display the AD or SharePoint stored photo, but will also give the user the option to turn off photos altogether as illustrated below.

The cmdlet syntax for this as as follows:

Set-CsClientPolicy -Identity PhotosControl -DisplayPhoto PhotosFromADOnly

Now, we already assigned the policy to a user in the last section, so all we need to do is sign out and sign back into Lync to see what the resultative behaviour is.

When we open up Options on Lync, here’s what we see. The user only has the option to show the default corporate picture from AD/SharePoint or no picture at all.

And this is reflected on the main UI of Lync accordingly.

Disabling photos completely in Lync

This setting will display no photo at all and Lync will drop back to only displaying the small, square presence icons. To other users, they will see no photo of you on their contact list.

The cmdlet syntax for this as as follows:

Set-CsClientPolicy -Identity PhotosControl -DisplayPhoto NoPhoto

Now, we already assigned the policy to a user in the last section, so all we need to do is sign out and sign back into Lync to see what the resultative behaviour is.

The results in the main Lync client UI look like this:

Very similar to what things looked like in Office Communicator 2007 R2. Great for when you want to deploy Lync but don’t want the UI look and feel to disrupt users too much.

And if we open up Options, we see that the My Picture tab is completely gone and we can’t change anything.

Conclusion

As you can see, there is a very granular level of control over how photos are presented in Lync. Using the cmdlets above you can mix and match as to which users can and can’t display photos and whether they can display any photo they like or only what you’ve imported into AD/SharePoint.

Hope this helps you determine how you’ll deploy photos and as always, any questions/comments below.

A presentation went up this afternoon (GMT+1) from TechEd 2011 NA by Kirk Gregersen titled Lync 2010 & the Future of Productivity. It’s about an hour long and covers a lot of content. It is somewhat high level, but there are a few things covered in this video that are well worth the watch (I’ve highlighted the super important ones in bold):

• How the user experience is the key focus of the product group. It remains pretty high level for the first 10 minutes and includes a demo of Lync (focusing on contact card pervasiveness in Outlook, SharePoint etc).
• Live demonstrations of:
  • The language translation app running on Silverlight.
  • The meeting schedule and join experience.
  • PowerPoint controls in a meeting, allowing a user to jump back and forth through slides.
  • The meeting recording experience.
• Mobile client demos (32 minutes in) of Windows Phone 7 and iPhone.
• Case study videos from LA Fitness, Commonwealth Bank of Australia and Herrenknecht.
• More demos of application development and client extensibility:
  • IM and Expert including how questions are asked, how an expert provides data on their knowledge and the interaction that takes place between the question asker and the answerer via the bot on Lync.
• A demo of Polycom multi-party video conference.
• A brief overview of the Lync Roadmap for 2011.
  • US and UK pilot around online voice later in the year.
  • WP7, iPhone, Blackberry, Android, Nokia clients coming by end of calendar year.
• A few words on the Skype purchase and what this means for Lync. “We (the Lync Product Group?) have been working on this as far back as January”.
  • Compares Lync to Skype, and how there is an interesting opportunity to marry the two via networks/federation.
  • The first public comments from the Lync team on the Skype integration.

You can view the presentation here. Some really exciting developments today, mostly around seeing the iPhone mobile client in action for the first time. Let’s hope we see Lync showcased some as TechEd NA rolls on.

Recently I needed to setup URL filtering on Lync Server for a project. Pretty simple task you’d think, but I needed to exclude local intranet hyperlinks from being blocked as well. I found out that this is much easier said than done in Lync.

The Problem

Everything exists in the Lync Server Control Panel for this, and there is advice here on TechNet to configure it, but it’s very vague and only scratches the surface as to what is actually required. To get this working, you need to add the URLs you want to exclude to the Local Intranet Sites zone on each Front End Server, as per TechNet.

The URL Filter page in the Lync Server 2010 Control Panel

Sounds easy enough right? Wrong. Because the Lync Front End Server service now runs under the Network Service account, you can’t just open up your Internet Options and pop them in there, you need to open Internet Options as the Network Service account.

Usually to execute an application under a different account, you can use the runas command, which would look like this:

runas /user:”NT Authority\Network Service” “C:\Program Files\Internet Explorer\iexplore.exe”

This doesn’t work properly though, because you’re prompted for the Network Service password, which we don’t know (because this is a system account). The way around this then, is using the PsExec tool from SysInternals. The process to point you in the right direction for doing this is detailed here by Ben Parker (hat tip to Paul Nearney, a fellow Modality rockstar for bring this to my attention).

So using PsExec, the command we want to run is:

psexec -i -u “NT Authority\Network Service” “C:\Program Files\Internet Explorer\iexplore.exe”

The Internet Options dialog when executed under the Network Service account

Pretty useless really, because we can’t change anything! We can’t click on Sites to add the URLs we want to exclude, so we’re stuck. This is where I escalated this problem to Microsoft.

The Workaround

I engaged Microsoft PSS and after some investigation and reproduction of the issue, the engineer (thanks to Debasis Mishra) and the Lync Product Group identified this as a bug and came back with a workaround.

To get this working today, we need to do a bit of registry hacking to add local intranet URLs manually to the Local Intranet zone:
The Network Service like all AD objects has a SID and that is unique and common across all. The SID of Network Service account is S-1-5-20.

1. Launch the registry on the Lync Front End server and browse to HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains (in case you don’t find ZoneMap and Domains, create new keys with these names in the Internet Settings key).
2. From here, we can add the first Intranet site which is, let’s say for example http://contoso.com.
3. Under Domains, create a new key and name it contoso.com.
4. Next, create a DWORD with name http and set the value to 1. You can do the same for https if you need this.
5. Similarly for a second site, create a key and name it contoso.local for example.
6. Here you need to create DWORD(s) for each protocol you want to allow. Let’s say one with the name https and the other with the name ftp. Set the value to 1 for both.
   

   Excluding local intranet URLs from filtering in the Windows registry

7. Once done, restart the FE service and you should now be able to send IMs with the intranet URLs you’ve specified e.g. http://www.contoso.com

And there you have it, that’s how you do it my friends. A bit convoluted right now and messy, but it get’s the job done. Hopefully a hotfix will be released in an upcoming Cumulative Update and the documentation will be updated.

Let me know if you have any problems with it in the comments section below.

So, today it all went down. There were rumours floating around since Sunday that either Facebook, Google or Microsoft were going to snap up Skype. Commence a flurry of observations and comments as to why one or the other would/should buy Skype.

Fast forward to Tuesday and it’s all a done deal. Microsoft have purchased Skype for some $8 billion in cash. A hefty sum to pay, considering eBay sold Skype to a bunch of investors for only $2 billion only 2 years ago. They have had some awesome growth since then however, and have delivered new functionality to the market like video calling from the desktop to the mobile.

There were blog posts and news articles everywhere saying it was soon to come and each was speculating on why this is strategic for Microsoft, how it will affect consumers and what will happen to Skype when they become part of Redmond. This all cumulated in a press release and live conference this afternoon (London time) that announced a few things:

• Skype will connect users with Lync, Office 365, Outlook (does this mean a Skype Outlook add-in?) Windows Live and Xbox Kinect.
• Enhance Lync for our enterprise customers (interoperate with Skype).
• Continued commitment to non-Microsoft platforms for Skype.
• An entirely new business division will be created under the current Skype CEO’s (Tony Bates) leadership “Microsoft Skype Division” and Bates will become the President of this division, reporting directly to Steve Ballmer.

Here’s an interesting question, what will happen to David Gurle the current head of Skype’s Business division? He’s a previous Microsoft employee, and he used to head up the LCS team in Microsoft. Will he want to stick around and bring some value or will he jump ship quick smart?

Also, what will the Lync interoperability look like? Will it be via the Edge Server? That’s the obvious integration point really. They need to deliver every communications modality, not just IM and audio/video. What about archiving and compliance? Security? I can only see this interoperability being delivered in a new version of Lync.

With 600 million users registered and 30 million online at any one time, that’s a huge population of users to connect the existing business communications (running Lync) world to.
It means that any seat in any business and any home can connect to each other using IM, audio/video or collaboration. Not to mention people running Xbox Live with Kinect. Now that’s a pretty exciting nirvana to look forward to.

Recently I completed a white paper that details a lot of information regarding the many ways you can integrate OCS 2007 R2/Lync Server with Cisco Unified Communications Manager. This covers Remote Call Control, CUCiMOC and Simultaneous Ringing (a flavour of Enterprise Voice) and includes loads of screenshots to actually give you a visual idea of what the user experience looks like.

It’s up over on the Modality Systems blog, and you can check it out here.

What if you have a supported back-end server version (e.g. OCS 2007 R1) to coexist with Lync, but you’re running Office Communicator 2005 out on the desktop? What happens when you want to migrate?
It’s going to be pretty rare that you might encounter this kind of scenario, but I did recently and it’s worth documenting the behaviour we observed.
Unfortunately there’s no pretty screenshots in this post, so use your imagination.

The Environment

The situation I encountered was an OCS 2007 R1 backend with all clients running Office Communicator 2005. We deployed a new Lync 2010 Front End pool in the same forest and the two pools happily talked to each other (as OCS 2007 R1 and Lync Server 2010 coexistence is supported).
It was only until we begin running client testing that we started to notice weird things happening.

The Behaviour

If you have one user using Office Communicator 2005 and another user using Lync 2010, you will see strange behaviour if the session is initiated from the Lync user to the OC 2005 user.
If the Lync 2010 user polls for presence of the OC 2005 user in any way, whether this is by searching the address book for a user, expanding a distribution group or exposing their name in Outlook, the OC 2005 user will get a Add to Contact List notification. This detracts from the way things usually work, where you can get presence of a user without first adding them to your contact list.
When I tested this same scenario using OC 2007 R1 and Lync 2010, I couldn’t reproduce the issue.

My only guess is that there is a difference between the SIP INFO packets Lync 2010 and OC 2007 R1/R2 send to get presence information, and the way OC 2005 interprets them.

Obviously this is not ideal, and will most likely pose an unacceptable issue during a period of coexistence whilst migrations are occurring. Given that hundreds of these interactions could occur a day per user in a large environment, this presents a massive support issue for your internal IT helpdesk.

The Solution

In the end, you have two options depending on how long your period of coexistence will be and how complicated/large your environment is. These are:

1. Migrate from OC 2005 to OC 2007 R1 on your existing OCS 2007 R1 backend, then migrate your users to the Lync 2010 backend and upgrade your clients to Lync 2010.
2. Migrate your users to the Lync 2010 backend and upgrade your clients to Lync 2010 all in one go, effectively having no period of coexistence.

In conclusion, TechNet documentation defines that this kind of coexistence is “only supported if Communicator 2005 is on a federated network” and now we know why. I’d say this has something to do with what the Edge Server does to the SIP packets on their way in and out of the network.