Archives September 2010

A new job; yes another one!

Hi,

It’s not been that long since the last of my job posts, but sometimes that’s the way these things go.

As regular visitors will know, I’ve been working at Grey Convergence as UC Lead for the last three months. It’s been a brilliant experience, and I feel that I have both learnt and hopefully also contributed a lot. The company has made a huge leap forward and, if the number of Lync 2010 meetings that are lined up are anything to go by, will be very busy over the next few months.

So I am therefore both sad and excited to say that I am leaving. Sad because it’s a great company to work for; people focussed, both internally and with clients. I know that had I stayed I would have learnt a great deal more, as I had only just started getting to grips with the working methods and philosophy which in my career so far are unique and which was what drew me to Grey Convergence in the first place.

The excitement comes from my new job. I’m honoured to have been given a role at Microsoft as a Unified Communications Technical Solution Professional.

The UC TSP role is pretty much my ideal job! In a nutshell my aim is to communicate with Microsoft customers (and partners) the new unified communications technologies such as Lync 2010 and Exchange 2010. I will be presenting, leading chalk and talks and supporting the Microsoft sales teams in helping companies make the decision to implement what I truly feel is some of the most exciting technology out there at the moment.

Of course I am looking forward to the new challenge a great deal, but as some people have told me, it does mean buying some new shirts, as working for Microsoft means I will no longer be an MVP, and MVP shirts make up much of my wardrobe!

Cheers

Nathan


Can Lync send audio/media direct to the PSTN using G.711?

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


Getting photos in Lync 2010 from SharePoint via Active Directory

 

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:

image

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.

image

image 

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.

image

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

image

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.

image

image

image

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.

image

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

image

 

Hope that helps people

Cheers

Nathan


Enabling RDP management access to Forefront TMG 2010

Over the last few weeks I have been building up a new home lab system for production and semi production testing.

The system runs on my new Dell Vostro 430 machine with i780 CPU and 16GB of RAM and hosts Exchange 2010 SP1 and Lync 2010 RC amongst other things.

One of the other things is the Forefront TMG box that publishes various content to the Internet. Until recently I was managing TMG via the console viewer on HyperV, however on Friday last week a colleague helped me setup internal RDP access for remote desktop. Here’s how:

First open up Forefront TMG Management console and in the left hand pane click on Firewall Policy.

In the far right pane, click on Toolbox and drill down into Computer Sets to find Enterprise Remote Management.

image

Double click Enterprise Remote Management to open the set and then use the Add button to ensure that your internal subnet is listed.

image

Next back in the left hand pane right click Firewall Policy and create a new access rule:

image

You should give the rule a meaningful name like TMG RDP Management and then setup the rule to allow RDP (Terminal Services) traffic from the Internal network to the Local Host.

image

At this point save all the new configuration and enjoy being able to manage your TMG box via RDP from your LAN.

Cheers

Nathan


Connecting Lync 2010 or OCS 2007 R2 to the PSTN

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


MMMUG September 2010 – Exchange virtualisation

Hi,

Tony and I have another MMMUG event setup in a couple of weeks as per the below:

Hot on the heels of the August event we now have the September event booked. The subject of the event is Exchange Virtualisation, it’ll be held on Thursday 30th September and EMC will be presenting for half of the session.

Since there wasn’t really time for a Q/A session in the last meeting – we’ll making up for it in this one with half of the time dedicated to a roundtable discussion.

The meeting will be held at one of EMC’s London offices (near Southwark tube station) – there are spaces for 30 people and food and drink will be provided.

Meeting Agenda:

6:00pm – Registration & Welcome

6:30pm – EMC – Virtualising Exchange 2010

             · Introduction and Welcome
             · Why Virtualising Exchange
             · EMC Testing and Validation
             · Backup and Recovery
             · Compliance
             · DR options in a virtual world
             · Q&A

7:30pm – Refreshments

8:00pm  -  Roundtable discussion

9:00pm  -  Meeting ends

Meeting Location: EMC Consulting, Room 3.3, Notcutt House, 36 Southwark Bridge Road, London SE1 9EU.

 

To sign up see the link here

 

Hope to see you there.

Cheers

Nathan


Windows XP SP3 Address Bar return

Yup, I know, why am I using Windows XP SP3. Well I’m not, it’s on my wife’s laptop.

Anyhow, with the install of SP3 a while back, we noticed that the address bar was gone from the task bar. It turns out that this was a “by design” issue rather than a bug as described in the KB article below:

http://support.microsoft.com/kb/951448/en-gb

To rectify the issue originally, I found a third party utility which provided an address bar, however after some recent tidying and software un-installation, it vanished!

Having looked around, there is a much better option which doesn’t require any hacking of system files as mentioned in various website, or the use of a third party tool.

To get the taskbar back, simply drag the My Computer icon up to the top of your screen and drop it. It will then create a bar along the top edge of the screen and from there you can right click, go to the toolbar list and add the “address bar”. Now, right click again and remove My Computer from this bar after which you will be left with just the “address bar”.

Finally, click to pickup the address bar and drag it off the top of the screen and down onto your real taskbar. You may have to play about with exactly where to drag it, but get it right and it will dock into the main task bar and you will have you normal address bar back.

Cheers

Nathan