How to Disable Interfaces on AudioCodes Mediant 1000

One of our clients recently rolled out AudioCodes Element Management System (EMS) and noticed that they were receiving a lot of alarms about interfaces being down. You might also see these alarms show up on the gateway management page:

I wasn't able to find much online in the way of how to administratively down or disable the alarms on each gateway so I opened a support ticket figured it out and thought I should post this in the event that anyone else out there also needs to do this. 

First login to your gateway and determine which interface you want to turn disable the alarm on. The interfaces are read on the top row beginning as GB_0_1 on the left and then going two, three, four, etc, if you have another row of interfaces then it would be GB_X_1 with X being 1-9

Once you have written down which interface you want to remove, expand VoIP -> Network -> and select Ethernet Groups Table:

Select Index 0 (or whichever index has the interface under the member column) and then click edit:

In the edit record window click the drop down of the member you want to remove, and change it to none:

Click submit, and your changes should show the Index as no longer having that interface listed:

You will then need to restart the gateway for the changes to take effect 

Lync Server 2013 Services by Server Type

The following is a list of each server role and the associated Lync server services for Lync 2013:

Enterprise Edition Front End:

Lync Server Application Sharing

Lync Server Audio Test Service

Lync Server Audio/Video Conferencing

Lync Server Bandwidth Policy Service (Authentication)

Lync Server Bandwidth Policy Service (Core)

Lync Server Call park

Lync Server Conferencing Announcement

Lync Server Conferencing Attendant

Lync Server File Transfer Agent

Lync Server Front-End

Lync Server IM Conferencing

Lync Server Master Replicator Agent

Lync Server Mediation

Lync Server Replica Replicator Agent

Lync Server Response group

Lync Server Web Conferencing

Lync Server Web Conferencing Compatibility

Standard Edition Front End:

Lync Server Application Sharing

Lync Server Audio Test Service

Lync Server Audio/Video Conferencing

Lync Server Bandwidth Policy Service (Authentication)

Lync Server Bandwidth Policy Service (Core)

Lync Server Call park

Lync Server Conferencing Announcement

Lync Server Conferencing Attendant

Lync Server Front-End

Lync Server IM Conferencing

Lync Server Mediation

Lync Server Replica Replicator Agent

Lync Server Response group

Lync Server Web Conferencing

Lync Server Web Conferencing Compatibility

Mediation:

Lync Server Front-End

Lync Server Mediation

Lync Server Replica Replicator Agent

SBA:

Lync Server Front-End

Lync Server Mediation

Lync Server Replica Replicator Agent

Edge:

Lync Server Access Edge

Lync Server Audio/Video Authentication

Lync Server Audio/Video Edge

Lync Server Replica Replicator Agent 

Skype for Business Hybrid Remote PowerShell

I recently began to start working on a couple hybrid deployments both internally and for clients. One of the first things that noticed was it was not as straight forward to get connected to remote PowerShell as it was for Azure AD or Exchange Online. The first thing to note is that if you are in a hybrid and you have your lyncdiscover.domain.com pointed to your on-premise environment you will be greeted with the following error:

Get-CsPowerShellEndpoint : Unable to connect to the remote server

At C:\Program Files\Common Files\Skype for Business

Online\Modules\SkypeOnlineConnector\SkypeOnlineConnectorStartup.psm1:94 char:26

+             $targetUri = Get-CsPowerShellEndpoint -TargetDomain $adminDomain

+                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Get-CsPowerShellEndpoint], WebException

    + FullyQualifiedErrorId : System.Net.WebException,Microsoft.Rtc.Management.OnlineConnector.GetPowerShellEndpointCm

   Dlet

Normally the workaround that has been in place for this is to specify the -OverrideAdminDomain switch and specify your tenant. However I have recently learned that this does not always work. When I tried I was greated with the following error:

New-PSSession : [admin0b.online.lync.com] Processing data from remote server admin0b.online.lync.com failed with the

following error message: The specified tenant 'spscom.onmicrosoft.com' could not be found in current forest. Please

verify the tenant Identity and then try again. For more information, see the about_Remote_Troubleshooting Help topic.

At C:\Program Files\Common Files\Skype for Business

Online\Modules\SkypeOnlineConnector\SkypeOnlineConnectorStartup.psm1:118 char:16

+     $session = New-PSSession -ConnectionUri $ConnectionUri.Uri -Credential $webt ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin

   gTransportException

    + FullyQualifiedErrorId : IncorrectProtocolVersion,PSSessionOpenFailed

I opened a ticket with Microsoft and we were able to get connectivity to work by specifying the -OverridePowerShellURI parameter, and then using the same URL that you access the control panel within O365:

New-CsOnlineSession –Credential $cred –OverridePowershellURI –OverridePowershellURI https://admin2a.online.lync.com/OcsPowershellLiveid”

We escalated this issue to the product group in which responded with the following:

There is a known issue currently where DomainUrlMap (what gets used for Autodiscovery) is only being populated with the domains of online enabled users. While our tenant does have some online enabled users, it would appear that those users are all on spscom.com – Autodiscover doesn’t know about the spscom.onmicrosoft.com domain so you get routed somewhat randomly when trying to resolve that domain.

There are two workarounds – 1) you could enable a user for spscom.onmicrosoft.com and subsequently disable it, once the domain is in the DomainUrlMap it should remain there, or 2) use “-OverrideAdminDomain spscom.com”, which is already in the DomainUrlMap.

Solution:

I created a new cloud only user with an onmicrosoft.com UPN, licensed them for Skype for Business Online, and then was able to sucessfully access remote PowerShell:

You can then remove the cloud only user it is only needed to add the onmicrosoft.com domain to the DomainUrlMap

Limitations on Transferring Conference Calls

A client recently reported that they were no longer able to transfer conference calls to their mobile phone. I invited them to a conference to test and I was able to, however upon performing a screen share session with them I confirmed that they were not able to. Upon logging into their environment with a test account I confirmed that the test account was also unable to transfer conference calls:

We then tested and we were able to transfer a call when it was a peer to peer session. This made me think that this has to be due to a conferencing or voice policy. I checked and found that there was no difference in the configuration between my configuration and the clients. I spent some time reproducing and looking at each of the client’s .UCCAPI logs thinking it was something that was being denied in the in-band-provisioning however nothing jumped out. 

I finally noticed that it was only allowing me to transfer the conference call to a mobile phone and not to any other user like it would in the peer-to-peer session. I immediately checked the Phones list on the client that was not working and all the fields were blank:

Upon configuring the client with a Mobile phone:

I was then able to transfer the conference call to my mobile:

Solution:

In order to transfer conference calls to another phone, the phone number must be associated with the user’s account either by one of the telephone fields in AD, or by configuring the number within the client itself. 

Skype for Business UI Transfer Call Bug

After working on an issue for about half of a year now and finally finding a workaround for it I wanted to share it with anyone else who might also be having the same issue. Currently there is a known bug within the Skype for Business UI that does not allow users to transfer calls to other phone numbers or voicemail listed on someone’s contact card.

For example, if I was to receive a call, and wanted to transfer the call directly to one of my co-worker’s voice mail, normally you would initiate a transfer, search for the recipient, and right click their name to get a list of alternate call options from their contact card:

 When you select Voice Mail or any other number listed the client does nothing. 

SOLUTION:

A workaround for this issue is to force the Lync 2013 UI for the user with a client policy. Then this functionality still works:

I currently have a Microsoft Premier ticket open and I will update this post once the fix has been published. 

UPDATE: This has been addressed with the February 2016 client CU:
https://support.microsoft.com/en-us/kb/3114732

Federating Lync 2010 Hybrid with Skype for Business Online

I had an interesting case today where a client who was running a Lync 2010 hybrid with O365 Skype for Business online reported that federated partners who were also using Skype for Business Online could not IM, call, screen share, or see presence.  My initial reaction was to check and see if they had configured their on-premises instance for federated domains to use the “sipfed.online.lync.com” proxy FQDN as both Phil Sharp  and our Tom Pacyk had blogged about issues with Lync 2013 when you have the domain configured as both an Edge Server and Hosted Provider. Sure enough they had a couple domains configured this way.  I used the following command to update all the domains to not specify sipfed.online.lync.com as a proxy fqdn:

Get-CsAllowedDomain | Where {$_.ProxyFqdn -eq "sipfed.online.lync.com"} | Set-CsAllowedDomain -ProxyFqdn $null

I forced replication and waited 15 minutes and re-tested, still no luck. I then pulled the client logs and noticed that my messages were resulting in a 504 Server Time-Out:

The entire message did not give me much to go on:

Server: IncomingFederation/6.0.0.0
ms-diagnostics: 1036;reason="Previous hop shared address space peer did not report diagnostic information";Domain="clientpartnerdomain.org";PeerServer="sipfed.online.lync.com";source="sip-na.clientdomain.com"
ms-edge-proxy-message-trust: ms-source-type=AuthorizedServer;ms-ep-fqdn=na1.clientdomain.com;ms-source-network=federation;ms-source-verified-user=verified

I then decided to collect SIP and S4 traces from the edge server while attempting to IM a user on S4B online, the trace at this point also did not provide much information other than that it was being routed correctly but that once it reached O365 it would just timeout:

At this point I felt that this had to be something with O365’s Skype for Business settings and not an issue with our client’s on premises configuration. So I checked the portal’s settings and they had configured “On only for allowed domains” and enabled “Let people use Skype for Business to communicate with Skype users outside your organization”.

So federation was enabled, however it was only for specific domains, so I added the clientpartnerdomain.org to the list of allowed domains (which was empty) and then waited 30 minutes and sure enough it worked!

SOLUTION:

Make sure that if you have a hybrid configuration that your on premises allowed domains, are also listed in your O365 tenant! 

The Never Ending Call Forward

Recently I had a client that reported they had a user who went on vacation and had configured their call forwarding settings to forward all their calls to the office receptionist while they were out. When they returned they disabled call forwarding however all of their calls were still being forwarded to the receptionist. Now this is not the first time I have heard of this issue, so I began by first taking a look at their call forwarding settings using SEFAUtil as sometimes the client and the pool won't sync and it takes forcibly changing it via SEFAUtil to change the setting. I pulled the user's config however there was nothing set:

I then tried using Anthony Caragol's Call Forwarding Script just to double check and see if maybe SEFAUtil wasn't reporting something correctly but it reported the same thing:

I thought that this was odd, so I decided to reproduce the issue and pull a trace from the FE pool. Doing so I saw that the call rang the user, then was responded with a PRAC and the forwarding user's identity:

Looking at the closest traces yielded nothing so I decided to also trace from the SBA that the user was registered to. This showed that a Added P-Asserted-Identity from EPID ashirey@clientdomain.com was being sent. Meaning that an endpoint was causing the call forwarding. Now this also was not unheard of however I found it strange that her client was showing no call forwarding and it was and endpoint. So I asked the user to log off of her client and then wait 1 minute then sign back in an re-test. This also yielded the same behavior and same message in the trace. 

SOLUTION:

I was starting to run out of ideas and so I had one last thought, why not have the user that was receiving the forwarded calls also sign out. After having both users sign out and remain signed out for 5 minutes, then signing back in, the call forwarding was finally disabled. 

So when in doubt while troubleshooting call forwarding have all the users sign out that are involved.