Windows Tutorials

How to configure IIS Web site authentication in Windows Server 2003

2010-03-16T00:36:00.000-07:00

This article describes how to configure Microsoft Internet Information Services (IIS) Web site authentication in Windows Server 2003. You can configure IIS to authenticate users before they are permitted access to a Web site, a folder in the site, or even a particular document contained in a folder in the site. Authentication in IIS can be used to strengthen the level of security on sites, folders, and documents that are not to be viewed by the general public.

Authentication in IIS is critical when resources are not meant for anonymous or public access, but when the Web server must be accessible to approved users over the Internet. Examples of Web site applications that require authentication access control include Microsoft Outlook Web Access (OWA) and the Microsoft Terminal Services Advanced Client.

How to configure Authentication in IIS

Start IIS Manager or open the IIS snap-in.
Expand Server_name, where Server_name is the name of the server, and then expand Web Sites.
In the console tree, right-click the Web site, virtual directory, or file for which you want to configure authentication, and then click Properties.
Click the Directory Security or File Security tab (as appropriate), and then under Anonymous and access control, click Edit.
Click to select the check box next to the authentication method or methods that you want to use, and then click OK.

The authentication methods that are set by default are Anonymous access and Integrated Windows authentication:
- Anonymous access: When anonymous access is turned on, no authenticated user credentials are required to access the site. This option is best used when you want to grant public access to information that requires no security. When a user tries to connect to your Web site, IIS assigns the connection to the IUSER_ComputerName account, where ComputerName is the name of the server on which IIS is running. By default, the IUSER_ComputerName account is a member of the Guests group. This group has security restrictions, imposed by NTFS file system permissions, that designate the level of access and the type of content that is available to public users. To edit the Windows account used for anonymous access, click Browse in the Anonymous access box.
  
  Important If you turn on anonymous access, IIS always tries to authenticate users by using anonymous authentication first, even if you turn on additional authentication methods.
- Integrated Windows authentication: Formerly named NTLM or Windows NT Challenge/Response authentication, this method sends user authentication information over the network as a Kerberos ticket, and provides a high level of security. Windows Integrated authentication uses Kerberos version 5 and NTLM authentication. To use this method, clients must use Microsoft Internet Explorer 2.0 or later. Additionally, Windows Integrated authentication is not supported over HTTP proxy connections. This option is best used for an intranet, where both the user and Web server computers are in the same domain, and administrators can make sure that every user is using Internet Explorer 2.0 or later.
  
  Note If multiple authentication options are selected, IIS tries to negotiate the most secure method first, and then it works down the list of available authentication protocols until a mutual authentication protocol is supported by both client and server.
- Digest authentication for Windows domain servers: Digest authentication requires a user ID and password, provides a medium level of security, and may be used when you want to grant access to secure information from public networks. This method offers the same functionality as basic authentication. However, this method transmits user credentials across the network as an MD5 hash, or message digest, in which the original user name and password cannot be deciphered from the hash. To use this method, clients must use Microsoft Internet Explorer 5.0 or later.
  
  If you turn on digest authentication, type the realm name in the Realm box.
- Basic authentication (password is sent in clear text): Basic authentication requires a user ID and password, and provides a low level of security. User credentials are sent in clear text across the network. This format provides a low level of security because the password can be read by almost all protocol analyzers. However, it is compatible with the widest number of Web clients. This option is best used when you want to grant access to information with little or no need for privacy.
  
  If you turn on basic authentication, type the domain name that you want to use in the Default domain box. You can also optionally enter a value in the Realm box.
- Microsoft .NET Passport authentication: .NET Passport authentication provides single sign-in security, which provides users with access to diverse services on the Internet. When you select this option, requests to IIS must contain valid .NET Passport credentials on either the query string or in the cookie. If IIS does not detect .NET Passport credentials, requests are redirected to the .NET Passport logon page.
  
  Note When you select this option, all other authentication methods are unavailable (appear dimmed).
Another type of authentication is based on the requesting host instead of on user credentials. You can limit access based on source IP address, source network ID, or source domain name. To configure this type of authentication, follow these steps:
1. Under IP Address and Domain Name Restrictions, click Edit.
2. Do one of the following:
  - To deny access, click Granted Access, and then click Add. In the Deny Access On dialog box that appears, specify the option that you want, and then click OK.
    
    The computer, group of computers, or domain that you specified is added to the list.
  - To grant access, click Denied Access, and then click Add. In the Grant Access On dialog box that appears, select the option that you want, and then click OK.
    
    The computer, group of computers, or domain that you selected is added to the list.
3. Click OK.
Click OK, and then quit IIS Manager or close the IIS snap-in.

Troubleshooting

You may be prompted to apply any changes that you have made to existing sites. If you want the authentication changes applied to other content, click the content from the list of child nodes, and then click OK. If you do not want the changes applied to any of the child nodes, do not select any items on the list, and then click OK.
In IIS, you can set authentication options at the Web site, directory, or file level. The same principles that are discussed in this article apply to each.

How To Configure IPSec Tunneling in Windows Server 2003

2010-03-15T21:32:00.000-07:00

You can use IP Security (IPSec) in tunnel mode to encapsulate Internet Protocol (IP) packets and optionally encrypt them. The primary reason for using IPSec tunnel mode (sometimes referred to as "pure IPSec tunnel") in Windows Server 2003 is for interoperability with non-Microsoft routers or gateways that do not support Layer 2 Tunneling Protocol (L2TP)/IPSec or PPTP virtual private network (VPN) tunneling technology.

Windows Server 2003 supports IPSec tunneling for situations where both tunnel endpoints have static IP addresses. This is primarily useful in gateway-to-gateway implementations. However, it may also work for specialized network security scenarios between a gateway or router and a server. (For example, a Windows Server 2003 router that routes traffic from its external interface to an internal Windows Server 2003-based computer that secures the internal path by establishing an IPSec tunnel to the internal server that provides services to the external clients).

Windows Server 2003 IPSec tunneling is not supported for client remote access VPN use because the Internet Engineering Task Force (IETF) IPSec Requests for Comments (RFCs) do not currently provide a remote access solution in the Internet Key Exchange (IKE) protocol for client-to-gateway connections. IETF RFC 2661, Layer Two Tunneling Protocol "L2TP," was specifically developed by Cisco, Microsoft, and others to provide client remote access VPN connections. In Windows Server 2003, client remote access VPN connections are protected using an automatically generated IPSec policy that uses IPSec transport mode (not tunnel mode) when the L2TP tunnel type is selected.

Windows Server 2003 IPSec tunneling also does not support protocol-specific and port-specific tunnels. While the Microsoft Management Console (MMC) IPSec Policy snap-in is very general and allows you to associate any type of filter with a tunnel, make sure that you use only address information in the specification of a filter for a tunnel rule.

For more information about how the IPSec and IKE protocols work, see the Microsoft Windows Server 2003 Resource Kit.

This article describes how to configure an IPSec tunnel on a Windows Server 2003 gateway. Because the IPSec tunnel secures only traffic that is specified in the IPSec filters that you configure, this article also describes how to configure filters in the Routing and Remote Access service to prevent traffic outside the tunnel from being received or forwarded. This article uses the following scenario to make it easy to follow the configuration steps:

Collapse this tableExpand this table

NetA-
WIN2003intIP-

-Windows Server 2003 gateway-
-WIN2003extIP-

-Internet-

-non-Microsoft gateway-
-3rdExtIP-

-NetB
-3rdIntIP

NetA is the network ID of the Windows Server 2003 gateway internal network.

WIN2003intIP is the IP address that is assigned to the Windows Server 2003 gateway internal network adapter.

WIN2003extIP is the IP address that is assigned to the Windows Server 2003 gateway external network adapter.

3rdExtIP is the IP address that is assigned to the non-Microsoft gateway external network adapter.

3rdIntIP is the IP address that is assigned to the non-Microsoft gateway internal network adapter.

NetB is the network ID of the non-Microsoft gateway internal network.

The goal is for the Windows Server 2003 gateway and the non-Microsoft gateway to establish an IPSec tunnel when traffic from NetA must be routed to NetB or when traffic from NetB must be routed to NetA so traffic is routed over a secure session.

If you want to configure an IPSec policy, you must build two filters: one filter to match packets going from NetA to NetB (tunnel 1), and one filter to match packets going from NetB to NetA (tunnel 2). You must configure a filter action to specify how the tunnel is secured (a tunnel is represented by a rule, so two rules are created).

Create IPSec Policy

Typically, a Windows Server 2003 gateway is not a member of a domain, so a local IPSec policy is created. If the Windows Server 2003 gateway is a member of a domain that has IPSec policy applied to all members of the domain by default, this prevents the Windows Server 2003 gateway from having a local IPSec policy. In this case, you can create an organizational unit in Active Directory, make the Windows Server 2003 gateway a member of this organizational unit, and assign the IPSec policy to the Group Policy object (GPO) of the organizational unit. For more information, see the "Creating, modifying, and assigning IPSec policies" section of Windows Server 2003 online Help.

Click Start, click Run, and then type secpol.msc to start the IP Security Policy Management snap-in.
Right-click IP Security Policies on Local Computer, and then click Create IP Security Policy.
Click Next, and then type a name for your policy (for example, IPSec Tunnel with non-Microsoft Gateway). Click Next.

Note You can also type information in the Description box.
Click to clear the Activate the default response rule check box, and then click Next.
Click Finish (leave the Edit check box selected).

Note The IPSec policy is created with default settings for the IKE main mode. The IPSec tunnel is made up of two rules. Each rule specifies a tunnel endpoint. Because there are two tunnel endpoints, there are two rules. The filters in each rule must represent the source and destination IP addresses in IP packets that are sent to that rule's tunnel endpoint.

Build a Filter List from NetA to NetB

In the new policy properties, click to clear the Use Add Wizard check box, and then click Add to create a new rule.
Click the IP Filter List tab, and then click Add.
Type an appropriate name for the filter list, click to clear the Use Add Wizard check box, and then click Add.
In the Source address box, click A specific IP Subnet, and then type the IP Address and Subnet maskto for NetA.
In the Destination address box, click A specific IP Subnet, and then type the IP Address and Subnet mask for NetB.
Click to clear the Mirrored check box.
Click the Protocol tab. Make sure that the protocol type is set to Any, because IPSec tunnels do not support protocol-specific or port-specific filters.
If you want to type a description for your filter, click the Description tab. It is generally a good idea to give the filter the same name that you used for the filter list. The filter name appears in the IPSec monitor when the tunnel is active.
Click OK.

Build a Filter List from NetB to NetA

Click the IP Filter List tab, and then click Add.
Type an appropriate name for the filter list, click to clear the Use Add Wizard check box, and then click Add.
In the Source address box, click A specific IP Subnet, and then type the IP Address and Subnet mask for NetB.
In the Destination address box, click A specific IP Subnet, and then type the IP Address and Subnet mask for NetA.
Click to clear the Mirrored check box.
If you want to type a description for your filter, click the Description tab.
Click OK.

Configure a Rule for a NetA-to-NetB Tunnel

Click the IP Filter List tab, and then click to select the filter list that you created.
Click the Tunnel Setting tab, click The tunnel endpoint is specified by this IP Address box, and then type 3rdextip (where 3rdextip is the IP address that is assigned to the non-Microsoft gateway external network adapter).
Click the Connection Type tab, click All network connections (or click Local area network (LAN) if WIN2003extIP is not an ISDN, PPP, or direct-connect serial connection).
Click the Filter Action tab, click to clear the Use Add Wizard check box, and then click Add to create a new filter action because the default actions allow incoming traffic in clear text.
Keep the Negotiate security option enabled, and then click to clear the Accept unsecured communication, but always respond using IPSec check box. You must do this for secure operation.

Note None of the check boxes at the bottom of the Filter Action dialog box are selected as an initial configuration for a filter action that applies to tunnel rules. Only the Use session key perfect forward secrecy (PFS) check box is a valid setting for tunnels if the other end of the tunnel is also configured to use PFS.
Click Add, and keep the Integrity and encryption option selected (or you can select the Custom (for expert users) option if you want to define specific algorithms and session key lifetimes). Encapsulating Security Payload (ESP) is one of the two IPSec protocols.
Click OK. Click the General tab, type a name for the new filter action (for example, IPSec tunnel: ESP DES/MD5), and then click OK.
Click to select the filter action that you just created.
Click the Authentication Methods tab, configure the authentication method that you want (use preshared key for testing, and otherwise use certificates). Kerberos is technically possible if both ends of the tunnel are in trusted domains, and each trusted domain's IP address (IP address of a domain controller) is reachable on the network by both ends of the tunnel during IKE negotiation of the tunnel (before it is established). But this is rare.
Click Close.

Configure a Rule for a NetB-to-NetA Tunnel

In IPSec policy properties, click Add to create a new rule.
Click the IP Filter List tab, click to select the filter list that you created (from NetB to NetA).
Click the Tunnel Setting tab, click The tunnel endpoint is specified by this IP Address box, and then type WIN2003extIP (where WIN2003extIP is the IP address that is assigned to the Windows Server 2003 gateway external network adapter).
Click the Connection Type tab, click All network connections (or click Local area network (LAN) if WIN2003extIP is not an ISDN, PPP, or direct-connect serial connection). Any outbound traffic on the interface type that matches the filters tries to be tunneled to the tunnel endpoint that is specified in the rule. Inbound traffic that matches the filters is discarded because it must be received secured by an IPSec tunnel.
Click the Filter Action tab, and then click to select the filter action that you created.
Click the Authentication Methods tab, and then configure the same method that you used in the first rule (the same method must be used in both rules).
Click OK, make sure both rules that you created are enabled in your policy, and then click OK again.

Assign Your New IPSec Policy to Your Windows Server 2003 Gateway

In the IP Security Policies on Local Computer MMC snap-in, right-click your new policy, and then click Assign. A green arrow appears in the folder icon next to your policy.

After your policy is assigned, you have two additional active filters (Routing and Remote Access automatically creates IPSec filters for L2TP traffic). To see the active filters, type the following command at a command prompt:

netdiag /test:ipsec /debug

You can optionally redirect the output of this command to a text file so you can view it with a text editor (such as Notepad) by typing the following command:

netdiag /test:ipsec /debug > filename.txt

The netdiag command is available after you install the Microsoft Windows Server 2003 Support Tools. To install the Support Tools, locate the Support\Tools folder on your Windows Server 2003 CD-ROM, right-click the Suptools.msi file, and then click Install. After installation, you may have to run the netdiag command from the %SystemRoot%\Program Files\Support Tools folder (where %SystemRoot% is the drive where Windows Server 2003 is installed).

The tunnel filters look similar to the following example:

Local IPSec Policy Active: 'IPSec tunnel with {tunnel endpoint}' IP Security Policy Path:
SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecPolicy{-longnumber-}

There are two filters
From NetA to NetB
Filter ID: {-long number-}
Policy ID: {-long number-}
IPSEC_POLICY PolicyId = {-long number-}
Flags: 0x0
Tunnel Addr: 0.0.0.0
PHASE 2 OFFERS Count = 1
Offer #0:
ESP[ DES MD5 HMAC]
Rekey: 0 seconds / 0 bytes.
AUTHENTICATION INFO Count = 1
Method = Preshared key: -actual key-
Src Addr: NetA Src Mask: -subnet mask-
Dest Addr: NetB Dest Mask: -subnet mask-
Tunnel Addr: 3rdExtIP Src Port: 0 Dest Port: 0
Protocol: 0 TunnelFilter: Yes
Flags : Outbound
From NetB to NetA
Filter ID: {-long number-}
Policy ID: {-long number-}
IPSEC_POLICY PolicyId = {-long number-}
Flags: 0x0
Tunnel Addr: 0.0.0.0
PHASE 2 OFFERS Count = 1
Offer #0:
ESP[ DES MD5 HMAC]
Rekey: 0 seconds / 0 bytes.
AUTHENTICATION INFO Count = 1
Method = Preshared key: -actual key-
Src Addr: NetB Src Mask: -subnet mask-
Dest Addr: NetA Dest Mask: -subnet mask-
Tunnel Addr: W2KextIP Src Port: 0 Dest Port: 0
Protocol: 0 TunnelFilter: Yes
Flags: Inbound

Configure Routing and Remote Access Filtering

If you want to prevent traffic that does not have a source or destination address that matches NetA or NetB, create an output filter for the external interface in the Routing and Remote Access MMC so that the filter drops all traffic except packets from NetA to NetB. Also create an input filter so the filter drops all traffic except packets from NetB to NetA. You also have to allow traffic to and from WIN2003extIP and 3rdExtIP to allow IKE negotiation when the tunnel is being created. Routing and Remote Access filtering is performed over IPSec. You do not have to specifically allow the IPSec protocol because it never reaches the IP packet filter layer. The following example is a very simple representation of the Windows Server 2003 TCP/IP architecture:

Application layer
Transport layer (TCP|UDP|ICMP|RAW)
---- Network layer start ----
IP Packet Filter (where NAT/Routing and Remote Access filtering is done)
IPSec (where IPSec filters are implemented)
Fragmentation/Reassembly
---- Network layer end ------
NDIS Interface
Datalink layer
Physical layer

To configure the filters in the Routing and Remote Access service, load the Routing and Remote Access MMC and follow these steps:

Expand your server tree under Routing and Remote Access, expand the IP Routing subtree, and then click General.
Right-click WIN2003extIP, and then click Properties.
Click Outbound Filters, and then click New.
Click to select the Source network and Destination network check boxes.
In the Source network box, type the IP address and Subnet mask for NetA.
In the Destination network box, type the IP address and Subnet mask for NetB.
Keep the protocol set to Any, and then click OK.
Click New, and then click to select the Source network and Destination network check boxes.
In the Source network box, type the IP address and Subnet mask for WIN2003extIP.
In the Destination network box, type the IP address and Subnet mask for 3rdExtIP (for IKE negotiation use a subnet mask of 255.255.255.255).
Keep the protocol set to Any, and then click OK.
Click to select the Drop all packets except those that meet the criteria below check box, and then click OK.
Click Input Filters, click Add, and then click to select the Source network and Destination network check boxes.
In the Source network box, type the IP address and Subnet mask for NetB.
In the Destination network box, type the IP address and Subnet mask for NetA.
Keep the protocol set to Any, and then click OK.
Click New, and then click to select the Source network and Destination network check boxes.
In the Source network box, type the IP address and Subnet mask for 3rdExtIP.
In the Destination network box, type the IP address and Subnet mask for WIN2003extIP (for IKE negotiation use a subnet mask of 255.255.255.255).
Keep the protocol set to Any, and then click OK.
Click to select the Drop all packets except those that meet the criteria below check box, and then click OK two times.

Note If the Routing and Remote Access server has more than one interface that is connected to the Internet, or if you have multiple IPSec tunnels, create Routing and Remote Access exempt filters for each IPSec tunnel (each source and destination IP subnet) for every Internet interface.

Configure Static Routes in Routing and Remote Access

The Windows Server 2003 gateway must have a route in its route table for NetB. To configure this route, add a static route in the Routing and Remote Access MMC. If the Windows Server 2003 gateway is multihomed with two or more network adapters on the same external network (or two or more networks that can reach the destination tunnel IP 3rdExtIP), the potential exists for the following:

Outbound tunnel traffic leaves on one interface, and the inbound tunnel traffic is received on a different interface. Even if you use IPSec offload network adapters, receiving on a different interface (than the outbound tunnel traffic is sent on) does not allow the receiving network adapter to process the encryption in hardware, because only the outbound interface can offload the Security Association (SA).
Outbound tunnel traffic leaves on an interface that is different from the interface that has the tunnel endpoint IP address. The source IP of the tunneled packet is the source IP on the outbound interface. If this is not the source IP that is expected by the other end, the tunnel is not established (or packets are dropped by the remote endpoint if the tunnel has already been established).

To avoid sending outbound tunnel traffic on the wrong interface, define a static route to bind traffic to NetB to the appropriate external interface:

In the Routing and Remote Access MMC, expand your server tree, expand the IP Routing subtree, right-click Static Routes, and then click New Static Route.
In the Interface box, click WIN2003extIP (if this is the interface that you want to always use for outbound tunnel traffic).
Type the Destination network and Network mask for NetB.
In the Gateway box, type 3rdextip.
Keep the Metric value set to its default (1), and then click OK.

Note To address the issue of receiving inbound tunnel traffic on the wrong interface, do not advertise the interface's IP address by using a routing protocol. Also, configure a filter in the Routing and Remote Access service to drop packets to NetA or WIN2003extIP as indicated in the "Configure Routing and Remote Access Filtering" section of this article.

Test Your IPSec Tunnel

You can initiate the tunnel by pinging from a computer on NetA to a computer on NetB (or from NetB to NetA). If you created the filters correctly and assigned the correct policy, the two gateways establish an IPSec tunnel so they can send the ICMP traffic from the ping command in encrypted format. Even if the ping command works, verify that the ICMP traffic was sent in encrypted format from gateway to gateway. You can use the following tools to do this.

back to the top

Back to the top

Enable Auditing for Logon Events and Object Access

This logs events in the security log. This tells you if IKE security association negotiation was tried and if it was successful or not.

Using the Group Policy MMC snap-in, expand Local Computer Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Audit Policy.
Enable Success and Failure auditing for Audit logon events and Audit object access.

Note If the Windows Server 2003 gateway is a member of a domain and if you are using a domain policy for auditing, the domain policy overwrites your local policy. In this case, modify the domain policy.

IP Security Monitor

The IP Security Monitor console shows IPSec statistics and active security associations (SA). After you try to establish the tunnel by using the ping command, you can see if an SA was created (if the tunnel creation is successful, an SA is displayed). If the ping command is successful but there is no SA, the ICMP traffic was not protected by IPSec. If you see a "soft association" that did not previously exist, then IPSec agreed to allow this traffic to go "on the clear" (without encryption). For additional information about "Soft Associations", click the following article number to view the article in the Microsoft Knowledge Base:

234580 (http://support.microsoft.com/kb/234580/EN-US/ ) "Soft Associations" Between IPSec-Enabled and Non-IPSec-Enabled Computers

Note In Microsoft Windows XP and the Windows Server 2003 family, IP Security Monitor is implemented as a Microsoft Management Console (MMC) console. To add the IP Security Monitor snap-in, follow these steps:

Click Start, click Run, type MMC, and then click OK.
Click File, click Add/Remove Snap-in, and then click Add.
Click IP Security Monitor, and then click Add.
Click Close, and then click OK.

Network Monitor

You can use Network Monitor to capture traffic going through the WIN2003extIP interface while you try to ping the computer. If you can see ICMP packets in the capture file that have source and destination IP addresses that correspond to the IP addresses of the computer that you are pinging from and the computer you are trying to ping, then IPSec is not protecting the traffic. If you do not see this ICMP traffic but do see ISAKMP and ESP packets instead, IPSec is protecting the traffic. If you are using only the Authentication Header (AH) IPSec protocol, you will see the ISAKMP traffic followed by the ICMP packets. ISAKMP packets are the actual IKE negotiation occurring, and ESP packets are the payload data encrypted by the IPSec protocol.

To install Network Monitor, follow these steps:

Click Start, click Control Panel, click Add or Remove Programs, and then click Add/Remove Windows Components.
In the Windows Components wizard, click Management and Monitoring Tools, and then click Details.
In Subcomponents of Management and Monitoring Tools, click to select the Network Monitor Tools check box, and then click OK.
If you are prompted for additional files, insert the installation CD for your operating system, or type a path of the location of the files on the network.

Actual Test

Before you try to ping from a computer on one subnet to the other (NetA or NetB), type ipconfig at a command prompt. The network interfaces that are initialized in the TCP/IP stack are displayed.
Start the IP Security Monitor tool.
Start Network Monitor, and then on the Capture menu, click Networks. Click the WIN2003extIP interface, and then click OK.
Try to ping the computer. The first ICMP echo packets may time out while the IPSec tunnel is being built. If the ping is not successful, check the security and system logs.
If the ping is successful, stop the Network Monitor capture and see if the ICMP traffic went "on the clear" or if you just see the ISAKMP and IPSec protocol packets. Check IP Security Monitor to see if an SA was created using the NetA to NetB filter you created. Also check the security log. You should see Event ID 541 (IKE security association established).
Type ipconfig at a command prompt again to verify that there is no additional TCP/IP interface while the tunnel is in use. This behavior occurs because IPSec is protecting the traffic that is going through the physical interface (WIN2003extIP).

If the remote gateway is also a Windows Server 2003 node, remember that:
- The default gateway for clients in NetA is WIN2003extIP. The default gateway for clients in NetB is 3rdIntIP.
- An IPSec tunnel does not change the way traffic is routed in the Windows Server 2003 gateway. (This gateway can route packets because routing is enabled in Routing and Remote Access. The actual LAN or WAN interface metrics are still used.)

How to install and configure a Virtual Private Network server in Windows Server 2003

2010-03-15T21:29:00.000-07:00

This step-by-step article describes how to install virtual private networking (VPN) and how to create a new VPN connection in servers that are running Windows Server 2003.

With a virtual private network, you can connect network components through another network, such as the Internet. You can make your Windows Server 2003-based computer a remote-access server so that other users can connect to it by using VPN, and then they can log on to the network and access shared resources. VPNs do this by "tunneling" through the Internet or through another public network in a manner that provides the same security and features as a private network. Data is sent across the public network by using its routing infrastructure, but to the user, it appears as if the data is sent over a dedicated private link.

Overview of VPN

A virtual private network is a means of connecting to a private network (such as your office network) by way of a public network (such as the Internet). A VPN combines the virtues of a dial-up connection to a dial-up server with the ease and flexibility of an Internet connection. By using an Internet connection, you can travel worldwide and still, in most places, connect to your office with a local call to the nearest Internet-access phone number. If you have a high-speed Internet connection (such as cable or DSL) at your computer and at your office, you can communicate with your office at full Internet speed, which is much faster than any dial-up connection that uses an analog modem. This technology allows an enterprise to connect to its branch offices or to other companies over a public network while maintaining secure communications. The VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link.

Virtual private networks use authenticated links to make sure that only authorized users can connect to your network. To make sure data is secure as it travels over the public network, a VPN connection uses Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) to encrypt data.

Components of a VPN

A VPN in servers running Windows Server 2003 is made up of a VPN server, a VPN client, a VPN connection (that portion of the connection in which the data is encrypted), and the tunnel (that portion of the connection in which the data is encapsulated). The tunneling is completed through one of the tunneling protocols included with servers running Windows Server 2003, both of which are installed with Routing and Remote Access. The Routing and Remote Access service is installed automatically during the installation of Windows Server 2003. By default, however, the Routing and Remote Access service is turned off.
The two tunneling protocols included with Windows are:

Point-to-Point Tunneling Protocol (PPTP): Provides data encryption using Microsoft Point-to-Point Encryption.
Layer Two Tunneling Protocol (L2TP): Provides data encryption, authentication, and integrity using IPSec.

Your connection to the Internet must use a dedicated line such as T1, Fractional T1, or Frame Relay. The WAN adapter must be configured with the IP address and subnet mask assigned for your domain or supplied by an Internet service provider (ISP). The WAN adapter must also be configured as the default gateway of the ISP router.

NOTE: To turn on VPN, you must be logged on using an account that has administrative rights.

How to install and Turn on a VPN Server

To install and turn on a VPN server, follow these steps:

Click Start, point to Administrative Tools, and then click Routing and Remote Access.
Click the server icon that matches the local server name in the left pane of the console. If the icon has a red circle in the lower-left corner, the Routing and Remote Access service has not been turned on. If the icon has a green arrow pointing up in the lower-left corner, the Routing and Remote Access service has been turned on. If the Routing and Remote Access service was previously turn on, you may want to reconfigure the server. To reconfigure the server:
1. Right-click the server object, and then click Disable Routing and Remote Access. Click Yes to continue when you are prompted with an informational message.
2. Right-click the server icon, and then click Configure and Enable Routing and Remote Access to start the Routing and Remote Access Server Setup Wizard. Click Next to continue.
3. Click Remote access (dial-up or VPN) to turn on remote computers to dial in or connect to this network through the Internet. Click Next to continue.
Click to select VPN or Dial-up depending on the role that you intend to assign to this server.
In the VPN Connection window, click the network interface which is connected to the Internet, and then click Next.
In the IP Address Assignment window, click Automatically if a DHCP server will be used to assign addresses to remote clients, or click From a specified range of addresses if remote clients must only be given an address from a pre-defined pool. In most cases, the DHCP option is simpler to administer. However, if DHCP is not available, you must specify a range of static addresses. Click Next to continue.
If you clicked From a specified range of addresses, the Address Range Assignment dialog box opens. Click New. Type the first IP address in the range of addresses that you want to use in the Start IP address box. Type the last IP address in the range in the End IP address box. Windows calculates the number of addresses automatically. Click OK to return to the Address Range Assignment window. Click Next to continue.
Accept the default setting of No, use Routing and Remote Access to authenticate connection requests, and then click Next to continue. Click Finish to turn on the Routing and Remote Access service and to configure the server as a Remote Access server.

How to Configure the VPN Server

To continue to configure the VPN server as required, follow these steps.

How to Configure the Remote Access Server as a Router

For the remote access server to forward traffic properly inside your network, you must configure it as a router with either static routes or routing protocols, so that all of the locations in the intranet are reachable from the remote access server.

To configure the server as a router:

Click Start, point to Administrative Tools, and then click Routing and Remote Access.
Right-click the server name, and then click Properties.
Click the General tab, and then click to select Router under Enable this computer as a.
Click LAN and demand-dial routing, and then click OK to close the Properties dialog box.

How to Modify the Number of Simultaneous Connections

The number of dial-up modem connections is dependent on the number of modems that are installed on the server. For example, if you have only one modem installed on the server, you can have only one modem connection at a time.

The number of dial-up VPN connections is dependent on the number of simultaneous users whom you want to permit. By default, when you run the procedure described in this article, you permit 128 connections. To change the number of simultaneous connections, follow these steps:

Click Start, point to Administrative Tools, and then click Routing and Remote Access.
Double-click the server object, right-click Ports, and then click Properties.
In the Ports Properties dialog box, click WAN Miniport (PPTP), and then click Configure.
In the Maximum ports box, type the number of VPN connections that you want to permit.
Click OK, click OK again, and then close Routing and Remote Access.

How to Manage Addresses and Name Servers

The VPN server must have IP addresses available to assign them to the VPN server's virtual interface and to VPN clients during the IP Control Protocol (IPCP) negotiation phase of the connection process. The IP address assigned to the VPN client is assigned to the virtual interface of the VPN client.

For Windows Server 2003-based VPN servers, the IP addresses assigned to VPN clients are obtained through DHCP by default. You can also configure a static IP address pool. The VPN server must also be configured with name resolution servers, typically DNS and WINS server addresses, to assign to the VPN client during IPCP negotiation.

How to Manage Access

Configure the dial-in properties on user accounts and remote access policies to manage access for dial-up networking and VPN connections.

NOTE: By default, users are denied access to dial-up networking.

Access by User Account

To grant dial-in access to a user account if you are managing remote access on a user basis, follow these steps:

Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
Right-click the user account, and then click Properties.
Click the Dial-in tab.
Click Allow access to grant the user permission to dial in. Click OK.

Access by Group Membership

If you manage remote access on a group basis, follow these steps:

Create a group with members who are permitted to create VPN connections.
Click Start, point to Administrative Tools, and then click Routing and Remote Access.
In the console tree, expand Routing and Remote Access, expand the server name, and then click Remote Access Policies.
Right-click anywhere in the right pane, point to New, and then click Remote Access Policy.
Click Next, type the policy name, and then click Next.
Click VPN for Virtual Private Access access method, or click Dial-up for dial-up access, and then click Next.
Click Add, type the name of the group that you created in step 1, and then click Next.
Follow the on-screen instructions to complete the wizard.

If the VPN server already permits dial-up networking remote access services, do not delete the default policy. Instead, move it so that it is the last policy to be evaluated.

How to Configure a VPN Connection from a Client Computer

To set up a connection to a VPN, follow these steps. To set up a client for virtual private network access, follow these steps on the client workstation:

NOTE: You must be logged on as a member of the Administrators group to follow these steps.

NOTE: Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.

On the client computer, confirm that the connection to the Internet is correctly configured.
Click Start, click Control Panel, and then click Network Connections. Click Create a new connection under Network Tasks, and then click Next.
Click Connect to the network at my workplace to create the dial-up connection. Click Next to continue.
Click Virtual Private Network connection, and then click Next.
Type a descriptive name for this connection in the Company name dialog box, and then click Next.
Click Do not dial the initial connection if the computer is permanently connected to the Internet. If the computer connects to the Internet through an Internet Service Provider (ISP), click Automatically dial this initial connection, and then click the name of the connection to the ISP. Click Next.
Type the IP address or the host name of the VPN server computer (for example, VPNServer.SampleDomain.com).
Click Anyone's use if you want to permit any user who logs on to the workstation to have access to this dial-up connection. Click My use only if you want this connection to be available only to the currently logged-on user. Click Next.
Click Finish to save the connection.
Click Start, click Control Panel, and then click Network Connections.
Double-click the new connection.
Click Properties to continue to configure options for the connection. To continue to configure options for the connection, follow these steps:
- If you are connecting to a domain, click the Options tab, and then click to select the Include Windows logon domain check box to specify whether to request Windows Server 2003 logon domain information before trying to connect.
- If you want the connection to be redialed if the line is dropped, click the Options tab, and then click to select the Redial if line is dropped check box.

To use the connection, follow these steps:

Click Start, point to Connect to, and then click the new connection.
If you do not currently have a connection to the Internet, Windows offers to connect to the Internet.
When the connection to the Internet is made, the VPN server prompts you for your user name and password. Type your user name and password, and then click Connect.
Your network resources must be available to you in the same way they are when you connect directly to the network.NOTE: To disconnect from the VPN, right-click the connection icon, and then click Disconnect.

Troubleshooting

Troubleshooting Remote Access VPNs

Cannot Establish a Remote Access VPN Connection

Cause: The name of the client computer is the same as the name of another computer on the network.

Solution: Verify that the names of all computers on the network and computers connecting to the network are using unique computer names.
Cause: The Routing and Remote Access service is not started on the VPN server.

Solution: Verify the state of the Routing and Remote Access service on the VPN server.

See Windows Server 2003 Help and Support Center for more information about how to monitor the Routing and Remote Access service, and how to start and stop the Routing and Remote Access service. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: Remote access is not turned on on the VPN server.

Solution: Turn on remote access on the VPN server.

See the Windows Server 2003 Help and Support Center for more information about how to turn on the remote access server. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: PPTP or L2TP ports are not turned on for inbound remote access requests.

Solution: Turn on PPTP or L2TP ports, or both, for inbound remote access requests.

See the Windows Server 2003 Help and Support Center for more information about how to configure ports for remote access. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The LAN protocols used by the VPN clients are not turned on for remote access on the VPN server.

Solution: Turn on the LAN protocols used by the VPN clients for remote access on the VPN server.

See the Windows Server 2003 Help and Support Center for more information about how to view properties of the remote access server. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: All of the PPTP or L2TP ports on the VPN server are already being used by currently connected remote access clients or demand-dial routers.

Solution: Verify that all of the PPTP or L2TP ports on the VPN server are already being used. To do so, click Ports in Routing and Remote Access. If the number of PPTP or L2TP ports permitted is not high enough, change the number of PPTP or L2TP ports to permit more concurrent connections.

See the Windows Server 2003 Help and Support Center for more information about how to add PPTP or L2TP ports. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN server does not support the tunneling protocol of the VPN client.

By default, Windows Server 2003 remote access VPN clients use the Automatic server type option, which means that they try to establish an L2TP over IPSec-based VPN connection first, and then they try to establish a PPTP-based VPN connection. If VPN clients use either the Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option, verify that the selected tunneling protocol is supported by the VPN server.

By default, a computer running Windows Server 2003 Server and the Routing and Remote Access service is a PPTP and L2TP server with five L2TP ports and five PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to zero.

Solution: Verify that the appropriate number of PPTP or L2TP ports is configured.

See the Windows Server 2003 Help and Support Center for more information about how to add PPTP or L2TP ports. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common authentication method.

Solution: Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common authentication method.

See the Windows Server 2003 Help and Support Center for more information about how to configure authentication. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN client and the VPN server in conjunction with a remote access policy are not configured to use at least one common encryption method.

Solution: Configure the VPN client and the VPN server in conjunction with a remote access policy to use at least one common encryption method.

See the Windows Server 2003 Help and Support Center for more information about how to configure encryption. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN connection does not have the appropriate permissions through dial-in properties of the user account and remote access policies.

Solution: Verify that the VPN connection has the appropriate permissions through dial-in properties of the user account and remote access policies. For the connection to be established, the settings of the connection attempt must:
- Match all of the conditions of at least one remote access policy.
- Be granted remote access permission through the user account (set to Allow access) or through the user account (set to Control access through Remote Access Policy) and the remote access permission of the matching remote access policy (set to Grant remote access permission).
- Match all the settings of the profile.
- Match all the settings of the dial-in properties of the user account.
See the Windows Server 2003 Help and Support Center for an introduction to remote access policies, and for more information about how to accept a connection attempt. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The settings of the remote access policy profile are in conflict with properties of the VPN server.

The properties of the remote access policy profile and the properties of the VPN server both contain settings for:
- Multilink.
- Bandwidth allocation protocol (BAP).
- Authentication protocols.
If the settings of the profile of the matching remote access policy are in conflict with the settings of the VPN server, the connection attempt is rejected. For example, if the matching remote access policy profile specifies that the Extensible Authentication Protocol - Transport Level Security (EAP-TLS) authentication protocol must be used and EAP is not enabled on the VPN server, the connection attempt is rejected.

Solution: Verify that the settings of the remote access policy profile are not in conflict with properties of the VPN server.

See the Windows Server 2003 Help and Support Center for more information about additional information about multilink, BAP and authentication protocols. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The answering router cannot validate the credentials of the calling router (user name, password, and domain name).

Solution: Verify that the credentials of the VPN client (user name, password, and domain name) are correct and can be validated by the VPN server.
Cause: There are not enough addresses in the static IP address pool.

Solution: If the VPN server is configured with a static IP address pool, verify that there are enough addresses in the pool. If all of the addresses in the static pool have been allocated to connected VPN clients, the VPN server cannot allocate an IP address, and the connection attempt is rejected. If all of the addresses in the static pool have been allocated, modify the pool. See the Windows Server 2003 Help and Support Center for more information about TCP/IP and remote access, and how to create a static IP address pool. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN client is configured to request its own IPX node number and the VPN server is not configured to permit IPX clients to request their own IPX node number.

Solution: Configure the VPN server to permit IPX clients to request their own IPX node number.

See the Windows Server 2003 Help and Support Center for more information about IPX and remote access. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN server is configured with a range of IPX network numbers that are being used elsewhere on your IPX network.

Solution: Configure the VPN server with a range of IPX network numbers that is unique to your IPX network.

See the Windows Server 2003 Help and Support Center for more information about IPX and remote access. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The authentication provider of the VPN server is improperly configured.

Solution: Verify the configuration of the authentication provider. You can configure the VPN server to use either Windows Server 2003 or Remote Authentication Dial-In User Service (RADIUS) to authenticate the credentials of the VPN client.

See the Windows Server 2003 Help and Support Center for more information about authentication and accounting providers, and how to use RADIUS authentication. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN server cannot access Active Directory.

Solution: For a VPN server that is a member server in a mixed-mode or native-mode Windows Server 2003 domain that is configured for Windows Server 2003 authentication, verify that:
- The RAS and IAS Servers security group exists. If not, create the group and set the group type to Security and the group scope to Domain local.
- The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access Check object.
- The computer account of the VPN server computer is a member of the RAS and IAS Servers security group. You can use the netsh ras show registeredserver command to view the current registration. You can use the netsh ras add registeredserver command to register the server in a specified domain.
  
  If you add (or remove) the VPN server computer to the RAS and IAS Servers security group, the change does not take effect immediately (because of the way that Windows Server 2003 caches Active Directory information). To immediately effect this change, restart the VPN server computer.
- The VPN server is a member of the domain.
See the Windows Server 2003 Help and Support Center for more information about how to add a group, how to verify permissions for the RAS and IAS security group, and about netsh commands for remote access. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: A Windows NT 4.0-based VPN server cannot validate connection requests.

Solution: If VPN clients are dialing in to a VPN server running Windows NT 4.0 that is a member of a Windows Server 2003 mixed-mode domain, verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the following command:
"net localgroup "Pre-Windows 2000 Compatible Access""
If not, type the following command at a command prompt on a domain controller computer, and then restart the domain controller computer:
net localgroup "Pre-Windows 2000 Compatible Access" everyone /add
See the Windows Server 2003 Help and Support Center for more information about Windows NT 4.0 remote access server in a Windows Server 2003 domain. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: The VPN server cannot communicate with the configured RADIUS server.

Solution: If you can reach your RADIUS server only through your Internet interface, do one of the following:
- Add an input filter and an output filter to the Internet interface for UDP port 1812 (based on RFC 2138, "Remote Authentication Dial-In User Service (RADIUS)"). –or-
- Add an input filter and an output filter to the Internet interface for UDP port 1645 (for older RADIUS servers), for RADIUS authentication and UDP port 1813 (based on RFC 2139, "RADIUS Accounting"). -or-
- -or- Add an input filter and an output filter to the Internet interface for UDP port 1646 (for older RADIUS servers) for RADIUS accounting.
See the Windows Server 2003 Help and Support Center for more information about how to add a packet filter. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: Cannot connect to the VPN server over the Internet using the Ping.exe utility.

Solution: Because of the PPTP and L2TP over IPSec packet filtering that is configured on the Internet interface of the VPN server, Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To turn on the VPN server to respond to ICMP (ping) packets, add an input filter and an output filter that permit traffic for IP protocol 1 (ICMP traffic).

See the Windows Server 2003 Help and Support Center for more information about how to add a packet filter. Click Start to access the Windows Server 2003 Help and Support Center.

Cannot Send and Receive Data

Cause: The appropriate demand-dial interface has not been added to the protocol being routed.

Solution: Add the appropriate demand-dial interface to the protocol being routed.

See the Windows Server 2003 Help and Support Center for more information about how to add a routing interface. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: There are no routes on both sides of the router-to-router VPN connection that support the two-way exchange of traffic.

Solution: Unlike a remote access VPN connection, a router-to-router VPN connection does not automatically create a default route. Create routes on both sides of the router-to-router VPN connection so that traffic can be routed to and from the other side of the router-to-router VPN connection.

You can manually add static routes to the routing table, or you can add static routes through routing protocols. For persistent VPN connections, you can turn on Open Shortest Path First (OSPF) or Routing Information Protocol (RIP) across the VPN connection. For on-demand VPN connections, you can automatically update routes through an auto-static RIP update. See Windows Server 2003 online Help for more information about how to add an IP routing protocol, how to add a static route, and how to perform auto-static updates. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: A two-way initiated, the answering router as a remote access connection is interpreting router-to-router VPN connection.

Solution: If the user name in the credentials of the calling router appears under Dial-In Clients in Routing and Remote Access, the answering router may interpret the calling router as a remote access client. Verify that the user name in the credentials of the calling router matches the name of a demand-dial interface on the answering router. If the incoming caller is a router, the port on which the call was received shows a status of Active and the corresponding demand-dial interface is in a Connected state.

See Windows Server 2003 online Help for more information about how to check the status of the port on the answering router, and how to check the status of the demand-dial interface. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: Packet filters on the demand-dial interfaces of the calling router and answering router are preventing the flow of traffic.

Solution: Verify that there are no packet filters on the demand-dial interfaces of the calling router and answering router that prevent the sending or receiving of traffic. You can configure each demand-dial interface with IP and IPX input and output filters to control the exact nature of TCP/IP and IPX traffic that is permitted into and out of the demand-dial interface.

See Windows Server 2003 online Help for more information about how to manage packet filters. Click Start to access the Windows Server 2003 Help and Support Center.
Cause: Packet filters on the remote access policy profile are preventing the flow of IP traffic.

Solution: Verify that there are no configured TCP/IP packet filters on the profile properties of the remote access policies on the VPN server (or the RADIUS server if Internet Authentication Service is used) that are preventing the sending or receiving of TCP/IP traffic. You can use remote access policies to configure TCP/IP input and output packet filters that control the exact nature of TCP/IP traffic permitted on the VPN connection. Verify that the profile TCP/IP packet filters are not preventing the flow of traffic.

See Windows Server 2003 online Help for more information about how to configure IP options. Click Start to access the Windows Server 2003 Help and Support Center.

Using FTP Over SSL

2010-03-15T19:09:00.000-07:00

Introduction

Microsoft has created a new FTP service that has been completely rewritten for Windows Server® 2008. This FTP service incorporates many new features that enable web authors to publish content better than before, and offers web administrators more security and deployment options.

One of the features is FTP over Secure Sockets Layer (SSL), which allows sessions to be encrypted between an FTP client and server. This document walks you through: setting up an FTP site; and, configuring that site to use SSL with the new FTP user interface, which allows you to directly edit the IIS 7.0 configuration files. It contains:

Note: This walk-through contains a series of steps where you log in to your FTP site using the local administrator account. These steps should only be followed on the server itself using the loopback address or over SSL from a remote server. If you prefer to use a separate user account instead of the administrator account, you must create the appropriate folders and set the correct permissions for that user account when necessary.

Prerequisites

The following items are required to be installed to complete the procedures in this article:

IIS 7.0 must be installed on your Windows 2008 Server, and the Internet Information Services Manager must be installed.
The new FTP service. You can download and install the FTP service from the http://www.iis.net/ web site using one of the following links:

You will need to create a root folder for FTP publishing:
- Create a folder at "%SystemDrive%\inetpub\ftproot"
- Set the permissions to allow access for the administrators group:
  - Open a command prompt.
  - Type the following command:
    ICACLS "%SystemDrive%\inetpub\ftproot" /Grant administrators:F /T
  - Close the command prompt.

Note: The settings listed in this walkthrough specify "%SystemDrive%\inetpub\ftproot" as the path to your FTP site. You are not required to use this path; however, if you change the location for your site you must change the site-related paths that are used throughout this walkthrough.

OPTIONAL: Creating a Self-signed SSL Certificate

In this optional task you will create a self-signed SSL certificate that you will use for testing your FTP site.

Note: If you are setting up an FTP site for Internet-based activity, you would obtain an SSL certificate from one of the many Certification Authorities, such as VeriSign, Thawte, DigiCert, etc. For more information about Certification Authorities, see the following page on the Microsoft Developer Network Web site:

http://msdn.microsoft.com/en-us/library/bb540797(VS.85).aspx

Open the Internet Information Services (IIS 7.0) Manager.
Click your computer at the top node of the Connections tree, then double-click the Server Certificates feature.
Click Create Self-Signed Certificate in the Actions pane.
Enter "My FTP Certificate" as the name for the new certificate, then click OK.

Creating an SSL-enabled FTP Site Using the IIS 7.0 Manager

Step 1: Use the FTP Site Wizard to Create an SSL-based FTP Site

In this first step, you create a new FTP site that can only be opened using your administrator account.

Go to IIS 7.0 Manager. In the Connections pane, click the Sites node in the tree.
Right-click the Sites node in the tree and click Add FTP Site, or click Add FTP Site in the Actions pane.
When the Add FTP Site wizard appears:
- Enter "My New FTP Site" in the FTP site name box, then navigate to the "%SystemDrive%\inetpub\ftproot" folder that you created in the Prerequisites section. Note: If you choose to type in the path to your content folder, you can use environment variables in your paths.
- Click Next.
On the next page of the wizard:
- Choose an IP address for your FTP site from the IP Address drop-down, or choose to accept the default selection of "All Unassigned." Because you will use the administrator account later in this walk-through, make sure that you restrict access to the server and enter the local loopback IP address for your computer by typing "127.0.0.1" in the IP Address box.
- You would normally enter the TCP/IP port for the FTP site in the Port box. For this walk-through, choose to accept the default port of 21.
- For this walk- through, you do not use a host name, so make sure that the Virtual Host box is blank.
- Make sure that the Certificates drop-down is set to your SSL certificate. For example, if you followed the optional step to create a self-signed certificate, the drop-down box should say "My FTP Certificate".
- Make sure that the Allow SSL option is selected.
- Click Next.
On the next page of the wizard:
- Select Basic for the Authentication settings.
- For the Authorization settings:
  - Choose "Specified users" from the Allow access to drop-down.
  - Type "administrator" for the user name.
  - Select Read and Write for the Permissions option.
- When you have completed these items, click Finish.

Summary

You have successfully created a new SSL-based FTP site using the new FTP service.

To recap the items that you completed in this step:

You created a new FTP site named "My New FTP Site", with the site's content root at "%SystemDrive%\inetpub\ftproot".
You bound the FTP site to the local loopback address for your computer on port 21.
You chose to require Secure Sockets Layer (SSL) for the FTP site, and selected your SSL certificate.
You enabled Basic Authentication and created an authorization rule for the local administrator account for Read and Write access.

Step 2: Configuring Additional FTP SSL Settings

The SSL policy for FTP is customizable on a site-by-site basis. Different settings can be specified for the control and data channels. In this step, you configure additional SSL settings for your FTP site that ensure that all user credentials are encrypted, even if all other FTP activity is not.

Go to the IIS 7.0 Manager. Click the node for the FTP site that you created in Step 1. The icons for all of the FTP features display.
In order to configure the SSL options, double-click the FTP SSL Settings icon to open the SSL settings feature page.
When the FTP SSL Settings page displays, select the Custom option, and then click the Advanced button.
When the Advanced SSL Policy dialog box is displayed:
- Select the Require only for credentials option for the control channel. Note: This setting requires that all user names and password are encrypted via SSL, but the client can choose whether to encrypt all other control channel activity.
- Select the Allow option for the data channel. Note: This setting allows the client to choose whether to encrypt any data channel activity.
- When you have completed these items, click OK.
On the FTP SSL Settings page, click Apply in the Actions pane to save the SSL settings.

Summary

To recap the items that you completed in this step:

You configured the control channel SSL policy to require that all user credentials are encrypted, and allowed FTP clients to determine whether to encrypt all other control channel activity.
You configured the data channel SSL policy to allow FTP clients to determine whether to encrypt any data channel activity.

Logging in To Your FTP Site

In Step 1, you created an FTP site that can be accessed by the administrator account. In Step 2, you configured the control channel SSL policy to require that all user credentials are encrypted while allowing FTP clients to choose whether or not all other control channel and data channel activity be encrypted.

When logging in to the FTP server using an SSL-capable FTP client, the FTP server supports the following explicit security options:

TLS-C/TLS - Use TLS for the connection with RFC2228 defaults. This means that there is no implicit protection of the data connection.
TLS-P/SSL - Use TLS for the connection. This means that the data connection is implicitly protected.

These settings can be configured when specifying the SSL connection options in most 3^rd-part FTP clients.

Adding SSL-based FTP Publishing by Editing the IIS 7.0 Configuration Files

You can also add SSL-based FTP publishing to an existing Web site by editing the IIS 7.0 configuration files.

Note: Editing your applicationHost.config file requires full administrative permissions. Use one of two methods:

If you are logged in using an account with administrative permissions that is not the local "administrator" account, open Notepad using the "Run as Administrator" option.

Note: One of the above steps is required because the User Account Control (UAC) security component in the Windows Vista and Windows Server 2008 operating systems prevents access to your applicationHost.config file. For more information about UAC, please see the following documentation:

http://go.microsoft.com/fwlink/?LinkId=113664

The following steps walk you through all of the required settings to add FTP publishing for the Default Web Site.

Step 1: Retrieve the Hash for your SSL Certificate:

In the Server Certificates feature, double-click your SSL certificate. For example, if you followed the optional step to create a self-signed certificate, you would double-click the certificate that is named "My FTP Certificate".
Click the Details tab.
Scroll through the fields until you locate the Thumbprint value.
Highlight the Thumbprint value, the data displays as:
"f0 1e d2 3c b4 5a 96 78 87 69 a5 4b c3 2d e1 0f f0 1e d2 3c"
Copy the hex data from the text box and paste it in the clipboard. Then, open Windows Notepad and paste the data into a blank document.

Note: You will use this information later.

Step 2: Add FTP to your Default Web Site

Using a text editor such as Windows Notepad, open your applicationHost.config file, which is located in your %SystemRoot%\System32\inetsrv\config folder by default.
Locate the section for your Default Web Site. It should resemble the following example:
```
 
     
 
 
     
 
```
Create a new binding element in the bindings collection. Set the value of the protocol attribute on the new binding element to contain "ftp", then change the port value of the bindingInformation attribute to contain "21". Your Default Web Site's settings should now resemble the following example:
```
 
     
 
 
     
     
 
```
Add an
section beneath the closing
tag that will contain your authentication and SSL settings. Note: The authentication settings for FTP sites are configured at the site-level, unlike authentication for Web sites, which can be configured per URL.
```
 
     
         
         
     
     
 
```
Copy and paste the thumbprint data from the SSL certificate into the serverCertHash attribute of the SSL element. Remove all the spaces from the thumbprint data. (Note: If you do not convert the hex data to uppercase, it will not show up in IIS Manager later.) Your Default Web Site settings should now contain something like the following example:
```
 
     
 
 
     
     
 
 
     
         
             
             
         
     
     
 
```
Scroll to the bottom of your applicationHost.config file and add a location section for your Default Web Site that will contain your authorization settings. Note: As shown in this example, the authorization settings for FTP sites are configured per URL.
```
 
     
         
             
         
     
 
```
Save your applicationHost.config file.

You should now be able to log in to your Default Web Site using an SSL-based FTP client.

Summary

In this task you added SSL-based FTP publishing to your Default Web Site by editing the IIS 7.0 configuration files. To recap the items that you completed in this task:

You added an FTP binding to the Default Web Site.
You enabled FTP basic authentication and disabled FTP anonymous authentication for the Default Web Site.
You configured the site to require SSL for all control channel and data channel activity.
You configured the administrator account for Read/Write permissions for the Default Web Site.

Configuring FTP Firewall Settings

2010-03-15T18:59:00.000-07:00

Introduction

This document walks you through configuring the firewall settings for the new FTP server. It contains:

Use the FTP Site Wizard to Create an FTP Site With Anonymous Authentication

In this section you, create a new FTP site that can be opened for Read-only access by anonymous users. To do so, use the following steps:

Go to the IIS 7.0 Manager. In the Connections pane, click the Sites node in the tree.
Right-click the Sites node in the tree and click Add FTP Site, or click Add FTP Site in the Actions pane.
When the Add FTP Site wizard appears:
- Enter "My New FTP Site" in the FTP site name box, then navigate to the "%SystemDrive%\inetpub\ftproot" folder that you created in the Prerequisites section. Note: If you choose to type in the path to your content folder, you can use environment variables in your paths.
- Click Next.
On the next page of the wizard:
- Choose an IP address for your FTP site from the IP Address drop-down, or choose to accept the default selection of "All Unassigned." Because you will be accessing this FTP site remotely, you want to make sure that you do not restrict access to the local server and enter the local loopback IP address for your computer by typing "127.0.0.1" in the IP Address box.
- You would normally enter the TCP/IP port for the FTP site in the Port box. For this walk-through, you will choose to accept the default port of 21.
- For this walkthrough, you do not use a host name, so make sure that the Virtual Host box is blank.
- Make sure that the Certificates drop-down is set to "Not Selected" and that the Allow SSL option is selected.
- Click Next.
On the next page of the wizard:
- Select Anonymous for the Authentication settings.
- For the Authorization settings, choose "Anonymous users" from the Allow access to drop-down. Select Read for the Permissions option.
- Click Finish.
Go to the IIS 7.0 Manager. Click the node for the FTP site that you created. The icons for all of the FTP features display.

Summary

To recap the items that you completed in this step:

You created a new FTP site named "My New FTP Site", with the site's content root at "%SystemDrive%\inetpub\ftproot".
You bound the FTP site to the local loopback address for your computer on port 21, choosing not to use Secure Sockets Layer (SSL) for the FTP site.
You created a default rule for the FTP site to allow anonymous users "Read" access to the files.

Step 1: Configure the Passive Port Range for the FTP Service

In this section, you configure the server-level port range for passive connections to the FTP service. Use the following steps:

Go to IIS 7.0 Manager. In the Connections pane, click the server-level node in the tree.
Double-click the FTP Firewall Support icon in the list of features.
Enter a range of values for the Data Channel Port Range.
Once you have entered the port range for your FTP service, click Apply in the Actions pane to save your configuration settings.

Notes:

The valid range for ports is 1024 through 65535. (Ports from 1 through 1023 are reserved for use by system services.)
You can enter a special port range of "0-0" to configure the FTP server to use the Windows TCP/IP dynamic port range.
For additional information, please see the following Microsoft Knowledge Base articles:
- 174904 - Information about TCP/IP port assignments
- 929851 - The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
This port range will need to be added to the allowed settings for your firewall server.

Step 2: Configure the external IPv4 Address for a Specific FTP Site

In this section, you configure the external IPv4 address for the specific FTP site that you created earlier. Use the following steps:

Go to IIS 7.0 Manager. In the Connections pane, click the FTP site that you created earlier in the tree, Double-click the FTP Firewall Support icon in the list of features.
Enter the IPv4 address of the external-facing address of your firewall server for the External IP Address of Firewall setting.
Once you have entered the external IPv4 address for your firewall server, click Apply in the Actions pane to save your configuration settings.

Summary

To recap the items that you completed in this step:

You configured the passive port range for your FTP service.
You configured the external IPv4 address for a specific FTP site.

(Optional) Step 3: Configure Windows Firewall Settings

Windows Server 2008 contains a built-in firewall service to help secure your server from network threats. If you choose to use the built-in Windows Firewall, you will need to configure your settings so that FTP traffic can pass through the firewall.

There are a few different configurations to consider when using the FTP service with the Windows Firewall - whether you will use active or passive FTP connections, and whether you will use unencrypted FTP or use FTP over SSL (FTPS). Each of these configurations are described below.

Note: You will need to make sure that you follow the steps in this section walkthrough while logged in as an administrator. This can be accomplished by one of the following methods:

Logging in to your server using the actual account named "Administrator".
Logging on using an account with administrator privileges and opening a command-prompt by right-clicking the Command Prompt menu item that is located in the Accessories menu for Windows programs and selecting "Run as administrator".

One of the above steps is required because the User Account Control (UAC) security component in the Windows Vista and Windows Server 2008 operating systems prevents administrator access to your firewall settings. For more information about UAC, please see the following documentation:

http://go.microsoft.com/fwlink/?LinkId=113664

Note: While Windows Firewall can be configured using the Windows Firewall applet in the Windows Control Panel, that utility does not have the required features to enable all of the features for FTP. The Windows Firewall with Advanced Security utility that is located under Administrative Tools in the Windows Control Panel has all of the required features to enable the FTP features, but in the interests of simplicity this walkthrough will describe how to use the command-line Netsh.exe utility to configure the Windows Firewall.

Using Windows Firewall with non-secure FTP traffic

To configure Windows Firewall to allow non-secure FTP traffic, use the following steps:

Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
To open port 21 on the firewall, type the following syntax then hit enter:
netsh advfirewall firewall add rule name="FTP (non-SSL)" action=allow protocol=TCP dir=in localport=21
To enable stateful FTP filtering that will dynamically open ports for data connections, type the following syntax then hit enter:
netsh advfirewall set global StatefulFtp enable

Important Notes:

Active FTP connections would not necessarily covered by the above rules; an outbound connection from port 20 would also need to be enabled on server. In addition, the FTP client machine would need to have its own firewall exceptions setup for inbound traffic.
FTP over SSL (FTPS) will not be covered by these rules; the SSL negotiation will most likely fail because the Windows Firewall filter for stateful FTP inspection will not be able to parse encrypted data. (Some 3rd-party firewall filters recognize the beginning of SSL negotiation, e.g. AUTH SSL or AUTH TLS commands, and return an error to prevent SSL negotiation from starting.)

Using Windows Firewall with secure FTP over SSL (FTPS) traffic

The stateful FTP packet inspection in Windows Firewall will most likely prevent SSL from working because Windows Firewall filter for stateful FTP inspection will not be able to parse the encrypted traffic that would establish the data connection. Because of this behavior, you will need to configure your Windows Firewall settings for FTP differently if you intend to use FTP over SSL (FTPS). The easiest way to configure Windows Firewall to allow FTPS traffic is to list the FTP service on the inbound exception list. The full service name is the "Microsoft FTP Service", and the short service name is "ftpsvc". (The FTP service is hosted in a generic service process host (Svchost.exe) so it is not possible to put it on the exception list though a program exception.)

To configure Windows Firewall to allow secure FTP over SSL (FTPS) traffic, use the following steps:

Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
To configure the firewall to allow the FTP service to listen on all ports that it opens, type the following syntax then hit enter:
netsh advfirewall firewall add rule name="FTP for IIS7" service=ftpsvc action=allow protocol=TCP dir=in
To disable stateful FTP filtering so that Windows Firewall will not block FTP traffic, type the following syntax then hit enter:
netsh advfirewall set global StatefulFtp disable

More Information about Working with Firewalls

It is often challenging to create firewall rules for FTP server to work correctly, and the root cause for this challenge lies in the FTP protocol architecture. Each FTP client requires two connections to be maintained between client and server:

FTP commands are transferred over a primary connection called the Control Channel, which is typically the well-known FTP port 21.
FTP data transfers, such as directory listings or file upload/download, require a secondary connection called Data Channel.

Opening port 21 in a firewall is an easy task, but this means that an FTP client will only be able to send commands, not transfer data. This means that the client will be able to use the Control Channel to successfully authenticate and create or delete directories, but the client will not be able to see directory listings or be able to upload/download files. This is because data connections for FTP server are not allowed to pass through the firewall until the Data Channel has been allowed through the firewall.

Note: This may appear confusing to an FTP client, because the client will seem to be able to successfully log in to the server, but the connection may appear to timeout or stop responding when attempting to retrieve a directory listing from the server.

The challenges of working with FTP and firewalls doesn't end with the requirement of a secondary data connection; to complicate things even more, there are actually two different ways on how to establish data connection:

Active Data Connections: In an active data connection, an FTP client sets up a port for data channel listening and the server initiates a connection to the port; this is typically from the server's port 20. Active data connections used to be the default way of connecting to FTP server; however, active data connections are no longer recommended because they do not work well in Internet scenarios.
Passive Data Connections: In a passive data connection, an FTP server sets up a port for data channel listening and the client initiates a connection to the port. Passive connections work much better in Internet scenarios and recommended by RFC 1579 (Firewall-Friendly FTP).

Note: Some FTP clients require explicit action to enable passive connections, and some clients don't even support passive connections. (One such example is command-line Ftp.exe utility that ships with Windows.) To add to the confusion, some clients attempt to intelligently alternate between the two modes when network errors happen, but unfortunately this does not always work.

Some firewalls try to remedy problems with data connections with built-in filters that scan FTP traffic and dynamically allow data connections through the firewall. These firewall filters are able to detect what ports are going to be used for data transfers and temporarily open them on firewall so that clients can open data connections. (Some firewalls may enable filtering FTP traffic by default, but it is not always the case.) This type of filtering is known as a type of Stateful Packet Inspection (SPI) or Stateful Inspection, meaning that the firewall is capable of intelligently determine the type of traffic and dynamically choose how to respond. Many firewalls now employ these features, including the built-in Windows Firewall.

For information regarding Microsoft's Windows Firewall software, please see the following topics on Microsoft's web sites:

How to map a drive in Windows

2010-03-15T18:57:00.001-07:00

Mapping drives is Windows is one of the essential actions everyone should know how to do. Whether you are at home or at the office, there comes a time in everyone’s life when they have to map a drive! It sounds all complicated, but it’s actually really simple to do.

You may need to get some information from your IT administrator at work, since mapping a drive usually means connecting to a server share. A server share is basically a folder on a different computer that is being shared with everyone else. So when you “map a drive”, you are just saying that you want access to that folder on your computer also, which is done by mapping it to a letter, i.e. F, G, H, etc.

In this article, I’ll explain how you can map a drive in Windows XP, Windows Vista, and even map a drive via the command prompt.

Map a drive in Windows XP

Open My Computer and click on the Tools menu option. From the drop down list, choose Map Network Drive.

Pick a drive letter that you want to use to access the shared folder and then type in the UNC path to the folder. UNC path is just a special format for pointing to a folder on another computer. You first use two slashes “\\” and then the computer name, \\testcomp and then another “\” followed by the shared folder name, \\testcomp\foldername.

Click on “Reconnect at logon” to make the connection permanent, which means the drive will still be mapped even after you restart the computer.

If you’re not sure what the name of the folder is, you can click on Browse and try to find the computer that way. Click on Entire Network, then Microsoft Windows Network and then expand out the workgroup or domain that your computer is in.

If there are any shared folders on a computer, you will be able to see them here by expanding each computer individually. Click Finish and you have now mapped a drive!

How to map a network drive in Vista

Mapping a network drive in Vista is slightly different than in XP, but pretty simple also. First, click on Computer from your Start Menu or Desktop. You’ll see a couple of buttons across the top, one of them being “Map network drive“.

Other than the fancy interface, all of the options are the same! Choose a drive letter, type in the folder path, choose “Reconnect at logon” and click Finish!

Remember, the folder can be located on a local or remote server or even to a FTP site!

How to map a drive using command prompt

First click on Start and then Run. Type cmd in the Open box.

Then type the following DOS command to map the network drive:

net use x: \\computer name\share name

where x: is the drive letter you want to assign to the shared folder.

You can delete a mapped network drive using the command prompt by typing in

net use x: /delete

If you have any problems mapping a drive in Windows, post a comment and I’ll try to help you out! Enjoy!

[tags]map network drives, map drives, map a drive, how to map a drive, how to map network drives[/tags]

How to setup an FTP server in Windows using IIS

2010-03-15T18:56:00.001-07:00

Earlier, I had written a post on how to turn your computer into a Windows file sharing server using a program called HFS. If you’re looking for a quick way to share the files on your local computer with friends or family, this is an easy way to do so.

However, if you’re looking to setup your own FTP server in Windows using IIS, you can do so, but it requires more technical knowledge. Of course, it also gives your more granular control over sharing and security, so it’s better for anyone who has a little computer know-how.

How to setup and configure an FTP server in IIS

The first thing you’ll need to setup your own FTP server in Windows is to make sure you have Internet Information Services (IIS) installed. Remember, this only comes with Windows XP Professional or Windows Vista Business or higher.

Click on Start, Control Panel and go to Add/Remove Programs. Then click on Add/Remove Windows Components.

In the components wizard, scroll down until you see IIS in the list and check it off. Before you click Next though, make sure you click on Details and then check off File Transfer Protocol (FTP) Service.

Click OK and then click Next. Windows will go ahead and install the necessary IIS files along with the FTP service. You may be asked to insert your Windows XP or Windows Vista disk at this point.

Setup and configure IIS for FTP

Once IIS has been installed, you may have to restart your computer. Now we want to go ahead and open the IIS configuration panel to setup our FTP server. So go to Start, then Control Panel and click on Administrative Tools. You should now see an icon for Internet Information Services.

When you open IIS for the first time, you’ll only see your computer name in the left hand menu. Go ahead and click the + symbol next to the computer name and you’ll see a couple of options like Web Sites, FTP Sites, etc. We’re interested in FTP Sites, so expand that out also. You should see Default FTP Site, click on it.

You’ll notice after you click on the default FTP site that there are a couple of buttons at the top that look like VCR buttons: Play, Stop, and Pause. If the Play button is greyed out, that means the FTP server is active. Your FTP server is now up and running! You can actually connect to it via your FTP client software. I use Smart FTP, but you can use whatever you like best.

Open your FTP client software and type in localhost as the host name and choose Anonymous for the login. Connect and you should now see an empty folder.

Ok, so that’s step 1! Now where the heck is this folder that you are currently viewing? Well the default FTP site is actually located in C:\Inetpub\ftproot. Open this directory and dump some files into it.

Now refresh on your FTP client and you should now see your files listed!

So you now have an up and running FTP server on your local computer. Before I show you how you can create separate folders that are stored in a different directory other than the default Inetpub folder, let’s first connect to our FTP server from another computer on the network.

In order to do this, you’ll have to open up the Windows Firewall to allow FTP connections to your computer, otherwise all external computers will be blocked. You can do this by going to Start, Control Panel and then clicking on Windows Firewall. Click on the Advanced Tab.

Under the Network Connection Settings section, make sure all of the connections are checked in the left list and then click on the Settings button. You’ll now be able to open certain ports on your computer based on the service your computer is providing. Since we are hosting our own FTP server, we want to check off FTP Server.

A little popup window will appear with some settings that you can change, just leave it as it is and click OK. Click OK again at the main Windows Firewall window. You have now opened up the firewall for FTP connections. Now try to connect to your FTP site from a different computer on your network. You’ll need to get the IP address of the computer first before you can connect into it from a different computer.

Go to Start, click Run and type in CMD. Type IPCONFIG and jot down the number for IP Address:

In your FTP client on the other computer, type in the IP Address you just wrote down and connect anonymously. You should now be able to see all of your files just like you did on the FTP client that was on the local computer.

Now that the FTP site is working, you can create as many folders as you like for FTP purposes. In this way, when a user connects, they specify a path that will connect to one specific folder.

Back in IIS, right click on Default FTP Site and choose New, and then Virtual Directory.

When you create a virtual directory in IIS, you’re basically going to create an alias that points to a folder on the local hard drive. So in the wizard, the first thing you’ll be asked is for a alias name. Make is something simple and useful like “WordDocs” or “FreeMovies”, etc.

Click Next and now browse to the path where you want the alias to refer to. So if you have a bunch of movies you want to share, browse to that folder.

Click Next and choose whether you want it as Read access only or Read and Write access. If you simply want to share files, check Read. If you want people to be able to upload files to your computer, choose Read and Write.

Click Next and then click Finish! Now you’ll see your new virtual directory below the default FTP site. You can connect to you using your FTP client by putting in the Path field “/Test” or “/NameOfFolder”.

Now you’ll only see the files that are in the folder we had browsed to.

And that’s about it! You can create as many folder as you like! The only thing other thing that you would need to do is to give out your public IP address to anyone who is connecting from outside of your internal network. If you want users to connect from anywhere in the world, you’ll have to give them your public IP address, which you can find out by going to http://whatismyipaddress.com/.

Finally, you’ll need to forward the FTP port on your router to your local computer that is hosting the FTP server. Port Forward is a great site to show you how to forward ports on your router to computers on your home network.

Any questions, post a comment! Enjoy!

[tags]setup ftp server, setup ftp server iis, setup windows FTP server, windows xp ftp server, configure ftp server, how to ftp server[/tags]

You cannot log on to Windows XP after you remove Wsaupdater.exe

2010-03-15T18:49:00.000-07:00

Use the Recovery Console to copy Userinit.exe to Wsaupdater.exe to allow logon capability to be restored and to let you manually correct the registry data. To do this, follow these steps:

Use Recovery Console to copy Userinit.exe to Wsaupdater.exe

At the Recovery Console command prompt, type cd system32, and then press ENTER.
Type copy userinit.exe wsaupdater.exe, and then press ENTER.
Type exit, and then press ENTER.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows

Back to the top

Modify the registry

Click Start, click Run, type regedit, and then click OK.
In Registry Editor, expand
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
.
In the right pane, right-click userinit, and then click Modify.
Replace wsaupdater.exe with userinit.exe, (make sure to include the comma, as shown), and then click OK.
Restart your computer.

Delete the Wsaupdater.exe file

Log on to the computer by using an account that has administrator-level permissions.
Click Start, click Run, type%Windir%\system32, and then click OK.
Right-click wsaupdater.exe, click Delete, and then click OK.

For additional information about the Windows Recovery Console, click the following article number to view the article in the Microsoft Knowledge Base:

Error message when non-administrator users who have been delegated control try to join computers to a Windows Server 2003-based or a Windows Server 28

2010-03-15T18:44:00.000-07:00

Users cannot join a computer to a domain

To resolve the issue in which users cannot join a computer to a domain, follow these steps:

Click Start, click Run, type dsa.msc, and then click OK.
In the task pane, expand the domain node.
Locate and right-click the OU that you want to modify, and then click Delegate Control.
In the Delegation of Control Wizard, click Next.
Click Add to add a specific user or a specific group to the Selected users and groups list, and then click Next.
In the Tasks to Delegate page, click Create a custom task to delegate, and then click Next.
Click Only the following objects in the folder, and then from the list, click to select the Computer objects check box. Then, select the check boxes below the list, Create selected objects in this folder and Delete selected objects in this folder.
Click Next.
In the Permissions list, click to select the following check boxes:
- Reset Password
- Read and write Account Restrictions
- Validated write to DNS host name
- Validated write to service principal name
Click Next, and then click Finish.
Close the "Active Directory Users and Computers" MMC snap-in.

Users cannot reset passwords

To resolve the issue in which users cannot reset passwords, follow these steps:

Click Start, click Run, type dsa.msc, and then click OK.
In the task pane, expand the domain node.
Locate and right-click Builtin, and then click Properties.
In the Builtin Properties dialog box, click the Security tab.
In the Group or user names list, click Account Operators.
Under Permissions for Account Operators, click to select the Allow check box for the Read permission, and then click OK.

Note If you want to use a group or a user other than the Account Operators group, repeat steps 5 and 6 for that group or that user.
Close the "Active Directory Users and Computers" MMC snap-in.

"The security log on this system is full" message when you try to log on to a computer that is running Windows XP or Windows Server 2003

2010-03-15T18:41:00.000-07:00

When you use an account that is not a member of the Administrators group to try to log on to a computer that is running Microsoft Windows Server 2003 or Microsoft Windows XP, you may receive the following message in the "Log On to Windows" window:

The security log on this system is full. Only administrators can log on to fix the problem.

You can log on to the computer by using an account that is a member of the Administrators group, such as the built-in Administrator account. However, if you log on to the computer remotely, you may receive the following message:The security log on this system is full
To resolve this issue, use an account that is a member of the Administrators group to log on to the computer. Then, follow these steps to specify that Security log events can be overwritten:

Click Start, point to All Programs, point to Administrative Tools, and then click Event Viewer.
Right-click Security, and then click Properties.
In the Log Size area of the Security Properties window, click the Overwrite events as needed option under When maximum log size is reached.
Click OK.
Close Event Viewer.

Task Manager has been disabled by your administrator" error message

2010-03-15T18:40:00.000-07:00

1. Verity that the "Local Group Policy" or "Domain Group Policy" doesn’t block you from using

"Task Manager".

1.1 "Local Group Policy"

a. Go to "Start" -> "Run" -> Write "Gpedit.msc" and press on "Enter" button.

b. Navigate to "User Configuration" -> "Administrative Templates" -> "System" -> "Ctrl+Alt+Del Options"

c. In the right side of the screen verity that "Remove Task Manager"" option set to "Disable" or "Not Configured".

d. Close "Gpedit.msc" MMC.

e. Go to "Start" -> "Run" -> Write "gpupdate /force" and press on "Enter" button.

Note: If you are using Windows 2000, please follow KB q227302 instead stage "e".

Using SECEDIT to Force a Group Policy Refresh Immediately
http://support.microsoft.com/kb/q227302/

1.2 "Domain Group Policy"

a. Contact you local IT support team.

2. Verity correct registry settings::

a. Go to "Start" -> "Run" -> Write "regedit" and press on "Enter" button.

Warning: Modifying your registry can cause serious problems that may require you to reinstall your operating system.
Always backup your files before doing this registry hack.

b. Navigate to the following registry keys and verity that following settings set to default:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System]
"DisableTaskMgr"=dword:00000000

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\LocalUser\Software\Microsoft\Windows\CurrentVersion\Policies\System]
"DisableTaskMgr"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\]
"DisableTaskMgr"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DisableCAD"=dword:00000000

c. Reboot the computer.

You cannot delete e-mail messages from your Inbox in Outlook 2000

2010-03-15T17:41:00.000-07:00

To resolve this behavior, use the Mdbvu32.exe utility to identify and to delete corrupted e-mail messages. The Mdbvu32.exe utility is an Extended MAPI message store viewer.

To manually remove corrupted e-mail messages by using the Mdbvu32.exe utility, follow these steps:

Insert the Microsoft Exchange 5.5 Server CD-ROM in your CD-ROM drive or DVD-ROM drive.
Start Microsoft Windows Explorer, and then open the drive:\Server\Support\Utils\I386 folder, where drive is the CD-ROM drive or the DVD-ROM drive that contains the Exchange 5.5 Server CD-ROM.
Copy the following files to the computer where you have Outlook 2000 installed:
- Mdbvu32.exe
- Propvu32.dll
- Statvu32.dll
- Tbvlu32.dll
- Xvport.dll
Verify the following information:
- That a profile exists for the user's mailbox.
- If that profile is selected as the default profile.
- That a user with the required permissions to the mailbox is successfully logged on to the client workstation.
Verify that Outlook 2000 is not currently running on your workstation.
Double-click Mdbvu32.exe to start the MDB Viewer Test Application.
In the MAPILogonEX (MAPI_LOGON_UI) dialog box, click OK.
Click the appropriate profile in the Profile Name box, and then click OK.
On the MDB menu, click OpenMessageStore.
Click the appropriate mailbox, and then click Open.
On the MDB menu, click Open Root Folder. After the Open Root Folder dialog box opens, follows these steps to delete the corrupted e-mail messages.
1. In the Child Folders box, double-click Search Root.
2. In the child folders pane of the MAPI_FOLDER – Top of Personal folders dialog box, double-click Inbox. The properties for the Inbox folder appear.
3. Locate the messages in folder pane in the MAPI_FOLDER - Inbox dialog box, and verify that the text that is in the Subject box of the e-mail message is not deleted or is not corrupted.
4. Select the e-mail messages that are corrupted in the messages in folder pane of the MAPI_FOLDER - Inbox dialog box.
5. In the MAPI_FOLDER - Inbox dialog box, click lpFldDeleteMessages() in the Operations available list, and then click Call Function.
6. In the MAPI_FOLDER – Inbox DeleteMessages() dialog box, click OK.
  
  Repeat step a through step f for each e-mail message that you want to delete.
7. To quit the Mdbvu32 utility, click Close in all the dialog boxes until the MDB Viewer Test Application window appears.
8. Click Store Logoff on the MDB menu in the MDB Viewer Test Application window.
In the LpMDB StoreLogoff() dialog box, click OK.
In the LOGOFF_COMPLETE dialog box, click OK.
Close the MDB Viewer Test Application window.

"Access Denied" Error Message During Active Directory Promotion of Replica Domain Controller

2010-03-15T17:39:00.000-07:00

To resolve this problem, use the appropriate method:

Verify that the current domain controllers in the domain have applied security policy and the Enable computer and users accounts to be trusted for delegation user right is granted to the Administrators Group in the domain controllers policy (click Computer Configuration, click Windows Settings, click Security Settings, click Local Policies, and then click User Rights Assignment).

For additional information about editing Group Policy Objects in Windows 2000, click the following article number to view the article in the Microsoft Knowledge Base:
322143 (http://support.microsoft.com/kb/322143/EN-US/ ) HOW TO: Administer GPOs in Windows 2000
For computers that do not have this right, confirm that group policy objects in the directory service and file system have replicated, and then manually apply the policy by typing the following command:
secedit /refreshpolicy machine_policy
NOTE: Look for the following message in the application log to confirm the application of the policy:
Event ID 1704: Security Policy in the Group policy objects are applied successfully.
Stop the Netlogon service on the source domain controllers that do not have this right applied to discover another domain controller in the domain that applied this right.
Verify that the source domain controller is in the organization unit. The name of the source domain controller can be found in the hidden file called Dcpromo.log in the %Systemroot%\debug folder on the Windows 2000 server that you are trying to promote.
Open a command prompt on the source domain controller, and run the Gpresult.exe Resource Kit utility to verify that the domain controllers policy is being applied to the source domain controller.

Error message when attempting to start the Windows Event Log Service: "Access denied"

2010-03-15T17:35:00.000-07:00

Restore the default permissions on %SystemRoot%\System32\winevt\logs.
Authenticated user - List folder/read data, Read attributes, Read Extended attributes, Read permissions
Administrators - Full control
SYSTEM - Full control
EventLog - Full control
Method1
To restore the default permissions on folder %SystemRoot%\System32\winevt\logs, follow these steps.

Right-click on %SystemRoot%\System32\winevt\logs and select Properties.
Select the Security tab.
Click Edit button and click the Add button in the permissions dialog box.
In Select users, computers, or Groups dialog box ensure that under object types Built in Security Principals and the location as local computer name is selected.
Enter the object name as "NT SERVICE\EventLog" without quotes. And click OK. This group should have full control on the folder.
Once EventLog group is added add the rest of the groups with above mentioned permissions.

Method 2

Identify a Windows Server 2008 machine with default permissions.

Click Start, and then type cmd in the Start Search box.
In the search results list, right-click Command Prompt, and then click Run as Administrator.
When you are prompted by User Account Control, click Continue.
Type the command CD %SystemRoot%\SYSTEM32.
Once the working directory is changed to %SystemRoot%\SYSTEM32 type the command icacls winevt\* /save acl /T.
This will save a file named ACL in %SystemRoot%\SYSTEM32. Copy this file to the C: drive on the problem computer.
On the problem computer, open command prompt with administrator privileges (refer to previous steps 1-3).
Change the working directory to %SystemRoot%\SYSTEM32.
Execute the command icacls winevt\ /restore acl.

Default permissions on the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Reliability should be:

CREATOR OWNER - Full control
SYSTEM - Full control
LOCAL SERVICE - Query Value, Set Value, Create Subkey, Notify and Delete
Administrators - Full control
Users - Read

To set the permission on this registry key:
1. Click the Start menu, select Run and type Regedit.
2. Go to the location HKLM\Software\Microsoft\Windows\CurrentVersion\Reliability.
3. From the Edit menu click Permissions.
4. Add the permissions for the accounts as listed above.

How to Install a DNS server in Windows Server 2008

2010-03-15T03:01:00.000-07:00

IT administrators who have little or no experience with Domain Name System (DNS), can learn to install, configure and troubleshoot a Windows Server 2008 DNS server.

As many of you are probably aware, the Domain Name System (DNS) is now the name resolution system of choice in Windows. Without it, computers would have a very tough time communicating with each other.

However, most Windows administrators still rely on the Windows Internet Name Service (WINS) for name resolution on local area networks and some have little or no experience with DNS. If you fall into this category, read on. We'll explain how to install, configure, and troubleshoot a Windows Server 2008 DNS server.

Installation
You can install a DNS server from the Control Panel or when promoting a member server to a domain controller (DC) (Figure A).

During the promotion, if a DNS server is not found, you will have the option of installing it.

Figure A

Domain controller

To install a DNS server from the Control Panel, follow these steps:

From the Start menu, select | Control Panel | Administrative Tools | Server Manager.
Expand and click Roles (Figure B).
Choose Add Roles and follow the wizard by selecting the DNS role (Figure C).
Click Install to install DNS in Windows Server 2008 (Figure D).

Figure B

Expand and click Roles

Figure C

DNS role

Figure D

Install DNS

DNS console and configuration
After installing DNS, you can find the DNS console from Start | All Programs | Administrative Tools | DNS. Windows 2008 provides a wizard to help configure DNS.

When configuring your DNS server, you must be familiar with the following concepts:

Forward lookup zone
Reverse lookup zone
Zone types

A forward lookup zone is simply a way to resolve host names to IP addresses. A reverse lookup zone allows a DNS server to discover the DNS name of the host. Basically, it is the exact opposite of a forward lookup zone. A reverse lookup zone is not required, but it is easy to configure and will allow for your Windows Server 2008 Server to have full DNS functionality.

When selecting a DNS zone type, you have the following options: Active Directory (AD) Integrated, Standard Primary, and Standard Secondary. AD Integrated stores the database information in AD and allows for secure updates to the database file. This option will appear only if AD is configured. If it is configured and you select this option, AD will store and replicate your zone files.

A Standard Primary zone stores the database in a text file. This text file can be shared with other DNS servers that store their information in a text file. Finally, a Standard Secondary zone simply creates a copy of the existing database from another DNS server. This is primarily used for load balancing.

To open the DNS server configuration tool:

Select DNS from the Administrative Tools folder to open the DNS console.
Highlight your computer name and choose Action | Configure a DNS Server' to launch the Configure DNS Server Wizard.
Click Next and choose to configure the following: forward lookup zone, forward and reverse lookup zone, root hints only (Figure E).
Click Next and then click Yes to create a forward lookup zone (Figure F).
Select the appropriate radio button to install the desired Zone Type (Figure G).
Click Next and type the name of the zone you are creating.
Click Next and then click Yes to create a reverse lookup zone.
Repeat Step 5.
Choose whether you want an IPv4 or IPv6 Reverse Lookup Zone (Figure H).
Click Next and enter the information to identify the reverse lookup zone (Figure I).
You can choose to create a new file or use an existing DNS file (Figure J).
On the Dynamic Update window, specify how DNS accepts secure, nonsecure, or no dynamic updates.
If you need to apply a DNS forwarder, you can apply it on the Forwarders window. (Figure K).
Click Finish (Figure L).

Figure E

Configure

Figure F

Forward lookup zone

Figure G

Desired zone

Figure H

IPv4 or IPv6

Figure I

Reverse lookup zone

Figure J

Choose new or existing DNS file

Figure K

Forwarders window

Figure L

Finish

Managing DNS records
You have now installed and configured your first DNS server, and you're ready to add records to the zone(s) you created. There are various types of DNS records available. Many of them you will never use. We'll be looking at these commonly used DNS records:

Start of Authority (SOA)
Name Servers
Host (A)
Pointer (PTR)
Canonical Name (CNAME) or Alias
Mail Exchange (MX)

Start of Authority (SOA) record
The Start of Authority (SOA) resource record is always first in any standard zone. The Start of Authority (SOA) tab allows you to make any adjustments necessary. You can change the primary server that holds the SOA record, and you can change the person responsible for managing the SOA. Finally, one of the most important features of Windows 2000 is that you can change your DNS server configuration without deleting your zones and having to re-create the wheel (Figure M).

Figure M

Change configuration

Name Servers
Name Servers specify all name servers for a particular domain. You set up all primary and secondary name servers through this record.

To create a Name Server, follow these steps:

Select DNS from the Administrative Tools folder to open the DNS console.
Expand the Forward Lookup Zone.
Right-click on the appropriate domain and choose Properties (Figure N).
Select the Name Servers tab and click Add.
Enter the appropriate FQDN Server name and IP address of the DNS server you want to add.

Figure N

Name Server

Host (A) records
A Host (A) record maps a host name to an IP address. These records help you easily identify another server in a forward lookup zone. Host records improve query performance in multiple-zone environments, and you can also create a Pointer (PTR) record at the same time. A PTR record resolves an IP address to a host name.

To create a Host record:

Select DNS from the Administrative Tools folder to open the DNS console.
Expand the Forward Lookup Zone and click on the folder representing your domain.
From the Action menu, select New Host.
Enter the Name and IP Address of the host you are creating (Figure O).
Select the Create Associated Pointer (PTR) Record check box if you want to create the PTR record at the same time. Otherwise, you can create it later.
Click the Add Host button.

Figure O

A Host (A) record

Pointer (PTR) records
A Pointer (PTR) record creates the appropriate entry in the reverse lookup zone for reverse queries. As you saw in Figure H, you have the option of creating a PTR record when creating a Host record. If you did not choose to create your PTR record at that time, you can do it at any point.

To create a PTR record:

Select DNS from the Administrative Tools folder to open the DNS console.
Choose the reverse lookup zone where you want your PTR record created.
From the Action menu, select New Pointer (Figure P).
Enter the Host IP Number and Host Name.
Click OK.

Figure P

New Pointer

Canonical Name (CNAME) or Alias records
A Canonical Name (CNAME) or Alias record allows a DNS server to have multiple names for a single host. For example, an Alias record can have several records that point to a single server in your environment. This is a common approach if you have both your Web server and your mail server running on the same machine.

To create a DNS Alias:

Select DNS from the Administrative Tools folder to open the DNS console.
Expand the Forward Lookup Zone and highlight the folder representing your domain.
From the Action menu, select New Alias.
Enter your Alias Name (Figure Q).
Enter the fully qualified domain name (FQDN).
Click OK.

Figure Q

Alias Name

Mail Exchange (MX) records
Mail Exchange records help you identify mail servers within a zone in your DNS database. With this feature, you can prioritize which mail servers will receive the highest priority. Creating MX records will help you keep track of the location of all of your mail servers.

To create a Mail Exchange (MX) record:

Select DNS from the Administrative Tools folder to open the DNS console.
Expand the Forward Lookup Zone and highlight the folder representing your domain.
From the Action menu, select New Mail Exchanger.
Enter the Host Or Domain (Figure R).
Enter the Mail Server and Mail Server Priority.
Click OK.

Figure R

Host or Domain

Other new records
You can create many other types of records. For a complete description, choose Action | Other New Records from the DNS console (Figure S). Select the record of your choice and view the description.

Figure S

Create records from the DNS console

Troubleshooting DNS servers
When troubleshooting DNS servers, the nslookup utility will become your best friend. This utility is easy to use and very versatile. It's a command-line utility that is included within Windows 2008. With nslookup, you can perform query testing of your DNS servers. This information is useful in troubleshooting name resolution problems and debugging other server-related problems. You can access nslookup (Figure T) right from the DNS console.

Figure T

How to Install and Configure Windows Server 2008 DHCP Server

2010-03-15T03:00:00.001-07:00

Introduction

Dynamic Host Configuration Protocol (DHCP) is a core infrastructure service on any network that provides IP addressing and DNS server information to PC clients and any other device. DHCP is used so that you do not have to statically assign IP addresses to every device on your network and manage the issues that static IP addressing can create. More and more, DHCP is being expanded to fit into new network services like the Windows Health Service and Network Access Protection (NAP). However, before you can use it for more advanced services, you need to first install it and configure the basics. Let’s learn how to do that.

Installing Windows Server 2008 DHCP Server

Installing Windows Server 2008 DCHP Server is easy. DHCP Server is now a “role” of Windows Server 2008 – not a windows component as it was in the past.

To do this, you will need a Windows Server 2008 system already installed and configured with a static IP address. You will need to know your network’s IP address range, the range of IP addresses you will want to hand out to your PC clients, your DNS server IP addresses, and your default gateway. Additionally, you will want to have a plan for all subnets involved, what scopes you will want to define, and what exclusions you will want to create.

To start the DHCP installation process, you can click Add Roles from the Initial Configuration Tasks window or from Server Manager à Roles à Add Roles.

Figure 1: Adding a new Role in Windows Server 2008

When the Add Roles Wizard comes up, you can click Next on that screen.

Next, select that you want to add the DHCP Server Role, and click Next.

Figure 2: Selecting the DHCP Server Role

If you do not have a static IP address assigned on your server, you will get a warning that you should not install DHCP with a dynamic IP address.

At this point, you will begin being prompted for IP network information, scope information, and DNS information. If you only want to install DHCP server with no configured scopes or settings, you can just click Next through these questions and proceed with the installation.

On the other hand, you can optionally configure your DHCP Server during this part of the installation.

In my case, I chose to take this opportunity to configure some basic IP settings and configure my first DHCP Scope.

I was shown my network connection binding and asked to verify it, like this:

Figure 3: Network connection binding

What the wizard is asking is, “what interface do you want to provide DHCP services on?” I took the default and clicked Next.

Next, I entered my Parent Domain, Primary DNS Server, and Alternate DNS Server (as you see below) and clicked Next.

Figure 4: Entering domain and DNS information

I opted NOT to use WINS on my network and I clicked Next.

Then, I was promoted to configure a DHCP scope for the new DHCP Server. I have opted to configure an IP address range of 192.168.1.50-100 to cover the 25+ PC Clients on my local network. To do this, I clicked Add to add a new scope. As you see below, I named the Scope WBC-Local, configured the starting and ending IP addresses of 192.168.1.50-192.168.1.100, subnet mask of 255.255.255.0, default gateway of 192.168.1.1, type of subnet (wired), and activated the scope.

Figure 5: Adding a new DHCP Scope

Back in the Add Scope screen, I clicked Next to add the new scope (once the DHCP Server is installed).

I chose to Disable DHCPv6 stateless mode for this server and clicked Next.

Then, I confirmed my DHCP Installation Selections (on the screen below) and clicked Install.

Figure 6: Confirm Installation Selections

After only a few seconds, the DHCP Server was installed and I saw the window, below:

Figure 7: Windows Server 2008 DHCP Server Installation succeeded

I clicked Close to close the installer window, then moved on to how to manage my new DHCP Server.

How to Manage your new Windows Server 2008 DHCP Server

Like the installation, managing Windows Server 2008 DHCP Server is also easy. Back in my Windows Server 2008 Server Manager, under Roles, I clicked on the new DHCP Server entry.

Figure 8: DHCP Server management in Server Manager

While I cannot manage the DHCP Server scopes and clients from here, what I can do is to manage what events, services, and resources are related to the DHCP Server installation. Thus, this is a good place to go to check the status of the DHCP Server and what events have happened around it.

However, to really configure the DHCP Server and see what clients have obtained IP addresses, I need to go to the DHCP Server MMC. To do this, I went to Start à Administrative Tools à DHCP Server, like this:

Figure 9: Starting the DHCP Server MMC

When expanded out, the MMC offers a lot of features. Here is what it looks like:

Figure 10: The Windows Server 2008 DHCP Server MMC

The DHCP Server MMC offers IPv4 & IPv6 DHCP Server info including all scopes, pools, leases, reservations, scope options, and server options.

If I go into the address pool and the scope options, I can see that the configuration we made when we installed the DHCP Server did, indeed, work. The scope IP address range is there, and so are the DNS Server & default gateway.

Figure 11: DHCP Server Address Pool

Figure 12: DHCP Server Scope Options

So how do we know that this really works if we do not test it? The answer is that we do not. Now, let’s test to make sure it works.

How do we test our Windows Server 2008 DHCP Server?

To test this, I have a Windows Vista PC Client on the same network segment as the Windows Server 2008 DHCP server. To be safe, I have no other devices on this network segment.

I did an IPCONFIG /RELEASE then an IPCONFIG /RENEW and verified that I received an IP address from the new DHCP server, as you can see below:

Figure 13: Vista client received IP address from new DHCP Server

Also, I went to my Windows 2008 Server and verified that the new Vista client was listed as a client on the DHCP server. This did indeed check out, as you can see below:

Figure 14: Win 2008 DHCP Server has the Vista client listed under Address Leases

DHCP Server Security (Part 2)

2010-03-15T02:55:00.000-07:00

In Part 1 of this two-part article we looked at the different types of threats faced by DHCP servers and outlined some general countermeasures for mitigating these threats. Part 2 continues with a list of practical steps administrators can follow and tools they can use to help secure their Windows 2000 and Windows Server 2003 DHCP servers.

As we discussed earlier in Part 1 of this article, DHCP is inherently insecure and your first line of defense for protecting yourself from rogue DHCP servers and clients is rigorous physical security for your network. Fortunately Windows 2000 and Windows Server 2003 do support some features you can use to enhance DHCP security, and there are some tools you can use to detect rogue DHCP servers on your network so you can eliminate them. Let's look at each of these features and tools now.

DHCP Server Auditing

Auditing the DHCP database on your DHCP servers lets you determine which DHCP clients on your network are leasing addresses from your server. Auditing also lets you look for BAD_ADDRESS entries in the database and see where they originate, and this is important because such entries can indicate address conflicts arising when rogue DHCP servers assign addresses that are already in use. Such address conflicts can also arise if a rogue client has a static address that is within the scope of a legitimate DHCP server, or when you accidentally configure two DHCP servers to have overlapping scopes. Whatever the cause, BAD_ADDRESS entries indicate some kind of problem, whether misconfiguration or a security hole, that needs to be addressed.

To enable auditing on your DHCP servers, open the DHCP console and connect to a DHCP server on your network. Then right-click on the server node and select Properties, and on the General tab make sure the checkbox labeled "Enable DHCP audit logging" is enabled:

Figure 1: Enabling DHCP audit logging

DHCP audit logs are stored by default in the %windir%\system32\dhcp directory, but this can be changed using the Advanced tab of the DHCP server's properties sheet. DHCP audit logs are created or appended on a daily basis and are named DhcpSrvLog-Mon.log, DhcpSrvLog-Tue.log, and so on. Each log entry begins with an event ID, and the header of the log contains a list of possible event IDs together with an explanation of each one. Further configuration can be performed using the HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters key in the Registry where the following keys control how DHCP logging works:

DhcpLogFilesMaxSize specifies a maximum file size for all DHCP log files (default is 7 MB)
DhcpLogDiskSpaceCheckInterval specifies how frequently DHCP checks disk space usage (default is every 50 minutes)
DhcpLogMinSpaceOnDisk specifies the free space threshold below which logging becomes temporarily disabled (default is 20 MB)

DHCP Administrators Group

While members of the Domain Admins group obviously have full power to configure DHCP on the server, you can also delegate limited power to users whose job is to manage DHCP servers on your network. To do this, open Active Directory Users and Computers and add the name of the user to the DHCP Administrators domain local group:

Figure 2: Adding user Bob Smith to the DHCP Administrators group

This gives the user the ability to manage DHCP servers on your network without giving him any unnecessary authority to perform other administrative tasks, which is an example of the well-known security best practice of least privilege. The problem however is, how do you monitor membership in the DHCP Administrators group to make sure no unauthorized users are accidentally (or maliciously) added to the group?

You can monitor membership of critical groups like DHCP Administrators using the Restricted Groups feature of Group Policy. To do this, first use Active Directory Users and Computers to open your Default Domain Policy (or some other GPO if the computer accounts for your DHCP servers were placed in some OU in your domain) and navigate to Computer Configuration\Windows Settings\Security Settings\Restricted Groups:

Figure 3: Restricted Groups

Now right-click on the Restricted Groups node and select Add Group, and specify DHCP Administrators as the group whose membership you want to monitor:

Figure 4: Monitor membership in the DHCP Administrators group

Click OK and use the Add button in the next properties sheet to specify which users are allowed to be members of this group. Note that even if the group already has members in it, you still have to perform this step and identify them again:

Figure 5: Bob Smith is the only user allowed to be a member of the DHCP Administrators group

Now click OK and membership in the DHCP Administrators group is restricted to only Bob Smith as desired:

Figure 6: Membership in DHCP Administrators has been restricted to Bob Smith

What happens now is that when Group Policy refreshes on your domain controllers (typically every 5 minutes) membership in the DHCP Administrators group is checked, and if by accident (or malicious intent) some other user like Mary Smith has been added to the group then she will automatically be removed and an ID 637 event will be logged to the Security log if you have auditing of account management events enabled. Membership in the DHCP Administrators group is thus monitored and controlled as desired.

NOTE: Windows 2000 also includes another group called DHCP Users which can be used to grant users read-only access to the DHCP console, and membership in this group can be similarly controlled using Restricted Groups.

DNSUpdateProxy Group

On Windows-based networks, DHCP and DNS can work together to simplify the configuration and operation of your network. Normally what happens is a DHCP client register its A (host) record directly with the DNS server, while the PTR (pointer) record is instead registered on behalf of the client by the DHCP server. This means an attack on a DHCP server could compromise control over records registered with your DNS server and be used to redirect traffic to a hostile site or cause denial of service. If you make a DHCP server a member of the DNSUpdateProxy group however, your DHCP server will not take ownership of any resource records it registers on behalf of clients. This approach is typically used when upgrading from Windows NT to ensure downlevel clients that do not support DDNS can take ownership of their own resource records when they are upgraded to Windows 2000 or Windows XP.

The point is that you should only add the computer accounts for your DHCP server to the DNSUpdateProxy group if you are going to be upgrading pre-Windows 2000 computers to Windows 2000 or Windows XP. And you should never add your DHCP server to this DNSUpdateProxy group if your DHCP server is running on a domain controller.

Detecting Rogue DHCP Servers

Finally, there are a few tools you can use to detect the presence of rogue DHCP servers on your network so you can get rid of them. These include both tools from Microsoft and from third-party sources, and we'll end by examining two of these tools.

Dhcploc.exe

Dhcploc.exe is a command-line tool that is part of the Windows Support Tools found in the \Support\Tools folder on your Windows XP product CD and it can be used to display all DHCP servers that are active on the local subnet. Dhcploc.exe has been around since Windows NT 4.0 and it works by sending out DHCPREQUEST messages and displaying the IP addresses of the DHCP servers that responded with DHCPACK. You can find the syntax of this tool in the Help file that is installed when you install the Support Tools on your machine.

dhcp_probe

The Network Systems Group at Princeton University's Office of Information Technology has developed a tool called dhcp_probe that tries to discover DHCP and BOOTP servers on a directly-attached Ethernet network. The existing build runs on Solaris 8 on SPARC with gcc and there is patch for it to work on Linux also, so if you have either of those platforms you can try using this tool to detect any rogue DHCP servers that might be running on your network. You can find the Network Systems Group's tools page here and can download dhcp_probe directly from here.

Summary

In this article and the previous one I've examined why DHCP is intrinsically an insecure protocol and what you can do to secure it on Windows-based networks. Even if you implement the best practices I've suggested for securing DHCP, review your DHCP audit logs regularly, run Dhcploc.exe or other tools regularly to locate rogue servers, restrict membership in the DHCP Administrators group, and make judicious use of the DNSUpdateProxy group, it's pretty clear that DHCP still remains a weak point in your network's overall security landscape. What does the future hold then for DHCP security?

Since 2003 the Internet Engineering Task Force (IETF) is working on this problem, and is working on a proposed standard, RFC 3118 Authentication for DHCP Messages. This RFC suggests a couple of extensions for DHCP to provide for authentication of DHCP messages on your network using either a token-based exchange of messages or a shared symmetric key. The problem with these extensions however is that they require some additional initial configuration of the DHCP client, and the whole point of why DHCP was developed in the first place was to get away from having to pre-configure clients before they can participate on the network. So this solution would probably only be acceptable to enterprises if vendors could pre-configure machines at the factory level, and so far no vendors have taken on the task of implementing this solution.

On the other hand, IPv6 may offer a simpler solution to the problem of DHCP security. Since IPv6 is designed with end-to-end security from the ground up, it can protect DHCP traffic and make it more difficult for attackers to spoof DHCP messages or hijack DHCP traffic. Since the U.S. Department of Defense (DoD) is mandating use of IPv6 on all their networks in the near future, vendors are scrambling to make their hardware and software support IPv6 and this may drive enterprise adoption for IPv6 sooner than previously anticipated. When that happens, network security experts will probably have to revisit the whole question of DHCP security all over again and develop tools and best practices to ensure 21st century networks remain secure in an increasingly hostile cyberworld.

DHCP Server Security (Part 1)

2010-03-15T02:54:00.000-07:00

Part 1 of this two-part article looks at the different types of threats faced by DHCP servers and countermeasures for mitigating these threats. Part 2 will continue the discussion with a list of practical steps administrators can follow and tools they can use to help secure their Windows 2000 and Windows Server 2003 DHCP servers.

Although DHCP servers are critical to the operation of most enterprise networks, DHCP server security is often one of the most overlooked areas of network security. One reason for this might be the simplicity of how DHCP works: DHCP clients broadcast discovery messages (DHCPDISCOVER) containing their MAC addresses and DHCP servers respond by offering (DHCPOFFER) to lease an IP address and other TCP/IP settings that the client can use to communicate on the network. The client responds (DHCPREQUEST) to the first lease offer it receives and the server acknowledges (DHCPACK) the request and marks the address as leased in its DHCP database. That's all there is to it—who needs to worry about security?

Attacking DHCP

Unfortunately it's the very simplicity of DHCP that's actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.

For example, a rogue DHCP server could provide legitimate clients with bogus TCP/IP information that prevents the clients from communicating on the network. A denial of service (DoS) condition then results, and users are unable to connect to network resources to perform their work. Setting up a rogue DHCP server could be as simple as conducting a social engineering attack to gain physical access to your network and plugging in a laptop configured as a DHCP server.

Another scenario might involve an attacker compromising a client computer on your network and installing software that repeatedly requests new IP addresses using spoofed MAC addresses until the entire pool of addresses in your DHCP server's scope is leased. When this happens, legitimate clients that boot onto the network can't acquire an address and again users are unable to access the network and can't do their work.

A more sinister result happens when an attacker breaches network security and gains control of your own DHCP servers. At that point the attacker might proceed to modify the DHCP server to assign clients an incorrect subnet setting and thus create another DoS condition. Or they might modify the server to assign clients incorrect DNS settings and redirect clients to rogue or hijacked DNS servers, which could then redirect clients to hostile websites where they unknowingly download a trojan. Or they could modify the server to assign the address of the attacker's own machine as default gateway, which results in outbound client traffic being redirected to the attacker's machine which captures and reads the traffic and forwards it to the real default gateway. The result is exposure of sensitive business information without users even being aware of what's happening.

Worse yet, if you're running your DHCP server on a domain controller then an attacker who compromises your DHCP server gains access to your accounts database and can cause all sorts of further problems. The result is usually your worst nightmare. Fortunately, there are some measures you can take to protect your DHCP servers and avoid many of these scenarios, provided you're also following all the usual best practices for securing Windows-based networks. Let's look at some specific threats to DHCP on your network and the countermeasures you can take to mitigate these different threats.

Threats and Countermeasures

On the face of it, the requirement that Windows 2000 and Windows Server 2003 DHCP servers be authorized in Active Directory before they can start leasing addresses to requesting clients seems to mitigate the threat of rogue DHCP servers on your network. Authorization means that when a Windows 2000 or Windows Server 2003 DHCP server boots onto an Active Directory network it first contacts a domain controller to check if its own IP address is found on the list of authorized DHCP servers maintained by the domain controller. If the DHCP server determines that it is authorized to lease addresses to clients, it begins to do so. If it's not authorized, Windows shuts down the DHCP Server service on the machine so it won't be able to lease addresses.

The real benefit of this is to protect your network against legitimate DHCP servers that are badly configured, though it has the added side effect of guarding against accidental or rogue DHCP servers running Windows 2000 or Windows Server 2003. What happens though if an attacker compromises your network with a rogue DHCP server not running Windows 2000 or Windows Server 2003? In this case authorization won't help because non-Microsoft DHCP servers may not respond the same way as Microsoft ones to the DHCPINFORM messages Windows uses to check if DHCP servers are authorized. Even Windows NT DHCP servers fall under this category, so an attacker with a laptop running Windows NT as a rogue DHCP server gets away scott free. Fortunately there are other ways to detect rogue DHCP servers and we'll look at these in Part 2 of this article later. But making sure your DHCP servers are properly authorized is still an important first step in deterring rogue servers on your network.

Rogue clients is another problem entirely though, as DHCP is designed to make it easy for clients to obtain IP addresses so they can participate on a network. The obvious way of dealing with the problem of rogue clients would seem at first to be DHCP reservation, though on large networks this entails considerable administrative overhead. A reservation is a predefined setting that maps a MAC address to an IP address so that only a client with a particular MAC address can lease the IP address associated with that reservation. If security is critical an administrator could create reservations for each and every client machine on the network, and if unreserved IP addresses still remain in the DHCP server's cope then these could be reserved using invalid or non-existing MAC addresses. Then when a rogue client tries to boot on the network the result is that the DHCP server has no free addresses to lease and the client can't connect.

If only it were that simple. While this approach might foil a casual attack, sophisticated attackers have ways for circumventing DHCP reservations. The simplest approach is for the attacker to run a program that listens for DHCPDISCOVER broadcasts from clients and harvests their MAC addresses. Then when a legitimate client shuts down the rogue client can reconfigure its MAC address to match that of the legitimate client and hijack the legitimate client's lease or try to disrupt communications for the client. Considering this, security-conscious administrators might consider dropping DHCP entirely in favor of static addressing, but what's to stop an attacker who has physical access to your network from assigning a static address to their own machine and joining the network? One might go further and install a firewall on every client on your network and configure it to only allow communications with allowed IP addresses of legitimate clients, but imagine the administrative headache that would involve. So the bottom line is that the only way to really protect your network against rogue DHCP clients (and also rogue DHCP servers) is rigorous physical security i.e. no unsecured wall jacks, locked doors, staff trained to recognize social engineering attempts, and so on.

Even if your network is physically secure however, it also needs to be secure from a network entry point of view. If an attacker can penetrate your perimeter defenses and somehow compromise a DHCP server, then several kinds of exploits could be attempted including modification of DNS resource records when Dynamic DNS (DDNS) is being used, corrupting the DHCP database, and gaining access to sensitive information such as the details of your network's addressing scheme and reserved addresses of critical servers. Basic security best practices like perimeter firewalls and intrusion monitoring are clearly your front line in preventing your DHCP servers from being compromised, but there are also some DHCP-specific monitoring procedures you can follow which we'll look at in Part 2 of this article later.

Summary

Let's look at our list so far of best practices for ensuring DHCP security on your network. We'll add to this list further in Part 2 with some specific steps you can follow on Windows-based networks, but for now be sure to start at least with the following if you want to protect your network against DHCP exploits:

Implement rigorous physical and perimeter security for your network and be vigilant in maintaining such security.
Upgrade any lingering Windows NT domains so you can make use of the DHCP server authorization feature of Active Directory.
Avoid using Windows 2000 or Windows Server 2003 domain controllers as DHCP servers.
Use reservations for assigning addresses of critical servers on your network, or use static addresses for them instead.

In Part 2 of this article we'll continue by discussing how to enable auditing on DHCP servers, monitor membership in the DHCPAdministrators group using the Restricted Groups feature of Windows Server 2003, en

Setting up a DHCP Server

2010-03-15T02:47:00.001-07:00

his will serve as a step-by-step guide on how to setup a DHCP server.

Installing the DHCP server is made quite easy in Windows 2003. By using the "Manage your server" wizard, you are able to enter the details you require and have the wizard set the basics for you. Open to "Manage your server" wizard, select the DHCP server option for the list of server roles and press Next.
You will be asked to enter the name and description of your scope.

Scope: A scope is a collection of IP addresses for computers on a subnet that use DHCP.

The next window will ask you to define the range of addresses that the scope will distribute across the network and the subnet mask for the IP address. Enter the appropriate details and click next.

You are shown a window in which you must add any exclusions to the range of IP addresses you specified in the previous window. If for example, the IP address 10.0.0.150 is that of the company router then you won't want the DHCP server to be able to distribute that address as well. In this example I have excluded a range of IP addresses, 10.0.0.100 to 10.0.0.110, and a single address, 10.0.0.150. In this case, eleven IP's will be reserved and not distributed amongst the network clients.

It is now time to set the lease duration for how long a client can use an IP address assigned to it from this scope. It is recommended to add longer leases for a fixed network (in the office for example) and shorter leases for remote connections or laptop computers. In this example I have set a lease duration of twelve hours since the network clients would be a fixed desktop computer in a local office and the usual working time is eight hours.

You are given a choice of whether or not you wish to configure the DHCP options for the scope now or later. If you choose Yes then the upcoming screenshots will be of use to you. Choosing No will allow you to configure these options at a later stage.

The router, or gateway, IP address may be entered in next. The client computers will then know which router to use.

In the following window, the DNS and domain name settings can be entered. The DNS server IP address will be distributed by the DHCP server and given to the client.

If you have WINS setup then here is where to enter the IP Address of the WINS server. You can just input the server name into the appropriate box and press "Resolve" to allow it to find the IP address itself.

The last step is to activate the scope - just press next when you see the window below. The DHCP server will not work unless you do this.

The DHCP server has now been installed with the basic settings in place. The next stage is to configure it to the needs of your network structure.

Configuring a DHCP server

Hereunder is a simple explanation of how to configure a DHCP server.

The address pool displays a list of IP ranges assigned for distribution and IP address exclusions. You are able to add an exclusion by right clicking the address pool text on the left hand side of the mmc window and selecting "new exclusion range". This will bring up a window (as seen below) which will allow you to enter an address range to be added. Entering only the start IP will add a single IP address.

DHCP servers permit you to reserve an IP address for a client. This means that the specific network client will have the same IP for as long as you wanted it to. To do this you will have to know the physical address (MAC) of each network card. Enter the reservation name, desired IP address, MAC address and description - choose whether you want to support DHCP or BOOTP and press add. The new reservation will be added to the list. As an example, I have reserved an IP address (10.0.0.115) for a client computer called Andrew.

If you right click scope options and press "configure options" you will be taken to a window in which you can configure more servers and their parameters. These settings will be distributed by the DHCP server along with the IP address. Server options act as a default for all the scopes in the DHCP server. However, scope options take preference over server options.

In my opinion, the DHCP server in Windows 2003 is excellent! It has been improved from the Windows 2000 version and is classified as essential for large networks. Imagine having to configure each and every client manually - it would take up a lot of time and require far more troubleshooting if a problem was to arise. Before touching any settings related to DHCP, it is best to make a plan of your network and think about the range of IPs to use for the computers.

DHCP Database in Windows Server 2003

2010-03-15T02:44:00.000-07:00

DHCP - Display Statistics

Bizarrely, I find 'Display Statistics' the most difficult tab to find on the DHCP server. This is because it's the first item on the menu, and is often masked by the very highlight that should attract me. I just hope that you are not afflicted by this blind spot. In any event, Display Statistics is one of the most interesting and rewarding items on the DHCP menu.

Display Statistics is available at both the server and the scope level. My first thought is, 'How many leases are left?' Next, I look to see if there have been any NACKS or lease declines. See the screen shot to find the Display Statistics... menu.

DHCP Database

DHCP has its own database. Stored in this DHCP.mdb are the addresses, scopes and leases of the clients. Understanding this database will help you backing up and restore a DHCP server.

Check out this folder: %systemroot%\system32\dhcp\dhcp.mdb

As time goes by the database will grow, and best practice dictates that you should consolidate the database by freeing up space taken up by old leases.

The procedure for compacting the dhcp.mdb database is this.

1) Stop the DHCP service. Either right click the DHCP Server icon, select All tasks then Stop. Alternatively, go to the command line and type: NET Stop DHCPServer. (For once the command really is DHCPserver, NOT DHCPyourservername.)

2) At the command line, navigate to: %systemroot%\system32\dhcp\dhcp.mdb.

3) Jetpack dhcp.mdb temp.mdb. What this does is copies the existing database, compacts it, then copies it back to the original location - clever.

4) Remember to restart DHCP. Either use the GUI, or if you are at the command line, NET Start DHCPServer

Warning: Do not 'mess' with any of the files that you find in the %systemroot%\system32\dhcp folder, if you do, then DHCP will stop working and you will either have to restore, or else re-install DHCP.

Backing up the DHCP Database

The first surprise is that this dhcp.mdb database is backed up every hour.

The second surprise is that the old jetpack database engine controls the database.

The third surprise is that you can only automatically backup to a local folder. Should you need a 'real' backup, then just backup the files in the %systemroot%\system32\dhcp\Backup\ directory.

Finally, and unsurprisingly, there is a GUI to backup the DHCP database.

Reconcile

Reconcile is a technical term for making sure that DHCP information is consistent. What can happen is that when you restore a database, there is a miss-match between lease information in the database and the same information in the DHCP server's registry. Specifically, the registry just stores basic or summary information, the detailed information from a recent restore maybe different, so a 'Reconcile' will ensure that the database and registry data are consistent once more.

Bear in mind that you can either reconcile individual scopes or choose all scopes. It all depends on the 'focus' of what you select. If you select an individual scope that that is the limit of what you can reconcile, however, when you select the server icon, you can: Reconcile All Scopes - see diagram above. (not below)

DHCP Audit Log

Once you setup DHCP auditing, you get a separate log for each day of the week. The logs are a wealth of information, not just about the health of the server, but also which machine gets which IP address for how long.

To setup Auditing, right click the DHCP server, then select properties.

Auditing removes the last reason for having static IP addresses, accountability. Die-hards, Luddites who resist DHCP often justify static IP addresses on the grounds that you can always account for which machine had which IP address on a particular day. With DHCP Auditing you can achieve the same result and have all the benefits of central administration, instant control over default gateways and a raft of other options.

How to move a DHCP database from a computer that is running Windows NT Server 4.0, Windows 2000, or Windows Server 2003 to a computer that is running

2010-03-15T02:42:00.000-07:00

This step-by-step article describes how to move a Dynamic Host Configuration Protocol (DHCP) database from a computer that is running Microsoft Windows NT Server 4.0, Microsoft Windows 2000, or Microsoft Windows Server 2003 to a computer that is running Windows Server 2003.

Note You can use the Microsoft Windows backup utility (ntbackup.exe) to back up and restore the DHCP database on a single server. Do not use the backup utility to migrate or to move a DHCP database from one DHCP server to another.

Back to the top

Export the DHCP database from a server that is running Windows NT Server 4.0 or Windows 2000

Stop the DHCP Server service on the server:
1. Log on to the source DHCP server by using an account that is a member of the local Administrators group.
2. Click Start, click Run, type cmd in the Open box, and then click OK.
3. At the command prompt, type net stop dhcpserver, and then press ENTER. You receive a "The Microsoft DHCP Server service is stopping. The Microsoft DHCP Server service was stopped successfully" message.
4. Type exit, and then press ENTER.
Compact the DHCP database by using the JetPack utility:
1. Click Start, click Run, type cmd in the Open box, and then click OK.
2. At the command prompt, type cd %systemroot%\system32\dhcp, and then press ENTER.
3. Type jetpack dhcp.mdb temp.mdb, and then press ENTER.
4. After the database is compacted successfully, type exit, and then press ENTER.
Export the DHCP database by using the DHCP Export Import utility (Dhcpexim.exe). You can obtain this utility from the Windows 2000 Resource Kit Supplement 1. You can also visit the following Microsoft Web site to obtain Dhcpexim.exe:
http://support.microsoft.com/kb/927229 (http://support.microsoft.com/kb/927229)
To export the database:
1. Install the Dhcpexim.exe utility, and then start the Dhcpexim.exe utility.
2. At the Welcome to DHCP Export Import tool screen, click Export configuration of the local service to a file, and then click Ok.
3. In the File name box, type the file name for the exported file, and then click Save. For example, type dhcpdatabase.txt.
4. Click the scope or scopes that you want to export, click to select the Disable the selected scopes on local machine before export check box, and then click Export.
5. Click OK.
Disable the DHCP Server service on the server. Disabling the DHCP Server service prevents the service from starting after the database has been transferred. To disable the DHCP Server service:
1. Click Start, point to Settings, click Control Panel, and then double-click Services.
2. In the Service list, click Microsoft DHCP Server, click Startup, click Disabled, and then click OK.
3. If the service is started, click Stop, and then click Yes to confirm the stopping of the service.
4. Click Close to close the Services dialog box.

Important Dhcpexim.exe is required to move the database successfully from a server that is running Windows 2000 or Windows NT 4.0 to a server that is running Windows Server 2003. Netsh commands for DHCP are not available in Windows NT 4.0.

Note If only the configuration (not the database) is required, use the following command (instead of Dhcpexim.exe) on the Windows 2000-based server that you want to export from. (Do not use Dhcpexim.exe.)

netsh dhcp dump >C:\dhcp.txt

where C:\dhcp.txt is the name and path of the export file that you want to use.

Note The export option does not exist in the netsh command on Windows 2000 Server. The netsh dhcp server dump and netsh dhcp server import commands are not compatible. If you try to import the data that is created by netsh dhcp server dump > C:\dhcp.txt by using netsh DHCP server import > C:\dhcp.txt, you receive the following error message on the Windows Server 2003-based computer:

The request is not supported.

You can migrate the exported configuration file to the new Windows Server 2003 server by using the following command:

netsh exec c:\dhcp.txt

Dhcpexim.exe is not supported in Windows Server 2003. If a database is exported on a Windows 2000-based computer by using Dhcpexim.exe, and you try to import the data to Windows Server 2003, Dhcpexim.exe quits, and you receive the following error message:

An error occurred. An attempt was made to load a program with a incorrect format.

If this behavior occurs, export data from Windows 2000 by using dhcpexim and then import the data on the Windows Server 2003 environment by using netsh DHCP server import xyz.txt.

Back to the top

Export the DHCP database from a server that is running Microsoft Windows Server 2003

To move a DHCP database and configuration from a server that is running Windows Server 2003 to another server that is running Windows Server 2003:

Log on to the source DHCP server by using an account that is a member of the local Administrators group.
Click Start, click Run, type cmd in the Open box, and then click OK.
Type netsh dhcp server export C:\dhcp.txt all, and then press ENTER.

Note You must have local administrator permissions to export the data.

Back to the top

Install the DHCP server service on the server that is running Windows Server 2003

To install the DHCP Server service on an existing Windows Server 2003-based computer:

Click Start, click Control Panel, and then double-click Add or Remove Programs.
Click Add/Remove Windows Components.
In the Windows Component Wizard, click Networking Services in the Components box, and then click Details.
Click to select the Dynamic Host Configuration Protocol (DHCP) check box if it is not already selected, and then click OK.
In the Windows Components Wizard, click Next to install the selected components. Insert the Windows Server 2003 CD into your computer CD drive or DVD drive if you are prompted to do this. Setup copies the DHCP server and tool files to your computer.
When Setup is complete, click Finish.

Back to the top

Import the DHCP database

Note You may receive an "access denied" message during this procedure if you are not a member of the Backup Operators group. If you receive an "Unable to determine the DHCP server version for server" error message, make sure that the DHCP Server service is running on the server and that the user logged on is a member of the local Administrators group.

Important Do not use Dhcpexim.exe to import a DHCP database in Windows Server 2003. Additionally, if the target Windows 2003 server is a member server, and if you plan to promote it to a domain controller, we suggested that you perform the DHCP database migration before promoting it to a domain controller. Although you can migrate the DHCP database to a Windows 2003 domain controller, the migration to a member server will be easier because of the existence of the local administrator account.

Log on as a user who is an explicit member of the local Administrators group. A user account in a group that is a member of the local Administrators group will not work. If a local Administrators account does not exist for the domain controller, restart the computer in Directory Services Restore Mode, and use the administrator account to import the database as described later in this section.
Copy the exported DHCP database file to the local hard disk of the Windows Server 2003-based computer.
Verify that the DHCP service is started on the Windows Server 2003-based computer.
Click Start, click Run, type cmd in the Open box, and then click OK.
At the command prompt, type netsh dhcp server import c:\dhcpdatabase.txt all, and then press ENTER, where c:\dhcpdatabase.txt is the full path and file name of the database file that you copied to the server.

Note When you try to export a DHCP database from a Windows 2000 domain controller to a Windows Server 2003 member server of the domain, you may receive the following error message:
Error initializing and reading the service configuration - Access Denied
Note You must have local administrator permissions to import the data.
To resolve this issue, add the Windows Server 2003 DHCP server computer to the DHCP Admins group at the Enterprise level.
If the "access is denied" error message occurs after you add the Windows Server 2003 DCHP server computer to the DHCP Admins group at the Enterprise level that is mentioned in step 4, verify that the user account that is currently used to import belongs to the local Administrators group. If the account does not belong to this group, add the account to that group, or log on as a local administrator to complete the import.

Note If the DHCP IMPORT or EXPORT command fails for users who are not explicit members of the local Administrators group, you must apply the following hotfix on the Windows Server 2003-based computer:

833167 (http://support.microsoft.com/kb/833167/ ) A Volume Shadow Copy Service (VSS) update package is available for Windows Server 2003
After you receive the message that the command completed successfully, quit the command prompt.

Back to the top

Authorize the DHCP server

Click Start, point to All Programs, point to Administrative Tools, and then click DHCP.

Note You must be logged on to the server by using an account that is a member of the Administrators group. In an Active Directory domain, you must be logged on to the server by using an account that is a member of the Enterprise Administrators group.
In the console tree of the DHCP snap-in, expand the new DHCP server. If there is a red arrow in the lower-right corner of the server object, the server has not yet been authorized.
Right-click the server object, and then click Authorize.
After several moments, right-click the server again, and then click Refresh. A green arrow indicates that the DHCP server is authorized.

How to move a DHCP database from a computer that is running Windows Server 2003 to Windows Server 2008

2010-03-15T02:40:00.000-07:00

Export the DHCP database from Windows 2003:

1. On the Windows 2003 DHCP server, navigate to a command prompt

2. Type the following Command: netsh

3. Type the following Command: DHCP

4. Type the following Command: server <\\Name or IP Address>

5. Type the following Command: export c:\w2k3DHCPdb all

Note You must have local administrator permissions to export the data.

Import the DHCP database

1. Copy the exported DHCP database file to the local hard disk of the Windows Server 2008-based computer.

2. Install the DHCP Role on the server.

3. Stop the DHCP server service on the server. To do this, follow these steps:

a. Log on to the target DHCP server by using an account that is a member of the local Administrators group.

b. Click Start, click Run, type cmd in the Open box, and then click OK.

c. At the command prompt, type net stop DHCPserver , and then press ENTER. You receive a "The Microsoft DHCP Server service is stopping. The Microsoft DHCP Server service was stopped successfully" message.

d. Type exit, and then press ENTER.

4. Delete the DHCP.mdb file under c:\windows\system32\DHCP folder.

5. Start the DHCP server service.

6. Right-click on the Command Prompt (cmd) and select run as administrator, to open the cmd prompt using elevated privileges.

Note You must have local administrator permissions to import the data.

7. Type the following Command: netsh

8. Type the following Command: DHCP

9. Type the following Command: server <\\Name or IP Address>

10. Type the following Command: import c:\w2k3DHCPdb

11. Restart DHCP and verify the database has moved over properly.

more infomation
While exporting the configuration on the Windows 2003 Server, using netsh, you may see an error message similar to one of the following:

· Access is denied

· An attempt was made to load a program with an incorrect format.

In this case following steps can be followed to export the DHCP database.

1. On the Windows 2003 DHCP server which had the original database, at a cmd prompt type the following command: netsh DHCP server dump >c:\DHCPdump.txt

2. Copy the DHCPdump.txt to another Windows 2003 box

3. Open up the text file and edited the text file with a find and replace changing the IP address from the old to the new Windows 2008 server, and then save the file.

4. Stop the DHCP server service and delete the contents of the DHCP folder and subfolders.

5. Start the DHCP server.

6. Right-click on the Command Prompt (cmd) and select run as administrator, to open the cmd prompt using elevated privileges.

Note You must have local administrator permissions to import the data.

7. At the command prompt type: netsh exec DHCPdump.txt

8. At the command prompt type: netsh DHCP server initiate reconcile

9. Open up the console and check that all of the options are intact and the Reservations are present.

10. At the command prompt type: netsh DHCP server export c:\DHCP.txt all

In some scenarios you may receive the following error while importing the database on a 2008 server.

"The Requested operation requires Elevation."

Make sure that the command prompt is opened with elevated privilege on windows server 2008.

To do so right click on the command prompt menu option and select run as administrator and then try and import the database.

For more information on moving a DHCP server from one operating system to another see the following knowledgebase article:

325473 How to move a DHCP database from a computer that is running Windows NT Server 4.0, Windows 2000, or Windows Server 2003 to a computer that is running Windows Server 2003
by microsoft

Recovery process of a DFS Namespace in Windows 2003 and 2008 Server

2010-03-15T02:35:00.000-07:00

The recovery process of a DFS Namespace depends on how the namespace configuration data was lost, the type of Namespace (domain or standalone), and what types of backups exist of the data. The data may have been inappropriately modified through the DFS management tools, deleted directly within Active Directory or the registry, or corrupted. Backups types of the configuration data include System-state backups of a domain controller, backups of DFS Roots/Namespace servers, exported data via the dfsutil.exe utility, and DFS service registry keys.

Background:

Before beginning the recovery process, determine if the loss of the DFS Namespace was due to accidental administrative deletion of the namespace contents or by loss/corruption of the DFS configuration data.

DFSN Recovery options:

· Standalone DFSN

o Registry data deleted?

§ Use system-state backup of Namespace server, see recovery option 1 of Standalone DFS Root and Links

§ Use exported copy of the DFSN namespace using DFSUTIL, see recovery option 2 of Standalone DFS Root and Links

§ Recreate the DFS Namespace

o Root or Link share deleted?

§ Use system-state backup of namespace server, see recovery option 1 of Shared folders

§ Use saved share configuration registry data, see recovery option 2 of Shared folders

· Domain DFSN

o Active Directory configuration data is deleted?

§ Restore the Active Directory DFS configuration data from backup, see recovery option 1 of Domain DFS Root and Links

§ Use exported copy of the DFSN domain namespace using DFSUTIL, see recovery option 2 of DFS Root and Links

§ Recreate the namespace, see recovery option 3 of DFS Root and Links

o Registry data deleted?

§ Use system-state backup of Namespace server to recover the registry

§ Recreate the namespace, see recovery option 3 of DFS Root and Links

o Root or Link share deleted?

§ Use system-state backup of namespace server, see recovery option 1 of Shared folders

§ Use saved share configuration registry data, see recovery option 2 of Shared folders

The following chart details how the data (Active Directory or registry of a DFS namespace server) is impacted by various operations against a DFS namespace:

Collapse this tableExpand this table

Namespace type	Modification type	Resulting configuration changes
Domain	Domain DFS Root or Links	Active Directory, Registry
Standalone	Standalone Root/Link	Registry
Domain/Standalone	Shared folders	File System, Registry

Utilize the dfsutil.exe utility to view the contents of the DFS configuration. Dfsutil is available within the Windows Server 2003 and the Windows XP Support Tools package, and it is included with Windows Server 2008 once the Distributed File System Role Service is installed via Server Manager. The following data lists the configuration for the DFS namespace/root named "DATA" after running the commands "dfsutil /root:\\contoso.com\DATA /view" (on 2003) or "dfsutil root \\contoso.com\DATA" (on 2008):

DFS Utility Version 5.2 (built on 5.2.3790.3959)

Copyright (c) Microsoft Corporation. All rights reserved.

Domain Root with 1 Links [Blob Size: 704 bytes]

SiteCosting:ENABLED

Root Name="\\CONTOSO\DATA" State="1" Timeout="300" Attributes="64"

Target Server="2003SERVER1" Folder="DATA" State="2" [Site: Default-First-Site-Name]

Link Name="documentation" State="1" Timeout="1800"

Target Server="2003server1" Folder="documentation" State="2" [Site: Default-First-Site-Name]

Target Server="2003server2" Folder="documentation" State="2" [Site: Default-First-Site-Name]

Root with 1 Links [Blob Size: 704 bytes]

This DFS namespace contains a single folder/link called "Documentation" and contains two folder/link targets, "\\2003server1\documentation" and "\\2003server2\documentation".

The DFS configuration Data queried by DFSUtil is stored within the following location within Active Directory:

CN=Dfs-Configuration,CN=System,DC=

In Windows Server 2003, each Domain DFS Root/Namespace is stored within an "fTDfs" object which contains an attribute "pKT" containing the configuration data (namespace settings, namespace servers, folder targets, etc). For instance, the "DATA" namespace listed in the dfsutil.exe output above is located with an fTDfs object at this location: CN=DATA,CN=Dfs-Configuration,CN=System,DC=. No parts of this object should ever be modified directly.

CN=Dfs-Configuration,CN=System,DC=
|_fTDfs

In Windows Server 2008, Domain DFS Roots/Namespaces may be configured in "Windows Server 2008 mode". In this mode, configuration data is stored under an "msDFS-NamespaceAnchor" class object. An object of class "msDFS-Namespacev2" represents each root, and each root contains an "msDFS-Linkv2" object representing each hosted link.

CN=Dfs-Configuration,CN=System,DC=
|_msDFS-NamespaceAnchor
|_msDFS-Namespacev2
|_msDFS-Linkv2

Each DFS Namespace/Root server utilizes registry data to identify the root(s) it hosts. Without this information, the DFS service would not obtain the configuration data from Active Directory and would fail to host the root(s).

For 2003/2008 domain-based DFS roots, this keys store the root associations:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain

For "Windows Server 2008 mode" roots, the following key stores the root associations:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\DomainV2

Within this key exists a subkey for each root hosted by the server and specifies the root share via two values "LogicalShare" and "RootShare". The key for the "DATA" root would be as follows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain\DATA

For standalone DFS roots, configuration data isn't stored within Active Directory. Configuration data is stored within the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone

Beneath the "Standalone" key exists subkeys for the specific standalone root(s) hosted by the server, and within each, subkeys containing configuration data for the hosted folders/links.

The file server shares specified by the "LogicalShare" and "RootShare" registry values must exist and be accessible for proper operation of a DFS root. Access will be denied to a root if the share is missing or is configured with inappropriate permissions. It is recommended to never directly edit these registry values. Backup:

To backup a DFS Namespace server, a system-state backup is required. The backup will contain the registry configuration for the server's DFS service. If the domain-based namespace server is also a domain controller, the system-state will also include a backup of the Active Directory database, where domain-based DFS namespaces store the configuration data. For namespace servers not running on domain controllers, ensure at least one domain controller is backed up regularly to prevent the loss of configuration data in the event a domain controller experiences a failure. Lastly, ensure the DFS-related folders residing on the server are included within the backup.

For additional details about system-state backups and restorations, please see the following articles:

Windows Server 2003
http://technet.microsoft.com/en-us/library/cc759141.aspx

Windows Server 2008
http://technet.microsoft.com/en-us/library/cc770266.aspx

Please note the typical shelf life of a system-state backup of Active Directory is only 60 days:
http://support.microsoft.com/kb/216993

An alternate method to save the DFS configuration data is via the DFSUtil.exe utility. The output created via the "export" option may be used to recreate the missing DFS configuration information lost through accidental deletion.

Collapse this tableExpand this table


	Collapse this imageExpand this image

Recovery:

Once the scope of the modifications have been identified, the appropriate recovery process should be performed.

Domain DFS Root and Links

Option 1 - Restore the Active Directory DFS configuration data from backup

For domain-based DFS, modification of a DFS root via a management tool has the largest potential impact to the namespace. This is because whenever modifications are performed via DFS API's, all root servers are notified of the changes and they will update their registry as required. Thus, restoration of the DFS configuration within Active Directory from backups may also require the task of recovering the registry of root servers.

Authoritatively restore the DFS configuration blob. This requires the startup of a DC in DS restore mode, restoring the Active Directory database from a backup which still contains a valid copy of the DFS configuration, marking the DFS root directory object as authoritative, and replicating this throughout the domain. DFS roots, by default, obtain DFS configuration data from the PDC FSMO role owner domain controller. To prevent replication latencies from impacting the time until the roots begin hosting the restored namespace(s), consider using the PDC FSMO as the domain controller to restore.

The authoritative restoration process is detailed in the following article:

Performing an Authoritative Restore of Active Directory Objects

http://technet.microsoft.com/en-us/library/cc779573.aspx

Restoring Active Directory:

Windows Server 2003:
http://technet.microsoft.com/en-us/library/cc758435.aspx
a. Start the computer in Directory Services Restore Mode.
b. To start the Windows Server 2003 backup utility, click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup.
c. On the Welcome to the Backup or Restore Wizard page, click Next.
d. Click Restore files and settings, and then click Next.
e. Select System State, and then click Next.
f. On the Completing the Backup or Restore Wizard page, click Advanced.
g. In Restore files to, click Original Location, and then click Next.
h. Click Leave existing files (Recommended), and then click Next.
i. Click Finish.
j. When the restore process is complete, click Close, and then click No to remain in Directory Services Restore Mode.

NOTE: Do not reboot when prompted by the backup program. If a reboot is performed and Active Directory replication takes place, the domain controller will replicate the deletions again.

Windows Server 2008:
http://technet.microsoft.com/en-us/library/cc730683.aspx

1. At the Windows logon screen, click Switch User, and then click Other User.

2. Type .\administrator as the user name, type the DSRM password for the server, and then press ENTER.

3. Click Start, right-click Command Prompt, and then click Run as Administrator.

4. At the command prompt, type the following command, and then press ENTER:

wbadmin get versions -backuptarget::

-machine:

Where:

: is the location of the backup that you want to restore.

is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was taken.

5. Identify the version that you want to restore. You must enter this version exactly in the next step.

6. At the command prompt, type the following command (wrapped for readability), and then press ENTER:

wbadmin start systemstaterecovery -version:

-backuptarget:: -machine:

-quiet

Marking the DFS configuration data authoritative:

It is important to know the distingiushed name of the namespace(s) to be restored so that the DFS root object(s) may be marked authoritatively. It should be in the format "CN=,CN=DFS-Configuration,CN=System,DC=" and may need to be enclosed in quotation marks if spaces exist within any labels.

a. In Directory Services Restore Mode, click Start, click Run, type ntdsutil, and then press ENTER.

b. At the ntdsutil: prompt, type authoritative restore, and then press ENTER.

c. To restore a subtree of objects, type the following command and then press ENTER:

restore subtree DistinguishedName

For example, to restore all DFS Namespace objects in the domain contoso.com , type:

restore subtree "CN=Dfs-Configuration,CN=System,DC=contoso,dc=com"

*Warning* - All DFS namespaces will be affected by this operation, returning them to the state contained in the backup.

To restore a single DFS Namespace object for a root named "DATA" in the domain contoso.com, type:

restore subtree "CN=DATA,CN=Dfs-Configuration,CN=System,DC=contoso,dc=com"

Restoring a subtree of objects ensures the operation will complete successfully for both v1 and v2 namespaces.

d. Click Yes in the message box to confirm the command.

e. At the authoritative restore: and ntdsutil: prompts, type quit, and then press ENTER.

f. Restart the domain controller in normal operating mode.

g. Allow Active Directory replication sufficient time to replicate the objects throughout the domain.

Verify registry data on all DFS roots

Each domain DFS namespace/root server must have proper registry data under the location "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain" in order to properly host the restored DFS root(s). If the DFS namespace was deleted via a DFS management tool, you may have to manually create the keys and "LogicalShare" and "RootShare" values on each root. Once the registry data is in place, restart the DFS service on each root to reinitialize DFS and obtain the restored configuration data.

For example, to create the "LogicalShare" and "RootShare" for a DFS Namespace named "Data" whose shared folder for the root is named "DataShare", the following steps are used:

1. Click Start , click Run , type regedit in the Open box, and then click OK .
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain
3. Right-click Domain , point to New , and then click Key.
4. Type "Data" as the key name, and then press ENTER.
5. Right-click the "Data" key, point to New, and then click "String Value".
6. Type "LogicalShare" as the value name.
7. Right-click the "LogicalShare" value, and then click Modify.
8. In the Value data box, type "DataShare" , and then click OK .
9. Right-click the "Data" key, point to New, and then click "String Value".
10. Type "RootShare" as the value name.
11. Right-click the "RootShare" value, and then click Modify.
12. In the Value data box, type "DataShare" , and then click OK .

Option 2 - Import the DFS configuration if an export is available

An export of the DFS configuration consists of a text file generated via dfsutil.exe and the following command:

Windows Server 2003:
dfsutil /root:\\contoso.com\DATA /export:DATA-dfs-Root.txt

Windows Server 2008:
dfsutil root export \\contoso.com\DATA DATA-dfs-root.txt

To recover a namespace via an export file, perform the following:

a. If the root doesn't already exist, create it using DFS Management. Add all appropriate root targets. Dfsutil.exe will fail to import the configuration if the root itself doesn't already exist and will not add root targets as defined in the file. However, you may review the contents of the export file to identify which root targets should be manually added.

b. Import the configuration file to create all of the hosted links via the commands:
Windows Server 2003:
dfsutil /root:\\contoso.com\DATA /import: DATA-dfs-Root.txt

Windows Server 2008:
dfsutil root import set DATA-dfs-Root.txt \\contoso.com\DATA

(Where the domain is contoso.com, "DATA" is the root's name, and "DATA-dfs-Root.txt" is the export file)

Attempting the import before the root has been created will result in the error "Element not found."

Attempting to add a root target that already has registry configuration data associated with the root results in the errors "The device is not ready for use" or "Cannot create a file when that file already exists." To remove the registry data from the affected server, utilize the "clean" option within DFSUtil:

Windows Server 2003:
dfsutil /clean /server: /share:

Windows Server 2008:
dfsutil diag clean \\\

c. Verify the import was successful. You may have to reopen any DFS management tools to observe the imported links.

Option 3 - Recreate the Namespace(s)

It may be easier to simply recreate the namespaces as required. This activity will update the configuration within Active Directory and the registry of the roots. If adding a server as a root fails indicating the root is already hosted by the server, check the registry configuration of the server to ensure that it doesn't already have configuration data for the original root. To remove such data, run the following command:

dfsutil /clean /server:servername /share:sharename

(Where "servername" is the server which needs to be added as a new root target and "sharename" is the name of the share to host the root)

On Windows Server 2008:

dfsutil diag clean \\servername\sharename Active Directory fTDfs object

If the ftDfs object within Active Directory was directly deleted, restore the object as detailed in Option 1 of the "Domain DFS Root and Links" section. There should be no need to repair missing registry data, as a direct deletion of the fTDfs object is performed without using DFS API's and no notifications sent to the DFS roots of the deletion.

If an export of the DFS configuration exists, the process will be similar to that in Option 2 of the "Domain DFS Root and Links" section.

Lastly, you may also recreate the DFS namespace, ensuring each DFS root has been properly cleaned of the previous configuration. See Option 3 of the "Domain DFS Root and Links" section for more details. Standalone DFS Root and Links

Option 1 - Restore the Standalone DFS configuration data from backup

If a standalone DFS namespace/root server experiences configuration data loss, it is recommended to restore the system-state of the server from backup. This operation will automatically restore the configuration data to the proper state. Attempting to modify the registry of a standalone DFS root is not recommended.

Option 2 - Import the DFS configuration if an export is available

If a DFSUTIL.EXE export exists for the root, it may be imported via the commands:

Windows Server 2003:
dfsutil /root:\\server-name\namespace-name /import: DATA-dfs-Root.txt

Windows Server 2008:
dfsutil root import set DATA-dfs-Root.txt \\contoso.com\DATA

Option 3 - Recreate the Namespace(s)

It may be easier to simply recreate the standalone namespace(s) as required. Shared folders

If a domain-based or a standalone DFS namespace server experiences loss of a DFS share and the DFS configuration remains, the shares must be recovered to restore DFS functionality.

Option 1 -Restore the Standalone DFS configuration data from backup

Restore the system-state from a backup made prior to the loss. The system-state includes the registry data for the server to host the shares. Ensure the folder(s) for the share(s) also are present on the server.

Option 2 - Recover the share configuration data from the registry

If a system-state backup of a DFS Namespace server is not available but share registry information exists, this information may be used to restore the share configuration of the server. Shares and assigned share permissions are stored in the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

To save this registry key using the registry editor, click Export on the File menu.

This registry key may be imported to the DFS Namespace server or used as a reference of the share names and location of shared folders for manual creation.

To restore or import the registry key using the registry editor, click Import on the File menu.

Once the shares have been recovered, restart the Namespace server's DFS service to initialize the namespace.

by microsoft

"Outlook.pst can not be accessed - 0x80040116" error message when you start Outlook 2000 or open a personal folder file

2010-03-15T01:53:00.001-07:00

To resolve this issue, run the "2 GB Truncation" tool, run the Inbox Repair tool, and then open the repaired file.

NOTE: Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.

Part 1: Run the "2 GB Truncation" Tool

The "2 GB Truncation" tool (Pst2gb.exe) is available for download from the Microsoft Download Center:
http://www.microsoft.com/downloads/details.aspx?familyid=B33B1DFF-6F50-411D-BBDF-82019DDA602E&displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=B33B1DFF-6F50-411D-BBDF-82019DDA602E&displaylang=en)
Extract the 2gb152.exe file to an empty folder. You should see the following five files:
- Msstdfmt.dll
- Msvbvm60.dll
- Pst2gb.exe
- Readme.rtf
- Readme.txt
Click Start, and then click Search.
On the Tools menu, click Folder Options, and then click the View tab.
Click Show hidden files and folders, click to clear the Hide extensions for known file types check box, click to clear the Hide protected operating system files (Recommended) check box, click Yes to confirm that you want to display protected operating system files, and then click OK.
Under What do you want to search for?, click All files and folders.
In the All or part of the file name box, type *.pst.
In the Look in list, click Local Hard Drives (C:), and then click Search.
Note the path to the .pst file that you want to repair. By default, this file is named Outlook.pst.
Click Start, click Run, type path\pst2gb.exe -s, and then click OK, where path is the complete path to the Pst2gb.exe file that you extracted in step 2. For example, if you extracted the "2 GB Truncation" tool files to the C:\Files folder, type c:\files\pst2gb.exe -s, and then click OK.
Click Continue, and then click Browse.
Click the .pst file that you want to repair, and then click Open. By default, this file is named Outlook.pst.
Click Create, type a new unique file name for the .pst file such as Outlook-2 in the File name box, and then click Save.
In the Oversized PST Recovery Tool dialog box, click Start.
After you run the tool, click OK, and then click Close.

Part 2: Run the Inbox Repair Tool

Click Start, and then click Search.
Under What do you want to search for?, click All files and folders.
In the All or part of the file name box, type scanpst.exe.
In the Look in list, click Local Hard Drives (C:), and then click Search.
In the list of found files, double-click the Scanpst.exe file.
Click Browse, and then open the folder that contains the new .pst file that you created by using the "2 GB Truncation" tool.
Click the new .pst file that you created, and then click Open.
In the Inbox Repair Tool dialog box, click Start.
When the file has been scanned, click Repair to repair the errors in the file.

NOTE: This procedure may take several hours.
When you receive the "Repair complete" message, click OK.
Restart the computer.

Part 3: Open the Repaired File in Outlook 2000

Start Outlook 2000.
On the File menu, point to Open, and then click Personal Folders File (.pst).
Open the folder that contains the new .pst file that you created and repaired.
Click the new .pst file, and then click OK.

NOTE: If this file opens successfully, it is listed in the file list under Recovered Personal Folders.
Copy the data from each folder in Recovered Personal Folders to the "Outlook Today - (Personal Folders)" folders.

by microsoft

You receive an error message when you start Outlook

2010-03-15T01:50:00.000-07:00

Open a New Personal Folders (.pst) File

If you want to open a new .pst file, type a name for the new file in the Create/Open Personal Folders File dialog box, and then click Open.

Personal Folders (.pst) File That Is Located on a Network Server

.PST files that are located on network drives are not supported.

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

297019 (http://support.microsoft.com/kb/297019/ ) Personal folder files are unsupported over a LAN or over a WAN link

Corrupted Personal Folders (.pst) File

If you suspect that your .pst file is corrupted, you may be able to recover the file by using the Inbox Repair Tool. To do so, follow these steps.

Note Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.

Click Start, point to Search, and then click Files or Folders.
Type scanpst.exe in the Search for files or folders named box, and then click Search Now.
In the list of found files, double-click the Scanpst.exe file.
Type the name of the .pst file that you want to repair, or click Browse to locate the .pst file.
Click Start.

If you receive an error message, you have the option to back up the file before you try to repair it.

The log file for the repair process has the same name as the .pst file with a .log file name extension. If you repair a file that is named Mailbox.pst, the log file is named Mailbox.log.