Patching Without an Internet Connection

In some organizations, allowing servers to have direct access to the Internet isn’t permitted. Or, it could be you have an isolated lab and need to patch your machines. WSUS is great, but not always possible to implement.

There are a couple of utilities available that help with this. The first is quite excellent,

The second one I haven’t personally used

Either of these tools should get you patched, without needing to worry about Internet connectivity from your machines.


FXO vs FXS in Skype for Business

Analog trunks and devices are less and less of a factor in many of the projects that I work on. Areas where I still see analog are branch office trunks, faxes, door buzzers/enterphones, paging systems, and ring-down phones that you might see in a parking lot to contact security or a cab company.

To integrate analog trunks or devices with SfB, you connect them to a gateway. The gateway can come with two types of ports: FXO, and FXS. FXO is an abbreviation for Foreign eXchange Office, and FXS for Foreign eXchange Subscriber.

So, clear as mud and we’re done here, right? If you’re an old school telecom guy, you know there’s a lot of complexity hidden behind that simple jack in the wall. The good news is for nearly all SfB use cases we can boil things down so they’re very simple.

FXO is a port that you plug a telco trunk line into. FXS is a port that you plug your phone or other device into. Mostly. Confusion pops into the picture when you have paging systems or enterphones, which may oddly use the opposite interface than you’re expecting, or give you the option for both.

You can think of FXO and FXS as North and South on a magnet, or male and female, or whatever pairing you’d like. A FXO device plugs into an FXS device, and all is well, like this:

Your phone, which has an FXO jack on it, plugs into the wall, which is an FXS interface.

Your phone, which has an FXO jack on it, plugs into the AudioCodes MP-118 gateway FXS port.

The AudioCodes MP-114 gateway FXO jack plugs into the wall, which is an FXS interface.


MP114 back

An AudioCodes MP-114 gateway. From the left are power, Ethernet, RS-232 serial console, two FXS ports and two FXO ports.

Great, so why then would a paging system offer both FXO and FXS interfaces? The answer is that there are two different use cases for the paging system.

One use case is a standalone, where a phone plugs directly into the paging system. You pick up the phone, maybe enter some digits to indicate what zone to page, and you talk away. The paging system is acting as a PBX in this scenario.

The second use case is PBX integrated, where the paging system acts as a phone. You dial the extension for the paging system, it rings and then answers, you maybe enter some digits to indicate what zone to page, and you talk away.

These two use cases also apply to things like enterphones or gate/door buzzers. You can have a phone plugged directly into the enterphone, or you have have the enterphone act as an extension on your PBX.

The standalone option is simple, but restricts you to interacting via a single phone. The PBX integrated option is more complex, but allows you to interact via any phone on the PBX.

Caution: “interact via any phone on the PBX” in the SfB world means that in a global deployment, you could have a prankster user in New York telling jokes over a paging system in Paris. Configure your dial plans appropriately if your paging system doesn’t offer PIN functionality!

If you have a choice between using an FXO port or FXS port on a gateway to integrate with an analog device that offers both, I recommend you pick the FXO port. This has the device act as a PBX, which means that there is no ringing when you call it, and call setup is faster. Disconnects are usually quicker too, which is important if the paging system or enterphone is used a lot.

When you configure the device to plug into an FXO port on the gateway, set the gateway to route calls to that number out via the FXO port you’ve connected it to. If the device will be sending calls to the gateway, set the gateway to

You’ll need to use an FXS port on your device to connect to the gateway’s FXO port. If your device has one port that’s switchable between FXO and FXS, read the manual carefully – I’ve seen some that aren’t clear whether they mean FXO mode is “setting this device to FXO” or “setting this device to talk to FXO”. If it’s really unclear, plug a boring analog phone in. If the line is dead, the device is set to act as an FXS device and the port is configured as an FXO interface.

Do you need a voice VLAN?

I’ve had three conversations in the past week or so around whether a voice VLAN is required or recommended for use with Skype for Business. Let’s take a quick look at where the concept of voice VLANs came from, what they can do for you, and whether you need them for your SfB deployment.

The idea of a voice VLAN first came about when the only IP endpoint for you IP PBX was a phone on their desk. The phones generally needed a specific DHCP configuration, and if the phones were in their own VLAN this was easier to do. QoS was implemented as 802.1p at the layer 2 (switch) level, and it was much easier to simply say “this voice VLAN gets a priority of 5”. Some switches would use Cisco Discovery Protocol (CDP) or Link-Layer Discovery Protocol (LLDP) to automatically put a device that said it was a phone into the voice VLAN. Much of this early IP telephony was done with voice guys coming from a traditional TDM PBX environment. The world of IP was new to them, so anything that made their lives easier and more automatic was welcomed by not only the voice guys, but also by any IT guys who had to work with them.

Raise your hand if you ever had to explain IP subnetting to your voice guys new to IP, and try to sort out for them why the IP telephone system vendor was blabbering on about Class A subnet masks and VLAN 0. Thankfully for me, my voice guys were smarter than your average bear and quickly picked up some good habits vs the drivel in the phone vendor manuals. (Thanks Brian and Willy!)

The curious thing is that at no point did anything actually require a voice VLAN. They just made life a lot easier and more “automagic”. You could deploy a perfectly good VoIP solution without using voice VLANs.

Fast forward to today, when we talk about Unified Communications instead of IP telephony. We now have soft clients, room systems, and mobile clients. In additional to voice, we have modalities like video, web conferencing and screen sharing, all from the same client. We’ve also got BYOD and Cloud technologies to add excitement to the mix.

Having your desk phones into a voice VLAN doesn’t provide any benefit to you when you’re conferencing from a PC, or watching a PowerPoint on your iPhone in the lunchroom while you wait for the coffee to finish brewing. A good number of your users might not even have a desk phone, opting instead for a headset and soft client.

One scenario where a voice VLAN does make some sense, is when you’re doing a large-scale deployment and the number of phones you are adding outstrips the number of available IP addresses on your existing subnets. In this case, it may make sense to create a new VLAN for the phones. I say “may” as you might also have a requirement to use IP subnets for location determination for emergency calling. Overlaying a single voice VLAN to cover your site may not be suitable – you may have to deploy multiple voice VLANs to provide the location granularity required. It may make more sense to simply further partition your network into general purpose user VLANs.

Do I recommend voice VLANs? No. I think they’re a thing of the past. They add complexity to your network, increase your administration, and affect only a very small number of your UC endpoints. For those endpoints that they do affect, they do not offer any benefits that can be provided via other means, and often those other means will need to be in place for other endpoint types and other modalities.

Bad Checksum in Packet Captures

I was working with a carrier to identity some SIP trunk issues recently, and they requested a packet capture of the traffic leaving our Mediation servers. I sent the capture over, and they quickly came back with a question: Why are all of the packets marked as “Bad Checksum” in NetMon.


As it turns out, this isn’t anywhere near the disaster that the carrier thought it was. If we open the same capture in Wireshark, we can see that Checksum validation is disabled.


This is expected when you are running your packet capture on a host that is generating or receiving the traffic you’re interested in (versus setting up a span port on a switch and mirroring traffic to a dedication packet capture machine). The reason? The packet capture takes place within the network driver stack, while checksums are almost always offloaded to hardware. For outgoing traffic, the packet is captured before the checksum is calculated, and there is no valid checksum available to include in the packet capture.

Here’s handy diagram courtesy of that shows the network stack and where the Packet Capture and Checksum take place. (Red arrows and boxes)

First with Offloading:


Packet capture with Offloading

And now without Offloading:


Packet capture without Offloading


If you’re not capturing packets to detect and correct malformed packets, this shouldn’t be of concern to you. If you need checksums, you have two options. One is to select your network adaptor, choose Properties, and on the Advanced tab, find all of the “Checksum Offload” properties and set them to Disabled (don’t do this). The other use a span port on a switch to mirror traffic to a dedicated capture PC (do this instead). Setting Checksum Offload to disable means you will take a performance hit, as you are no longer using the hardware on the NIC to perform these calculations. If you absolutely cannot do a span port, disable Checksum Offload with caution and be sure to re-enable it immediately after you’re done.


Happy packet capturing!

Cool tool – MAdCaP manager for analog and common area phones

Let’s face it, creating Common Area Phones (CAPs) and Analog Phones in Lync is annoying. Managing them is even more annoying. Greig Sheridan has the answer with MAdCaP (“Manage Analog Devices & Common Area Phones”).

MAdCaP allows you to create and edit Common Area Phones and Analog Devices as the name implies. This includes the little details like setting the correct dial plan, voice policy, client policy, and PINs.

This is a great tool for an Admin who’s in charge of phones, but has zero idea what PowerShell is. I’ve also found it handy at the end of a very long day when my brain simply won’t do PowerShell commands.

Cool tool – IIS Crypto

Every once in a while, a Lync admin gets to experience the true horror of changing crypto settings. More often than not, this is through following a series of registry edits found online, either on TechNet or a helpful looking blog.

IIS Crypto is a tool that allows you to fiddle with the protocols, cyphers, hashes, key exchanges and cypher suite order, all in a nicely put together GUI. Better yet, there are templates that’ll set your server to Best Practices, PCI, FIPS140-2, and Windows Defaults. That last one comes in really handy when that helpful looking blog turns out to be not so helpful, and your notes on what keys you changed in RegEdit aren’t so clear.