• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Configuring a Remote Access Server

    With the preliminaries and theory out of the way, it's time to prepare a server for dial-in access. The Routing and Remote Access Services (RRAS) service is installed by default but it is kept in a disabled state until needed.

    The RRAS service is managed via the Routing and Remote Access Services console, Rrasmgmt.msc. You can manage all servers running RRAS from a single console as long as you have administrator rights on the servers themselves. You cannot manage desktop connections from the RRAS console. You can also manage NT4 RRAS servers but several of the router options are not available. Your best option is to copy the classic NT4 RAS management utility, Rasadmin.exe, to your desktop. When you add the legacy server to the RRAS console and click the icon, the console automatically launches Rasadmin.

    Initial RRAS Service Setup

    Figure 20.28 shows a relatively simple remote access configuration. The remote access server has been placed outside the firewall in a De-Militarized Zone (DMZ) to improve security. The server routes dial-in client traffic onto the main network through the DMZ interface, which is trusted but provides a higher level of control than simply dialing into the server behind the firewall. Because a standalone RRAS server can only authenticate users in its local SAM, it has been configured to use RADIUS and paired with an IAS server inside the firewall.

    Figure 20.28. Simple dial-up configuration that permits domain users to connect directly to an RRAS server then be routed onto the main network after being authenticated via RADIUS.

    graphics/20fig28.gif

    Here are the general steps involved in building this configuration:

    • Install a modem or modem bank or T-1 card or ISDN BRI or PRI adapter in the remote access server. You'll need drivers designed either for Windows Server 2003/XP or Windows 2000.

    • Configure the RRAS service for remote access.

    • Configure remote access to accept dial-in connections and to use RADIUS for authentication.

    • Configure the IAS server to accept authentication requests from the remote access server.

    • If the domain is in Mixed, configure the individual user accounts in Active Directory to permit dial-in access. If the domain is in Native, use the remote access policies in RRAS to control dial-in permissions.

    • Add the remote access server to the RAS and IAS Servers group in other domains in the forest, if there are any.

    There is no need for special configuration at the dial-in clients. The clients use their default authentication method, which is MS-CHAPv2 for Windows clients.

    Like most setup operations in Windows Server 2003, the RRAS setup uses a wizard. The configuration options you select in the wizard are not quite as simple as they appear. Let's use the wizard to initialize the service then walk through some details on the settings. Follow Procedure 20.9.

    Procedure 20.9 Initializing the RRAS Service to Support Remote Access

    1. Open the Routing and Remote Access console using START | PROGRAMS | ADMINISTRATIVE TOOLS | ROUTING AND REMOTE ACCESS. The icon representing the local server has a red down-arrow, indicating that the service has not yet been started.

    2. Right-click the local server icon and select CONFIGURE AND ENABLE ROUTING AND REMOTE ACCESS from the flyout menu. This launches the Routing and Remote Access Server Setup Wizard. The Configurations window opens first (see Figure 20.29).

      Figure 20.29. RRAS Setup WizardConfigurations window showing options for wizard-based configuration.

      graphics/20fig29.jpg

    3. Select Remote Access and click Next. The Remote Access window opens.

    4. You can select either Dial-up or VPN or both. For now, select Dial-up.

    5. Click Next. The Network Selection window opens (see Figure 20.30). This is where you select the interface that the server will use for assigning IP configuration settings. On a multihomed server, be sure to select the interface connected to the main network.

      Figure 20.30. RRAS Setup WizardNetwork Selection window showing list of available interfaces.

      graphics/20fig30.jpg

    6. Click Next. The IP Address Assignment window opens. You can elect to use DHCP or a static address range. See the section, "Configuring Dial-In IP Settings," for details about what to select here based on your IP infrastructure.

    7. Click Next. The Managing Multiple Remote Access Servers window opens. This window gives you the option of using RADIUS for authentication. When you select this option, the wizard steps you through selecting a RADIUS server and a shared secret. See the "Configuring Internet Authentication Services (IAS)" section for details.

    8. Click Next. A summary window opens. Click Finish to start the service.

    9. If the domain is in Mixed, make sure the user accounts have dial-in permission in Active Directory. If the domain is in Native, use the RRAS console to change the setting of the Allow Access If Dial-in Permission Is Enabled policy under Remote Access Policies to Grant Access. This gives access to authorized users.

    Checking Dial-In Connections Using Remote Access Logging

    The server is now ready to accept dial-in users. Test by making a connection from a client desktop using credentials from an Active Directory account. If you encounter problems that are related to remote access, not the modem connection, you may want to enable one of the Logging options in RRAS.

    The first logging option is enabled for the server itself via the RRAS server Properties window (see Figure 20.31).

    Figure 20.31. RRAS server Properties window showing Logging tab.

    graphics/20fig31.gif

    This option places information about the server operation in the Event log. The second logging option is available in the Remote Access Logging icon in the RRAS management console. This option tracks activity at each dial-in interface. It is a valuable analytical tool, but it takes a little patience to interpret.

    The log is a comma-delimited file with each line representing one record. The first line is a header that contains information about the dial-in user who accessed the server:

    10.4.1.1  IP address
    testuser  logon name
    02/15/2002  access date
    22:24:5  access time
    RAS  access method
    DC-01  target domain controller
    

    The next fields are number pairs. The first number is the attribute designator and the second number is the value for the attribute. Here is a brief example for a user who was denied access:

    4121,0x00453D36343920523D3020563D33  CHAP error
    4127,4  authentication type
    4130,SUBSIDIARY\testuser  Fully qualified user name
    4136,3  packet type (accept-reject)
    4142,48  rejection reason (incomplete accounting-request packet received.)
    

    If you want more information about the attributes and constraints that are listed in the log entries, search the online help for "Interpreting IAS-Formatted Log Files." This contains an exhaustive list of the attribute types and meanings. Also check out RFC 2138, "Remote Authentication Dial In User Service (RADIUS)" with Microsoft extensions documented in RFC 2548, "Microsoft Vendor-Specific RADIUS Attributes."

    The vendor attributes associated with each interface are stored in Active Directory in an object called Identity-Dictionary. This object is located in cn=RRAS, cn=Services,cn=Configuration,dc=<domain>,dc=<root>. You can view the contents of this attribute using with the ADSI Editor from the Support Tools.

    Configuring Dial-In IP Settings

    From the perspective of NDIS, the network interface represented by a modem or ISDN terminal adapter is no different than that of an Ethernet adapter. You'll see terms in the interface such as PPP adapter and virtual WAN interface assigned to these connections. In actuality, NDIS sees all network interfaces as virtual adapters, not just remote access connections. One of the functions of the NDIS wrapper is to hide underlying physical hardware behind a virtual shroud of access logic.

    If you were to run ipconfig /all on any of the machines shown in the figure, you'd see a PPP adapter listed along with the network adapter. Here's an example listing:

    Windows IP Configuration
            Host Name . . . . . . . . . . . . : pro1
            Primary Dns Suffix  . . . . . . . :
            Node Type . . . . . . . . . . . . : Mixed
            IP Routing Enabled. . . . . . . . : No
            WINS Proxy Enabled. . . . . . . . . : No
    
    Ethernet adapter Local Area Connection:
            Connection-specific DNS Suffix  . :
            Description . . . . . . . . . . . : 3Com XL 10/100 PCI NIC (3C905C-TX)
            Physical Address. . . . . . . . . : 00-14-39-3C-6B-2D
            Dhcp Enabled. . . . . . . . . . . : No
            IP Address. . . . . . . . . . . . : 192.168.0.3
            Subnet Mask . . . . . . . . . . . : 255.255.255.0
            Default Gateway . . . . . . . . . : 192.168.0.254
             DNS Servers . . . . . . . . . . .  : 192.168.0.15
    
    PPP adapter Company VPN:
            Connection-specific DNS Suffix  . :
            Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
            Physical Address. . . . . . . . . : 00-13-25-00-00-00
            Dhcp Enabled. . . . . . . . . . . : No
            IP Address. . . . . . . . . . . . : 192.168.10.23
            Subnet Mask . . . . . . . . . . . : 255.255.255.255
            Default Gateway . . . . . . . . . : 192.168.10.23
             DNS Servers . . . . . . . . . . . : 192.168.10.100
    

    The default gateway for the PPP adapter is the same as the IP address assigned to the interface by the RRAS server. This is an old routing trick that says, in essence, "If you want an exit path off this machine, I'm your guy." You can confirm this by running route print. Here's an example with the dial-in connection shown in bold:

    ===========================================================================
    Interface List
    0x1 ............................... MS TCP Loopback interface
    0x2 ... 00 14 39 3C 6B 2D ......... 3Com 10/100 PCI NIC (3C905C-TX)
    0x20006 ...00 13 25 00 00 00 ...... WAN (PPP/SLIP) Interface
    
    ===========================================================================
    Active Routes:
    Network Destination        Netmask          Gateway       Interface  Metric
              0.0.0.0          0.0.0.0      192.168.0.1   192.168.0.253       21
              0.0.0.0          0.0.0.0    192.168.10.23   192.168.10.23       1
            127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
          192.168.0.0    255.255.255.0    192.168.0.253   192.168.0.253       20
          192.168.0.2  255.255.255.255        127.0.0.1       127.0.0.1       20
        192.168.0.255  255.255.255.255    192.168.0.253   192.168.0.253       20
         192.168.10.3  255.255.255.255        127.0.0.1       127.0.0.1       50
       192.168.10.255  255.255.255.255    192.168.10.23   192.168.10.23       50
            224.0.0.0        240.0.0.0    192.168.0.253   192.168.0.253       20
            224.0.0.0        240.0.0.0    192.168.10.23   192.168.10.23       1
      255.255.255.255  255.255.255.255    192.168.0.253     192.168.0.2       1
    Default Gateway:      192.168.10.23
    ===========================================================================
    Persistent Routes:
      None
    

    The end result of this maneuvering is to route non-local IP traffic from the client to the RRAS server and from there onto the network. A single virtual WAN adapter at the RRAS server handles all incoming traffic. The interface appears in the Network Connections as an Incoming Connections icon.

    The IP settings assigned to the PPP adapters come from the RRAS server unless the system has been configured to permit dial-in clients to use static addresses assigned at the client. The IP options for RRAS are located on the IP tab of the Properties window for the server in the RRAS console. Figure 20.32 shows an example.

    Figure 20.32. Properties window for an RRAS server showing the IP tab for configuring routing, address assignments, and name resolution settings.

    graphics/20fig32.gif

    Assigning Client IP Addresses

    The IP Address Assignment window has two options for assigning addresses to dial-in clients and to the PPP interface on the RRAS server.

    One option specifies a static range of IP addresses. This option is for use if you do not have a DHCP server or you do not want to obtain dial-in addresses from DHCP. When you specify the address range, select a range in a different subnet than the main interface on the RRAS server. The server will route traffic between the two subnets. See the sidebar, "Routing Protocols."

    The other option is to use DHCP. When you make this selection, the RRAS server locates the DHCP server for its subnet and leases IP addresses for its dial-up interfaces from that DHCP server. The key word here is interfaces, not clients. The RRAS server does not wait for the client to connect to lease the address. It grabs the addresses immediately.

    In NT4, this could cause problems if you had a rack with 20 or 30 modems or you configured a few dozen Point-to-Point Tunneling Protocol (PPTP) interfaces. The RRAS server would reach out and nab addresses for all the interfaces plus one for itself. This could exhaust the supply of addresses in the DHCP address pool.

    Starting with Windows 2000, RRAS was modified to lease only 10 addresses at a time. If you have 10 modems and 30 VPN interfaces but normally only have 18 concurrent logons, you would lose only 20 addresses from the DHCP address pool.

    Configuring Name Resolution

    A dial-in client needs to resolve names to IP addresses just like every other PC on the network. Getting the DNS and WINS settings to the client, though, is not as straightforward as you might think.

    PPP clients obtain their configuration settings during the IPCP phase of the connection transaction. The remote access server determines where to obtain the values for these settings based on the IP addressing options discussed in the previous section.

    Static IP Addressing

    If the remote access server is configured to use a static range of addresses, the DNS and WINS settings are obtained from the LAN adapter settings.

    If the LAN adapter is configured to use DHCP, the settings given to the dial-in clients are taken from the dynamic settings on the LAN adapter.

    If the LAN adapter uses DHCP but also has static configurations for DNS and WINS, the static configurations take precedence and are the only settings delivered to the dial-in clients.

    Routing Protocols

    If you have a remote access server that uses a separate IP subnet for the dial-in clients along with various LAN segments connected to different servers, it can be a hassle keeping the routing tables up to date. Also, you might have standard routers that also need to know about the subnets.

    In these situations, you can enable Routing Information Protocol (RIP) in the RRAS console. RIP uses broadcasts to keep its fellow routers updated with new routes. If your existing routers use OSPF (Open Shortest Path First), you can enable OSPF at the RRAS server. Work carefully with the network engineers to ensure you do not create a routing circularity or propagate inappropriate OSPF information. The last thing you want is to have 5000 network clients routed through your RRAS server just because it advertised its routing metrics incorrectly.

    If the remote access server has more than one LAN adapter, you can select which one will be used to obtain IP configuration settings. The option is located in the IP tab of the RRAS server Properties window.

    If you leave the selection in the default setting of Allow RAS to Select Adapter, the server will select the first adapter listed under the Routing Interfaces icon of the main RRAS console. This is typically the first interface installed on the server. If this adapter is not available, the second one on the list is used.

    DHCP-Based IP Addressing

    If the remote access server is configured to use DHCP to lease addresses for the dial-in client, the situation gets a little more complex.

    As discussed in the last section, the IP addresses assigned to the dial-in clients come from a set of addresses leased from DHCP and cached locally by the remote access server. However, the IP configuration settings delivered to the dial-in clients during IPCP come from the LAN interface, not from DHCP. There is not enough time during IPCP to stop and get current configurations from DHCP.

    You can effectively deliver current DHCP configuration settings, though, by enabling DHCP on the LAN interface of the remote access server. The DNS and WINS settings obtained from DHCP become the settings that will be delivered to the dial-in clients. If you statically assign different DNS or WINS settings to the LAN adapter, those take precedence.

    DHCPINFORM

    Many IT shops prefer to statically assign IP settings to servers. If the statically assigned DNS and WINS settings on the LAN adapter are suitable for the dial-in clients, this is not a problem. In cases where those settings are not appropriate, a modern Windows client can take over and obtain different settings from DHCP.

    This trick depends on a relatively new DHCP feature called DHCPINFORM. One of the functions of DHCPINFORM is to permit a non-DHCP client to obtain configuration settings from a DHCP server.

    Windows Server 2003, XP, and Windows 2000 clients take advantage of this feature by broadcasting a DHCPINFORM packet after the PPP transaction has been completed. The DHCP Relay Agent service on the remote access server passes the DHCPINFORM packet to a DHCP server, which responds with a configuration packet. The client assigns the settings in the configuration packet to its dial-up interface in addition to those it obtained during IPCP.

    You do not need a packet sniffer to follow this transaction. At a dial-in client, disable the Ethernet interface then run ipconfig /all at a command prompt. You will get no listings. Now, initiate a dial-in connection to the remote access server. As soon as the modem finishes squealing, start repeating the ipconfig /all entry. You'll first see a single set of configuration settings that match the LAN interface at the remote access server. Then, in a few seconds, the listing changes to include the configuration settings from the DHCP server.

    You'll end up with at least two entries for DNS and WINS. This is your indication that the DHCPINFORM process completed successfully. Here's a sample listing. The bold entries were obtained via DHCPINFORM. The secondary entries came from the LAN interface:

    C:\>ipconfig/all
    Windows IP Configuration
            Host Name . . . . . . . . . . . . : xp-pro1
            Primary Dns Suffix  . . . . . . . : subsidiary.com
            Node Type . . . . . . . . . . . . : Unknown
            IP Routing Enabled. . . . . . . . : No
            WINS Proxy Enabled. . . . . . . . : Yes
            DNS Suffix Search List. . . . . . :   subsidiary.com
    
    PPP adapter server3:
            Connection-specific DNS Suffix  . :
            Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
            Physical Address. . . . . . . . . : 00-53-45-00-00-00
            Dhcp Enabled. . . . . . . . . . . : No
            IP Address. . . . . . . . . . . . : 192.168.10.19
            Subnet Mask . . . . . . . . . . . : 255.255.255.255
            Default Gateway . . . . . . . . . : 192.168.10.19
            DNS Servers . . . . . . . . . . . : 192.168.10.200
                                                192.168.0.100
            Primary WINS Server . . . . . . . : 192.168.10.200
            Secondary WINS Server . . . . . . :   192.168.0.100
    

    As you can see from the listing, the DHCPINFORM settings become the primary settings for the client. This permits the client to use DNS and WINS servers that are appropriate for its IP subnet.

    Remember to enable the DHCP Relay Agent service in the RRAS console. You'll need to specify an interface on which to listen for DHCPINFORM broadcasts and you'll need to enter the IP address of at least one DHCP server.

    If you have NT4 and Windows 9x clients, you will need to configure a different workaround because those clients do not use DHCPINFORM. The most straightforward method is to statically configure DNS and WINS settings in the dial-up connection. These settings will take effect even though the client obtains an address from the remote access server.

    Flat Name Resolution

    The Enable Broadcast Name Resolution option in the IP tab of the remote access Property window is a new feature in Windows Server 2003 and one that is not enabled by default. Its purpose is to simplify name resolution on small networks where DNS and WINS services are not installed.

    An example would be a small manufacturing firm where the computer names were assigned by the owner's teenage children when they installed the network. When a dial-up user at a laptop named Blink_182 attempts to connect to a server named DMX over a mapped drive, the laptop needs a way to resolve the name into an IP address. On the local network, this would be done with broadcasts. By enabling broadcasts through the dial-up connection, the name can still be resolved.

    Broadcast name resolution is not a welcome feature in large networks, but for a few dozen nodes in a single subnet, it works well and should not be avoided simply because of the traffic. If you are going to install Windows Server 2003 in this office, though, you might as well install DNS and WINS and avoid the broadcasts.

    Configuring Miscellaneous IP Options

    The Enable IP Routing option in the IP tab of the remote access server Properties window is set by default. This option controls access to the main network. This is a handy way to block network access when you want to change settings but you do not want to bring down the server. You do not need to stop and restart the service if you change this option. It takes effect immediately.

    The Allow IP-Based Remote Access and Demand-Dial Connections option acts as an on-off toggle for remote access. This is a useful option when you are troubleshooting a problem and you want to leave the RRAS service up but you want to block access. Unfortunately, the users get a Cannot connect to remote network error rather than an error such as Remote network temporarily unavailable.

    RRAS Command-Line Management

    Windows Server 2003 includes a general-purpose, text-based tool for managing network settings, including the settings in RRAS. The tool is called the Network Shell, or Netsh.

    The Netsh utility provides a text-based interface with a variety of options. If you run the utility on one of your servers, you may not see some of these options listed. They are only displayed if the associated service is enabled.

    To go to a particular context in the namespace, enter the name of the context at the prompt. For example, enter ras to go to the netsh ras> context.

    You can move from one context to another without navigating up and down the namespace. For example, from the netsh ras> context, you can enter interface to go directly to the netsh interface> context. You can navigate up to a parent context using a double dot (..), just like navigating in a directory tree. Type bye, exit, or quit to exit the shell.

    To see the available commands at each level of the namespace, type ? at the netsh> prompt. Some commands have additional parameters. Enter the command followed by a question mark to see them. For example, the show ? command lists the parameters of the current context:

    
    netsh ras>show ?
    show tracing            - Shows whether extended tracing is enabled for components.
    show user               - Displays RAS properties for a user(s).
    show authmode           - Shows the authentication mode.
    show authtype           - Displays the authentication types currently enabled.
    show link               - Shows the link properties PPP will negotiate
    show multilink          - Shows the multilink types PPP will negotiate
    show registeredserver   - Displays whether a computer is registered as a RAS server in 
    graphics/ccc.gifthe Active Directory of the given domain.
    show domainaccess       - Displays whether NT4 RAS servers or Windows Server 2003 RAS 
    graphics/ccc.gifservers in trusted NT4 domains have been enabled in the Active Directory of the given 
    graphics/ccc.gifdomain.
    show activeservers      - Listens for RAS server advertisements.
    show client             - Shows RAS clients connected to this machine.
    show alias              - Lists all defined aliases.
    show mode               - Shows the current mode.
    

    Enter the command with the correct syntax and the results are listed in the console:

    ras>show registeredserver domain=company.com
    The following RAS server is registered:
         RAS Server:     DC-01
         Domain:          company.com
    

    To change a parameter, substitute the word set for show. The Network Shell has two modes: online and offline. You can shift back and forth between them by entering online or offline at the netsh> prompt. In the online mode, any changes you make are implemented immediately. In the offline mode, changes are saved but not implemented. Implement them using the commit command or discard them using the abort command.

    One of the most useful Network Shell features is its capability to dump the current configuration to a script so you can replay the script and get back your original configuration. The command to show the running configuration is dump. You can type dump at the shell prompt to see the results on the screen, but to save the output to file, you must run it from a command prompt and redirect the output to a file. For example, enter c:\>netsh dump > netsh.scr.

    If you want to limit the dump to a particular context, put the context on the command line. Here is an example:

    c:\>netsh ras ip dump > netshrasip.scr
    
    # -----------------------------------------
    # RAS IP Configuration
    # -----------------------------------------
    
    pushd ras ip
    
    set negotiation mode = allow
    set access mode = all
    set addrreq mode = deny
    set pool addr = 10.1.2.0  mask = 255.255.255.240
    set addrassign method = auto
    
    popd
    
    # End of RAS IP configuration.
    

    To apply the settings you saved in the script, enter netsh f <filename>. For example:

    c:\>netsh f netshrasip.scr.
    

    You can use Netsh to control other servers either by executing the script remotely using a remote shell or by putting the script in the Windows Scheduler at the remote server for execution at a later time.

    Managing Client Remote Access Connections with Group Policies

    There are a variety of group policies available for managing remote access connections at the client desktops. These policies are available in the Group Policy Editor under Administrative Templates | Network | Network Connections. There is a short set of policies for Computers and a longer set for Users.

    The Computer-side policies permit you to disable the following services at the desktops:

    • Internet Connection Sharing (ICS)

    • Internet Connection Firewall (ICF)

    • Network Bridge

    • Certificate-based authentication of wireless connections

    Of these, you may want to consider disabling ICS very soon after you begin deploying Windows 2000 and XP desktops. This prevents users with local admin rights from creating back doors out of your network.

    The User-side policies restrict users from changing or even viewing the contents of their remote access connections. This is a handy set of policies to implement if you want to avoid constant calls to the Help Desk from users who think they know enough to change the connection settings. Because group policies remain in effect even when a machine is off the network, you may want to ease up on the restrictions for users who might need to change phone numbers for connecting to their ISPs as they travel.

    Making Dial-In Connections from the Command Line

    You do not need to use the graphical user interface to initiate a dial-up session. An executable to handle the connection, Rasdial.exe, can be called from the command line or a batch file.

    Using Rasdial, you can configure an unattended workstation to use the Task Scheduler to make dial-up connections, transfer files, pick up email, or do other periodic chores. Do this by configuring the batch file to give Rasdial the name of a phonebook entry. The name of the entry is the same as the name assigned to the Connection icon in the Networking and Dial-up Connections window. For example, if you have a connection named Home Office, the syntax would be as follows:

    rasdial "home office"
    

    During the time that the system is making the connection, the console displays the same status information that you would see from the graphical interface. When you are ready to hang up, enter the following:

    rasdial /disconnect
    

    Unfortunately, you cannot use Rasdial in conjunction with a smart card. You must use passwords. If you do not cache your passwords when you use dial-up connections, or you want to provide a different set of credentials than those stored in the phonebook, you can provide this information on the command line. Here's the syntax: (The parameters are not case sensitive.)

    rasdial "home office" username * /DOMAIN:domain /PHONE:phonenumber
    /CALLBACK:callbacknumber /PREFIXSUFFIX
    

    The * causes Rasdial to prompt for a password. You can enter the password on the command line, if you prefer. The /prefixsuffix switch tells Rasdial to use the TAPI settings for the modem interface.

    You can also modify the phonebook from the command line by entering rasphone on the command line. This opens the standard graphical interface, but at least it's faster than going through all the mouse-clicks to get to the Connection icons. If you enter rasphone a, you are taken directly to the Network Connection Wizard.

      Previous Section Next Section