Enable-CsTopology : Error accessing folder \\sfbshare

I have made some changes to my Skype for Business topology and I finished that as usual with the cmdlet “Enable-CsTopology”.

However, I got like 51 errors all stating :

Enable-CsTopology : Error accessing folder
\\sfb-fe.contoso.com\sfbshare\1-ApplicationServer-1\AppServerFiles\CPS.
At line:1 char:1
+ Enable-CsTopology
+~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Invalid Data: (:SourceCollection) [Enable-CsTopology], DeploymentException
+ FullyQualifiedErrorId : InvalidFolder,Microsoft.Rtc.Management.Deployment.ActivateTopologyCmdlet
Enable-CsTopology : Error accessing folder \\sfb-fe.contoso.com\sfbshare\1-ApplicationServer-1\AppServerFiles\Rgs.
At line:1 char:1
+ Enable-CsTopology
+~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Invalid Data: (:SourceCollection) [Enable-CsTopology], DeploymentException
+ FullyQualifiedErrorId : InvalidFolder,Microsoft.Rtc.Management.Deployment.ActivateTopologyCmdlet
Enable-CsTopology : Error accessing folder \\sfb-fe.contoso.com\sfbshare\1-ApplicationServer-1\AppServerFiles\WinFabTraceFiles.
At line:1 char:1

lync

The errors clearly mention an access to lyncshare folder error. I tried to actually enter the share folder through its FQDN, and I browsed in Windows Explorer \\sfb-fe.contoso.com\sfbshare and SURPRISE!! I was denied.

I browsed again the Lyncshare but this time through its IP address \\@IP-ADDRESS\sfbshare and it works! So, I understood that it was a DNS related issue.

I opened a cmd shell and did a simple ping sfb-fe.contoso.com and I got an IPv6 response!

I disabled IPv6 on the network card like that :ipv6

and did an ipconfig /flushdns on cmd.

After these two actions, I was able to browse the SFB Share through its FQDN and finally the share folder is accessible and the Enable-CsTopology worked successfully.

It’s really surprising because the SFB was up and running in production. I don’t want caused the Enable-CsTopology where no recent changes happened.

Integrating Cisco Meeting Server with Lync/Skype for Business

I have implemented this week multiparty conferencing through the new Cisco’s CMS conferencing product. CMS enables Lync and Cisco users to participate in the same conference with a seamless behavior between Lync and Cisco experience.

The CMS is excellent for organizations where both Lync and Cisco UC deployments are used. (yes, Cisco is best in Telephony, yes Lync is best in Chat & IM, and yes opinions are shared for video/webconferencing)

The configuration is pretty straightforward. I’m really surprised with the ease of the configuration in CMS.

I will not detail how to integrate CMS with CUCM. A prerequisite of the following is that Cisco endpoints eg. Jabber and/or DX endpoints are able to connect to the same Space.

Note that the word “Space” in Cisco meeting Server is actually the equivalent of the Collaboration Meeting Room in Cisco Conductor.

The configuration steps on Lync/SfB Front-End are detailed in the CMS deployment guide Appendix C.

So basically, you need a choose domain for CMS  which needs to be different than the Lync domain. (for example, if your Lync deployment is contoso.com , you may choose for example the domain cms.contoso.com to route calls from Lync to CMS). This is because Lync needs to differentiate “Lync internal” calls (user@contoso.com) from “Lync external” calls (room@cms.contoso.com). You may even choose a completely different domain like “contoso2.com”, not only a different subdomain.

Here are the steps :

1- Download the Root CA certificate that signed the CMS certificate and import it to each Lync Front-End server. Put it in the “Trusted Root Certificate Authorities” folder. The Root CA certificate should be a .cer or .crt or whatever certificate file extension.

Importing the Root CA certificate that signed Lync Front-Ends to CMS is recommended however not required since CMS certificate verification is disabled by default.

2- Open Lync Server Management Shell to create the “Trunk” between Lync and CMS. The “Trunk” with CMS will be of type “Trusted Application Pool”; as far as Lync guys are concerned. Type the following cmdlets :

New-CsTrustedApplicationPool -Identity cms.contoso.com -ComputerFqdn cms.contoso.com-Registrar sfb-pool.contoso.com -site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true

New-CsTrustedApplication -ApplicationId meetingserver-application -TrustedApplicationPoolFqdn cms.contoso.com -Port 5061

$x=New-CsStaticRoute -TLSRoute -Destination “cms.contoso.com” -MatchUri “cms.contoso.com” -Port 5061 – UseDefaultCertificate $true

Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$x}

and Finally : Enable-CsTopology

3- That’s it ! From a Lync client call “room@cms.contoso.com” and you should be in the virtual room. Don’t forget to open your webcam. Seems that Lync don’t negociate inbound Video until you actually open your webcam and trigger the outbound Video negociation.

4- You may face a problem where the Lync call to “room@cms.contoso.com” window appears and then disappears suddenly and the call gets disconnected.
I troubleshooted the issue in the CMS

2017-01-25 16:17:47.805 Info call 25: recognised as Lync
2017-01-25 16:17:47.805 Info call 25: incoming encrypted SIP call from “sip:lyncuser@contoso.com” to local URI “sip:room@cms.contoso.com” (Lync)
2017-01-25 16:17:47.817 Info conference “Test”: unencrypted call legs now present
2017-01-25 16:17:47.922 Info participant “lyncuser@contoso.com” joined space 32c459e9-fb89-4b5f-96d9-73aab7e5c7f4 (Test)
2017-01-25 16:17:47.962 Info call 25: ending; remote SIP teardown; ICE negotiation in process – connected for 0:00
2017-01-25 16:17:47.962 Info participant “lyncuser@contoso.com” left space 32c459e9-fb89-4b5f-96d9-73aab7e5c7f4 (Test)

A detailed call trace on CMS will show a SIP BYE message with the cause :
ms-client-diagnostics: 52001;reason=”Client side general processing error.”;UserType=”Callee”;MediaType=”audio”

2017-01-25 16:18:50.797 Info SIP trace: connection 31: incoming SIP TLS data from 10.210.30.9:59210 to 10.210.30.5:5061, size 699:
2017-01-25 16:18:50.797 Info SIP trace: BYE sip:room@cms.contoso.com;transport=tls SIP/2.0
2017-01-25 16:18:50.797 Info SIP trace: Via: SIP/2.0/TLS 10.210.30.9:59210;branch=z9hG4bKDEEFB2EF.FF22BB7957D3B46E;branched=FALSE
2017-01-25 16:18:50.797 Info SIP trace: Max-Forwards: 69
2017-01-25 16:18:50.797 Info SIP trace: Via: SIP/2.0/TLS 172.30.22.241:6174;ms-received-port=6174;ms-received-cid=E5400
2017-01-25 16:18:50.797 Info SIP trace: From: <sip:lyncuser@contoso.com>;tag=d8804dbf7f;epid=eedfaef46a
2017-01-25 16:18:50.797 Info SIP trace: To: “Test” <sip:7000@cms.contoso.com>;tag=a1ed2fe26aae6b2b
2017-01-25 16:18:50.798 Info SIP trace: Call-ID: 3238de7a9d0547978d0a00d24623c4cb
2017-01-25 16:18:50.798 Info SIP trace: CSeq: 2 BYE
2017-01-25 16:18:50.798 Info SIP trace: User-Agent: UCCAPI/15.0.4893.1000 OC/15.0.4893.1000 (Skype for Business)
2017-01-25 16:18:50.798 Info SIP trace: ms-client-diagnostics: 52001;reason=”Client side general processing error.”;UserType=”Callee”;MediaType=”audio”
2017-01-25 16:18:50.798 Info SIP trace: Content-Length: 0
2017-01-25 16:18:50.798 Info SIP trace: ms-routing-phase: from-uri-routing-done

The problem was that, by default, the “SIP Media Encryption” parameter on CMS (menu Configuration > Call Settings) was set to “disabled”. Since Lync requires encryption you may turn it to “allowed” and everything will work as a charm!

One last thing, the Lync client can also give you the presence status of the room. It will show Ready if nobody is in the Room and “In a call” if a meeting is in progress.

Collaboration Edge with Let’s Encrypt certificate and 7800/8800 IP phones

I have finished few weeks ago a Collaboration Edge deployment through Expressway for a customer.

We used in this deployment the new “free” Certificate Authority aka Let’s Encrypt.

In fact, this authority is supported by 7800/8800 series IP phones as stated by the Certificate Authority Trust List document.

Many websites provides simplified management and generation of Let’s Encrypt certificate (native one requires API integration etc. a hussel!), we used sslforfree.com for instance.

We have generated the certificate for ONLY the FQDN of Expressway as Subject Name. We did not put anything as SAN, no top-level domain especially. (Expressway version is 8.7.3 but it should work for later versions)

And it worked like a charm. One last thing is that the certificate has to be regenerated each 3 months so that it keeps current.

He’s my conclusion in two points:

  • Let’s Encrypt is trusted by Cisco IP phones and can be used as the Certificate Authority for Expressway-E
  • Putting ONLY the FQDN of Expressway in the certificate is pretty enough to make phones work outside the corporate LAN

 

Corporate directory for 7800/8800 IP phones on CME “Host not found”

Last week, I was deploying a new CME with some 7821 IP phones with some 8861 IP phones for the executivess.

However, I faced a problem regarding the corporate directory on those new SIP IP phones.

Phones were stating “Host not found”.

I searched around forums and blogs but didn’t find anything helpful.

As soon as I added the following three commands, the corporate directory worked.

CME(config)#ip http server

CME(config)#telephony-service

CME(config-telephony-service)#url directories http://CME-IP-Address/localdirectory

Following this, the Corporate directory worked like a charm! Yes it doesn’t mean anything to use “telephony-service” which is supposed to be used in case we have Skinny phones. Well not.

Don’t forget to save your config! “wr” 😉

t38modem Windows binary HERE!! (+ Signed com0com drivers)

Today I’m giving you a very precious bounty.

Many people may already have t38modem windows binary but I really really struggled to get it. It’s like a rare material to find. All my compilation attempts of the project were big fails (VC++ 2005 and cross compilation and I don’t know what else… a nightmare!)

But when I found the t38modem binary, I thought everything is great. I went ahead but when I wanted to also use com0com, I realized that Windows doesn’t accept anymore unsigned  drivers. So com0com has to be signed. Some kind human being made that available for download.

So I bundled this and kept it in safe.
Don’t ask me for a specific version of t38modem, it’s version 1.1.0 it’s all what I have, nevermind for bugs etc. I’m sharing this as best effort.

It’s a full working FoIP windows binaries including t38modem and com0com.

You can use it for example with the built-in Windows Fax & Scan role in all Windows versions.

In my case, I also used a cron job on the Windows Server so that the .bat batch file (running t38modem with the relevant parameters) would run as soon as the machine comes up.

Enjoy!

The file name is : t38modem&com0com.zip

Download it here from 4shared.

Its MD5 hash is : 0dcb573daeb1a9d924a6243f11f3b1fa

Why you should not upgrade your WebEx to 2.7

… Until you retire the last computer using Windows 7 in your company, or even until your last customer stop using it.

So here we are.

Webex development team decided to drop support of TLS 1.0 for security reasons.

Here’s an excerpt from the CWMS 2.7 Release Notes :

TLS Support

CWMS Release 2.7 supports TLS 1.1 and later; TLS 1.0 is not supported, with one exception. Client connections to an SMTP server using TLS 1.0 are supported.

And as I far as I’m concerned, Windows 10 general adoption is still so far from being a reality. Moreover, as far as I know, Windows 7 is not yet (at least today) End of Support.

Since that by default, Windows 7 Internet Options only support TLS 1.0 and earlier versions of SSL. (unless you check TLS 1.1 and TLS 1.2), a default common configuration of Windows 7 won’t be able to connect to a WebEx meeting hosted on CWMS 2.7

Given that changing a such company-wide parameter is not easy at all, and that since Webex is not only meant for internal users, but also for guest and external users (that we need to give the easiest possible webconferening user experience and are more likely to have Windows 7 than any other OS), I think that Cisco should have simply said “Windows 7 is not supported with CWMS 2.7”. It would be quite simpler and more alarming for administrators who attempts to upgrade their CWMS System (2.6 to 2.7 shouldn’t be that difference)

I have seen many other situations where Cisco dropped support for OS/Browsers for far less limitations that this.

Yes, I’m not happy. I’m going to fresh reinstall CWMS 2.6 tomorrow after an entire week to deploy CWMS 2.7 😦

 

UCCX Agent reporting outage frenzy

CUIC and HRC don’t generate Agent reports

Monday, september 12 2016. Yes we all love mondays very much hein!!

My phone rang from 3 different customers.

“Hello! We have a problem on CUIC reports! We can’t generate reports!!”

“Good morning! We are unable to generate our daily Agent Summary report! We can’t count the working hours of our employees! We need this for calculating wages”

“Hello, when I try to generate an Agent Report on Historical Reporting Client, we get an error, I sent it to you by email, check it out :
Nested SQLException; SQLState: IX000 Vendor code: -1265 Message: Overflow occurred on a datetime or interval operation. ”

Well the statements above are sorted from worst to best customer (I’m sure you understand why when you read the 3 different problem descriptions). We all have a customer that doesn’t give any further information about incidents!!! Just “we have a problem, come onsite”, as dry as that.

(Please if you are customer be like the 3rd and not 1st one)

 

Anyway, the problem is general and covers all versions from 8.x to latest 11.x

One Cisco developer has been coding UCCX Reporting anyhow and declared the date variable in a horrible manner. As a result all CCX deployments suffered that 12 Sep from an outage in Agent Reports. In the Bug Search toolkit, I have seen the number of cases is around 425 after only two days, good luck TAC people!

Luckily Cisco published a bug fix called ciscouccx.ReportFix.cop.sgn and it immediately solves the issue. No restart/reboot of services/server is needed. Don’t forget to install it on both nodes not the Publisher only.
You can download the COP file from this supportforums topic.

Otherwise, contact TAC so they send it to you (hey! You don’t like what I said YOU who refuses to renew Service Contrat! Haha. This time it’s OK there’s a COP file, tomorrow who say what happens ? Long life to Cisco Products.)

 

 

EDIT : The COP file is no longer shared in the supportforums. You have to download it directly from Cisco and yes, you need a valid support contract to do so.