If you have done any work with Remote Access Services, you know that the various configuration wizards available usually do a pretty good job at simplifying what would otherwise be a fairly complicated setup. Although Microsoft has done a pretty good job of masking the Remote Access Service’s underlying complexity, this can sometimes be a double-edged sword. When things do not work as expected, it can sometimes be a little bit tough to troubleshoot the problem because so much of the Remote Access Services inner workings are hidden beneath the surface. Often though, the solution to seemingly daunting problems is surprisingly simple if you know where to look. In this article, I want to talk about some of the Remote Access Service related problems that I have run into over the years, and how to get around them.

Users Can’t Browse the Network

The most common problem that I have encountered in relation to Remote Access Service involves users connecting to a RRAS server from their home computers and not being able to browse the network. This is also one of the problems that I have always dreaded troubleshooting the most, because it means diagnosing problems with somebody’s home computer.

If you attempt to diagnose the problem over the phone, it usually means a long troubleshooting session after hours. After all, the user has to be at home before they can help you troubleshoot their home computer. Needless to say, this is no fun, because nobody wants to have to do telephone support for a user once they go home for the day.

On the other hand, if you have the user bring their computer into the office you might be able to solve the problem more quickly, and you may even be able to do it during the work day rather than using your own personal time, but you may have the user hovering over your shoulder the entire time.

As for the actual diagnostic process, there are any number of things that can cause a user not to be able to browse the network once they connect to the RRAS server. I myself have run into situations in which the user’s home computer was infested with viruses, and situations in which the user’s kid had altered the TCP/IP stack. Both of these types of situations can take a lot of effort to repair. The good news is that my experience has been that the vast majority of the time, correcting the problem is fairly simple.

The first thing that I would recommend doing is teaching the user how to map a network drive, and then how to use the mapped drive to get to their files. I have seen a number of situations, particularly with older versions of Windows, in which network browsing does not work, but drive mapping does.

Another thing that you can do to correct the problem is to have the user change their workgroup setting. Most of the time, when a consumer buys a PC, PC to PC is configured by default to act as a part of a workgroup named WORKGROUP. Most corporate networks use domains rather than workgroups. Often times, directing the user to change the workgroup name to match the name of the domain that they are logged into will allow the user to browse the network.

Trouble Dialing in to a Remote Access Server

Probably the second most common problem that I have encountered with relation to the Remote Access Services involves the user attempting to dial into a Remote Access Server, but not actually being able to establish connectivity. Again, there are any number of situations that can cause this problem.

In my own personal experience, I have used the Remote Access Services primarily as a means for allowing users located in remote areas to dial into the corporate network. In these types of situations, using Remote Access Services and a dial in connection may be the only option because of the unavailability of broadband connections in these types of areas.

What I have found is that often, these remote areas have phone lines of insufficient quality to reliably carry data. I have also sometimes found this to be true of older office buildings whose phone lines have been in place for a long time.

Phone line quality issues are always a little bit tricky to overcome. In some situations, I have been able to at least partially correct the problem by installing filters between the phone line and the modem. These filters help to condition the line by getting rid of excess noise. Other times though, low-budget filters are ineffective, and I have had to seek help from the phone company.

If you are trying to establish a connection in a rural area, or if the phone lines coming into the building are ancient, it is fairly easy to explain why you may not be getting a good connection. Other times though, the reason why a connection is failing is a lot less predictable.

If you have ever looked around in the Remote Access Services console, you have probably noticed that there is no mechanism in order to diagnose connectivity problems. However, there are some helpful diagnostic tools in the Control Panel.

If you are having trouble establishing a connection using a modem, then the first thing that you will have to do is to narrow the problem down to either the client or the server. Typically, this is easy to do because if the problem exists on the server end than any clients to dial into that server will experience problems. If only one client experiences the problem, then it is a good bet that the problem is related to the client, not to the server.

Before you determine that the problem is definitely client related, you must consider whether or not the server uses multiple phone lines. If the server does use multiple phone lines, then you should do some tests to see if other clients are able to dial into the same phone line as the client who is experiencing difficulties, and successfully establish a connection.

Another thing that you should take into account is whether or not the connection has ever worked reliably in the past. If the connection has always been reliable, but suddenly refuses to work, then there are a couple of things that you can look for.

One possibility is that the phone company may be doing work in the area. I would not really think that this would cause any problems as long as you can still get a dial tone on the line, I have experienced situations in which modem connectivity failed until the guys outside on the pole finished what they were doing.

A more common problem is that an electrical surge may have damaged the modem. Even if there have not been any storms recently, it is not uncommon to have electrical surges on phone lines. These surges are not usually strong enough to damage a telephone, but they can damage a modem; particularly if the modem line does not pass through a surge protector. The easiest way to test for this condition is to simply swap out the modem and see if you can establish connectivity.

If you are using Windows Vista as your primary desktop for managing Windows Server 2008, then you will need RSAT to do so.

If you are using a Windows Vista machine to manage your Windows Server 2008 devices then you are already missing quite a few of the tool you need to do so effectively. You can get all of these tools by downloading and installing the Remote Server Administration Tools (RSAT). RSAT includes things such as Active Directory Domain Service tools, DHCP server tools, DNS server tools, and group policy management tools.

After making sure that your installation of Vista is at the Service Pack 1 level, you can download RSAT here: http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en&displaylang=en.

Installing this download will make sure the RSAT tools are on your system, but you must “unlock” them in order to use them. This is done by going to the system control panel, choosing Programs, and selecting Turn Windows Feature On or Off. In this dialog box, you can select the RSAT check box to make all of these tools available, or simply select certain tools individually.

Once these steps have been performed, you should have access to all of these tools under the Administrative Tools section in the control panel.