The challenges of remote support and implementation can be frustrating as you strive for a reliable, secure and speedy connections for your off-site users. The processes involved can be costly, time-consuming and morale-defeating, and that's when it works right. At its worst, you’ll end up quitting your profession in the IT arts, and becoming a simple woodsman.

As with any new technology or strategy deployed on your network, managing your remote users requires several stages of preparation.

• 1. Identify the goals of the project.
• 2. Assess the various tools you have at your disposal (and research ones you don’t have).
• 3. Develop a solution.
• 4. Test it. I can't stress this step enough.

Identifying your users’ needs and goals is the most important part of your planning regimen. These needs and goals must be clearly and concisely defined. You must accurately identify the specifics of what they want to do now and in the near future. Failure to do so may send you back to the drawing board several weeks or months later. Not only will you have wasted your time and resources, you will have created an antagonistic atmosphere towards remote access.

Following are some key details to work out that will help you to identify, develop and test an applicable solution (or combination of solutions). They fall under several categories, including transport issues (bandwidth, equipment and so on), security, reliability and convenience.

Transport issues are extremely important to network support representatives as they manage remote users. How will remote users get to your network? What equipment will they need? How reliable will it to be? Should they use direct-dial or an alternative connection technique, such as TCP/IP over a public network? These are all valid questions, but they are only the tip of the iceberg. These days, when remote access is the topic of conversation, people tend to think more in terms of using the Internet as the primary medium, leaving direct dial as an alternative connectivity method. We'll examine both methods, but with the exploding use of public networks and their increased acceptance in the corporate world, you'll find more solutions that bypass direct connections altogether.

Is the user going to be on the move, or is he or she going to be stationary (a telecommuter working from home)? The level of mobility will determine which security and access methods will be appropriate. A lack of a static IP address (having the same IP address assigned each time if the user dials into an ISP), for example, will prevent you from taking some basic security steps, such as placing an ACL (access-control list) on a router at the central network. Being able to recognize your user by only his or her login ID can restrict your overall security scheme. This will undoubtedly force you to make exceptions to your security policies, unless you use a VPN technology. We’ll elaborate on this in a later section.

To effectively manage a mobile user plan for all possible contingencies. Security issues aside, stability will be the hardest thing for you to provide or support. A truly mobile user is one of the most difficult to support and manage, make no mistake about it. "Mobile" equals analog connectivity subject to the whims of whatever telco or facility sits between you and your users. You can leave your fancy T1, DSL and fiber-delivered services behind you, because it’s back to the 1960s in terms of reliable connectivity. Except back then, they didn't design the analog infrastructure to accommodate a 56-Kbps connection through a hotel's switchboard.

Provide your users with as many alternate paths as you can into your network (without completely sacrificing security, of course). Make those choices clear and easy to understand. If the access isn’t simple and robust, your users will not want to use it, making your job harder in the long run.

Additionally, you’re not going to be able to hide all the sundry transport mechanisms, making the connectivity experience less than elegant. Generally speaking, it will be difficult to find a nonhostile environment for your users to dial in from. Specifically, they're going to be facing unfamiliar variables such as dial-tone access (for example will they have to dial a "9" to get an outside line or need to enter in an access PIN specific to an LD carrier?). They’ll have to cope with noisy switchboards causing static on the line and, of course, the inherent background noise found in most long-distance switched analog connections.

Don’t expect anything less, or you’re going to get burned. Even if your users are lucky enough to stay in hotels that have Ethernet connectivity, you’ll still need to jump through with whatever hoops the hotel setup requires. These hoops may include being a DHCP client or configuring for a proxy gateway. This might not sound like a big deal to you, but remember, we’re talking about your end users, not you. To them, it looks like more voodoo than they’d care to deal with. This isn't their job, after all; it’s yours! You will have users who would prefer to dial in using a modem rather than change any configuration settings.