Tag Lync 2010

Hi,

This has been coming up a few times in recent days on forums and distribution lists.

The question is can I install Lync Eval now, and then transfer to full Volume Licensed RTM code when it is available.

Well yes you can and it is supported.

Here’s how:

After you get access to volume bits  through a normal sources like the volume license site:

On every machine which has EVAL version of Server.MSI installed: 

1. run "msiexec.exe /fvomus server.msi EVALTOFULL=1 /qb (Note: the server.msi is from Volume media)

2. run PS cmdlet "enable-cscomputer"

Hope that helps

Cheers

Nathan

If you are at all into Unified Communications then you will have heard of Lync 2010. The new replacement for Office Communication Server 2007 R2 (OCS) which is now available as a Release Candidate and will ship soon.

Given that Lync has a huge amount of functionality, ranging from simple instant messaging to being a complete PBX and conferencing system, getting a “simple trial” underway may be daunting for some.

It is for this reason that Microsoft UK has worked with one of our UC Partners, PostCTI, to make available a fully featured trial which is hosted and free for 60 days.

Now if you don’t have the time, equipment or experience to get your own pilot going, you can sign up for this new hosted pilot and get a full 60 days to try all the features of Lync including the telephony pieces!

To sign up go here:

http://www.lynctrial.com

When you sign up use the Promo Code – MSUCC.

I hope this gets you excited about the possibilities in Lync. Feel free to get in touch if you would like to discuss how Lync could work for your business.

Cheers

Nathan

Well sort of!

G.711 is a voice codec, used by the majority of IP PBXs to encode their audio.

OCS and Lync can use it in some circumstances, although Microsoft also has their own codec called RTAudio, which is an adaptive codec and thus aims to cope well with challenging network bandwidth.

In OCS there is the Mediation role which was used to convert from RTAudio to G.711 as media flows out to the PSTN.

In Lync the mediation role has been allowed to be collocated with the Front End server. This is possible because of something called Media Bypass, which allows calls to the telephone system (PSTN) to send the signalling through the Front End with collocated Mediation server, but not the media. So instead of the end Lync client talking RTAudio to the Mediation server and then having it converted to G.711 and sent out to the PSTN Gateway, the media goes direct to the gateway. This allows for less load on the Mediation server.

There are various caveats, such as what happens if the client is external. In this case the media will come in as RTAudio via the edge server and need translating via the Mediation server. Depending on the level of externally originated PSTN traffic, you may consider a separate Mediation server pool for load purposes.

Equally another point is that for large FE pools where SIP Trunking is used (Rather than E1 connections from gateways) it is suggested to have a Mediation server pool so as to simplify the relationship between the provider of PSTN connectivity and the pool. (Simply put to allow for perhaps 2 mediation servers each with individual trunks for HA, rather than a pool of 8 combined FE and Mediation boxes with all the required trunks!)

So to answer the question, yes in some ways, and with the right provider a Lync client could potentially send audio (media) traffic direct to the PSTN, however signalling still needs to go through the Front End/Mediation server. Therefore the only scenario where media would flow without the FE is where a call has already been setup. At that point if the FE went down, the call would still be able to continue.

Cheers
Nathan

I have spent a fair amount of time recently working with Lync 2010 testing out new features and trying to figure out how everything works! One of the exciting developments in Lync is how well integrated it is with the rest of the Microsoft product stack. For me however this has caused some serious challenges as my knowledge of SharePoint is minimal, and certainly limited to end user knowledge.

This post outlines the process needed to get Lync showing photos uploaded to a users “My Site” in SharePoint 2010.

I am making the assumption that you already have SharePoint installed and that it has functioning “My Sites”. This was done for me by a colleague SharePoint consultant!

What follows is a discussion of the steps taken to get integration with AD to work and some of the troubleshooting tools I found along the way.

I started off by following this blog post:

http://blogs.technet.com/b/dcaro/archive/2010/06/05/replicating-user-pictures-from-sharepoint-2010-to-exchange-2010-and-communications-server-14.aspx

Step 1 from the above is easy to follow.

Step 2, makes the assumption that the User Profile Synchronization service is already in place. For me this was the case, however there was an issue with accounts which I will come onto!

Having followed Step 2 my final configuration screen looks like the below:

The reason I show that is because it shows the Source Data Connection. Given that I didn’t set this up, I thought I would investigate further, and it’s a good job I did because it became important to know what user account was being used for synchronization.

Back on the Central Administration, Manage Profile Service page seen below, I clicked on the Configure Synchronization Connections link.

You can see the Active Directory connection shown on the Picture Export screenshot above. Drilling into the connection shows that it runs using the 123-shpt service account.

With this knowledge, let’s return to the original blog post we were following here:

http://blogs.technet.com/b/dcaro/archive/2010/06/05/replicating-user-pictures-from-sharepoint-2010-to-exchange-2010-and-communications-server-14.aspx

We are now onto Step 3

I kicked off a full synchronization but it didn’t look like much was happening and photos certainly weren’t appearing in AD. At this point I looked at the event logs on the SharePoint server.

What I found was a bunch of errors like this: FIMSynchronizationService – EventID 6050 – Error

The following two blog posts both helped troubleshoot this.

http://blog.jussipalo.com/2010/02/sp2010-fimsynchronizationservice-errors.html

http://www.tsls.co.uk/index.php/2010/05/06/sharepoint-2010-user-profile-synchronisation-failing/

They also led me to discover the FIM Synchronization Service Manager (SSM) which is located here:

C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe.

This application is your window on FIM and shows exactly what is happening during the synchronization.

I discovered that my problems were permission related.

What was needed was to ensure that the account mentioned above (in the SharePoint Directory Connection section (123-shpt) has the relevant rights in AD. This is confusing because a number of posts say that it the account which runs the FIM service which needs rights, but this doesn’t appear to be the case.

So I gave the 123-shpt account replicating directory changes permissions as detailed below:

Confirm that the service account used to run Forefront Identity Manager Synchronization Service (FIMSynchronizationService) has the AD Security right of “Replicating Directory Changes” at the domain level

1. Open the Active Directory Users and Computers snap-in
2. On the View menu, click Advanced Features.
3. Right-click the domain object, such as “company.com”, and then click Properties.
4. On the Security tab, if the desired user account is not listed, click Add; if the desired user account is listed, proceed to step 7.
5. In the Select Users, Computers, or Groups dialog box, select the desired user account, and then click Add.
6. Click OK to return to the Properties dialog box.
7. Click the desired user account.
8. Click to select the Replicating Directory Changes check box from the list.
9. Click Apply, and then click OK.
10. Close the snap-in.

Having done this the I kicked off another Full Synchronization in SharePoint and whilst viewing though the FIM SSM mentioned above, saw that connections were taking place.

However, there were still errors! Again they were permissions based, and this time it was specific to the end users who I was trying to provision a photo for.

After a fair bit of digging it turns out that the 123-shpt account also needs rights to all users in the domain to provision permissions.

I provided this by setting permissions for the 123-shpt account on the root of the domain. I used the advanced settings to ensure that the permissions only applied to Descendant User Objects. At a high level the permissions needed are Read, Write and Create all child objects however when broken out they look more complex as seen below.

Having made those changes, I kicked off a final Full Synchronization and found that photos were imported demonstrated by viewing the Attribute editor of the user object.

Signing out and back in on Lync made the photo show up.

Hope that helps people

Cheers

Nathan

Hi,

Having just written a long (ish) post on a forum, I thought I would post it here for future reference.

These are high level methods of connecting OCS 2007 R2 or Lync 2010 to the PSTN.

There are three options;

In terms of capability of connection to the PSTN (Telephone network) functionally nothing much has changed in Lync 2010 compared to OCS 2007 R2 other than the need for SRTP support in gateways.

The lack of change is not a bad thing, as you really already have plenty of options!!

1.

Traditionally people have ISDN connections to the telephone network which in the USA are called T1 lines which give you a potential 24 channels (calls). Lync 2010 Server has no way of connecting to these ISDN lines without some form of interface. This could be putting an ISDN interface card into your server, but in general is by using a gateway device from the likes of Audiocodes or NET Quintum.

The gateway terminates the ISDN lines and then translates the audio into RTP streams (SRTP for Lync) and SIP for signalling (i.e. setting up who is calling who).

Generally this is the most used option as by terminating the ISDN lines on the gateway it is then possible to route calls either to Lync or to an existing PBX system

2.

The next most common option is to use an existing PBX to terminate the ISDN lines and have it talk to Lync, either through a gateway (kind of a reverse of the order above) or, the PBX might be able to talk SIP, and use TCP to talk over Ethernet to Lync.

3.

Instead of dealing with traditional ISDN lines the Lync server will connect over IP (TCP or UDP) Port 5060, to an ITSP (Internet Telephony Service Provider). For example people like Verizon, BT, Global Crossing etc.

This allows OCS to route and receive calls directly to the PSTN without the need for any legacy telephony equipment.

Sometimes, even with the above solution, a gateway can be useful, which can be used more like a session border controller, giving options to manipulate the traffic as it passes from Lync to the ITSP.

Hope that clears things up.

Cheers
Nathan