The pain of SOHO IT

TechTarget Australia New Zealand Networking Editor Richard Chirgwin has been acting as de facto CIO for a home-based venture. His report from the frontline of small business IT will be terrifyingly familiar to those with colossal IT departments at their disposal!

Speaking from recent and painful experience, I would like to ask the industry why is it so hard to set up the IT necessary to run a small or SOHO business?

Before anyone rushes to refute the idea, let's all remember that we're looking at things from the inside. Our own products are completely transparent to us, through familiarity and in-house training; but in the wild, those same products cause misery and tears to the purchasers.

If you're a micro-business wanting to do anything more complex than setting up a laptop and buying an external hard drive for backups, good luck. What you will find is that everything you need to do will need more expertise than you have; products will have quirks of interface and behaviour that mean you spend too much time trying to work out what's going wrong; and the kinds of features that might be life-savers for the SOHO are only available on "enterprise" products.

I am in the midst of such an exercise, on behalf of a friend who needed help creating a serious home office, but one that should have been simple enough to get worked out in a day, and I think the experience is worth recounting if only to try and find an easier way to do things.

First, let's understand that the environment isn't greatly complex. The home office needed:

  • An ADSL2+ router to connect to the Internet;
  • A storage server (preferably supporting external VPN access), since there will be occasions where more than one person has to use the same files, and because it's prudent to have more than one location for those files;
  • A backup to the external storage, because the business-person had been previosly and expensively burned by a failing NAS box that couldn't be recovered and whose files were stored in a proprietary encrypted format that couldn't be accessed;
  • A small VoIP server to run an IP phone, again with offsite access so that the softphone can be used when out-of-office, and so that an associate can take phone calls through the same number.

The Phones

The environment sits in the middle of VoIP requirements. Sure, there's any number of services that offer personal VoIP, from Skype through to various local ISP services, but if your requirements include being able to transfer calls between a local and remote extension, you're stuck with some kind of server.

And if you're budget-constrained and have spare computers around, the universal advice is to set up an Asterisk server.

This would be fine; as it happens, I've been using Asterisk in various environments for about three years. But using Asterisk is a completely different matter to actually installing it, configuring it, and trying to diagnose problems.

Pretty much all you get by way of diagnostics is Asterisk's extremely chatty logfile, so if something isn't working, you're stuck ploughing though thousands of lines of plain text just to find out if it can find the SIP server you're meant to connect to, whether it thinks it can register with the server, and what gets logged if you're trying to make a call.

There are various flavours of Asterisk in which the interface is designed for the small user - for example, FreePBX and [email protected] - but in spite of their names, they still make assumptions about the user's level of knowledge that don't fit with the kind of real people that might otherwise use the system.

To get started in any way at all, you have to at least understand these things:

  • Trunks - Calls will leave and arrive through trunks, which are the connection between you and the outside world.
  • Routes - You need some way of directing traffic on the "trunks" to different destinations, which means you need to be able to set up routes (for example, an outgoing route tells the system that if a user dials "9" the system should send the call to the outgoing trunk).
  • Extensions - The phones themselves need to register with the system, so you have to create extensions.

This sounds simple, but there are gotchas which are opaque to end users. To take just one: when you're setting up a trunk, both the FreePBX and [email protected] interfaces have a panel, in which you type "dialling rules" (for example that the trunk is invoked by dialling 9), and just underneath that panel, you have an "outbound dial prefix" panel.

The gotcha, instantly understood by the experienced user but not otherwise, is that the "outbound dial prefix" is going to be left blank for most users - it only matters in a multi-PABX environment, and indicates to the next PABX in the chain that it can strip off the first number dialled.

Remember that at least one of the systems I'm talking about, [email protected], is explicitly designed for the very small user - someone who will never in a million years run a multi-PBX environment. So why does the interface include something that serves only to confuse, and which if the user sticks their outbound prefix in that panel, will stop them making calls?

But the real killer is the lack of tools that would help diagnose specific operations. In my particular example, the Asterisk system (after a day or so of harder work than I enjoyed) is 90% working, except for one thing. It can't accept inbound calls, even though it's making outbound calls. If you dial the inbound number, as I have done too many times to want to count, it offers a busy signal. The system thinks it's registered the outbound trunk without trouble (at least, that's what I discern from the Byzantine log file), but the VoIP provider can't see the registration; and there's nothing I can discern from the router to suggest that traffic is somehow blocked there.

So without easy diagnostics, I am on the point of telling the user to kill the Asterisk server and look for some other way to configure the VoIP environment that won't cost an arm and a leg (and remember, for a SOHO business, IT budgets don't run to several thousand just to get the phones going).

Storage Issues

The next surprises came from the small NAS server which both the business-person and I thought was a must-have purchase.

I still think so, but various frustrations and surprises make me think the industry could do better.

I'm not going to name the devices, since at least some of the issues I've encountered are common to enough different products that I can fairly regard them as universal (I've used NAS boxes from the now-defunct YellowMachine, Stardom, Netgear, a roll-your-own FreeNAS, and one other vendor whose product failed so fast and was thrown away so quickly that I forget its name).

Here's one example of the gap between what the industry, and most product reviewers, take for granted but which is a mystery to the SOHO: file permissions.

To get the client's data onto the NAS box, I created the relevant volume, and copied the files from the terabyte external hard drive that was (and is) used as a backup (which makes that individual far more organised than I am, by the way!).

Had I mentioned that this friend is a Mac user? This is relevant, because every now and again there's a clash caused by how Finder handles long file names and how the rest of the world handles them; the result being that files copied by dragging-and-dropping from one device to another may not all arrive.

I decided it may be best to write a script to do the copying by creating, copying and extracting a tar archive. All worked nicely, until the friend decided to open the files and check.

In spite of my setting up users, groups and permissions, the NAS decided that as the creator of the files, I therefore owned the files, and it wasn't going to let anyone else into the folders. And because I was in a hurry, I decided to use Finder to reset the permissions to "everyone".

The NAS took exception to this, and reset the permissions - it blocked my access to the files, even though I was listed as an administrator. It took an awful lot of Googling through various user forums before I found a description of a bug that told me how to fix the problem; and I don't think that the ordinary SOHO user has the capacity to login to a NAS via SFTP, navigate to the right folder, and use the Linux "chown" command to set the right permissions.

If you're offering a box for a SOHO to use as a NAS, the fine points of file permissions are beyond the audience. A tick-box saying "only me / only these users / everyone on the LAN" is all that's required.

The Heat is On

Where do you find air-conditioned data centres - the enterprise space or the SOHO? So, which products most commonly offer comprehensive temperature management? The enterprise or the SOHO?

And where are temperatures going to rise the most when it's 37 degrees in Sydney? The SOHO, naturally.

We have a great number of products designed to be unobtrusive, discreet, and suited to being tucked out of the way, just where the airflows are the worst and the heat most likely to build up.

So during my marathon attempt at system configuration, with the temperature hitting the high half of the thirties, I probably shouldn't have been surprised that both the NAS and the router took exception to the environment and shut themselves down. But would some kind of warning be too much to ask? At least then, there would be something to wave in front of the SOHO owner to prove that there is a good reason to treat the equipment more kindly.

But after a day struggling with configurations that should have been easy, I wasn't much in the mood to treat equipment kindly. I was more wishing for just enough heat to turn everything into slag and start again.

These are just a few examples of how confronting IT can be to the SOHO. I would guess readers have more; and if any vendors really do think they've got the SOHO's problems licked, I'm happy to give their products a spin.

My final observation has to do with the router. I can see that there are very good reasons that some devices should be programmed through a port that's separate to the Ethernet ports (for example, because the user might want to change the address scheme away from the default, without losing access to the device). But I can't imagine why prominent vendors haven't yet noticed that nearly nobody has a newish computer fitted with any kind of traditional serial port. Take a walk around Harvey Norman sometime and count how many DB9 connectors you see on new laptops, if you don't believe me.

Read more on CW500 and IT leadership skills