Contents

OverviewExamining Remote Access Policies Examining Remote Access Policy

EvaluationCreating a Remote Access Policy Lab A: Creating a Remote Access Policy
and Profile Troubleshooting Remote Access Lab B: Troubleshooting Remote Access
(Simulation)Review
Module 8: Supporting Remote Access to a Network
1
2
4
8
12
19
29
31

Information in this document, including URL and other Internet Web site referenc
es, is subject to change without notice. Unless otherwise noted, the example co
mpanies, organizations, products, domain names, e-mail addresses, logos, people,
places, and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, e-mail address, logo, person,
places or events is intended or should be inferred. Complying with all applicab
le copyright laws is the responsibility of the user. Without limiting the right
s under copyright, no part of this document may be reproduced, stored in or intr
oduced into a retrieval system, or transmitted in any form or by any means (elec
tronic, mechanical, photocopying, recording, or otherwise), or for any purpose,
without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or othe
r intellectual property rights covering subject matter in this document. Except
as expressly provided in any written license agreement from Microsoft, the furn
ishing of this document does not give you any license to these patents, trademar
ks, copyrights, or other intellectual property.
2000 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Active Directory, BackOffice, FrontPage,
IntelliMirror, NetShow, Outlook, PowerPoint, Visual Studio, and Windows Media a
re either registered trademarks or trademarks of Microsoft Corporation in the U.
S.A. and/or other countries.
The names of actual companies and products mentioned herein may be the trademark
s of their respective owners.
Simulations and interactive exercises were built with Macromedia Authorware
Overview
In Microsoft Windows 2000, you can define and create remote access policies to con
trol the level of remote access that a user or group of users has to the network
. Remote access policies are a set of conditions and connection settings that gi
ve network administrators more flexibility in granting remote access permissions
and usage. The Windows 2000 Routing and Remote Access service and Windows 2000
Internet Authentication Service (IAS) both use remote access policies to determi
ne whether to accept or reject connection attempts. As the administrator, you ar
e also required to troubleshoot and maintain the remote access server for optimu
m performance.
At the end of this module, you will be able to:

Explain remote access policy and profile concepts.

Describe the process of remote access policy evaluation.
Create a remote access policy and configure a remote access profile.
Maintain and troubleshoot remote access.

You can use remote access policies to assign settings to a connection, based on
the user that is connecting and the properties of the connection. Understanding
how policies are applied will help you provide customized access to the various
users and groups in your organization. It is likely that the default policy sett
ings are adequate for your remote access needs. However, it is important that yo
u become familiar with remote access policies because using them effectively pro
vides you with flexibility in granting remote access permissions and usage.
Policies are Stored Locally
Windows 2000 stores remote access policies on the remote access server, not in t
he Active Directory directory service, so that policies can vary according to rem
ote access server capabilities.
Note You can centralize remote access policies through the use of IAS. For more
information about IAS, see module 9, Extending Remote Access Capabilities by Usin
g IAS, in course 2153, Implementing a Microsoft Windows 2000 Network Infrastructu
re.
Components of a Policy
A remote access policy consists of three components that cooperate with Active D
irectory to provide secure access to remote access servers. The three components
of a remote access policy are its conditions, permissions, and profile.
Conditions
The conditions of remote access policies are a list of parameters, such as the t
ime of day, user groups, caller IDs, or Internet Protocol (IP) addresses, that a
re matched to the parameters of the client that is connecting to the server. The
first set of policy conditions that match the parameters of the incoming connec
tion request is processed for access permission and configuration.
Permissions
Remote access connections are permitted based on a combination of the dial-in pr
operties of a user account and remote access policies. The permission setting on
the remote access policy works with the user s dial-in permissions in Active Dire
ctory.
For example, a policy can grant access to all users in Group A from 8:00 A.M. th
rough 5:00 P.M. However, the permissions for User X in Group A can be set to den
y access in Active Directory, whereas the permissions for User Y in Group A can
be set to allow access at all times. As a result, most users in Group A are cont
rolled by the policy setting and can gain access only from 8:00 A.M. through 5:0
0 P.M. However, User X is denied access completely, and User Y is granted 24-hou
r access.
Profile
Each policy includes a profile of settings, such as authentication and encryptio
n protocols, that are applied to the connection. The settings in the profile are
applied to the connection immediately, and may cause the connection to be denie
d. For example, if the profile settings for a connection specify that the user c
an only connect for 30 minutes at a time, the user will be disconnected from the
remote access server after 30 minutes.

Examining Remote Access Policy Evaluation

It is important to understand how remote access policies are evaluated, so that
you can determine the settings that will apply to incoming connections and plan
your policies appropriately. Remote access policies are evaluated according to a
logical flow that depends on whether the Windows 2000 domain is in mixed or nat
ive mode. (A mixed mode domain allows domain controllers to run Windows 2000 or
Microsoft Windows NT version 4.0. A native mode domain requires that all domain c
ontrollers run Windows 2000.) Familiarity with the logic of remote access policy
evaluation, the features of the default policy, and the interaction of multiple
policies will help you design effective remote access policies.
Following Policy Evaluation Logic
Windows 2000 evaluates a connection attempt based on logic that incorporates pol
icy conditions, user and remote access permissions, and profile settings.
Remote access policies are evaluated as follows:
1.
Routing and Remote Access matches the conditions of the remote access policy to
the conditions of the attempted connection:
If there is no policy defined, all access is denied.
If there is no policy that matches, the access is denied.
If there is a match, the policy is used to determine access.

2.
Routing and Remote Access checks the user account s dial-in permissions:
If the permission is set to Deny access, the user is denied access.
If the permission is set to Allow access, the user is granted access and the pro
file for the policy is applied.
If the permission is set to Control access through Remote Access Policy, the pol
icy s permission setting determines user access.

3.
Routing and Remote Access applies the settings in the policy s profile to the inco
ming connection.
The connection may not be allowed if a critical setting in the profile does not
match a setting on the remote access server. For example, the profile for an inc
oming connection may specify that a group can only connect at night. If a user i
n that group tries to connect during the day, the connection attempt will be den
ied.

The connection may be disconnected at a later stage due to a setting in the prof
ile, such as a time restriction on connecting.

Examining Default and Multiple Policies

The default remote access policy will have no effect on incoming connections whe
n the domain is in mixed mode, and the remote access policy has no profile setti
ngs associated with it. The default policy will be applied to all connection att
empts that do not match any other policies. You should be aware of the settings
of this policy and the implications of using the default policy in native mode a
nd mixed mode domains. You should also understand how multiple policies interact
.
Default Remote Access Policy
The default policy, called Allow access if dial-in permission is enabled, is cre
ated when Routing and Remote Access is installed. This policy controls access th
rough the user s dial-in permission. The following table describes the settings of
the default policy.
Setting Value
Conditions Current date/time = any day, any time
Permissions Deny access
Profile None
Native Mode and Standalone Servers
When your domain is running in native mode, or if your remote access server is a
standalone server, setting the dial-in permission on every user account to Cont
rol access through Remote Access Policy will result in the rejection of all conn
ection attempts if you do not change the default remote access policy. However,
if you set one user s dial-in permission to Allow access, that user s connection att
empts will be accepted. If you change the permission setting on the default poli
cy to Grant remote access permission, all connection attempts are accepted.
Mixed Mode
The default policy is always overridden in a mixed mode domain because the user s
dial-in permission, Control access through Remote Access Policy, is not availabl
e in mixed mode. However, the remote access server still applies remote access p
olicies to users in a mixed mode domain. If the user s dial-in permission is set t
o Allow access, the user still must meet the conditions of a policy to gain acce
ss.
Important When converting from mixed mode to native mode, the permissions for al
l users with a dial-in setting of Deny access will be changed to Control access
through Remote Access Policy. Permissions for all users with a dial-in setting o
f Allow access will remain set to Allow access. As a result, if the default remo
te access policy remains unaltered and no other policies exist, the conversion t
o native mode will have no effect on users remote access permissions.
Multiple Policies
Many organizations will have different remote access requirements for different
groups in the organization. These organizations will require multiple remote acc
ess policies. You should create these policies carefully. If a connection attemp
t does not match any of the remote access policies, the connection attempt is re

jected, even when a user s dial-in permission is set to Allow access.

When a user attempts to connect, the first policy in the ordered list of remote
access policies is checked. If all of the conditions of the policy do not match
the connection attempt, the next policy in the ordered list is checked, until a
policy matches the connection attempt.
The connection attempt is then evaluated against the profile and user account se
ttings of that profile. If the connection attempt does not match the profile or
user account settings of the first remote access policy that matches the connect
ion attempt, the connection attempt is rejected. No other policies are checked.
You can modify the order of remote access policies. For example, you might want
the remote access policy that applies to the majority of your users to be checke
d first, so that fewer connection attempts must be evaluated against more than o
ne policy.
To modify the order of remote access policies:
1.
In Routing and Remote Access, in the console tree, click Remote Access Policies.
2.
In the details pane, right-click the policy that you want to move, and then clic
k either Move Up to move the policy up one level, or Move Down to move the polic
y down one level.
Important Because Routing and Remote Access requires that the conditions of at l
east one policy be matched, if the default policy is removed and there are no ot
her policies, all connection attempts will be rejected. In most situations, you
should leave the default policy unaltered to provide access for users who are ex
plicitly granted access through their user permissions.
Creating a Remote Access Policy
You can create detailed rules for remote access that are as simple or as complex
as your organization needs. A remote access policy consists of user dial-in set
tings, remote access policy conditions, and remote access policy settings. Altho
ugh they do not need to be completed in any particular order, it is important to
include all three components in your planning.
Note For more information about user dial-in settings, see module 7, Configuring
Remote Access, in course 2153, Implementing a Microsoft Windows 2000 Network Infr
astructure.
Remote access policy conditions are attributes that are compared to the settings
of a connection attempt. If there are multiple conditions in a policy, all of t
he conditions must match the settings of the connection attempt, or the next pol
icy is evaluated.
The following table lists the conditions that you can set for a remote access po
licy.
Note Some of these conditions apply to Remote Authentication Dial-In User Servic
e (RADIUS). For more information about RADIUS, see module 9, Extending Remote Acc
ess Capabilities by Using IAS, in course 2153, Implementing a Microsoft Windows 2
000 Network Infrastructure.
Condition name Description Wildcard okay (*) Used by IAS
NAS IP Address A character string that identifies the IP address of the network
access server (NAS). Yes Yes
Service Type The type of RADIUS service that is requested. Examples include fra
med (such as Point-to-Point Protocol [PPP] connections) and logon (such as Telne
t connections). For more information about RADIUS service types, see RFC 2138 un
der Additional Reading on the Web page on the Student Materials compact disc. N
o Yes
Framed Protocol The type of framing for incoming packets. Examples include PPP,

AppleTalk, Serial Line Internet Protocol (SLIP), Frame Relay, and X.25. No Ye
s
Called Station ID A character string that identifies the telephone number of th
e NAS. Yes No
10 Module 8: Supporting Remote Access to a Network
(continued)
Wildcard Used by
Condition name Description okay (*) IAS
Calling Station ID
A character string that identifies the telephone number
that the caller Yes No uses. The telephone line, hardware, and hardware driver m
ust support reception of caller ID data.
NAS Identifier A character string that identifies the NAS from which the reques
t Yes No originated.
NAS Port Type The type of media that the caller uses. Examples include analog
No No telephone lines (or Async), Integrated Services Digital Network (ISDN), an
d virtual private networks (VPNs).
Day and Time The day of the week and the time of day of the connection attempt.
No No Restrictions Client IP Address A character string that identifies the IP a
ddress of the RADIUS Yes Yes client.
Client Vendor The manufacturer of the NAS that is requesting authentication. No
Yes Client Friendly A character string that identifies the name of the RADIUS cl
ient that Yes Yes Name is requesting authentication.
Windows Groups The names of the Windows 2000 groups to which the user who is No
No attempting the connection belongs. For a remote access server in a domain in
native mode or an IAS server, use universal groups. There is no condition for a
specific user name.
Tunnel Type
Tunneling protocols for incoming packets, such as Layer Two No N
o Tunneling Protocol (L2TP).
You can create a remote access policy and an associated profile under Remote Acc
ess Policies in the console tree of Routing and Remote Access.
To add a remote access policy:
1.
Open Routing and Remote Access from the Administrative Tools menu.
2.
Right-click Remote Access Policies, and then click New Remote Access Policy.
3.
In the Add Remote Access Policy wizard, type the name of the profile in the Poli
cy friendly name box, and then click Next.
4.
To configure a new condition, click Add.
5.
In the Select Attribute dialog box, click the attribute to add, and then click A
dd.
6.
In the attribute dialog box (the name of this dialog box will vary according to
the attribute selected), enter the information that the attribute requires, and
then click OK.
7.
Click Add to add another condition, or click Next to continue with the wizard.
8.
To grant access to callers matching these conditions, click Grant remote access

permission, or to deny access, click Deny remote access permission, and then cli
ck Next.
9.
You can then create a profile, or click Finish to create a policy without a prof
ile. You can add a profile after the policy is created.

The remote access profile specifies what kind of access the user will be given i
f the conditions match. Access will be granted only if the connection attempt do
es not conflict with the settings of the user account or the profile. You can co
nfigure a profile in the Edit Dial-in Profile dialog box by clicking Edit Profil
e in the Properties dialog box for a policy. You can configure the following set
tings in the dialog box:
Dial-in Constraints. You can use these settings to determine the amount of idle
time before disconnection; the maximum session time; and the days, times, teleph
one numbers, and media types (ISDN, VPN, and so on) that are allowed.
IP. You can configure client IP address assignment and Transmission Control Prot
ocol/Internet Protocol (TCP/IP) packet filtering on this tab. You can define sep
arate filters for inbound or outbound packets.
Multilink. You can configure Multilink and Bandwidth Allocation Protocol (BAP) o
n this tab. Use these settings to disconnect a line if bandwidth falls below a c
ertain level for a given length of time. Multilink can also be set to require th
e use of BAP.
Authentication. You can use these settings to define the authentication protocol
s that are allowed for connections that use this policy. Make sure that any prot
ocols that you select here are also enabled in the Properties dialog box for the
server.
Encryption. You can use this tab to specify the types of encryption that are pro
hibited, allowed, or required.
Advanced. You can use this tab to configure additional network parameters that c
an be sent from RADIUS servers running non-Microsoft operating systems.

Lab A: Creating a Remote Access Policy and Profile

Objectives
After completing this lab, you will be able to:
Create a remote access policy.
Create a remote access profile.

Test a policy and a profile.

Prerequisite
Before working on this lab, you must have a familiarity with remote access polic
y and profile concepts.
Lab Setup
To complete this lab, you need the following:
Successful completion of Lab A, Configuring a VPN Connection, in module 7, Configur
ing Remote Access of course 2153, Implementing a Microsoft Windows 2000 Network I
nfrastructure.
A computer running Windows 2000 Advanced Server that is configured as a domain c
ontroller in native mode.
A lab partner with a similarly configured computer.
You will also need the following information. If you are unsure about any of the
se values, please ask your instructor.
Number Record value here
Your student number x= Your partner s student number y=
Important The lab does not reflect the real-world environment. It is recommended
that you always use complex passwords for any administrator accounts, and never
create accounts without a password.
Important Outside of the classroom environment, it is strongly advised that you
use the most recent software updates that are necessary. Because this is a class
room environment, we may use software that does not include the latest updates.
Scenario
Your company needs to have more control over which employees have access to its
network remotely, and it also needs more control over how those employees connec
t to the network. To accomplish this, you are going to configure remote access p
olicies to control access to your network.
In this lab, you will work with a partner to configure remote access policies. Y
ou will create a user account, and configure its dial-in properties and group me
mbership. You will then create a remote access policy for this group, and config
ure access by using that policy. Your partner will then use the user account tha
t you created to dial in to your computer by a VPN connection, to test the use o
f the policy.
Estimated time to complete this lab: 45 minutes
Exercise 1 Configuring and Testing Remote Access Policies
Scenario
Northwind Traders has implemented remote access servers for the sales force, to
allow for secure access to the company network from the Internet. As the adminis
trator for the remote access servers on your network, you need to implement a re
mote access policy that grants access to the sales groups and denies access to e
veryone else. Before you set up the actual remote access policy, you will create
a test user and a test group.

Goal
In this exercise, you will create a test user in a test group, verify that the d
efault policy denies access to the test user, and then create and test a remote
access policy that grants access to members of the test group.
Tasks Detailed Steps
Perform the following procedures on both computers.
1. Create a user called RemoteUserx (where x is your student number), with a pas
sword of password. Configure the user properties to allow dial-in access. a. Lo
g on as administrator@domain.nwtraders.msft (where domain is the name of your do
main) with a password of password. b. Open Active Directory Users and Computers
from the Administrative Tools menu. c. In the console tree, under domain, rightclick Users, point to New, and then click User. d. In the New Object
User dialog
box, in the First name box, type RemoteUserx (where x is your student number).
e. In the User logon name box, type RemoteUserx f. Click domain.nwtraders.msft,
and then click Next. g. Set the password for the new user account to password, c
lick Next, and then click Finish. h. In the details pane, right-click RemoteUser
x, and then click Properties. i. On the Dial-in tab, click Allow access, and the
n click OK.
(continued) (continued) (continued)
Tasks Detailed Steps
2. Create a new global group called RemoteGroupx. Add the user that you just cre
ated to the group. a. In the console tree, right-click Users, point to New, and
then click Group. b. In the New Object
Group dialog box, in the Group name box,
type RemoteGroupx (where x is your student number). c. Under Group scope, verif
y that Global is selected, and under Group type, verify that Security is selecte
d, and then click OK. d. Open the Properties dialog box for RemoteGroupx. e. On
the Members tab, click Add. f. In the Select Users, Contacts, Computers, or Grou
ps dialog box, in the Look in box, verify that your domain is displayed. g. In t
he list of objects, click RemoteUserx, click Add, and then click OK. h. Click OK
to close the RemoteGroupx Properties dialog box. i. Minimize Active Directory U
sers and Computers.
Important: Wait until your partner has completed the previous procedures before
starting the following procedure.
3. Test your dial-in configuration by dialing in to your partner s computer by usi
ng the account that your partner created, and then close the connection. a. Rig
ht-click My Network Places, and then click Properties. b. In Network and Dial-up
Connections, double-click Virtual Private Connection. c. Connect as RemoteUsery
(where y is your partner s student number) with a password of password. d. Click
OK to close the Connection Complete message, and then disconnect the VPN connect
ion.
Important: You must perform tasks 4 and 5 at the same time as your partner.
4. Configure the dial-in permissions for RemoteUserx to have access controlled t
hrough the remote access policy. a. Restore Active Directory Users and Computer
s, and then open the Properties dialog box for RemoteUserx. b. On the Dial-in ta
b, click Control access through Remote Access Policy, and then click OK.
Note: The domain controllers must be running in native mode for the Control acce
ss through Remote Access Policy option to be available on the Dial-in tab.
4. (continued) c. Minimize Active Directory Users and Computers.
Tasks Detailed Steps
5. Test your dial-in configuration by dialing in to your partner s computer as Rem
oteUsery. a. In Network and Dial-up Connections, double-click Virtual Private C
onnection, and then connect as RemoteUsery (where y is your partner s student numb
er) with a password of password. The connection attempt was denied because the d
efault remote access policy denies access to all users. In native mode, if you s
elect Control access through Remote Access Policy, you must configure a policy t
hat allows access for your users. b. In the Error Connecting to Virtual Private
Connection dialog box, click Cancel. c. Minimize Network and Dial-up Connections
.

6. Use Routing and Remote Access to add a new policy called Allow RemoteGroupx a
ccess, which allows access to users in the RemoteGroupx group. Make sure that th
is policy is evaluated before the default policy. a. Open Routing and Remote Ac
cess from the Administrative Tools menu. b. In the console tree, expand server (
where server is the name of your computer), right-click Remote Access Policies,
and then click New Remote Access Policy. c. On the Policy Name page, type Allow
RemoteGroupx access (where x your student number), and then click Next. d. On th
e Conditions page, click Add, and in the Select Attribute dialog box, click Wind
ows-Groups, and then click Add. e. In the Groups dialog box, click Add. f. In th
e Select Groups dialog box, in the Look in list, click your domain. g. In the Se
lect Groups dialog box, under Name, click RemoteGroupx, click Add, and then clic
k OK. h. In the Groups dialog box, click OK. i. On the Conditions page, click Ne
xt. j. On the Permissions page, click Grant remote access permission, and then c
lick Next. k. On the User Profile page, click Finish. l. In Routing and Remote A
ccess, in the console tree, click Remote Access Policies, and in the details pan
e, right-click Allow RemoteGroupx access, and then click Move Up. m. Minimize Ro
uting and Remote Access.
Important: Wait until your partner has completed the previous procedure before s
tarting the following procedure.
Tasks Detailed Steps
7. Test your dial-in configuration by dialing in to your partner s computer. a. R
estore Network and Dial-Up Connections, double-click Virtual Private Network, an
d then connect as RemoteUsery with a password of password. b. Click OK to close
the Connection Complete message, and then disconnect the VPN connection.
8. Configure the order of the remote access policies so that the default policy
is evaluated first. a. Restore Routing and Remote Access. b. In the console tre
e, click Remote Access Policies, and in the details pane, right-click RemoteGrou
px, and then click Move Down. c. Minimize Routing and Remote Access.
9. Test your dial-in configuration by dialing in to your partner s computer. a. I
n Network and Dial-Up Connections, double-click Virtual Private Network, and the
n connect as RemoteUserx with a password of password. Notice that this connectio
n attempt fails because the policy denies dial-in permission. b. In the Error Con
necting to Virtual Private Connection message, click Cancel.
Important: You must perform tasks 10 and 11 at the same time as your partner.
10. Configure the user dial-in properties of RemoteUserx to allow access. a. Re
store Active Directory Users and Computers. b. Open the Properties dialog box fo
r RemoteUserx. c. On the Dial-in tab, click Allow access, and then click OK. d.
Close Active Directory Users and Computers.
11. Test your dial-in configuration by dialing in to your partner s computer. a.
In Network and Dial-Up Connections, double-click Virtual Private Network, and th
en connect as RemoteUsery with a password of password. b. Click OK to close the
Connection Complete message, and then disconnect the VPN connection.
Exercise 2 Disabling Routing and Remote Access
Scenario
One of your remote access servers is going to be replaced. You need to disable R
outing and Remote Access for the server before taking the server offline.
Goal
In this exercise, you will disable Routing and Remote Access on your server and
then log off.
Tasks Detailed Steps
1. Remove the remote access policy that you added in the previous exercise. a.
b. c. Restore Routing and Remote Access. In the console tree, click Remote Acc
ess Policies. In the details pane, right-click Allow RemoteGroupx access, and th
en click Delete.
d. In the Delete Policy box, click Yes.
2. Use Routing and Remote Access to disable the service on your computer, close
all open windows, and then log off. a. b. c. Right-click server (where server

is the name of your computer), and then click Disable Routing and Remote Access.
In the Routing And Remote Access dialog box, click Yes. Close all open windows,
and then log off.
Troubleshooting Remote Access
Remote access to your organization requires the successful operation of many com
ponents, including computers, communication hardware, communication lines, and i
n some cases, the Internet. Because the successful operation of remote access re
lies on such a large number of components to function correctly, operational pro
blems arise occasionally. The ability to diagnose and then fix problems is criti
cal to keeping your local and remote users connected to your network.
Monitoring the remote access server is the best method you can use to determine
the source of problems on a remote access server. There are several tools and lo
gs that can be used to monitor and troubleshoot remote access.
Event Logs
The Windows 2000 event log contains information about system components in Windo
ws 2000 and is one of the first places to check for information about a problem.
To access the event log, right-click My Computer, and then click Manage. Under
Computer Management, expand Event Viewer, and then click System. The entries tha
t have RemoteAccess listed in the source column are the event logs related to re
mote access.
Modem Logging
Windows 2000 Professional automatically records a log of communication made from
the computer to a modem during a connection. This log is normally overwritten e
ach time a new connection is made, but can be configured to append the log file.
In Windows 2000 Server and Advanced Server, you must manually enable the log fi
le.
To enable modem logging on Windows 2000 Server:
1.
In Control Panel, double-click Phone and Modem Options.
2.
In the Phone and Modem Options dialog box, on the Modems tab, click the modem th
at you are configuring, and then click Properties.
3.
In the Properties dialog box for the modem, on the Diagnostics tab, click select
the Record a Log check box, and then click OK. (In Windows 2000 Professional, t
his option appears as Append to Log. This means that each connection will not ov
erwrite the existing log file.)
To view the log file, click View log on the Diagnostics tab.
Windows 2000 has an extensive tracing capability that you can use to troubleshoo
t complex network problems. You can enable the components in Windows 2000 Server
to log tracing information to files. You must enable the tracing function by ch
anging settings in the Windows 2000 registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing
Caution Incorrectly editing the registry may severely damage your system. Before
making changes to the registry, you should back up all critical data on the com
puter.
You enable tracing for each remote access component by setting the registry valu
es described in the following table
Value Data type Description

EnableFileTracing REG_DWORD
FileDirectory REG_EXPAND_SZ
You can enable logging tracing information to a file by setting the value of Ena
bleFileTracing to 1. The default value is 0.
You can change the default location of the tracing files by setting FileDirector
y to the path that you want. The file name of the log file is the name of the co
mponent for which tracing is enabled. By default, log files are placed in the sy
stemroot\Tracing folder.
(continued)
Value Data type Description
FileTracingMask REG_DWORD FileTracingMask determines how
much tracing information is logged to
the file. The default value is
FFFF0000, which is the maximum
level of tracing.
MaxFileSize REG_DWORD You can change the size of the log file
by setting different values for
MaxFileSize. The default value is
65536 bytes (64 kilobytes).
Tracing consumes system resources, so you should use it only when necessary to h
elp identify network problems. After the trace is captured or the problem is ide
ntified, you should immediately disable tracing. Do not leave tracing enabled on
multiprocessor computers.
The tracing information can be complex and very detailed. Most of the time, this
information is useful only to Microsoft Product Support Services engineers or t
o network administrators who are highly experienced with the Windows 2000 based ro
uter.

Troubleshooting Communication Hardware

The first step in resolving a problem is to identify its source. After you ident
ify the source of a problem, the solution is usually self-evident. When problems
with remote access connections occur, the source may be the hardware on the use
r s computer or the hardware on the remote access server.
User s Communication Hardware
One of the first remote access components to check is the communication hardware
that the user is using to connect remotely. This hardware may be a modem, netwo
rk card, or some other device. Because most hardware has unique self-test proced
ures, refer to the hardware manufacturer s guidelines for information about how to
check hardware.
If the connection is by a modem, make sure that the modem is configured correctl
y in Windows 2000, and that the modem s self-test functions correctly.
To check the modem:
1.
In Control Panel, double-click Phone and Modem Options.
2.
On the Modems tab, click your modem, and then click Properties.
3.
Click the Diagnostics tab, and then click Query Modem.
If the modem is working correctly, a series of diagnostics responses should be r

eturned. If the modem is faulty, try reinstalling the modem, or consult the mode
m manufacturer for more information.
To get more information about what the modem is doing during a connection attemp
t, you can view the modem session log information to determine the source of the
error.
Remote Access Server Communication Hardware
Another possible source of problems with remote access connections is the commun
ication hardware of the remote access server itself. To determine whether the co
mmunication hardware is functioning, check the system event logs for error messa
ges, and use hardware testing methods provided by your hardware manufacturer.
If you suspect a problem with a modem, follow the same troubleshooting steps as
for the client computer. Another way of determining a problem with remote access
server modems is to call the modem with a normal telephone and hear whether the
modem picks up the line and attempts to connect. If the remote access server mo
dem does not try to connect, this is an indication that there is something wrong
with the remote access server s modem.
Caution The noise generated during a connection attempt may be very loud when em
itted from a normal telephone receiver. To avoid injury, hold the headset away f
rom your ear.
If the communication hardware is functioning correctly, the next step is to veri
fy that the communication lines are functioning.
Communication Line Failure
If the communication line is not working for some reason, or is not connected co
rrectly, remote access connection attempts will fail. This can be the result of
an incorrectly connected cable or disconnected telephone service.
In larger installations, it is common for many telephone lines to be used for re
mote access connections. Before connecting a telephone line to a modem, always c
heck to make sure that the line is working correctly by using a normal telephone
receiver.
Intermittent Connection Failure
Often, in large remote access installations, a single telephone number is used f
or dial-in and is then split into a number of separate telephone lines by a piec
e of hardware called a rotary splitter. Modems are then connected to each line.
In this situation, it is possible for one modem to be faulty or incorrectly conf
igured. This will give the end-user the appearance that the connection to the re
mote access server gives intermittent failures, because the connection attempt o
nly fails when the rotary tries to connect the user by using the line connected
to the faulty modem.
To identify the intermittent connection problem, use the system event logs; but
if the problem is in the remote access hardware itself, check which ports are be
ing used in Routing and Remote Access. The faulty modem port should appear as un
used even during busy times.
VPN Connection Failure
When troubleshooting a VPN connection, the communication line is replaced by the
Internet, which will result in different errors. If there is a problem connecti
ng to a VPN server, check that the Domain Name System (DNS) name of the server i
s correct, and check that DNS name resolution is functioning correctly. Also, if
you are connecting through a firewall, ensure that you have the correct ports o
pen at the firewall to allow the VPN connection through the firewall. Another re
ason for VPN connection failure can be the use of network address translation (N
AT). If you use NAT to protect internal IP addressing, you cannot use L2TP and I
PSec to connect to a remote VPN server. IPSec cannot pass through a NAT.
Troubleshooting Configuration Settings

After you determine that the source of the problem is not the hardware or commun
ication lines, check the configuration settings.
Network Configuration
Network configuration error occurs when the user successfully connects, and appe
ars to have a valid connection, but is still unable to access resources on the n
etwork. Network configuration error is usually due to a problem with the underly
ing network. It might occur if name resolution is not working correctly, or if s
ome other critical network function, such as routing, is not configured correctl
y.
When network configuration error occurs, confirm that you can access resources w
hen you are connected directly to the network, and check TCP/IP configuration pr
operties by using the ipconfig /all command on the client. Make sure that the DN
S and/or Windows Internet Name Service (WINS) server IP addresses are configured
and working. Also, attempt to diagnose the problem as if the user s computer were
connected directly to the local area network (LAN). Use the ping command on the
user s computer to determine where the network connectivity problem resides.
Remote Access Server Settings
The settings that you configure on your remote access server can prevent users w
ith incorrect settings from completing a connection. To determine whether a sett
ing on the remote access server is causing a connection to fail, the user must s
uccessfully connect to the server and then become disconnected due to one of the
configured settings.
To help determine which setting could be at fault, check the system event log on
the remote access server and on the computer on which the user dials in. In som
e cases it may be necessary to enable tracing on the remote access server to det
ermine the cause of the problem.
User Computer Settings
There are a number of settings that can be made to the computer and to the conne
ction properties that will cause a remote access connection to fail. For example
, if the computer on which the user dials in only uses the NWLink IPX/SPX/NetBIO
S Compatible Transport Protocol (NWLink) and the remote access server only uses
TCP/IP, the connection will not be successful.
In the event of a connection failure, if the remote access server and communicat
ion lines are tested and found to be working correctly, the cause of the failure
is probably in the user s computer settings. Examine the error messages that appe
ar; if they do not show the cause, check the system event log and the modem log,
if this is a modem connection.
A common problem with user computer settings occurs when a user has modified the
connection properties in such a way that it causes the connection attempt to fa
il. A quick way to determine whether this is the problem is to recreate the outbo
und connection by using the Make New Connection wizard. Either create a new conn
ection or instruct the user to create a new connection, and attempt to connect t
o the remote access server again. If this new connection succeeds, the configura
tion of the original connection was the problem.
Lab B: Troubleshooting Remote Access (Simulation)
Objectives
After completing this lab, you will be able to:
Read event logs to determine the cause of an error
Troubleshoot remote access problems

Prerequisites
Before working on this lab, you must have:
The ability to configure a remote access connection
An understanding of how VPN connections work

Lab Setup
This lab is a simulation. To complete this lab, you need the following:
A computer running Windows 2000, Windows NT 4.0, Microsoft Windows 98, or Micro
soft Windows 95
A minimum display resolution of 800 x 600 with 256 colors
To start the lab
1.
Insert the Student Materials compact disc into your CD-ROM drive.
2.
At the root of the compact disc, double-click Default.htm.
3.
On the Student Materials Web page, click Lab Simulations, and then click Trouble
shooting Remote Access.
4.
Read the introductory information, and then click the link to start the lab.

Estimated time to complete this lab: 15 minutes

Review
1.
You have been receiving many help-desk calls lately about users not being able t
o connect to your remote access servers because all available lines are busy. Yo
u monitor the incoming lines, and notice that many people connect and remain con
nected for many hours, even though they do not transmit or receive any data. How
can you reduce the time that users stay connected while idle?
2.
You want to allow different time use and Multilink settings for different groups
of users connecting to your remote access server. What steps do you need to per
form to achieve this?
3.

You want to control dial-up access to your remote access server completely throu
gh policies, but when you attempt to configure this by using Active Directory Us
ers and Computers, the option to Control access through remote access policy is
not available. Why?
4.
Users are
a message
in Active
hat could

attempting to connect to your remote access server, but are receiving

that they do not have dial-in permissions. You look up their accounts
Directory Users and Computers, and they do have dial-in permissions. W
be causing the problem?

5.
A user is calling the help desk to say that he cannot connect to the organizatio
n s remote access servers. You look up the event logs on the remote access server
for all remote access entries, but find no entries. What components of the remot
e access connection could be causing this error?