Monthly Archives: November 2014

AudioCodes ShellShock Patch Released

I’m posting this quickly for those of you who may not receive the AudioCodes announcements in your email as it is quite important.

A AudioCodes ShellShock security patch is now available for AudioCodes Products affected.  Please see my previous post for light information on the subject:

It is important to note that the ShellShock exploit does not affect most AudioCodes products such as MediaPacks and Mediant 800, 1000, 2000, 2600, and 3000s.

Products Affected:

  • AudioCodes EMS (Element Management System) / SEM (Session Experience Manager) version 6.6 to version 7.0 for installations running Linux CentOS version 5.9 Rev6, and versions 6.2 and 6.6 for installations running Solaris 10.
  •  AudioCodes Mediant 8000 and Mediant 5000 Shelf Controllers.

The product notice containing installation instructions can be found here (requires a login):

For EMS/SEM Systems running affected Linux versions download the patch here:

For EMS/SEM Systems running affected Solaris versions download the patch here:

For AudioCodes Mediant 5000/8000 devices, you will need to contact your AudioCodes representative to request the patch.

Lync is So 2014, Long Live Skype For Business!


It has now been publicly revealed, the next version of Lync, or Lync vNext, isn’t going to be Lync at all.  It’s going to be Skype for Business: and we can expect to see many exciting enhancements as the product lines draw closer together.

I personally am a bit torn, I’ve been with the product since the LCS days and cringe every time I see a name change.  This time around the name change brands it as a Skype product.  The icons and interface will have a somewhat similar look and feel as the Skype product.  That itself isn’t a bad thing, but while the products look the same and are branded the same, they are still (for now) distinct products.  My fear is that it’s going to be confusing to consumers when it’s time to download the client.   I expect “Which version of the client are you using?” is going to become one of our top troubleshooting questions.  I’m not overly concerned about the reaction of my clients, though I expect a few groans.

However, I also feel this needed to happen and I want to see the products have the ability to interact as closely as possible while remaining separate for security and compliance reasons.  I love the idea that Lync/Skype, a product that I believe in deeply and evangelize at every opportunity, will be huge and seamless across the business and consumer space.  I love hearing about the deep connectivity we can expect and am excited to show the new product off once I am able to.   Stay tuned as more details are revealed…

And now I can also reveal, this blog can be reached with 🙂 will always work, so will  Thank you for reading and let me know your thoughts.




Known Issue: UM Automated Attendant TUI Editing Broken During Migration

Update – response from Microsoft is as follows: “ I talked to the Escalation Engineer who put in the bug and it looks like the fix is going in for Exchange Online, but there is currently nothing planned for on-premises.  The logic being that the workaround of making sure your admins are on the same mailbox database is fairly simple for the on-prem environment whereas it is impossible for the Cloud environment.”  

So, this one won’t likely be fixed folks, however there is a workaround and if you feel it needs to be fixed please let me know and I can share case numbers and you can submit a business impact statement.


This is a developing issue but I wanted to write about it for anyone else out there searching.  I will try to keep this blog post updated for when a resolution is found.  I do not currently have all of the details.  In brief, users in charge of recording Exchange UM prompts prefer to dial directly in to make the changes over the phone due to the high frequency of greeting changes.  Once the IP Gateways have been pointed at Exchange 2013, calls to the Automated Attendants to record greeting audio is rejected with an audible “Sorry.. that extension isn’t correct.” error.


The environment is a mixed Exchange 2010 and 2013 environment across multiple sites.  All servers are running all Exchange updates as of the writing of this article.  A third party (not Lync) PABX is connected to the Exchange environment through four Sonus SBC 2000 devices.  The TechNet article to Upgrade Exchange 2010 UM to Exchange 2013 UM is being followed, all steps through 14 have been completed.  This means the system mailbox has been moved, and the IP gateways have been pointed at Exchange 2013.


A caller dials into the Automated Attendant and hits # then * and enters their extension.  An audio file plays “Sorry.. that extension isn’t correct“.  Pointing the IP gateways back at the Exchange 2010 UM servers resolves the issue.  We’re not seeing other issues related to UM at this time.

Resolution Attempts

  • UM Services were restarted on CAS/MBX roles.  -No affect
  • Users needing prompt editing access were removed and re-added to the UM Management RBAC group -No affect
  • Users with the Organization Management RBAC role and full domain administrative access show the same symptom.
  • Disabled and re-enabled TUIPromptEditing with: Set-UMDialPlan -TUIPromptEditingEnabled $true -No affect
  • Created new Automated Attendants from 2013 console -No affect
  • Created new users on the 2013 side with full permissions -No affect
  • Reviewed Event Logs and ran diagnostic logging.  The results pointed at an error, but not a why.  Similar results to a user without proper permissions making the attempt.


It smelled like a bug, and we’ve confirmed with Microsoft that it is a known issue.  What should happen is the following:

  1.  A call comes into a server hosting a CAS role/Unified Messaging Call Router via the IP Gateway.
  2. The call then flows to a server hosting the Mailbox role/Unified Messaging service.
  3. If this Mailbox server does not hold the user’s mailbox, it sends a SIP REFER back to the gateway noting which Mailbox server it should communicate with.
  4. The IP gateway connects with the appropriate Mailbox server which prompts for your pin.

Somehow, step 3 isn’t completed properly, we don’t see the REFER generated, and we hear the error.  The workaround for now is to locate the mailboxes that need TUI access on the same database/server as the system mailbox.  Please share your experience if you have this issue.

Error Starting Lync Bandwidth Policy Service

This is a small one, and not too common, but it’s come up on the TechNet forums a few times so I thought I’d take a moment to write it up and make it easier on those searching for the fix.

Issue Overview

The issue is that upon a server restart, the Lync Server Bandwidth Policy Service (Authentication) and Lync Server Bandwidth Policy Service (Core) services fail to start.  A few errors are generated in the event logs, notably the LS Bandwidth Policy Service (Authentication) Event 29004 and LS Application Server Event ID 32014.


Some examples of the logs are here:

Event ID 32014, source:LS Application Server

The application threw an exception while starting.

The application urn:application:testbot threw the following exception when starting: Exception: Microsoft.Rtc.Collaboration.ProvisioningFailureException
> FailureReason: ApplicationNotFound
> DetectionStackTrace:    at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at Microsoft.Rtc.Collaboration.ProvisioningFailureException..ctor(String message, Exception innerException, ProvisioningFailureReason failureReason)
at Microsoft.Rtc.Collaboration.PlatformDataImpl.CreateInstance(String requiredCertificateUsage, UCSettings ucSettings, String applicationId, Boolean enableCMSLoadBalancing, Boolean useLocalRegistrar)
at Microsoft.Rtc.Collaboration.ProvisioningSourceImpl.GetInitialPlatformData()
at Microsoft.Rtc.Collaboration.ProvisioningSourceGetInitialPlatformDataAsyncResult.ProcessCoreHelper()
at Microsoft.Rtc.Collaboration.SipCollaborationAsyncResult.ProcessCore()
at Microsoft.Rtc.Signaling.AsyncWorkitemQueue.ProcessItems()
at Microsoft.Rtc.Signaling.SerializationQueue`1.ResumeProcessing()
at Microsoft.Rtc.Signaling.SerializationQueue`1.ResumeProcessingCallback(Object state)
at Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod(WaitCallback method, Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
> Message: Application with id(urn:application:testbot) not found or a default port has not been configured for it.
> TargetSite: Exception: Exception has been thrown by the target of an invocation.
> StackTrace:    at Microsoft.Rtc.Internal.ServerSharedComponents.MachApplication.StartUp()
at Microsoft.Rtc.Internal.ServerSharedComponents.ServiceManager.Startup()
at Microsoft.Rtc.Internal.ServerSharedComponents.UCAS.MachUcasService.StartAsync()
at Microsoft.Rtc.ApplicationServerCore.ApplicationLoader.CallStartAsync()
> Source: Microsoft.Rtc.Collaboration
> HResult: -2146233088
Cause: Startup errors.
Check the events prior to this to resolve the service startup issue.


Event ID: 29004   Source: LS Bandwidth Policy Service (Authentication)

Error while trying to access local Settings. The LS Bandwidth Policy Service (Authentication) will stop.

Exception: System.Exception: MRAS port is not configured!
at Microsoft.Rtc.MRAS.Configuration..ctor(ConfigChangedHandler ConfigChangedEventHandler, RoleName roleName)
Cause: The current account may not have the necessary permissions to access these settings, or the LS Bandwidth Policy Service may not be installed correctly, or the settings are wrong.
Rerun LS Bandwidth Policy Service (Authentication) installation and activation.

Event ID: 29005   Source: LS Bandwidth Policy Service (Authentication)
LS Bandwidth Policy Service (Authentication) could not be started.

Exception: System.Exception: MRAS port is not configured!
at Microsoft.Rtc.MRAS.Configuration..ctor(ConfigChangedHandler ConfigChangedEventHandler, RoleName roleName)
at Microsoft.Rtc.MRAS.Core..ctor(ServiceStopHandler serviceStop, RoleName roleName)
at Microsoft.Rtc.MRAS.Server.OnStart(RoleName roleName)
Cause: Internal error.
Examine the details in the associated event log entry to determine the potential cause and report to Product Support Services.

Other errors seen are LS Bandwidth Policy Service (Authentication) Event 29005: “LS Bandwidth Policy Service (Authentication) could not be started”, LS Bandwidth Policy Service (Core) Event 36008: “LS Bandwidth Policy Service (Core) could not be started” and LS Bandwidth Policy Service (Core) Event 36058:” The LS topology is not configured to run the LS Bandwidth Policy Service (Core).  The PDP ports are not defined.”


The events seem a little scary, but the answer is simple.  Someone likely disabled call admission control but did not finish the process.

When you uncheck Call Admission Control at the site level and publish your topology, you’re not done.


You need to remove the components after you’ve republished by running the bootstrapper or step 2 of the Lync deployment wizard.


Running this step will remove these services at this point.  If you need Call Admission Control enabled, rechecking the box, publishing the topology and confirming your configuration should allow you to get the services started once again.