Working From Home

One staple of the office we probably won't have at home is a fax machine. Home facsimile transmitters and receivers are relatively inexpensive, but they certainly aren't ubiquitous. Most scanners can be used in conjunction with a PC to act as fax machines. Most PCs themselves can be used to transmit faxes created from standard electronic documents. It is arguably easier to transmit a fax on demand from a remote location than it is to receive one.

As a practical matter, though, faxing is just not something that is easily accomplished away from the office. Even though I can configure a workable fax process at home, I generally don't bother. I accumulate things that absolutely must be scanned and faxed until I am near a dedicated machine. Let's give faxing an unsatisfactory mark for matching the "in the office" experience.

Which brings up a point. If we are going to enable employees to work remotely, we need to expect them to use solutions that are easy to implement. Just because it is possible to do something does not mean we can expect the rank and file to be able to do it. I might be able to set up an open source e-mail client to hit an exposed POP and SMTP port off the corporate communications software, but that doesn't mean we can expect Bob from accounting to do the same thing.

In a world where computers are the tools of the trade, we cannot expect users to know much more than how to use them. If users understood how to set up their machines, the help desk wouldn't spend so much time showing users how to print to the color printer in the mail room.

If any tool can be considered the backbone of the present-day corporate world it would have to be e-mail–the de facto method of communication. Like it or not, knowledge workers use e-mail as the primary means of communicating with others. Within the corporate network they use fat-client applications that provide lots of additional functionality beyond just e-mail. Unless the user is joined to the network via VPN (virtual private network), those fat clients probably are not going to be available.

Fortunately, there are alternatives: Microsoft OWA (Outlook Web Access) and Domino Web Access offer users access to their e-mail with standard Internet protocols over port 80. Until recently, the experience provided by Web access was less than satisfactory. The latest generation of software (notably Exchange 2007) makes the Web client almost as feature rich as the fat client. Based on currently available tools, e-mail should not be a limiting factor for remote workers.

Which brings up another point. There is a tacit assumption remote workers will have access to broadband Internet access. Whether that access is through their cable provider, a cellular modem card, or the WiFi at Starbucks is largely irrelevant.

What may be relevant is how much responsibility corporate IT is going to take for providing that access to users and how much is going to be the responsibility of the remote worker. That is probably a different discussion, but for my dollar, I am going to insist voluntary telecommuters provide their own Internet access.

OK. I understand most of my readers no longer depend on file shares for storing important data. You all have implemented corporate knowledge management systems and use a collaboration portal for accessing those files. But that collaboration portal probably isn't available outside the firewall. Remote users are stymied unless they have VPN access. And that leads us into the really nasty thing about remote users–the fact they copy work files either to their portable computer or a thumb drive. They then modify their copy of the file and then sync it back up with the master version of that file whenever they have network access.

Even with sophisticated knowledge management systems, disconnected users are a problem. Version control is circumvented when a file is modified outside of the control of the system. Merging changes in multiple versions of the same file is a nightmare. This is where we see the limitations imposed upon remote workers.

Then we have the productivity tools we have spent so much money and effort to provide our workers. The ratings engine may use Web services to get a credit report, but there it sits–a fat-client three-tier application that needs to run on the network. Every organization, every knowledge worker uses computer-based tools that are only available on the network.

Which brings us to a recurring theme: VPN. There are simply too many things that cannot be accomplished without a connection through or around the firewall into the company network. This generally is accomplished through a VPN.

If remote workers are to be expected to be truly productive, they need to have secure access to corporate computing resources using VPN. A VPN is a network connected by way of secure communications tunnels. It is essentially nothing more than a connection across a public network (the Internet) to a secured corporate network. The two end points are connected using a secure (encrypted) channel or tunnel. Only devices with the correct "key" can operate using that tunnel.

Now comes the tricky part. There basically are two different VPN technologies. One technology offers ease of use. The other offers greater access to network resources.

IPsec, or Internet Protocol security, is the most widely used protocol for VPN. It provides a direct pipe to the corporate network. It requires each client computer have software installed, and that software then must be configured for use on a particular VPN. It requires a network device or appliance on the corporate side. It requires the use of ports that cannot always be expected to be open in a corporate firewall. Different versions of the client may not work with different versions of the appliance.

These requirements mean IPsec VPNs may not always be available. If I am at a client's site and need to VPN to my corporate network using IPsec, there is a very good chance I will not be able to tunnel through my client's firewall to get to my VPN. However, the rewards for connecting are great. Once connected using an IPsec VPN, the user experience is for all practical purposes identical to being on the network.

TCP/IP is protocol with a five-layer or -level model: Physical Layer (1), Data Link Layer (2), Network/Internet Layer (3), Transport Layer (4), and Application Layer (5). The lower the layer, the more functionality we have. IPsec operates at the network layer (3); the other VPN protocol, Secure Sockets Layer (SSL), operates at the Application Layer (5).

SSL VPNs employ browser-based technology to create the secure tunnel. Like their IPsec counterparts, SSL VPNs require an appliance on the secured network side. Since they use standard Web-browser technology, there is (largely) no need for any additional software to be installed on the client. If additional software is required, it is offered in the form of small active-x or Java components are downloaded and installed on demand. Since they use standard ports, their use generally is not blocked at corporate firewalls. Environments that block IPsec VPNs almost certainly will allow the use of SSL VPNs. There's a catch, though. Since the SSL pipe is at level 5, it is unable to provide as much functionality as an IPsec VPN running at level 3. SSL VPN vendors claim their products soon will provide just as much functionality as their IPsec cousins. Perhaps, but for now, there are simply some features they cannot provide.

So, you must weigh your choices when it comes to VPN. SSL is very easy to use. All your user needs is a URL, a user name, and a password. It can be used from any computer. That is a huge plus. It can be used in almost any environment. But it just doesn't provide the full functionality IPsec can. I work on remote systems all the time. Some of my clients use SSL, although most still rely on IPsec. From my perspective, IPsec is superior because it provides more functionality. But I still am able to function using either protocol.

The reason we use VPN in the first place is to keep our corporate assets secure. Through the use of encrypted tunnels, VPNs provide that security. But remember what I just mentioned about ease of use? All you need is a URL, user name, and password. In my book, that isn't too secure. Even using IPsec, all you often need is the client software, a configuration file, a user name, and password. A little better but not much.

The best systems use IPsec along with a portable key device, which provides a secure password key based on public-key encryption. There are trade-offs along the way that must be considered when choosing a VPN scheme for your employees. That decision needs to be made based upon the needs of that organization.

So, the bottom line is there are ways to provide proper tools to your employees to enable them to work remotely. You even might find they become more productive when they have the option to telecommute. I can assure you I would not be in my real office at the present time (4 a.m.), but I am comfortably working in my home office using VPN to tunnel into my corporate network. The only remaining question is why in the world would I want to? Some people will do anything to keep their editor happy.