Remote Office Support

6 Technologies For Remote Office Support, One To Avoid and a Cautionary Tale

Pity the remote office. Long on promises and short on technology support, workers at satellite sites often don't even have an IT person to beat up on when their Citrix sessions tank. Worse, they have a chart: Big Lan Threats -- Percentage of respondents who say the following users pose a threat to their LAN

chart: Big Lan Threats -- Percentage of respondents who say the following users pose a threat to their LAN

serious image problem: 57% of respondents to a recent survey cite remote employees as the biggest threat to their organizations among all users. That's unfortunate, because the trend toward geographically dispersed workplaces is growing as gas prices edge ever higher and companies seek alternatives to maintaining expensive centralized headquarters.

As a result, the law-abiding central office was soon crawling with viruses and malware.

And the travel budget should see some relief from those emergency visits to rebuild servers. One client, the IT director of a national facilities management firm, summarizes the disaster-recovery plan for boxes that crash at the company's 100-plus remote offices thusly: backup tapes and plane tickets. The company is looking to pilot a virtualized "office in a box" for remote support and disaster recovery.

3. IP TELEPHONY

Promise:
It's tough to get a definitive read on the percentage of corporate PBX systems that are IP-based, but the trend is clear. Infonetics Research predicts that the tipping point, when IP PBX shipments will outnumber TDM systems, will occur next year, and the firm expects the TDM segment of the enterprise telephony market to dip below the $1 billion mark for the first time this year. IP-centric vendors, notably Cisco, quote higher numbers, while those with a mix of TDM and IP systems, such as Avaya, Mitel, and Nortel, take a more nuanced stance. In fact, these vendors are using the ability to start the migration path but keep legacy handsets and port them onto a new IP PBX as a major selling feature.

So what does all this mean for branch offices? Plenty. Every major vendor offers an IP-based telecom system that lets remote sites become extensions of the main bank. Sure, the old TDM PBX systems did that, too. However, they typically required dedicated lines and fairly big boxes at both ends. In contrast, IP-based systems add some crazy flexibility, like being able to take a single phone, connect it to the Internet, and have it become an extension. If you're willing to invest in a small, inexpensive PBX unit at the remote site, it could be programmed to take over all calls in the event of a disaster, routing extensions to cell phones or a smaller bank of numbers.

For those remote offices that have warehouses or production floors, you can take all telephony support back to the main site while providing branch employees with nice IP features, such as wireless phones that work in the office and softphones for laptops. The list of vendors that have fleshed out their remote-office IP PBX offerings is huge, a good sign of maturity. Take your pick--Alcatel, Avaya, Cisco, Mitel, NEC, and Nortel are all vying for this business.

Reality:
Smaller sites can see major cost savings by removing all lines and linking their phone systems back to the main PBX. Offices with five to 10 phones can easily use the Internet to pass traffic if they have a T1 or better, and average throughput needs. However, before pursuing this route, think about bandwidth impact and 911 emergencies. Linking your staff and customers via a single extension system that supports transfers, conferences, and other PBX functionality is a big win in terms of productivity, and it will drive up your inter-site call volume. Don't make the mistake of underestimating the potential bandwidth hit at both ends, particularly if you plan to use the Internet to handle traffic. And remember - under these circumstances, your phones will only be as reliable as your internet connection.

Moreover, it's amazing how many times I see folks lay out a plan to funnel all calls back to a main site and forget about emergency services. If a user dials 911 on an IP phone, that caller ID needs to show the local location of the user, not a routed call from the home office. One possible solution is to leave a few analog lines at the remote site. Or, a nonprofit in downtown Boston found an innovative way to link its offices while providing for emergencies. Because there was line of sight between the remote building and HQ, IT installed a wireless bridge between the two sites and created a central phone system, then added a small phone switch at the remote location with a few analog lines. The switch was programmed to route 911 calls through the local lines, giving critical location details to responders.

Another option is to provision DSL at the remote office. DSL Internet links typically include two local lines, which also helps shore up redundancy. Many remote offices have only one Internet connection, so as more applications are moved into the cloud or centralized at the home office, the single line to the Internet becomes a major risk point. Supplementing a main line (typically a T1) with a DSL, cable modem, Verizon FiOS, or business-class wireless bridge like those from Towerstream is a must for remote sites. These second-tier lines won't come with a service-level agreement like a T1 provider, but they're a great way to increase bandwidth and provide backup connections. You should be able to easily add them into your remote firewall if you've adopted one of the modern unified threat management devices (click here for more on UTM).

4. WAN OPTIMIZATION

Promise:
The concept is straightforward: Stick an appliance on both sides of a WAN link and, voilà, faster traffic. No clients to load, no messing with the firewall (maybe). There are plenty of vendors to choose from: Blue Coat, Cisco, Citrix, F5, Juniper, Packeteer, and Riverbed have all been in this space for a while, tweaking and refining their systems or buying up promising upstarts. And they've all moved toward creating platforms that support appliance-to-appliance optimization and support for "soft clients," letting you bundle WAN investment to give even home office workers some compression.

Reality:
Test before you buy because performance is dependent on application load. In general, the bigger the individual packet size for an application, the better the optimizer will work. If you don't have a good sense of what traffic flows between your sites, we recommend getting an extended demo or try-and-buy. For example, if traffic between HQ and a remote office is mainly Citrix sessions, dropping $50,000 on a compression appliance is probably not the best way to improve speed. The packets are small and typically don't get enough boost from WAN optimization technologies.

A client company was all set to pull the trigger based on initial tests of passing graphics files. IT started down the slippery slope of creating an ROI calculation based on that initial compression. However, while the graphics transfers were a huge part of overall bandwidth, they represented only a small fraction of time during the day and a small number of users. The rest of the office used Citrix exclusively. They'd see a boost, but not the 50X performance jump that was in the cost justification for the CFO. The project went forward, but after setting the proper expectations; the purchase was justified for the graphics team, not for everyone.

Best bets for performance boosts that folks will notice: printing, SSL/HTTPS traffic, FTP, Windows file transfers, and Exchange. Worst bets: Citrix, Terminal Server, Telnet, VoIP (because compression should be done at the IP PBX), and GroupWise.

5. UTM APPLIANCES

Promise:
If there's one thing that creates friction between headquarters and remote IT staffs, it's device proliferation. One router, one firewall, one antivirus box, one intrusion-prevention system, one SSL/VPN appliance, one content filter, and soon there's no room for a coffeepot.

Enter the UTM, or unified threat management, appliance. The concept has been growing and expanding over the years, arguably in response to the security needs of smaller businesses. A 20-person office has the same threats as a large enterprise; however, this market typically refused to purchase multiple single-function devices. In response, security vendors such as SonicWall and WatchGuard added functionality to their appliances while striving to improve performance. Others, like Fortinet and Astaro, built from scratch based on the UTM concept. Not to be left out, larger players, notably Check Point, Cisco , and Juniper, have either combined existing functions or introduced new products to add broader UTM features on one box. This competition has spawned a wealth of options for remote sites, while the UTM concept provides central office with added consistency and manageability.

Reality Check:
Some UTM boxes may actually do too much, adding unneeded complexity. The key functionality remote sites need: basic firewall, gateway antivirus, intrusion prevention, content filtering, load balancing/failover, and site-to-site VPN. Nice-to-have features include inbound SSL/VPN, anti-spam, and client VPN access.

Push hard to get the right size device. Most vendors have product lines that can scale all the way up to the main office (imagine, a unified security design). Central IT could set the overall policy and design and give remote offices some level of control over which appliance is right for them.

6. INSTANT MESSAGING
Promise:
As instant messaging use continues to grow within the corporate walls, some sites have seen a reduction in e-mail of 10% to 15% and faster response to questions. IT departments were often the first to adopt IM, with remote offices becoming early benefactors of smoother communication, quick updates, and a reduction in e-mail chains. A medical instrumentation company in Boston, for example, deployed an enterprise-class IM system for the IT team. The goal was to facilitate better communication within the department. Remote IT staffers were added after the fact to address complaints about multiple voice-mail messages.

The project quickly expanded to engineering, production, and sales. The company got to 100% IM adoption within one year through a grassroots movement.

For an IM client the site, an IBM Lotus Notes shop, used Lotus Sametime, which has very nice integration with Notes. The company recently moved to Exchange but kept Sametime, not willing to switch to Office Communicator, the latest retooling of Microsoft's IM strategy. Redmond's previous IM attempts, notably Exchange 2000 Conference Server and Live Communication Server, have left many IT folks gun shy when it comes to Microsoft IM. Other possibilities for enterprise IM include software-as-a-service vendors like Near-Time and Google, as well as IP PBX vendors like Cisco and Mitel that combine their hardware and software into a unified approach.

Consumer IM systems such as MSN or AOL are free, but you get what you pay for. They generally don't provide enterprise-class control tools, such as access lists or logging, required by some compliance policies. AOL abandoned its enterprise IM service in 2004.

Reality:
What if you bypass free services, invest in corporate IM, and no one uses it? Will the company embrace IM, or will people simply see it as an annoyance and set their systems to perpetually "busy"? To know the answer, understand the culture at branch offices.

Then there's the Big Brother angle. If you think "IT is watching us" conspiracy theories are rampant at the corporate headquarters, head out to the field some day. Add any IM product with logging turned on--mandated for many companies--and folks get even more paranoid.

Finally, there's the specter of lost productivity. Unless you've blocked all the variants of IM, some users are already doing personal messaging. Once you sanction IM for corporate use, expect a flood of requests for gateway services to outside providers like AOL. It's a brave new world, and not everyone knows the rules. One senior executive told us he didn't think having an IM chat open all day with his daughter was the same waste of organizational resources as if he were calling her 20 times a day. How did I know they were IMing? He was constantly looking at his machine and typing back during our conversation.

DON'T GO THERE!

As always, there are technologies to avoid, and we'll address two specifically: Apple Macs and Microsoft Windows Vista. Let's face it: Many IT staffers and C-level folks now have Macs at home. Engineers love 'em. They can run Mac OS, Windows, and even VMware all on the coolest-looking laptop since the Epson HX-20. Apple's market share, while still relatively miniscule, is growing, according to most analysts. At first glance, Macs seem to make sense in the remote office because the promise (at least in the commercial) is that Macs are easier to use.

The issues:

• Limited support for Microsoft applications. Yes, it matters. Office for the Mac is good, but it's not the same client as Exchange nor does Mac Office offer the same collaborative toolset as Microsoft office 2007. No complete SharePoint functionality for you! The connections and layout are different and don't offer the same functionality.

• No Internet Explorer. This matters less than in the past in terms of Internet delivery of many applications, but for using Microsoft-centric apps such as SharePoint or Outlook Web access, Safari or Firefox users won't get the full functionality. This can also make access to certain financial institutions difficult.

• Unix chops. Just because engineers like Macs, that doesn't mean they know how to fix them. Don't forget, at the core of this nice-looking laptop is a BSD Unix kernel that takes some real skills to troubleshoot.

• Desktop management tools. Every network needs to have some level of desktop management, from asset tracking to desktop policies to patching and control. If you're Windows-centric, throw out most of your desktop management tools and strategies once you support Macs. You can integrate them into Active Directory, but your Group Policies won't run. The closest you'll get to a mixed-platform system is Altiris, and that's limited to inventory and software delivery. But hey - if you're Mac-centric, who needs things like management tools anyway?

That's what can bite you. Now before you flame me, I like Macs. They're fine for what they're best at. That said, they have major problems in a corporate environment, especially in an office that may not have sophisticated users. And even sophisticated users can develop 'Mac blinders' - the inability to see anything else as a possible solution to their problems - to the point where those blinkers become a serious liability to the way that the company's business needs to operate. Here's a case in point.

A cautionary tale.

Last year, when I was tapped to deal with a variety of IT issues of a local mining operation, the first thing out the CEO's mouth to me in our first meeting was, "I hate Microsoft." And he had done his very best, under the direction of a local Mac storefront operation (no agenda here - eh?) to purge his operation of any and all Microsoft-based PCs. There were just a couple - no, more than a couple - of problems with his animus against Microsoft. And it cost his company dearly.

First of all, he and his boss on the Board of Directors assumed that the mere usage of Macs automatically conferred invulnerability against security breaches. Of course, nothing could be further from the truth. IT security professionals and CEO/CIOs who know better know that one of the biggest sources of the loss of confidential information is the people in the organization itself. A careless conversation, email sent to the wrong destination or group list, a note left out in the open, inappropriate disposal of confidential/proprietary paper documents - these are just a few of the ways in which the 'people factor' comes into play. The path of best practices for securing your enterprise is a well-trodden one. But the CEO would hear none of this, nor would his boss. Yet, when a problem did occur with what appeared to be insider trading, it had to be the equipment, or the software. Or anything but the people involved. It was far easier to blame the system rather than the human factor. And to take responsibility for it.

Then there was the one immutable fact of this company's business operation - their primary line-of-business application resided on a Windows-based server and required a Windows desktop AND Internet Explorer in order to run. This application was a highly customized package that for better or worse, had become deeply woven into the company's DNA. The upshot is that in order to conduct business at all it was necessary to deliver a Microsoft desktop to each and every Mac client in the company. This was accomplished via Citrix Presentation Server (on yet another Windows based server - dang!). And because there could be no native Mac Internet Explorer, the application could not be delivered directly to the desk top or via the web - there are no activeX controls allowed in MacLand, you see. So the company had to forgo some of the key features of Citrx' ability to seamlessly deliver applications to a remote desktop, having to settle for a full desktop instead instead of an icon on the native desktop.

Because their local Mac storefront pals also had their nose up in the air regarding anything Microsoft, they were decidedly ill-suited to handle anything concerning the networking issues associated with connecting the company's branch offices over a wide area network. They weren't much better with the local HQ and branch office networks, for that matter. As a consequence, outside of a single sheet of paper with some server and router passwords, there was literally NO system documentation of any kind. None. It became my job to reverse-engineer their entire network architecture - built higgledy-piggledy by 'people reading from the manual' as one long suffering employee put it. Now this network encompassed several servers and routers distributed across several branch offices, networked printers and an IP telephony network for which no one claimed responsibility. Small wonder that the Mac storefront stopped returning their phone calls or answering their emails. You can't troubleshoot what you don't know about - or what's completely over your head. Nevertheless the job got done - mapped out in Visio and published as a website to the appropriate users.

Mac-induced blindness also resulted in a poorly constructed wireless network. There's an interesting tale behind this one. The company outgrew their space and obtained roomier quarters. Because they cut the deal before I could inspect the new building's wiring plant, it was not until a week before the move that I was able to determine that the entire facility had been wired with CAT 5 - not CAT 5e. Oh, what a difference that letter 'e' makes when it comes to network cabling. CAT 5 is basically telephone cable - 4 pairs, but no twist. CAT5e is the same, but with twisted pairs (one twist every half-inch). CAT 5 is only rated for 10 mbps. You need CAT 5e if you want to run your network reliably at 100 mbps. So the whole building wasn't capable of sustaining network speeds of better than 10 mbps, and owing to its nature, couldn't be retrofitted.

When I suggested an 'intelligent,' traffic-balanced multi-zone wireless LAN solution, our Mac-loving CEO informed me that he had already bought Mac Airport Extremes. These were installed by the local Mac store and with no regard for the existing network configuration. The inept installation brought the entire network to its knees. I had to reconfigure every one the AirPort Extremes in order to bet the rest of the wired network to function. The problems didn't stop there. Apple pushed out an update out that broke the connectivity between the Airport wireless function built into Mac laptops and the AirPort Extremes. The consequence - no one could log their MacBooks onto the network.

The Mac store solution to this was to archive the the installation, re-install Mac OS with everything except the offending wireless drive and then restore the user configuration and files back to the notebook. A process that, performed by the Mac boys, took hours. If this had been a Windows issue, the offending driver could have been rolled back within seconds. If the company had used the NETGEAR WG302 intelligent wireless access points as I had suggested, then they would not have had the problem in the first place. The 'gotcha' in the Airport Extremes is that they run in wireless 'N' mode all the time - period. They emulate wireless 802.11G and 802.11B. meaning that the easy solution for the problem - reverting to G mode on the access point - could not have been used anyway.

Furthermore, there was absolutely no guarantee that the same situation would not happen again. With all of its attendant cost in terms of downtime, lost productivity and consultant expense.

Ultimately, I had to walk away from the client. When your client insists upon making counter-productive decisions and persists in doing so, it's a no-win situation. Don't let this be you.