The third method for entering Netsh commands is to do so through a script or batch file. For example, through the Netsh interface, you can use the Exec Scriptfile command to execute a file that contains multiple Netsh commands. Alternatively, you can use the special f switch on the Netsh command line. (For information about this option, use the Netsh ? command.)
Another useful Netsh feature, the Dump command, lets you create a script file that represents a Routing and Remote Access server's existing configuration. You can run Netsh's Dump command at various levels in the Netsh shell, depending on the scope of the configuration data you want to dump. (For example, using Dump at Netsh's main prompt dumps the machine's entire network configuration, whereas using Dump at the ras prompt dumps only the RAS configuration information.) To dump RAS and routing-related configuration data into a file, you can use the following two command lines:
netsh ras dump > filename
netsh routing dump > filename
where filename is the name of the script file you want to create from the Dump command's output.
When you make changes to a Routing and Remote Access server either interactively or through batch or script files, you should always run the Dump command first to save the machine's existing configuration. That way, you can restore the configuration later if you encounter problems. Table 2, page 61, shows a list of all Netsh commands related to Routing and Remote Access.
Routing and Remote Access also contains logging (aka tracing) improvements. The service supports three levels of logging:
- Event logging—The system records events related to Routing and Remote Access in the system log.
- Local authentication and accounting logging—If you configure Windows as the Routing and Remote Access server's authentication or accounting provider, the system maintains a separate log file for recording events related to these services. These logs reside in the \%systemroot%\system32\logfiles folder (e.g., C:\winnt\system32\logfiles) in the Iaslog.log file. To configure log-file options, such as which events the system logs and whether the file uses IAS 1.0 or ODBC format, you use the Local File item's Properties dialog box, which is part of the Remote Access Logging option in the management console's left pane.
- RADIUS logging—If you configure Routing and Remote Access to use a RADIUS server (e.g., IAS) for authentication or accounting, Routing and Remote Access can request that the system log information about either feature to a remote RADIUS server.
In addition, you can now enable logging for nearly every component of Routing and Remote Access from within the GUI management console or from the command line.
The facilities for managing logging are far more intuitive than they are under NT 4.0. You can access logging options for individual Routing and Remote Access components within the Routing and Remote Access management console from each component's Properties dialog box. For example, to enable general Routing and Remote Access server event logging and PPP logging, right-click the Routing and Remote Access server name in the management console, choose Properties, and select the Event Logging tab, which Figure 6 shows. To configure logging from the command line, use the command
netsh ras set tracing component <enabled/disabled>
where component is the Routing and Remote Access component (e.g., PPP) for which you want to configure logging. To globally enable or disable logging for all Routing and Remote Access components, enter the command
netsh ras set tracing * <enabled/disabled>
Unlike other Routing and Remote Access events, which the system records in the system event log, these component-level logging entries reside in the server's \%windir%\tracing folder (e.g., C:\winnt\tracing). The system creates separate log files in this folder for each component for which you've enabled logging and names the log files after the component. For example, enabling PPP logging results in the creation of a ppp.log file.
Other New Features
Routing and Remote Access offers other features that you'll appreciate. One such improvement is the service's elimination of NT 4.0's 256-ports-per-server limitation. In Routing and Remote Access, each server can support a virtually unlimited number of ports. (Hardware limitations such as network bandwidth, memory, and CPU resources will be the primary constraints on this number.)
Routing and Remote Access also introduces several features that will help you reduce unwanted dial-up connections, such as dial-up Internet access by users and dial-on-demand LAN-to-LAN router links. First is the inclusion of a demand-dial filter feature, which lets you define filters that prevent demand-dial connections for certain traffic types. Second is the capability to define the hours during which users can make dial-out connections. Over time, both of these features will help you significantly reduce your organization's dial-up connection costs.
If you're using multilink RAS connections, you'll be interested in Routing and Remote Access's support for the Bandwidth Allocation Protocol (BAP) and the Bandwidth Allocation Control Protocol (BACP). These protocols, which are commonly used on hardware-based routers that employ multilink connections (e.g., ISDN lines, with their two 64KB "B" data channels), enable Win2K to automatically add or subtract lines from a multilink RAS connection based on the amount of consumed bandwidth or the time of the connection. You must enable bandwidth-allocation support on both the client and the server, and you configure the rules through the Routing and Remote Access management console's remote access policies. You configure BAP and BACP support for a Routing and Remote Access server in the server's Properties dialog box. Right-click the server name in the Routing and Remote Access management console's left pane, go to the PPP tab, and select the Dynamic bandwidth control using BAP or BACP check box.
Another improvement in Routing and Remote Access is the capability to define multiple IP address allocation ranges or pools from which Routing and Remote Access servers can assign IP addresses to dial-up clients. (NT 4.0 limits address allocation to one contiguous IP address range.) Routing and Remote Access also supports Extensible Authentication Protocol (EAP) and Microsoft Challenge Handshake Authentication Protocol (MSCHAP 2.0). EAP lets Routing and Remote Access support plug-in authentication modules for devices such as smart cards and lets RAS extend its authentication support to existing and forthcoming devices and technologies. MSCHAP 2.0 provides better security for authentication with Windows dial-up clients that support it (including Win2K, Windows Me, Win98, and Win95 with DUN update 1.3). The protocol also supports stronger encryption of passwords and password changes, and mutual authentication between the RAS client and server—rather than the one-way authentication that MSCHAP 1.0 supports.
Prev. page
1
2
3
4
[5]
6
next page 
