Month: June 2011
Removing server roles from OCS 2007 R2 servers
Unfortunately, if you follow the instructions here (http://technet.microsoft.com/en-us/library/dd572507(office.13).aspx) to the letter, you’ll get an error when you try to remove the Core Components.
The OCS Admin Tools are not listed in the removal order, and unfortunately will prevent you removing the Core role. So, where it says this….
If you are removing an Edge Server, a Mediation Server, an Archiving Server, or a Monitoring Server, remove the Office Communications Server 2007 R2 components in the following sequence:
- Microsoft Office Communications Server 2007 R2, Edge Server
- Microsoft Office Communications Server 2007 R2, Mediation Server
- Microsoft Office Communications Server 2007 R2, Archiving Server
- Microsoft Office Communications Server 2007 R2, Monitoring Server
- Microsoft Office Communications Server 2007 R2, Core Components
- Microsoft Office Communications Server 2007 R2, Unified Communications Managed API 2.0 Core Redistribution package
..it should actually read…
If you are removing an Edge Server, a Mediation Server, an Archiving Server, or a Monitoring Server, remove the Office Communications Server 2007 R2 components in the following sequence:
- Microsoft Office Communications Server 2007 R2, Edge Server
- Microsoft Office Communications Server 2007 R2, Mediation Server
- Microsoft Office Communications Server 2007 R2, Archiving Server
- Microsoft Office Communications Server 2007 R2, Monitoring Server
- Microsoft Office Communications Server 2007 R2, Administrative Tools
- Microsoft Office Communications Server 2007 R2, Core Components
- Microsoft Office Communications Server 2007 R2, Unified Communications Managed API 2.0 Core Redistribution package
Just sayin.
Migrating Dialogic Media Gateway from OCS R2 to Lync Mediation Servers
Having deployed a Lync pool alongside our OCS 2007 R2 pool, merged the topologies, and migrated the users all without much issue, I then wanted to migrate calling away from the OCS mediation servers to the Lync mediation servers. Sounded easy. Unfortunately it wasn’t. Outbound calling worked ok, but inbound calling failed.
As you see in the diagram, the topology is fairly straight foward. Two PSTN gateways on 10.10.10.1 and 10.10.20.1, listening on TCP:5066 and 5060 respectively – one talking (hopefully) to a Lync mediation server (10.10.10.4) on TCP:5066 and the other still talking to an old OCS 2007 R2 mediation server (10.10.20.4) on TCP:5060. For now, forget the 10.10.20.x devices.
Steps I followed to get to this point were essentially as outlined in this Technet library (and the equivalent downloadable word version) http://technet.microsoft.com/en-us/library/gg398092.aspx. In short, define a PSTN gateway in the Lync topology, set listening ports on PSTN and Mediation objects, define and commit a voice route, publish topology, done.
What isn’t well documented here is that if for any reason you change the listening ports for the mediation server after initial publish (which I did, mostly just to bring the port allocations in line with the new Lync default ports as the old OCS deployment was using weird ports), you have to restart the Lync Mediation service, otherwise it wont pick up your port changes, even if you re-run the deployment tool.
So at this point, outbound calls were working. No issue. Happy admin.
But incoming calls from the PSTN would fail with “VoIP Transport Failure” on the Dialogic.
What I had already done on the Dialogic was change the routing table properties, specifically the VoIP Host Group settings, to use the new gateway (as the old OCS R2 mediation server was on 10.10.10.3). This is done in the Dialogic UI under Configuration > Routing Table > VoIP Host Groups (radio button at the top). My config here is pretty straightfoward – a single host group, with a single host entry of the old mediation server. Removed the old host entry, added a new one for 10.10.10.4, and expected everything to just work. It didn’t.
When calling in, the line would never ring, you’d see the call appear in the Dialogic Call Log, but after about 15sec it would fail giving the caller a ‘number not connected’ tone, and the Call Log would display “VoIP: Transport Failure”.
Spun up two sets of logging – first I started the Trace Logger on the Dialogic, and second started a set of Lync logs on the mediation server (S4, SIPStack, MediationServer) – then tried another inbound call. Logging on the mediation server showed zero entries, so clearly nothing was getting past the Dialogic. Looking at the trace logs on the Dialogic, I found the following:
[RouteTable] Code outbound device: VOIP (user@host:port) @10.10.10.4:0
So my incoming call was being routed to the mediation server IP ok, but no port was being passed, so logically I would expect the mediation server to reject it at the network layer, as it didn’t match a listening port.
So, on a hunch, I went back to the VoIP Host Groups setting, and changed the host value from 10.10.10.4 to 10.10.10.4:5066. Instant success. Just for consistency, checked another trace log, and sure enough it looks like this:
[RouteTable] Code outbound device: VOIP (user@host:port) @10.10.10.4:5066
What made this unexpected was that the old host value didn’t include the port, just the IP, but for some reason it worked fine.
Usefully, at this point I’d only migrated one of our two Dialogics/Mediation Servers, so ran the same trace log on the un-modified Dialogic (10.10.20.1). Sure enough, the same thing happens – no port is passed in that RouteTable call. Yet it works. Keen to see more, I ran a “netstat -an 1 | findstr 10.10.20.1” on the OCS mediation server to start an endless netstat search for open connections to the Dialogic (refreshing every second). As soon as the call comes in, a connection opens between the two devices on 10.10.20.1:5060 and the call connects. So somewhere in between that routing call to 10.10.20.1:0 becomes a call to 10.10.20.1:5060. I confess, I don’t know how this manages to happen.
Hopefully this helps someone else avoid the frustration this has caused me. And if anyone has any ideas how OCS manages this port wizardry where Lync fails, I’d love to hear your thoughts.
SharePoint column lookup and calculation limitations
List lookup columns in SharePoint are great. Easy to setup, simple to use, and powerful. But they have some limitations that can be frustrating.
Let me paint you a picture..
You have a SharePoint list that contains information about a customer entity (yes it should probably be in CRM, but lets assume you don’t have one) – fields like contact names/numbers, addresses, unique systems, notes, etc. Some of these fields are single lines of text, pull-down menus, yes/no radio buttons, multiple lines of text, you name it.
You have another list that relates to sales of products to customers. Unsurprisingly, you want to link a sale to a customer, and you want to leverage the power of lookup columns to make that a simple and seamless process.
Not an unrealistic scenario. Sure there are better ways of doing it with the likes of webservices into CRM or BCS connections into LOB databases, but they all involve additional systems, coding skills, and generally more effort. All things that aren’t always readily available.
By adding a lookup column type to the sales list you can allow a customer entity to be selected from your customer list. Where this gets handier is you can have the sales list pull other values from the customer list without adding extra columns. Awesome.
But… not all the columns from your customer list are available. Why not?
SharePoint can only perform a lookup of values from columns that contain a ‘text’ value, and then only if it contains a single line of normal text (ie. “Single line of text”, a “number”, or “date”). Any field that contains multiple lines of text, other lookups, or multi-select items won’t be available to you, as SharePoint will automatically hide any columns that it knows it can’t return.
This same restriction applies to using these column types in calculated columns, and there is a great post by Dessie Lunsford on getting around this limitation in terms of calculated columns which you’ll find here – http://www.endusersharepoint.com/2009/06/17/taming-the-elusive-%E2%80%9Ccalculated-column%E2%80%9D-referencing-multiple-lines-of-text-column/
The workaround involves creating your problem field as a “single line of text” column, then creating a second calculated column that references the first column name – eg. [=ColumnName]. You then delete the first column and recreate it with the exact same name but this time selecting your column type of choice.
While Dessie’s post deals specifically with referencing these columns via calculated fields, by dint of good fortune and SharePoint consistency, the same workaround fixes the lookup problem as well. Thanks Dessie!
This issue applies to all versions of SharePoint since 2007, including SharePoint Online (BPOS/Office365)
External Response Group Call Routing with Lync Server
Once you start playing with Response Groups in Lync (or OCS) it probably wont be long before you want one to dial out to your PBX. In my case recently it was to get a support line to call an on-call mobile.
Out of the box, Lync wont.
Any outbound call needs a voice route to determine its routing path and permissions – without one it simply cant go anywhere. In short when the RGS tries to dial out it will default to your global voice policy which (unless you’ve changed it – and you shouldn’t) wont route.
Your first task is to therefore create a voice policy that includes the number (or number pattern) you want to call and define a gateway device.
- You can do this via the Lync Control Panel or Powershell.
- Make sure the voice policy is of type ”User” otherwise you wont be able to apply it to your RGS object
- Make sure you commit the new policy otherwise it wont be available for use (you’ll get a policy is not a user policy error).
Then you need to bind that policy to your RGS object. You definitely need Powershell for this bit.
Grant-CSVoicePolicy -identity “RGSWorkflowObject” –PolicyName VoicePolicyYouCreated
For identity, use the display name of your RGS Workflow object.
And you’re done. Your RGS can now dial out.
Last tip – make sure the number you’re trying to dial out to is entered fully normalised in the format +<countrycode><areacode><number>@<sipdomain>.
EDIT: My buddy Dono over at UCWhatIDidThere.com has just blogged about a great way of determining which voice policy is assigned to a response group object. Check it out at http://www.ucwhatididthere.com/?p=101
On The Socials
What happens if you jump the gun installing SP2010 SP1
June 30, 2011
2010, SharePoint
No Comments
gingerninjanz
Quick post on what seems a common issue.
You apply SP1, reboot the server, and open Central Admin to see all the bright shiny bits in SP1.
But alas, Central Admin returns a 503 error. In services.msc you find most of the SharePoint services are not started – admin, timer, user code host, search. Oh no!
Fear not, it’s just a case of being too keen for the shiny. The last step of the upgrade is to run the SharePoint Config Wizard. This completes the upgrade process, starts your services, and brings you all that is shiny and new.
Enjoy
Service PackTipsUpgrade