About Me

My Photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015) - before that, a Lync Server MVP (2010-2014). My day job is titled "Principal Consulting Engineer" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Yealink SIP Phone Review

Edited 2016-05-02

Yealink has already answered one of the login issues highlighted below – login from outside the edge server.  It would seem that the PKI is not trusted – I assumed it was not as I never put a copy of the trusted root on the device.  So disabling that security requirement allows the device to login from outside the edge server.


end 2016-05-02 edit

Yealink, in their infinite wisdom, shipped me a few units to play with.  When the box arrived, I found the following three SIP phones:  T42G, T46G, and a T48G.  Oddness is the different labeling depending on where you look.  On the boxes for each unit it says “Ultra-elegant Gigabit IP Phone SIP-T4xG” whilst on the web screen for the phone it says “Gigabit Color IP Phone SIP-T48G”; the T42G claims it is a “Enterprise IP phone SIP-T42G”; the T48G and the T46G claim “Gigabit Color IP Phone SIP-T46G” – I love the consistency between the box labels and the internal programmed labels eh wot?

Here are the three devices in the hot seat for this round of testing:  From the left:  T46, T42, and T48.  The 46 and 48 have a color screen, the 42 is a bit smaller with a monochrome display.  The 46 has buttons around the screen, the 48 is completely touch on the screen.  The 42 also has buttons around the screen.  Like the 46, some of the buttons on the 42 work, some do not.


Initial Impressions

I want to get on the record with one thing:  I like these phones.  A lot. There are some issues as you will see; but do not let that detract from that first concept – these are nice pieces.

Coming out of the box, all three devices feel solid, well-constructed, and the various ports are well laid out, marked legibly, and everything fit together as expected.  I am sure glad I have a PoE switch handy, or I would have been hurting as none of the devices came with a power brick.

The buttons push as expected, the screens are crisp and have a good layout.  As a Skype-compatible device, it would seem that Yealink has engineered their own GUI interface for the phones for Lync.  As I got the phones, they were SIP Phones, generic.  I had to flash the firmware and upload a license to enable them for Skype.  I expected this, as these units are pre-release, and the fine folks at Yealink had sent me instructions in advance.

Initial setup and login went about as expected. Attaching to internal worked perfectly.  The phone unlock code is nice touch.  User SIP and UPN and PIN login works as expected. 



On dial out, the phone does not start the call until pressing OK. I am used to seeing a Lync phone take 10 digits and start the call.  Or take 4 digits (or whatever) and start the call.  Other devices in the Tsoorad Test Lab do exactly that.  Mashing the ‘#’ key sends the call as expected. Something to do with a configuration perhaps?

Yes!  Found it.  Settings | Preference| Live Dialpad –> set to enabled.  Yay!  I am told that the documentation for the newest firmware is coming with the GTM which is supposed to be June-ish 2016.  Having documentation will make this sort of thing easier to sort.


Choosing your ringtone could be onerous.  When using the web interface, you have to choose one, then save it, then make a phone call to determine what is what.  Driving into the touch screen on the phone itself plays the ringtone for you in real time.  So, choose your management interface and learn it.  When doing ringtones, 6, 7, and 8 are interesting.  And according to choices in the web interface you can upload your own ringtones. 

OTOH, you can login to the phone as admin while someone is logged into the phone as a user.  I like that.  A lot.  A flip side to that is the web interface times out on a very short cycle, and I could never figure out where to lengthen that out to like several hours.

To get the phone to be the correct time, I had to set it as shown.  Using DHCP time did not work, it came up an hour off.  A competitor phone got the correct time from DHCP. 



Sample calls both inside and outside of the Tsoorad Test Labs facility were flawless.  Audio quality is really very nice impressive. The 7 (seven SEVEN) inch screen is really nice.  Touch.  Color.  I like it.  Here is the T48G.  Check out the color screen.  In phone terms, huge.  My old eyeballs have no issues reading the screen on the T48G.



The T46 has a smaller color screen than the T48 and the layout is different.  The functionality is the same, just things are in a different spot due to the interface being different.  Call quality, materials, and look and feel remain in the “dang this is a pretty nice unit” category. The T48 is all touch-screen and the only buttons are the dial pad and buttons down there; The T46 has buttons all the way around the screen – but only some of them are operational with the Skype firmware.  If you broke out Mr. Tape Measure, the T46 is also somewhat smaller overall.



The T42 is the smallest of the three, with a monochrome display.  Other than Skype sign-in, this unit it pretty much just punch the numbers and make calls.  I never did figure out how to do a conference call with the T42 even though the option is clearly presented.  The T42 is smaller than the T46, but the audio quality and build quality seem to be just as good as the larger units.


The Skype Connection

Obviously, or maybe not so obviously, I have only one reason to use a phone handset device like these.  To whit, I work with customers and their Skype projects and I get asked what handsets to use so I have to know.  For myself, I would not use a handset; I have my headset and I am good with that. But for others, a handset is requirement of life.  Therefore, we have Skype phones.  And they need to work to MY satisfaction. 

With the Yealink units, after flashing the firmware on all three phones, the Skype connection was entirely painless.  I inputted my user name and password and the phone signed right into the pool.  You cannot ask for more than that.  PIN login is equally painless. 

I could not get these phones to login to my lab from outside of my firewall.  Claims they cannot find the web server.  Funny.  Other vendors phones work just fine when attached outside of my Edge server. 

A lingering bug in the Yealink software will also prevent you from connecting to your organization from outside your domain and when your account is actually in a resource domain.  For instance, in my real world work, my account is actually in a subdomain of the larger forest.  And the Yealink phones don’t particularly like this arrangement.  I am told that the fix is a firmware revision that is coming with the anticipated Microsoft approval of these phones for use with Skype.  But on this list here the T48G is already listed…so I am now confused.  Which is really unfortunate, as these phones rock with Skype.


Better Together over Ethernet.  A little splice that goes onto your desktop and joins your phone at the hip to your full Skype client.  Pretty doggone handy for those without a CX phone.  Like me.  I installed the software on a Win8.1 machine and was up and running with the phone is less than 5 minutes.


After installing, all you need to know is the phones’ IP and the pairing PIN…




…and we are magically transported to EV-land, where the Skype client can operate as a softphone, a full web conference client, a desktop share client, a consumer, a producer, and a traditional telephony device user. 


So sweet. The Yealink BToE software is clean and well thought out and did not give me any hint of trouble.


Aside from a software/firmware thing that gets in the way of the phones being successful in two login scenarios – these Yealink Ultra-elegant GIgabit IP Phone units are easily on par with any other vendor device.  Provisioning via FTP is available.  Fellow MVP Grieg Sheridan seems to think that you can update these phones via CSCP tools…I could never find a ucupdates.exe for Yealink – but I also admit I did not look very hard (in my defense, I have one of those pesky customers that expects me to actually do things for them and not sit around dreaming up things to say in a blog article).

I found the materials, construction, and overall quality to be at least on par with all the other vendors out there in phone-land.  And two of these are COLOR.  Squirrel!

Documentation on these devices is extensive.

T48G firmware, docs, user guides, admin guides

T46G firmware, docs, user guides, admin guides

T42G – I am told by my “SFB Sales Engineer” who must remain nameless, that June 2016 will see complete SfB related documentation.  Which I hope applies to the T48 and the T46 also!

I really want to like these phones.  The market needs the competition.  Yealink has done a credible job on producing Skype versions of their existing (beautiful) phones.  So kudos to them for jumping into the fray.  Let’s hope they can iron out a few niggling firmware items and then they will have solid winners for the Skype environment.

You can get your Yealink phones right here:






AudioCodes 405 IP Phone

I used to think that the AudioCodes 420HD was my leading candidate for a low-cost, high-value SIP phone.  Now I think there is a new leader. 

Enter the AudioCodes 405 IP Phone.  I am getting some mixed signals as to how long this model has been on the market, but I just got one the other day and have been putting it to the Tsoorad Test Lab Experience for the last week or so.


Here’s a stock photo just to show the difference between a professional marketing photographer and yours truly with a cell phone camera.


You can get all the official AudioCodes material here.

Build Quality

Ho Hum.  I wish AudioCodes would ship a unit that would give me something for this section other than “excellent.” If I have to make some comment, the button feel is, IMHO, much better than the 420HD in a side-by-side.  Oh, and the display, while smaller, is crisper with a tad better contrast. While I did not use the handset to hammer nails, the materials appear to be a touch above some other competing vendor’s products.

Voice Quality

Again.  See previous paragraph.  BORING.  Same high standards as before.  Speaker phone volume is nicely controllable.

BToE (Better together over Ethernet) is available should you so desire. Second line, call transfers, conference calls, etc.  All that works as expected without doing anything other than maybe a quick study through the various documentation bits.  Here is the official market-speak pertaining to features on the 405 IP Phone:

The 405 SIP IP Phone is a cost-effective, entry-level IP phone designed to offer the essential everyday features that the modern business environment demands.

  • Graphical, backlit multi-lingual LCD (132 X 64)
  • 4 programmable soft keys
  • AudioCodes Auto-provisioning
  • Full SIP protocol support with extensive interoperability
  • Robust security mechanisms
  • Power over Ethernet (PoE)
  • Multiple language support
  • Integration with voice quality monitoring
  • Full duplex speakerphone and headset connectivity
400HD SIP IP Phone Series Shared Features
  • High voice quality
  • Full duplex speaker phone
  • Robust security mechanisms
  • PoE
  • Out of the box global redirection server support
  • Multi-language user interface
  • Centralized management with AudioCodes EMS

Skype for Business Connection

Seeing as how I make market with Skype, you know I had to connect this to a Skype system and kick the tires, right?  Here is the connections I made:  Ethernet and handset.  Highly technical, eh?


After that, it was a matter of a minute or so to input my login information and sign-in.  My lab worked perfectly first time through.  My work account worked perfectly the first time through also.  I literally did NOTHING to this device to make it Lync/SfB compatible; it just worked.  At that point, I had access to all applicable SfB Enterprise Voice functionality.  Without knowing anything more than my account and password.  This would seem to lend itself very nicely to providing a phone to a telecommuter.

You can get your very own AudioCodes 405 IP Phone right here.


A first rate telephony device for your SIP (I sure hope you are running Skype) system.  Excellent build quality, excellent audio, good feature set for the money, able to be centrally managed, part of a larger eco-system of VOIP solutions, etc.  You can’t do wrong choosing this direction.



Skype for Business Cloud Connector Edition

This is highly reminiscent of watching this Steve Martin classic.

But for those of us who have been waiting for lo! these many months, as of 0900 PST, the CCE is here!

The Skype for Business Cloud Connector Edition is a set of packaged virtual machines for deployment on-premises which connect a customer’s existing Public Switched Telephone Network (PSTN) service provider circuits with Skype for Business Cloud PBX operating in Office 365. This allows for the user’s phone capability to be managed out of Office 365 while their phone calls continue to use their existing phone number, circuits and PSTN provider contract.

One caveat – the existing documentation calls for Windows 2012 R2 Datacenter –


There is some light at the end of that particular tunnel in that Windows 2012 R2 Standard Edition appears to be valid also using a secondary methodology.  More clarification to the Technet documentation is pending.  Specifically, there is this statement in the reference:

Before you deploy Cloud Connector Edition, make sure you have the following for your environment:

  • A Windows Server 2012 R2 ISO image (.iso). Both Standard edition and Data Center edition are supported. The ISO will be converted to VHDs for the virtual machines that will run Skype for Business Cloud Connector Edition.

You can get started right here:  https://www.microsoft.com/en-us/download/details.aspx?id=51693



1008;reason=Unable to resolve DNS SRV record

ms-diagnostics: 1008;reason="Unable to resolve DNS SRV record";domain="domain.com";dns-srv-result="NegativeResult";dns-source="InternalCache";source="SfBSIP.domain.com"

Scenario Outline

SFB on-premises patched to November 2015. Split-DNS. Firewalls, networks, and even VLANs are all highly segregated.  Classic DMZ in operation with outside firewall, inside firewall, no internet browser access from DMZ servers.  Port 53 outbound from DMZ servers is not allowed.

The edge servers are using internal DNS resolution (hello InfoSec!).  Everything is testing perfectly.  IM/P, WebCon, media flow; the mobile clients are working, and PPT publishing internally and externally is perfect.  After working through the expected HLB and firewall issues, we are looking right successful.  First time through.  Nailed it.  But wait!

Organization moves from closed federation to open federation.  About a week later we notice that federation is suddenly borked – and one-way presence rears it’s ugly head – it would appear that federated partner –> internal org can start things, but the opposite does not work so well.  However, everything except presence works AFTER the inside person responds to the outside –> inside toast.  Screen sharing fails also – unless the outside person starts the screen share, then the inside person can share.  This is a hint for you troubleshooting mavens – we’ll wait while you digest all this information.


We traced the above client side errors and see the following:

Subscribe attempt…


…and the resulting 504.


We traced the same errors from the server-side (thank you centralzed logging) and see the same set of outcomes.  Here is a simple subscribe request from the inside to a federated partner…


…and you can see the 504 – I cannot find out who I am because I cannot resolve my federation SRV record.  This is not good.


A side symptom was that we were seeing similar 504 errors on test-csfederatedpartner and test-csmcxpushnotification.

Hmmm.  Does this look like the Edge server cannot find itself?  Like there is no _sipfederationtls._tcp.domain.com record?  Consider the lock-down environment, and the requirement that all DNS come from the inside…and the inside is going to be authoritative for the zone.  Hmm.  Lync 2013 documentation (essentially the same for SfB) indicates the SRV record for _sipfederationtls._tcp.domain.com needs to be on the external DNS server. So, go double check that.  Yes.  We got that part right. 

The Fix

Simple.  We put the _sipfederationtls._tcp.domain.com SRV record into place on the internal DNS, with the proper target.  And then modified the host file on each Edge server to have the public IP for themselves.  We did a TTL of 5 minutes on the SRV record.  Almost immediate relief.  It was like watching Bones cure the planetwide plague with a simple shot of his hyper-injector and you get watch the horrible disease be cured before the next commercial break.

But WHY?

Why did the transition from closed federation to open federation cause this?  And why did “this” take 7 days to manifest itself in failures?  Why didn’t the issue show up immediately?


I can guess at the first, as to the second and third, I am clueless. I am not willing to guess in a public forum, so you will have to draw your own conclusions. But I do know what fixed this issue – the federation SRV record being added to the internal DNS zone and modification of the Edge Server host files so that they can find the SRV target by IP.



SfB Patch/Upgrade Outline

Skype for Business (SfB) Server 2015 embodies several server-side enhancements beyond Lync Server 2013. The patching cycle for the SfB environment will need to be modified to allow for these enhancements. SfB contains five layers of servers, each of which will need to have separate handling:

  • Front End Pool Servers
  • Persistent Chat
  • Edge Servers
  • OWAS (Office Web Apps Servers) Servers
  • SQL Server and File Shares.

Host Server updates also need consideration – primarily because rebooting SfB servers can cause Windows Fabric errors that can affect the ability of the SfB server to recover into a running state.

Host Servers need to be patched to corporate standards; however, the application host servers cannot just be rebooted at will. Rebooting servers that host SfB services will result service outages and potentially in service failures where the servers may not recover services after rebooting.

Accordingly, phase one in the entire setup for patching SfB and related servers is to set the Windows Update to download but require administrator to install. For ORGNAME this may require moving servers away from containers to which GPO applies and controls WUPDATE settings.


This guidance will not apply to the SfB Edge servers as they are not domain members. However, the SfB Edge servers should be checked to ensure that the WUPDATE is set as shown.

Locate and download the latest SfB server updater from this site: https://technet.microsoft.com/en-us/office/dn788954 - as of this writing, November 2015 is the latest SfB 2015 update.  The consolidated server update installer is preferred over the individual updates. 

Note that the file name show is mostly correct, but that I rename them to help me keep track of what is what.


Place the update file in a separate folder on each front end, persistent chat, and edge server.  The update process generates log files which are kept in the origination location. Having a separate folder for each updater constrains the log file location and makes the entire thing easy to delete or verify later.

SfB Front End Servers


  1. https://support.microsoft.com/en-us/kb/3061064
    1. Find the section labeled: “Upgrade or update the Enterprise Edition pool that has at least three front-end servers” and READ IT.
  2. Read the following TechNet guidance: https://technet.microsoft.com/en-us/library/jj204736.aspx
  3. Then execute those instructions ONE SERVER AT A TIME.
  4. After each server reboots wait until ALL indicated services are running before moving to the next server in the pool. Keep in mind that these services are on delayed startup, and there could be a significant (10-15 minutes) delay before the SfB Front-End service starts.


SfB Persistent Chat Server

SfB Persistent Chat requires only that the services be running after the persistent chat server is patched and rebooted.


SfB Edge Servers

Edge servers are easy. Execute the serverupdateinstaller.exe on one Edge server at a time. Reboot if requested. If a reboot is needed, monitor the reboot process until the SfB services are restarted (about 10 minutes). Otherwise, verify the following services are running.


Do the next edge server.

Office Web Apps Server (OWAS)

The OWAS requires different handling from the other servers. See the following articles:

Assuming the two OWAS servers are hlbwowasp101 and hlbwowasp102, the following commands will recreate the OWAS farm when the time comes:

1. From server hlbwowasp101.corp.domain.com, open PowerShell as administrator, and execute the following (command wrapped):

    • new-officewebappsfarm -internalurl https://hlbsfbowas.domain.com -externalurl https://hlbsfbowas.domain.com -certificatename sfbwebext

2. From server hlbwowasp102.corp.domain.com, open powershell as administrator, and execute the following command AFTER the previous command on the other server:

    • new-officewebappsmachine -machinetojoin hlbwowasp101.corp.domain.com

After patching, reboot, and recreation of the WebAppsFarm, verify the following service is running on each server:


SfB File Shares

ORGNAME runs the SfB file share (\\corp.domain.com\sfb-fileshare ) on the OWAS servers. Care must be given to handling the DFS in that the entire environment is relying on the sfb-fileshare for various functions and downtime on the OWAS servers will affect all other servers. Other than the update process shown above, the OWAS servers should only be updated one at a time.


ORGNAME is using a single SQL server. This server should be patched along with the other SfB infrastructure with the following caveat: The SQL needs to be back online within 30 minutes or there will be impact to the users. The impact will be the clients entering “resiliency mode” due to the SQL server not being available to the front end servers. For more information, see this: https://technet.microsoft.com/en-us/library/jj205184.aspx.

If you have mirrored SQL or perhaps Availability Groups in SQL, then you will need to investigate the SQL patching process from a slighlty different aspect – namely, keeping the active node where you want it.


SfB has changed the patching process from how it was done in Lync 2010 and Lync 2013.  Each layer of the system needs something that is just a little different from the other layers of the system.



Netgear ProSAFE and Skype for Business

What are talking about today?

We all know how strapped the small business can be when it comes to resources. Staff, cash, cash flow, technical skills, and time. Another item is IP space.

When it comes to trifecta of IP space, cash, and technical skills, and then throwing the desire to have Skype for Business (SfB) deliver all communication modalities things can get a bit dicey. Between the need to communicate and the need to conserve cash, what usually gets hammered is the technical skills. So a pricey consultant is called in, who promptly tells you that you need to spend huge wads of cash on a firewall that will accept and deal with larger IP address space. This is counter-productive you might think, and you would be right.

But, Netgear has some answers, and combined with some judicious telecom provider shopping, you may be able to find the answers in the form of a /29 CIDR block.

I won’t try to answer all the questions here, but I do want to illustrate the configuration of the Netgear ProSAFE to support SfB. My issue is that the stock documentation for the Netgear ProSAFE is a bit shy on details. Past the statements that it supports multiple IP’s there is not much in the way of “how to do it” and if you think your ITSP provider is going to help, think again.

Tsoorad to the Rescue

As you might have guessed, Tsoorad.net falls into this category. First off, I am a cheap ba$tid. Second, I have particular needs what with the technical lab and all. Finally, I face the ca$h situation just like everyone else, and when combined with “first off” I decided against purchasing the more expen$ive “indu$try $tandard $olution$.” Still with a bit of reading and learning and poking your nose where the vendors don’t want you to poke it, you can make your system play well with others. I will NOT cover the SIP trunk provider or the reverse proxy stuff here; that you can get elsewhere in other articles.

IP Space

SfB, if you want the full suite of operations and features, is going to require a minimum of two (2) public IP addresses. No way around it. One (1) for the external side of the SfB edge server, and one (1) for the reverse proxy. You can do away with the reverse proxy address, but you will give up inviting outsiders to your web conferences and forget about your mobile clients working. As a side note, you may be able to piggy-back your reverse proxy needs onto an existing IP with 443 and content redirects, but that is usually well past internal SMB technical chops and will have you calling in a provider or con$ultant.

If you want to investigate the minimum IP requirement solution, see this section of the SfB documentation. You can also work up this requirement using the SfB Planning tool. For those tech heads out there, you should be reading this first. Adelante!

The biggest problem with the minimum IP space solution is using port 444 for web conferencing. In my experience, most larger environments will not allow port 444 outbound willy-nilly. Which will mean that crucial web conference that you are hosting on your minimum IP space solution will most likely not have any large corporate attendees.

Enter the /29

Offering 5 usable addresses, the /29 CIDR block is the smallest block that is usually provisioned by providers – other than giving out singles. I use a /29. One IP for general use, one IP for my SIP trunk with Intelepeer (they are great), and three for SfB. For my lab use, I have Office 365 in hybrid, and I also bring port 25 into one of my SfB-assigned addresses and use the firewall to pick off the SMTP traffic and send it to the proper internal server. Works great, less filling. And yes, the Netgear ProSAFE can be configured to support all of this (see how I worked around to the beginning thesis?)

ProSAFE Configuration

Ignoring the unboxing and basic connection steps, the first thing you need to do is configure the firewall for your public IP space.


Next, you may wish to change your things to match your internal subnet to which you are connecting.


Now onto the real fun

SfB has a variety of port requirements.  You can refresh your memory here. Assume the following

  • IP #1 = SIP
  • IP #2 = WebCon
  • IP #3 = AV
  • IP #4 = reverse proxy

So, IP #1 needs TCP 443, 5061, 5269.  Depending on your DNS source, opening TCP/UDP 53 may be needed – this is the for CRL check.  IP #2 needs TCP 443.  IP #3 needs TCP 443, UDP 3478, and optionally TCP/UDP 50,000-59999.  Simple, right?  IP #4 needs TCP 443 and 80.  If you are confused about the 50k range, see this.  Nothing has changed here since Lync 2013.

The Netgear issue

Netgear, like any firewall, blocks by default.  So we need to poke some holes.  Netgear, like almost everyone else, also provides some predefined services – and you can use them; like HTTPS or SMTP.  No sense in re-inventing wheels, eh?  The other issue with the ProSAFE is that ALL traffic, by default, goes OUT on whatever IP you assigned as the device primary in that first screen shot.  The solution here is to create outbound bindings so SfB traffic goes out on the IP that is expected.

Create Services

Because we are going to use the pre-defined HTTPS service, here is what is needed.  I feel that the construction of these services is very self-explanatory.


Inbound/Outbound Services

So here is where the rubber meets the road, or, to not mix metaphors and to maintain our focus, where the electrons meet the transistors. When creating your new outbound rule, what you need to know in advance, is what your NAT is that matches the service to the IP. Enter an IP that is valid for the your CIDR mask and it will work.  Typos count against you.


For the inbound service you need to know the exact same thing, and guess what, it looks pretty much the same.  A few things of note here.  First, you need the NAT information in advance.  Also, see the “WAN Destination IP Address:” thing?  This is where the Netgear documentation falls flat.  Doing multiple IP is simply not mentioned as to HOW.  But here you go.  Enter an IP that is valid for the your CIDR mask and it will work.


OK.  Now that we have that sorted, here is the full outbound rule set…


…and the full inbound rule set.


But wait!  The sharp-eyed critic will notice that the rules appear to be doubled-up for the HTTPS and TCP/UDP for WebCon and AV.  Yes, they are.  Inbound rules are dependent on External DNS resolution, and the outbound rules are dependent on the sending entity having an IP that matches the rule.  I keep my lab ready to demonstrate for the unbelievers that doing a single IP SfB (or Lync) edge will result in THEIR environment not being able to connect to a web conference hosted on a single IP Edge server (because of the port 444 thing).  Which usually brings them out of the dark into the light which is the greater good. I can live with some topology builder work and some server re-ip – it only takes a few minutes, and saves much teeth-gnashing later.  And the firewall don’t care if it has a few rules that aren’t in active use.

Furthermore, the really critical reader will complain that I have said squatoosh about the reverse proxy in all of this.  Here’s why:  Inbound rule #4 lands on my HLB, which is, by definition, a reverse proxy.  I bring ALL miscellanous web traffic for my domains to this one address, land it on my HLB layer, and use content redirect rules to parcel things out to the appropriate target service/server.  Works very nice, is totally less filling, and makes me wonder why anyone does anything else.

Let’s Wrap This Up

Netgear ProSAFE can be a great solution for the smaller SMB.  Skype for Business can also be a great solution for the smaller SMB.  But, to get all that both offer, you need to dig a little deeper than just throwing things at the wall to see what sticks.  Single IP Edge works, but it may not be the best choice.  Finally, we demonstrated how to make a ProSAFE work with a CIDR block, and also showed the rules needed to enable all of SfB through a ProSAFE device.



Skype Office 365 File Transfer

We all know and love file transfer within the Lync 2010, Lync 2013, and SfB client.  OK, while you may not think it’s so hot, *I* love it.  Therefore, YOU all love it too.  Simple logic.  No?

The Ask

At any rate, I was recently asked to kill two features in an Office 365 Skype for Business deployment.  To whit, the conversation history, and surprisingly (for me) the file transfer.  As you can guess, some legal issues come into play here, and compliance dictates that these features be off.

OK, the first was pretty easy. If you do some google-fu (bing-fu works also) on “Disable office 365 Auto Archive Skype” you will surely find this article. You should have no problems doing this little magic trick.  Even my shadow did it very well.

But, let’s talk about disabling the file transfer.  As we all know, file transfer is part of the conferencing policy granted per user.  OK, but I don’t want to apply a conferencing policy to each user as we migrate them up into Office 365, or at least I don’t want to do it one at a time via the GUI.  Maybe there is another way?  It turns out that maybe there is – or not.

My first effort was doing this:  In the Skype for Business Office Portal, under the users, and having a user selected, uncheck the indicated item.  See this for reference.  You can see why I tried this.


Guess what, it don’t work.  Don’t know why, but 24 hours later, the users we tried it on were happily doing file transfers and thumbing their noses at the corporate legal hacks.  If you read my reference up there, you will also note that this is one user at a time, AND wants a hold via Exchange to be placed on the user.  Another solution was needed.

The Solution

Thinking to identify which conferencing policy to use, if you do a remote powershell into your Office 365 tenant, and then a get-csconferencingpolicy you get the following list from hell – none of which you can change. I changed my font in PowerShell to get as much into the graphic as possible, and I still don’t have them all there.  You get the idea.


There must be a better way.

Enter, stage right, the Knower Of All Things, Bob Wille, who pointed out to run

get-csconferencingpolicy –applicableto –identity

which works out to this for my North American user object:


Way better.  Again, font reduced to fit things onto screen, and at least this time they all fit.  And, you are welcome, I have highlighted the one to use.

Now, a simple

grant-csconferencingpolicy –policyname tag: BposSAllModalityNoFT –identity martin.luther@tsoorad.net

and we are done.  And for your information the above line has a space between the ‘:’ and the “B” because of the totally unasked for emoticon that combination creates Sad smile.


You can also imagine that doing a get-csonlineuser and piping that into the grant-csconferencingpolicy would quickly apply this to all of your users.


Inter-pool Dial in Conference Transfer (SfB)

The Scenario

Doing an upgrade of the entire environment, Lync 2010 to Skype for Business Server 2015 – on-premises.  The existing dialin conferencing was ITSP to Avaya 6.3 SM to Lync 2010 Mediation server.  In this case the mediation servers were a separate pool from the FE pool.

The Issue

When we moved the first pilot users to the new pool and then tested against use cases, the dialin conferencing failed.  Oooops!  Some tracing and sharking of wires, along with looking at the client-side logs was pretty clear.  The call landed on the Lync 2010 mediation server just fine, the conferencing attendant on the Lync 2010 FE (and the proper one at that) picked up the call, but then promptly dropped the call during the conference identification phase. 

The Fix

I have seen this issue before, back in the murky days (daze?).  But usually you see this with simul ring or call forwarding out of the system to the PSTN.  See this here for some background.  I had thought this was fixed in Lync 2013 as I had not seen this for a long time.  And then, for some reason I thought it had been fixed in SfB.  But, apparently maybe not.  And specifically, if you are doing 2010 pools to SfB pools.  See this here for the exact error (or at least a reasonable approximation).

So off we went to the trunk configuration, set the refer support to NONE, and magically our dialin conferencing calls worked as expected.  We got by with doing the global trunk configuration, you may need to be a bit more granular.




VMware and SfB/Lync

In attempting to answer some customer questions, I ran across this document from VMware.  Interesting reading, don’t know why I have never seen it before, but maybe the rock I live under blocked the transmission…


SfB Conferencing Fails

Disclaimer:  While I found the failures, I did not initially get the fix.  When I saw the fix, I then remembered what I had forgotten.  Dang do I hate it when that happens.

The Scenario

My current project is to replace a seriously ill Lync 2010 deployment with SfB.  As part of Phase 3 of this project, we will be doing full EV and HA/DR.  All in all, an interesting project.
We had the SfB pool installed, and finally we got all the bits and pieces of the network, firewalls, and load balancers done the way we wanted them to be done (with the attendent convincing of network and security teams that we really did need things to be the way we wanted)(and that the errors we were seeing in the various layers where mis-configs on the network, firewall, and HLB layers) so we could move forward with doing the basic client tests.  And from there, move to the more complex testing.  Alas, this did not go so well.  And finding the fix proved to be a bit trying.

The Error

When a user moved to the new SfB pool, no conferencing worked.  This means that 1:1 worked OK, but moving to three or more users in conference bombed immediately.  Some careful testing revealed an “error 500 source 329” which I have seen before, but associated with voice calls.  MVP Greig Sheridan has a nice error message blog.
Oddly, the SfB user could create a meeting – joining which failed miserably for users on both sides of the environment.  Moving the user back to 2010 resulted in the meeting working. 

The Culprit

Because the customer did not want the 2010 environment to be fixed, we did not go past validating topology before we started SfB installs.  What we found was that the customer had never cleaned up the conference directories.  And what appears to be true for the 2010-2013 migrations apparently still holds true for 2010-SfB migrations.  To whit: having an orphaned conference directory screws up 2013 (and SfB) but not 2010.  You can read the baseline stuff here and here.  While these two references don’t exactly match what we were seeing, they were close enough to get the stupid out of my system and allow me to move forward.

The Fix

In my case, I removed the orphaned conference directory with a remove-csconferencedirectory –force command, which I sort of thought might fix things.  But I also had to run (on each SfB front end pool server)
  • enable-cscomputer
  • bootstrapper
  • rebooted the entire mess.
Retesting was flawless.


O365 E5 Licensing

It appears that Microsoft has gone somewhat live with their pricing structure for the upcoming E5 licensing.





Avanu WebMux Review

Here is a new twist on an old friend.  The Avanu WebMux line of hardware load balancers has been around on the approved list since, IIRC, OCS 2007 R2.  Here is the ancient link to that listingThe Webmux is also on the Lync 2013 OIP listing.

Avanu offered to let me try out their hardware and virtual appliances; so naturally, I jumped at the opportunity. Avanu first sent me a piece of hardware, an A500XD, which I will not specifically make detailed comments about, other than these two semi-humorous notes.

  • OMG, I have a 747 in my office!  This thing needs to go into a server room, or at least away from me!
  • Power Supply out/failed tone.  The alarm will wake the dead.  Removing the failed/disconnected power supply turns off the zombie alert, leaving you with just the 747 taxiing out for takeoff.

The A500XD oozes build quality.  A very nice piece of gear from that perspective.  And wicked fast. But, I am living in a mostly virtualized world, so Avanu sent me their virtual appliance, which they assure me (and I verified) that the interface and operation aspects of the virtual match that of the physical hardware.  So the remainder of this short article will focus on the virtual appliance and how it might work with Skype for Business Server 2015 in your environment.  You can do some light reading on the Avanu Virtual WebMux here.

Network Environment

Here is what we are going to walk through:


Pretty simple, yes?  Even so, Avanu has provided their WebMux with a set of wizards that will do most of the work for us.  So, first, let’s step through the basic networking of the applicance to get it into the environment, and then we’ll take a look at the wizard for SfB to see how that functions.

After downloading my VMDX/VMX files, and opening them with vmware, we get our first look at the virtual appliance.


I sent a quick note to the fine folks at Avanu tech support over the size of the disk… seemed small to me.  But, this is correct.  Very small footprint.  Makes me wonder what the other vendors are doing that requires all that drive space. 

But wait, it gets better.  No DHCP support, so the WebMux comes up on static addresses… and to be exact.  But which interface is which?  I learned more Linux figuring that out.  What you get in the vmware console is this:


Not exactly helpful for someone trying to figure out IP, eh wot?  But, in the best sysadmin tradition, I persevered.  It turns out that “ifconfig ethf0” and “ifconfig ethb0” gave me the existing IP (which are listed in the documentation)(but, which to paraphrase Alfred E. Newman, “What, me read?”) Ha!  For you intensely curious types, I  have vnet0 set to the net and vnet7 set to the net, and those are set to the first two virtual NICs for the WebMux vmx…




All of that got me to the web-based UI, so that humans (not to be confused with Linux admins) can configure the WebMux.  There is a CLI available that can whip the WebMux into shape, but dang, I am Mr. Visual.  So, we got to the GUI.

Basic Setup


You may note that I took this screen cap after I set the IP up to match the actual network.  And oh yes, you will need to educate yourself on the various network choices and their definitions.  You mean you did not read the link up above?  Here it is again but focused this time on the “Arms and Architecture” section.  If you are following along (and reading the (*&%$ doc) note that the “two-armed server LAN NAT” selection REQUIRES you to have the WebMux be the GW for the farm real servers.  Note down below that I chose for this – not a real address for anything else on my net, and one that the WebMux can float between HA instances if need be.  But, if your first efforts fail, remember that I told you to set the real server gateway to the WebMux impersonated IP.  I will wait whilst you digest that statement.

OK, so we need to choose “two-armed server LAN NAT” – got it.  And all the rest should be fairly obvious; well, it was to me.


With that out of the way, and after the reboot, let’s take a swing at the aforementioned wizard configuration.

SfB Wizard Configuration


I am going to choose the “Skype for Business” option..


This is so easy, even *I* got it right the first time…but here goes.


On to Step 2…


Step 3…


Step 4…I am a solo, no HA…so it looks like this:


Step 5…


Step 6… I don’t use the Monitoring Port, so I will use the default…


Step 7… Submit the configuration.  Yes, part of this will simply duplicate my network configuration work, but if you don’t get access to the WebMux in the first place, then you could not have gotten to this wizard unless you went through the “change the IP on a workstation” bit… chicken and egg scenario, but that is what we have to work with!


oh my, it’s rebooting!


And here we are:


Pretty slick.  If this meets your needs because your firewall is doing all the port redirects for you, then perfect. But what about the aspects of internal versus external?  I just did the external…and I need the 443 farm to be on the network and the external to come in on 443 and attach to the real servers on 4443.

Looks like the wizard might not be what we want, eh?  So we’ll have to do this manually!  Oh joy.  Luckily, this turns out to be dirt simple.

Manual Setup for SfB Basic Stuff using Two Nets

First, I blew off what the wizard put in for me.  I did not like it, and it only did my external stuff.  When I tried to run it again for the internal, I got only internal.  The reason seems pretty simple; the wizard appears to be doing the entire WebMux configuration and once things are in place, running the wizard again appears to re-configure.  Ooops!  Well, no matter, I want more control anyway.  And specifically, 90%+ of my workings will have an external facing subnet and an internal facing subnet, with certificates in both directions, so I need to know how to do this thing manually anyway.  And then wata-shi-wa get’s to be in control.  I am all about control  My SO says TOO controlling, but I let her go shopping every third month, so I think she is over-reacting.  Adelante!

Here is what I ended up with and working as expected:


A regex note

To do content redirects, you will need to get some content rules.  Here is where things get a little different – just like all developers everywhere, “they” followed a different “standard” so things look a bit “off” from what I am used to.

You want to do a host name filter you should use the "layer 7 host MIME header perl regex match" field since the host name requested by the browser is in the host MIME header of the HTTPS request.  The URI regex match field is for matching strings following the host name portion which you don't need in this case.

An example of a match pattern to allows all hosts in a specific domain would be: ^.*testing\.com$

That will allow all hosts for the domain "testing.com" to pass through that farm.

While putting together the virtual servers, keep this in mind: 

  • Each IP/Port combination must have it’s own virtual server.
  • Real servers MUST have their gateway set to the core IP of the WebMux
  • WebMux must be in Two-Arm NAT mode
  • When adding a farm, choose “service: generic no health check (TCP)”
  • The farm gets the core port, the real server gets the tranlated port (443 –> 4443 in the case of SfB)
  • If you want to do SSL other than a straight pass-through, you will need to remember that WebMux is a linux box, and it acts like one.  Holy moly!  To get your cert up into the WebMux is going to be pulling teeth.  I suggest you call them – the most excellent support folks up in WebMux-land were very helpful – and will do all the work for you if you wish.  You can read up on it here: http://avanu.com/webmux_ssl_certificate/ 


The WebMux, even in virtual living on my strapped-for-resources lab, was wicked fast.  Really excellent throughput and admin response.  The linux-based certificate goat-rope exercise was a royal PITA; but the Avanu folks are very helpful with working it through.  The WebMux is very granular.  Planning before jumping off the cliff is strongly recommended.  Did I mention the WebMux is wicked fast?