SQL Change Ports

The Port Change Issue

On a project where the SQL team has a policy of changing the SQL port away from the default of 1433? 

This does not pose a huge problem for your intrepid Skype (or Lync) deployment engineer.  If you are needing to know what to do, and maybe you have, oh, 30 or so front ends to modify, then maybe I can help you out a tad.

The issue is modifying the registry to tell your host server where to go to access the requisite port on the target SQL server.  As it turns out, I had to remember this, as it has been a bit since I had to last do this task. 

The Simple Fix to the Simple Issue

Luckily for you and me, it seems that every copy of a Windows operating system I looked at for this post (Win7, Win8, Win10, Server 2008+) have a utility in \windows\system32 called cliconfg.exe.  You can read up on that utility here.

A wonderful tool.  Here is it in Windows 10 form.  Which looks the same as Win7, so I think they will all pretty much appear to be the same. Actually, the Win7 version has a different set of window frames, so the appearance is more rounded instead of the ugly-ass Win10 metro crap.  But I digress.

What we need to do is select the Alias tab…the select Add.

For the purposes of this exercise, I need my system to talk to my SQL server (FQDN = sqlalwayson-a.tsoorad.net) on port 49001.  So, you set it up like this and then say OK.

Follow up that OK with an APPLY and your newly modified operating system will for thereafter talk to SQL server sqlalwayson-A.tsoorad.net on port 49001 vice 1433.  Simple.  Easy.  Works well.  Less filling.  Man, I am thirsty!

But Wait!  What if…

…you have like four user pools, and they all need to talk to the same monitoring server, but different archive targets per pool?  And what if there are like 30 front ends that need this modification, and every time you type this stuff in there is the possibility of spelling errors that mean system failure.  Now, I am sure there is some folks out there in techie land that are starting to chant “PowerShell!  PowerShell” -  but in this case, I am going to ignore them, and simply export a registry key, and then incorporate that into my server build process – which can be PowerShell-ized if you wish.

Here is the registry key to export.  HKLM\software\microsoft\mssqlserver\client\connectto

In my project, we had four SQL AG clusters, each with two nodes, a cluster name, and the AG name; all that needed to resolve by DNS.  So, our registry key looked somewhat like this: 16 entries with AG, cluster, node1, and node2 per supporting SQL cluster.  We then simply imported that into each server at build time.

Summary

The SQL mavens might well change ports on you.  If they do, there is an answer in form of cliconfg.exe.  If the scale is a tad larger than manual typing will cover, you can regedit your way to success.

YMMV

Windows 10 Battery Life

The Issue

I use a Lenovo Yoga 14 for my personal stuff.  A few weeks ago I ran updates.  I noticed that battery life dropped from nearly 10 hours to less than 3.  Closing the lid puts the Yoga to sleep, so opening it is a breeze and I have a working desktop in about 20 seconds or less.  After the updates, closing the lid still did the sleep thing, but on opening the lid the Yoga was dead.

The Problem

So, I started poking.  I discovered the latest rounds of updates had installed a Lenovo Screen Updater.  Holy Battery Drain.  The CPU was grinding away at 50%+ constantly.

The Fix

Remove it.  Now I get this here:

Seeing as how this was associated with the touch screen concepts, I imagine that this might help Win7, Win8, Win 8.1, et cetera – anything else that runs a touch screen with Lenovo and Windows.

YMMV

Stupid SfB Tricks

In a fit of angst, today I recreated the infinity mirror exercise from several years ago.

Yes, I was testing with a customer and not just bored.

YMMV

New SfB SE won’t start

Usually I see this problem with EE pools, but in this case I have now seen it with two different SE installs.

The Problem

RTCSRV won’t start.  It just sits there for a bit, like 10 minutes and claims it is “Starting”.  Then the service status goes to “Stopped”.

Nothing in the event log, nothing shows in Powershell.  If you try to start from services.msc, it just sits there.  Nothing.

How did we get here?

A fairly locked down environment.  OK.  A severely locked down environment.  The tin-foil hat types have found a home in this place.  New install – new as in greenfield deployment.  Standard Edition installs, and before starting services for the first time, we ran the February 2017 CU into place.  All of that seemed fairly normal.

But the service wont’ start.

The Fix

Again, I usually see this with EE pools, but here is what fixed it:

Reset-CsPoolRegistrarState –PoolFqdn poolfqdn.domain.com -ResetType FullReset

YMMV

Skype Test Matrix

As part of a project, Thaddeus Kurowski (CDW) and I put together a Skype test matrix to ensure that the implementation worked as designed/expected.

You may find it useful as well.

https://gallery.technet.microsoft.com/Skype-Implementation-Test-e11edf07

YMMV.

Skype Edge Server and 2:1 NAT

This morning, we resolved an issue that I have never seen before, and hope that I never do.

The Background

I tell customers during design sessions that if there are existing network issues, Skype (or Lync) is going to find them.  If there is something a bit wonky, we are going to discover the wonkiness.  And here we go.

Skype edge with 1:1 Nat.  Public IP is 71.16.x.x.  Edge server is doing the classic 3 IP thing.  Remote logins are fine.  Everything seems to be ducky.  Except we cannot talk outbound. 

Go check all the network again.  Looks good. Check the topology, servers, IP assignments, paths.  All good.  Certificates, the common culprit behind one-way federation and presence look good.  We are now scratching our heads.  We know now we are looking at something wonky, but what?

The Fix

I was under the impression that 1:1 NAT is 1:1.  But it turns out that a Watchguard Firebox is capable to doing 2:1 NAT.  Inbound to the Edge server worked because the firewall had 1:1 NAT from public to DMZ VLAN.  Edge trace logs showed subscriptions and connections timing out on the far side.  The connections were being made, just no return traffic.  No SYN.  Telnet client testing outbound from the edge server on 5061 ad 443 worked.  Clearly inbound connections were working or there would be no remote logins.

As long as the traffic originated from outside the organization, things worked fine and the Edge server, via the 1:1 NAT was responding as expected to the source IP.  But traffic originating from INSIDE the organization was failing.  One way presence, presence unknown, cannot send to user, etc.  Apparently…

…according to www.ipchicken, the Watchguard was sending all traffic from the DMZ external VLAN out via a completely separate set of addresses!  HUH?  Whaaaaat?  So inbound would work, but outbound went out on a separate address?

So their firewall guy fixed that, we are back to 1:1 NAT and all is good. Something to be aware of, eh? Go figure.

YMMV

Inbound Call Failures due to TCP configuration

I will not attempt to embellish this content past commenting that this call failure is not common.  I have rarely seen it, most likely because my implementation practice for upgrades is to match system settings before testing.

Having said that, I think I would have thought the initial setup described here would have worked.  But apparently not.  Inbound calls follow the original port.  Something to be aware of.

Thanks to Josh Walters, CDW Senior Consulting Engineer for writing this up for us.

YMMV

Scenario: 

Customer is deploying a new 3-node Skype for Business Enterprise Pool to replace their existing 2-node Lync 2010 Enterprise pool.  Enterprise voice is enabled in Lync 2010 and Lync call traffic is directed inbound from their PRI and delivered to an Avaya Session Manager appliance, then it is delivered to Lync.  Internal call flow functions as below:

PRI --> Avaya Aura System Manager --> Lync 2010 Enterprise Pool

After deploying the new Skype for Business FE Enterprise Pool, Edge Pool, and Back-End we decided to migrate a test user who was enabled for Enterprise Voice to the new Skype for Business Pool and test call flow with the new infrastructure.  The new expected call flow should function as below:

PRI --> Avaya Aura System Manager --> Lync 2010 Enterprise Pool --> Skype for Business Enterprise Pool

After moving the user, the user was able to successfully place an outbound call to both internal and external recipients but was unable to receive an inbound call.  When attempting to dial the Line# for the migrated user we were being routed directly to Voicemail (Exchange 2010 Unified Messaging).  What gives? 

Inbound Traffic

Avaya Aura System Manager --TCP 5060--> Lync 2010 Enterprise --TCP 5060--> Skype for Business Enterprise

Outbound Traffic

Skype for Business --TCP 5060 or TLS 5067--> Lync 2010 Enterprise --TCP 5060 or TLS 5067--> Avaya Aura System Manager

Well, what we found was that Avaya was routing SIP traffic to Lync 2010 using TCP port 5060 only (as seen above).  When Lync 2010 received the SIP request it attempted to route the traffic to the Skype for Business pool where the user is homed and it tried to use the same port it received the traffic on, but we had not yet activated TCP on the Skype for Business pool for Mediation.  The Skype for Business pool was therefore rejecting the traffic and then sending the call to Voicemail. 

The fix:  Enable TCP (and make sure to use the correct port for YOUR environment) so that the Skype for Business pool is listening for traffic on said port.   After enabling TCP 5060 on the Mediation Server (Collocated) all inbound call routing for the user started working.