Category Archives: Enterprise Voice

What happens when you’re A/V Edge Is Misconfigured: STUN/TURN

Ran into a very interesting issue recently at a customer. Below is the scenario:


OCS 2007 R2

Two pools, each with an associated edge pool.


Associated Edge Pool : EDGEPOOL01

Audio/Video Edge Public Interface: AV1.CONTOSO.COM


Associated Edge Pool: EDGEPOOL02

Audio/Video Edge Public Interface: AV2.CONTOSO.COM

First, the issue: External users homed on POOL02 cannot make/receive calls through the Edge.

We took Wireshark/Network Monitor traces from the external client when the client attempted to make an audio call. While reviewing traces of the call flow, the following error was thrown during the attempted allocate request(To see more details on the expected behavior of this process, check out the Lync Resource Kit Edge Chapter):


The Username Supplied in the request is not known.

The user was sending an allocate request with all required information, Username, Nonce, Realm and Message-Integrity however the A/V Edge Service was rejecting the authentication request stating that the username was unknown.

Next, we reviewed the client UCCAPI log (located at %userprofile%\tracing\Communicator-uccapi-0.uccapilog). When reviewing for the initial SIP INVITE from the user, the candidate list is incomplete. External users must also send Reflexive (Home router public IP Address) and Relay (A/V Edge Interface) IP and port combinations that have been allocated for media.

The initial thought was to attempt a connection to the A/V Edge Public Interface on 443. When users initiate calls they must be able to contact the server on 443 TCP and 3478 UDP to allocate ports. A quick telnet test proved that these connections were open. This proved the theory that the user could not allocate ports with the edge, although it could contact the edge on the proper ports.

m=audio 54614 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101




a=candidate:1 1 UDP 2130706431 54614 typ host

a=candidate:1 2 UDP 2130705918 54604 typ host

a=candidate:4 1 TCP-ACT 1684798463 54614 typ srflx raddr rport 54614

a=candidate:4 2 TCP-ACT 1684797950 54614 typ srflx raddr rport 54614

a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:nMf0n5KQE7L+fajVqoWo+DCMzKj7lHLfwskTMOTt|2^31|1:1

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:XykNc+3nFqRWu3l5IJJs/cAFvsUqaL5/ZaVdRhoa|2^31|1:1




The next step was to review the MRAS request during sign on to validate that it was actually receiving valid media relay credentials, and this is where the issue was spotted. To do this, we opened the client UCCAPI log and searched for MRAS(Detailed Information on this process, and tracking these processes can be found in the Lync Resource Kit Edge Chapter): In the MRAS request the client receives a valid 200 OK From the server, with what would be assumed are valid credentials and server information:


<?xml version=”1.0″?>

<response xmlns:xsi=”; xmlns:xsd=”; requestID=”80980176″ version=”2.0″ serverVersion=”2.0″ to=”;gruu;opaque=srvr:MRAS:k44hfHH-N0O1pJWhN9MnEwAA” from=”” reasonPhrase=”OK” xmlns=””>

  <credentialsResponse credentialsRequestID=”80980176″>

















Because the user is associated with POOL02, it should have received AV2.CONTOSO.COM as its public A/V Edge for Media Relay. However, due to a misconfiguration on the edge pool, the MRAS service was handing back the POOL01 A/V Edge Service. Because of this, the user would connect to that edge pool, but when attempting to allocate ports, the edge server had no idea who that user was.

The fix for this issue was to validate the R2 Edge External Interface configuration, we found that AV.CONTOSO.COM was configured as the public DNS name for POOL02, when it should have been AV2. CONTOSO.COM. As soon as this was updated, the issue was resolved.

Below is a reference diagram to help understand the issue.




Error When Installing UM Role on Exchange 2010 SP1

11/12/2010 12:31:24.0997] [2] Active Directory session settings for ‘install-umservice’ are: View Entire Forest: ‘True’, Configuration Domain Controller: domaincontrollerfqdn, Preferred Global Catalog: “domaincontrollerfqdn”, Preferred Domain Controllers: ‘{ domaincontrollerfqdn }’
[11/12/2010 12:31:24.0997] [2] Beginning processing install-UMService
[11/12/2010 12:31:26.0012] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:26.0012] [2] [ERROR] There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] The following 1 error(s) occurred during task execution:
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
[11/12/2010 12:31:27.0668] [1] 0.  ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)
   at Interop.NetFw.INetFwRules.Add(NetFwRule rule)
   at Microsoft.Exchange.Security.WindowsFirewall.ExchangeFirewallRule.Add()
   at Microsoft.Exchange.Configuration.Tasks.ManageService.Install()
   at Microsoft.Exchange.Management.Tasks.UM.InstallUMService.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()


When running the wizard to add the UM role to your Exchange 2010 Sp1 server, you may have this error appear in the install wizard:

ErrorRecord: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9)

If you take a look at the Exchange setup log, it is trying to add firewall rules, and fails, and kills the install. If your windows firewall service is not running, you must start it.  Re run the installation with windows firewall running, and all is fine Smile

Powershell Script to create new user, enable for Exchange, UM and Lync Server

I created this powershell for our internal onboarding process, figured I would share it with the masses.

I think there are a couple good takeways from this script, it remotes into Exchange 2010 and Lync Server 2010 Powershell sessions, so nothing except Powershell 2.0 is required on the client side, which is standard with Windows 7. It also shows how you can simultaneously use Exchange and Lync powershell commands in the same script to get things done.

A couple of disclaimers:

I am in no way advanced at powershell scripting, so nothing fancy here.

This was developed specifically for my internal needs, you will probably have to add/remove variables and requirements.


Script is above, any freedback is appreciated, if you improve on this at all, I would love to see it as well.

Configuring and Using Call Park In Communications Server 2010 (Beta)

One of the new enhanced telephony features supported in Communications Server 2010 is Call Park.

This feature allows you to “park” a call, and allow another user to pick up this call from the assigned extension. This was a common scenario on traditional PBX systems. Think of  “Randy, you have a call on 12345”. I can go to any phone, dial 12345, and answer the call on hold for me.

This feature requires you to dedicate a block of numbers in your environment for call park. This set of numbers can also start with a * or  #.  You must also be using Communicator 2010 to retrieve a parked call. Below, I will outline how to create a basic call park number range, and how to use this feature in the communicator client.

Note: These commands and screenshots are from the Beta release of Communications Server, appearance of commands may change at release

Creating the Call park Number Range

You can create or modify call park ranges in powershell or in The communications Server Control Panel, the new silver light based control panel for Communications Server.


First, make sure you are on a machine or server with the CS 2010 Admin Tools Installed, Open the  Communications Server Management Shell


For the Beta, the set of commands related to the Call Park service are:


As you can see below, in my environment when I run a Get-CsCallParkOrbit I have a number range configured as park test already in my beta deployment:


The call park number ranges have very basic information associated with them, The identity, and a set of number ranges and a server.

Lets create a new call park range with the name Winxnet Parking Lot and the number range #900-#950

This configuration would allow for me to have 50 Parked calls based on that range.

The command we are concerned with here is New-CsCallParkOrbit

Below is the cmdlet help information on this command:


    Creates a new, named, range of extensions assigned for parking calls within
     an organization.


    New-CsCallParkOrbit -Identity <XdsGlobalRelativeIdentity> -NumberRangeStart
     <String> -NumberRangeEnd <String> -CallParkService <String> [-Confirm [<Sw
    itchParameter>]] [-InMemory <SwitchParameter>] [-Priority <Int32>] [-Tenant
     <Nullable>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

    Parking a call assigns a received phone call to a specific extension for la
    ter retrieval. A call park orbit is the set of extensions defined to a spec
    ific call park server for this purpose. The New-CsCallParkOrbit cmdlet defi
    nes the extensions for a call park orbit and applies them to a specific a s
    ervice. Calls parked within the given range will be parked on the specified
     Call Park Service. Multiple call park orbits can be created; each must hav
    e a globally unique name and a unique set of extensions.


For my example, this command will read:

New-CsCallParkOrbit –Identity “Winxnet Parking Lot” –NumberRangeStart “#900” –NumberRangeEnd “#950” –CallparkService

Note the number range being in quotes because I am using a # symbol.

The output should look like below:


Communications Server Control Panel

The Communications Server Control Panel is the replacement for the old MMC snapin with previous OCS Versions. This is a silverlight based web client to manage majority of Communications Server Settings.

To complete the above configuration in the UI, first open Internet Explorer and navigate to your CSCP web page:


This UI may be changing a bit, so I will just cover what is involved in creating a call park group.

In the left navigation menu, choose Voice Features


You will see in the screenshot above the Call Park Number Range I previously created using powershell.

To create a New range Select New


You will be presented with a form to enter the same information as above. The only difference is that “Destination” is the CallparkService from your power shell command.

User Experience

Now that you have created a Call Park Number Range in your communications server environment, your clients should be able to place calls on park hold, and retrieve these calls.

While in a call, under the Transfer menu, you will have a new Option for Parking Lot


When you choose Parking Lot it will park the call, and notify you the call has been parked, and what number to dial to retrieve. You also have the option to Copy the text. If you copy the text it can be pasted into an IM or an Email to send to another user.


Now, in communicator I can dial the number specified in the message, to retrieve the call.


Once the call has been retrieved, the user will be notified that the call was retrieved, and the person retrieving the call will be connected to the user on the line.


The left side of the screenshot is the notice that the call was answered, and the right side is what it looked like when I retrieved the call.

This is one of the many great new functionalities coming with Communications Server 2010 later this year, to find out more please visit:

To learn more about CS 2010 Powershell, check out this awesome blog

Issue with DTMF While in Conference Call

I am currently investigating an issue I have internally, and have heard someone else having on the Technet forums:


The issue is that when in a communicator conference call, you cannot send DTMF tones to a PSTN participant. The scenario is as follows:

  1. Communicator call, or communicator conference call is initiated
  2. User invites a PSTN number to that conference call
  3. PSTN number requires DTMF tones, whether it is a conference bridge, or an attendant menu, could be various situations
  4. No DTMF is received by the PSTN number.

So far, I have been able to confirm a couple of things. This happens with CS2010 as well as OCS 2007 R2. Internally we use a Dialogic DMG2120 gateway, and I have confirmed that I do not see DTMF on the gateway’s SIP side from OCS.

I am using this post to hopefully get some partners and customers to try this scenario, and see if they have the same issue. I would find it hard to believe that this is a bug in OCS/CS2010 that Microsoft has not addressed, but I am hoping to find a common configuration among people experiencing this issue so we can maybe narrow it down.

Typically this is a gateway issue, however like I said, I have not seen any DTMF come from OCS to the gateway when in the conference call.

Please respond in the comments with a brief description of your OCS setup and gateway/SIP trunk, and if you experience this issue or not.




That was quick!;en-us;2254369&amp;sd=rss&amp;spid=12605

It is identified in the above article. AVMCU does not support DTMF Relay. Thanks to the commenter!

Alternative to RCC With Cisco and OCS 2007 R2

Often I run into customers that want Remote Call Control with their current phone system as an integration architecture with OCS 2007 R2. Personally I see the benefit to remote call control in LCS, and OCS 2007 R1, but not with the R2 release, and especially with Wave 14 so close. Many times I have had to explain the different scenarios, and why I think a different architecture is a better way to approach this. Today I had to develop this information for a Cisco Call Manager implementation, and wanted to have a reference point, as well as share my thoughts on the subject.

To give a brief background, the customer wanted RCC with Cisco, they currently have an OCS infrastructure in place, and wanted to add the RCC functionality to that environment. In order to do this, they would need to upgrade to Call Manager 7, which is the very first reason to not go any further with the RCC architecture in my opinion. If you are investing in the Microsoft Unified Communications technology stack, there is no reason to dump more money into another UC product along side it.

As a summary, here is a description of what RCC is… Credit goes to this blog post

This is a description from the R1 release of OCS 2007 but still holds true today.

Remote Call Control (RCC)


Also this voice scenario was already available in OCS 2007 predecessor Live Communications Server 2005 SP1. The users OC client does not act as a soft phone, does not need an audio or audio/video device connected to the PC and the user is not able to make or receive phone calls by using her/his PC. This is not a VoIP scenario!

User experience

In this scenario, an OCS 2007 user has a PBX or IP PBX phone with an extension (e.g. 1212) standing on her/his desk. In addition to that, Office Communicator (OC) 2007 is installed on the user’s PC.

In the office

On an incoming call the user’s PBX phone rings as well as that she/he receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts). The user is able to accept the call by picking up the receiver of the PBX/IP PBX phone or by clicking on the pop-up window for the incoming call on her/his PC. In both cases, media (voice stream) will stay on the PBX/IP PBX and there will be no VoIP connection to OC! The user does not need an audio device for telephony connected to her/his PC.

At home/on the internet

If the user receives an incoming call to her/his office number while being connected to the company’s IT environment over the internet (e.g. at home), the users PBX/IP PBX phone will ring in the office (what she/he most likely will not be able to hear J) as well as that she/he can see the pop-up window generated by OC on her/his PC. Accepting the call by clicking on the pop-up window will result in this scenario that the phone in the office will activate the speaker phone, but the user is not able to use her/his PC to talk to the caller. No VoIP connection through the internet is established! (However, the user can redirect an incoming call to her/his mobile phone and can pick up the call this way while working remotely.)

How it works in a nutshell

A CSTA Gateway (GW) needs to be installed between OCS 2007 and the PBX/IP PBX. Some PBX/IP PBX systems come with a CSTA interface natively so there is no need for an additional GW. Between OCS and the PBX/IP PBX call control commands will be sent, packed into a SIP INFO message that uses a long-lasting SIP dialog between OCS and the CSTA GW. The CSTA GW converts these call control messages into a format that the PBX/IP PBX understands. A CSTA GW is not a media GW so voice cannot be converted by a CSTA GW from a TDM (Time Division Multiplexing) or PSTN protocol to VoIP! OC can only control the functions of the PBX/IP PBX phone.


With a Cisco integration, we would actually be able to do direct sip as long as the following software requirements are met on the Cisco side:

  • Cisco Unified Communications Manager Release 7.0(2)
  • Cisco Unified Presence Release 7.0(3) with E.164 patch for RCC

One of the key features of the Microsoft OCS Platform is the ability to have not only integrated IM and Voice calling, but also conferencing, all within the same application, and all available through a single click. Any communication can be escalated to a conference by inviting PSTN or VOIP participants at any time. When you introduce the remote call control scenario this is no longer available. A Key thing to point out is that a user in this scenario cannot make or receive calls using communicator, they still must use the Cisco phone in all scenarios, which virtually eliminates the remote worker benefits of OCS.  Below is the list of other limitations taken from the Cisco Documentation on this configuration:

Features Not Supported

· Microsoft OC logon from two locations

· Call Forwarding

· Location Based

· Phone Settings

· Conferencing through remote call control


· Conferencing: OCS 2007 R2 does not support call conferencing through remote call control. Conferencing is available in IP Phone

only or OC only call scenarios.

· Call forward setting on IP phone: Call forward setting made on the Cisco IP phone (desktop), using its soft key button or the Cisco

UCM phone configuration page, is not reflected by the Microsoft OC GUI. As of Microsoft OCS 2007 release, this feature is not

supported. The Microsoft OC can override any call forward setting manually configured on the IP Phone and vice versa.

· Call Forward Setting from OC: Call forward setting from the OC through remote call control (RCC) fails on the IP Phone when the IP

Phone is initially configured with an E.164 DN. If the IP Phone is reconfigured to a non-E.164 DN then back to the E.164 DN, the

call forward setting from OC through RCC will work. This is a known issue on Cisco UCM 7.0(2) and has been documented in

CDETS CSCsy62620 to be fixed in a future release.

· Do Not Disturb (DND): DND is an unsupported feature with respect to CUP integration. Thus, any OC client with DND feature

enabled, will still have any received calls routed to its controlled IP Phone.

· Multiple Point of Presence (MPOP): As of the CUP release 6.0(1), the MPOP feature where a Microsoft OC user is logged in from

more than one location is not supported by CUP. Support for this feature affects other interoperability features between the Cisco

CUP and the Microsoft OCS. The affected features include basic placement and teardown of calls and locations-based call forwarding.

These features are inherent to MPOP and without support for this feature, the user experiences loss of device and call control when

logged in multiple locations.

· Transport Layer Security (TLS) connection between CUP and OCS: this feature was not tested in this release.

As you can see, you quickly start to lose a lot of the functionality of OCS. I will stress that the above is strictly related to Cisco, and may not be completely accurate for other RCC Scenarios.

The other option, and most optimal solution in my opinion can be most closely referred to as a standard Enterprise Voice Scenario. Really, it is the cheap way of doing remote call control.

Last year I had multiple voice deployments which had to provide interop between OCS and the existing PBX, mostly Avaya and Cisco systems. A key requirement of all of these deployments was the ability to pilot OCS functionality but also have access to their old phone for use. The architecture we used to provide this can be seen below. We had to make a connection between the OCS environment and the PBX, whether it was a Sip trunk to cisco, or a PRI connection via media gateway to the other systems. From there we have two options for routing incoming/outbound calls for OCS enabled users.

The first scenario is where the PBX controls the call routing. All PRIs, or SIP trunks come directly into the PBX, from there you have routing rules to route certain numbers over a trunk to OCS. This can be accomplished by setting routing rules at the PBX level, or simply forwarding your PBX Desk phone to your OCS extension, which will route it over to the OCS Trunk. It is important to note that in both scenarios you are configured for different extension on the PBX and OCS. Where your “real” extension goes depends on how you wish to route/forward calls. Regardless, any DID numbers, or existing extensions are still usable, it’s just a matter of getting the call there. In this scenario for example, you may have “fake extension” in OCS, and when your existing extension is rung, your cisco phone forwards the call to your OCS extension, in the PBX this new block of OCS extensions is configured explicitly to route over that new trunk, this is the simplest way to make this connection happen with the least amount of changes on the existing PBX environment.

The other scenario lets OCS control the call routing. In this scenario all PSTN calls destined for OCS Enabled users go directly to OCS. This can be more difficult to implement at first, but once it is in place, it provides a very smooth transition. This can be accomplished from a direct SIP trunking connection to an OCS mediation server, or a PRI/POTS connection from a provider, into a media gateway, which then sends the calls on to the OCS mediation server. It is possible to move all incoming PRI connections to a media gateway, which would then control all calls. From there that media gateway can send to the PBX or OCS. In the Cisco world, this could actually be a 2800 or 3800 series ISR. To some people this is a bit scary to hear at first, but really, your current PRI lines come into some sort of gateway device as it is, this would provide the same functionality. The gateways used are by companies like Dialogic and NET with great experience doing this for years for traditional PBX systems, so it is more than reliable. From here, there is also a trunk setup to the PBX to route extension dialing, as well as for simultaneously ringing the legacy PBX phone.  In both scenarios the voicemail can be sent to exchange unified messaging or back to the PBX voicemail system. When OCS has no answer, it can make this choice. The PBX will be smart enough when the call comes back and is tagged with no answer, to send it directly to voicemail instead of creating an endless ringing loop.

In scenario two, if the media gateway takes all PSTN calls in, it will have some basic routes on it. Routes that control sending OCS enabled users to the mediation server, and then a default route which will send everything to cisco. Basically, if you had 5 users enabled for OCS. You would have a rule on the gateway that had 1000-1005 with a destination of the mediation server. The second route would be * (any) with a destination of the PBX. This takes the load of modifying PBX configuration.

In this specific scenario, the media gateway could be a dialogic/NET device, or simply the PRI interface on the Cisco ISR.

It is important to note that with both of these scenarios you have full functionality of both systems at any given time. You can use your cisco phone to make and receive calls, or your OC client to make and receive calls. You can also take advantage of all conferencing, and other advanced functionality that OCS has to offer like remote access.


There may be some things that need clearing up in this, and I am open to some feedback, but this is really what I have been going off as a reference point for myself with these deployments. Another important factor is the retirement of Dual Forking and RCC in Wave 14 of OCS set to be released this year, existing OCS 2007 R2 implementations will be supported, however new deployments will not. This has made some companies forget about RCC implementations all together.

Configuring OCS DVT Agent/Organizer Scenario

There is no documentation on configuring the OCS Deployment Validation Tool in the Agent/Organizer Scenario. Setting up the Auto-Answer Agent is pretty straight forward and is documented in detail at Byron Spurlock’s blog here:

The Agent/Organizer scenario however is a bit more interesting.

To start, you can find the Deployment Validation Tool installation files in the OCS 2007 R2 Resource Kit files which can be downloaded here:

In the installation directory there is a sub folder for Deployment Validation Tool which has DVTAgent.MSI and DVTOrganizer.MSI.

First off both installs require you to install the UCMA Redistributable package which you can find in the OCS 2007 R2 setup files under Setup\AMD64\Setup\ucmaredist.msi

Once that package is installed you will also need to install SQL Express 2005 SP2 on the server you have picked as the organizer. This should not go on any heavy utilized OCS roles like the front end servers, in my environment I chose to put this on the Monitoring Server. Install SQL Express with all of the default options and continue with the Organizer install.

Before you run the organizer install be sure to create a SIP enabled account for the organizer. In my examples my account is .

Once SQL Express 2005 SP2 is installed you can run the DVTOrganizer.MSI.

The organizer service installs are pretty straight forward, the defaults should work for the installation. However, there is one piece in the Organizer Configuration that will throw you off. By default using the guides for Auto Answering Agent configuration you are instructed to leave the box checked for Use Default Credentials when configuring the Agents. I was having issues where all of my agents were showing offline and the Organizer server would report this error in the event logs:


Warning    8/3/2009 9:15:19 PM    OCS Deployment Validation Tool    51019    (1050)

The service wasn’t able to register with focus. It will attempt to reregister automatically.

Service : Organizer, URI:
Cause: This might be due to a configuration error, or due to network or focus problems.
Please check the configuration of the service including the account credentials used to register with focus.

After adjusting the Organizer configuration to specify the actual user credentials I was able to get the organizer to register with the focus and recognize the agents as Online.



Once you have the organizer installed you will want to install a couple of agents, try to put them across different subnets or different physical locations to make sure you get diverse scenarios for your call testing. Also try not to put the agent on any OCS roles if possible, I have mine located on terminal servers and desktops in the environment. You will need to create SIP enabled accounts for each agent in the environment. In my example I have, and these represent three separate subnets in my environment. Install the UCMARedist.MSI package on the agent machine and use the default information for the installation.


During the installation you may also see this error pop up which you can ignore:


At the end of the installation you will see the Agent Configuration tool pop up.

You will want to configure the agent as a Unified Communications agent with the SIP URI you have created for the agent and to be safe, manually configure the server information.


If you receive an error while configuring this agent and you are using Server 2008 or Vista/Windows 7 you will want to make sure UAC is off, or you will want to re open the agent configuration by choosing Run As Administrator.

Once this configuration is complete you will need to setup the service in windows to use the sip account of the agent.


Hit OK and start the service, jump back over to the organizer server and open the Organizer Admin Console to add your agents to the roster.


Its important to note that you will need at least 2 agents and an organizer to perform any tests. The organizer will perform tests between the agents in your roster with peer to peer as well as conference calls.

Once in the Admin Console you can view your test suite status, the easiest thing to do is to hit restore to default and it will configure the default tests between all of the agents in your roster.


The screenshot above shows the test suite tab with tests in progress and tests that have completed.

You can also view reports and alerts from all of your tests in their respective Tabs. The reports tab will show all tests that were done, if you choose a test and right click you can choose to see the complete details of the test which will look like this.


The report above shows the agents and details such as MOS Scores and Network connectivity and test length. This can be very useful when troubleshooting call quality issues.

If you have any additional questions about configuration please reach out to me, I am constantly testing new ways to use this tool and I will try to do another write up on the MOM Integration for alerting purposes as well.

WinXnet Launches MSCERTIFIED.COM For Microsoft UC Certified Devices!

Portland, ME (July 29, 2009) – Today, Winxnet, Inc. announced the launching of their new online store, which sells Microsoft-certified telephones, headsets, and accessories. Winxnet now has one of the only web stores exclusively selling this optimized hardware.

This new online store, which is located at, targets organizations who have converted to the more cost effective Microsoft Unified Communications and provides them with a convenient and quick method of purchasing additional equipment. As the cornerstone of Microsoft’s Unified Communications, Office Communications Server is the platform for instant messaging, audio and video conferencing, and internet based telephone communications for businesses worldwide.

“We have seen organizations purchasing equipment which was not designed to work with this new cutting edge Microsoft communications suite,” said Chris Claudio, CEO of Winxnet, Inc. “Winxnet recognized the need in the marketplace for these users to find the right product which will work for them and their communications needs.”

As a Microsoft Gold Certified Partner and Voice Certified Partner, Winxnet is a leader in implementing Microsoft’s Unified Communications technology throughout New England and considers this new online store as the next step in providing complete service.

“As more of our own clients convert to Microsoft Unified Communications, we wanted to offer a place to easily purchase Microsoft-certified headsets, phones, conferencing equipment and accessories,” said Chris Claudio, CEO of Winxnet, Inc. “I am proud that our own e-commerce team designed and developed this site and that we have already seen sales since our beta launch.”

Winxnet has deployed Unified Communications throughout New England for organizations such as Stanley Works, Harvard Vanguard, Eastern Maine Healthcare Systems, Aetna, Boston Medical Center and Children’s Hospital Boston.

The new Winxnet online store features Microsoft-certified devices from leading communication manufacturers such as Jabra, Polycom, and Plantronics.

About Winxnet

Winxnet, founded in 1999, was created to provide customer-focused IT consulting services to organizations and businesses throughout southern Maine and has grown its operations to include offices in Waltham, Massachusetts and Chattanooga, Tennessee, employing more than 30 people. Winxnet’s clientele consists of both publicly and privately held businesses across a variety of industries, including retail, professional services, healthcare, hospitality, energy, and technology in addition to both non-profit and governmental organizations. Cultivating partnerships with clients has been a cornerstone of Winxnet’s success and continues to be a top business priority moving forward.

Winxnet is a premier Microsoft Gold Certified Partner and is headquartered in Portland, Maine. For more information, please visit

Gloria White
(866) 946-9638

OCS R2 with Dialogic 2000 Series Gateway- Delay on answering calls

I have run into two instances recently when using DMG2000 series gateways to integrate with OCS there is a delay when making calls to the PBX/PSTN.

The scenario:

You call a PSTN number from Communicator, the user on the other end answers the call however your communicator does not show the call as answered. Sometimes this will answer after 5 seconds or so, other times it will not answer at all. The fix is a simple setting in the dialogic configuration.


The Dialogic gateways have a setting under TDM->T1/E1 called ISDN Answer Supervision Enable. By default this setting is “Yes”. If set to yes the gateway will wait for voice activity to answer the calls, if set to No it will only listen to ISDN Messages.

This seems to only be the fix when you are making outbound calls to the PBX or PSTN, the inbound call answer delays are another issue. There are two things I have run into relating to delays when a MOC user is answering an inbound call from the PBX.

1. Make sure the Dialogic firmware is the newest version ( needs to be at least 6.0128 for OCS 2007 R2)

As of this posting this is the latest DMG2000 firmware available on the Dialogic website.


2. Make sure the RFC 3960 Early Media Support setting under VoIP->Media is set to Always

3. Make sure Voice Activity Detection is set to Off


LCS 2005 SP1 Migrating Global Settings from System Container to Configuration Container

We have done many deployments that have been LCS 2005 to OCS 2007 R2 migrations, however recently we encountered our first experience where migrating the global settings from the System Container to the Configuration Container in Active Directory was requested by the customer.

This process is outlined in documentation provided by Microsoft that can be found here:

The important thing to note here is that the documentation is clearly outlined for OCS 2007 R1 to R2 migration scenarios, NOT LCS 2005 Sp1 to OCS 2007 R2 Migration Scenarios. The documentation states this works for LCS as well as OCS however, we ran into a bunch of flaws in the documentation that I will outline below with workarounds.

First off, LCS was never meant to work with the configuration container, Microsoft released an update here: that supposedly would fix this. Basically if you had not installed that KB Update and tried to use LCSCmd to prep the forest with the /global:configuration switch it would error out with Invalid Parameters. Once you install this patch, the LCSCmd will take the /global:configuration switch and report a success. The interesting part here is that any version of LCS 2005 Sp1 Forest or Domain prep will not perform the correct functions on the Global Settings if they are stored in the configuration container and the system container at the same time. The hard thing about this is that the documentation states to wait to delete the system container information until testing all services, unfortunately this is impossible.

Here are the various issues I ran into while performing this migration. First off, the scripts do their job just as they should, the script would successfully migrate the Global Settings containers to the Configuration Container. We did however start running into some minor issues when we went to update the user DN References. We noticed the user DN references script was not making any changes and kept saying it was not complete.

We decided to check the msRTCSIP-PrimaryHomeServer setting to see if these changes had indeed been made, we viewed users in different OUs and confirmed they were pointing to the configuration data for their home server.

From here we started to panic so we decided to test if we could start the LCS Service. The LCS Service would fail to start with the error messages shown below:

When using lcserror.exe to lookup the error code provided in the last error this was the response:

In the LCS Management Console there were two pools showing up, both with the same name. One pool would have no servers and users, and the other would have all of the servers and users. This was a good way for us to confirm that all users and servers were pointing to the Configuration Container for their information. The above error states it cannot find the AD objects it needs, which still didn’t seem to make sense because it was pointing to the configuration container. When checking the objects through ADSI Edit I noticed that the global settings containers were in the correct places, however none of the proper permissions had been applied to them, this usually happens during Domain Prep, which as I had mentioned above will not work with the global settings being in the System and Configuration Container at the same time. We manually added the RTCDomain groups to the containers with the proper permissions however the services still would not start.

Microsoft was able to confirm that the LCS Services would not start with the information in the System Container as well as the Configuration Container. After using the migration script to delete the System Container information the service still failed to start. I ran a domain prep check on the domain and was able to see the Microsoft container was not showing as ready. Once the domain prep was run again, all permissions were correctly added to the objects in the Configuration Container and the LCS Services would start and everything was functioning again.

To summarize key things to note about the process that differs from the documentation:

  1. You must delete the information from the system container before running domain prep or else Domain Prep will not be able to add the permission correctly and the LCS Services will not start.
  2. When updating the user DN References it may not always show as completed, however you can verify by checking the msRTCSIP-PrimaryHomeServer setting through ADSI Edit.

Hopefully Microsoft can get this documentation updated soon, or atleast an announcement about this in a public blog, I have to imagine this is causing a lot of havoc on the LCS to OCS Migrations.