In a domain environment, you configure the Slow network connection time-out for user profiles Group Policy setting to reduce the time that is required for roaming profile users to log on to the domain through a slow network connection. Assume a user then logs on or logs off the domain through a slow network connection from a Windows Vista Service Pack 1 (SP1)-based or a Windows Server 2008-based client computer. In this scenario, the time that is required to log on or to log off the domain is still longer than expected.

Note: After you configure this Group Policy setting, you expect the roaming profile client to use a local copy of the profile if the network connection is slow.

If you check the user environment debug log or if you capture a network monitor trace, you see that the client computer downloads or uploads the roaming user profiles every time that the user logs on or logs off the domain. This behavior occurs even in a slow network environment.

When you try to shut down a Windows Vista-based or Windows Server 2008-based computer, the shutdown process may become very slow.

This issue may occur if other computers have dialed into the computer that you try to shut down.

On a Windows Vista-based computer, you establish a Windows Meeting Space session that uses the Create a private ad hoc wireless network option. Then, a remote Windows Vista-based peer computer tries to join the Windows Meeting Space session. However, Windows Meeting Space may be unable to detect the remote computer and cannot establish the connection to the Windows Meeting Space session.

Environment
Novell Client for Vista 1.0.0 File Access

Situation
Problems can arise if the Novell Client provider is not listed in the Provider Order for the Local Area Network Connection on a Windows Vista workstation. A common symptom is seeing the drive mappings included in the “Network Location” section of the “Computer” view of Windows Explorer displayed with a red X.

On a Windows Vista-based computer, you change a wireless connection from a wireless access point that uses a valid Wired Equivalent Privacy (WEP) key to another wireless access point that uses an invalid WEP key. Then, the connection status may incorrectly display a “Connection Successful” message. However, the wireless connection is not connected.

In this scenario, either of the following messages should be displayed:

Connection Unsuccessful
Windows cannot connect to Wireless Access Point

On a Windows Vista-based computer, when you try to communicate with another computer through an Internet Protocol security (IPsec) tunnel-mode connection, the connection fails.

This issue occurs if the Windows Vista-based computer is behind a Network Address Translation (NAT) device.

You use the netsh advfirewall consec command together with the auth1 or auth2 authentication parameters to create a connection security rule that will work together with authentication methods that are specified on a Windows Vista-based computer. After you do this, the order of the values that you specify for the auth1 or auth2 parameters is not preserved in the connection security rule. Regardless of the order in which you specify the values for the auth1 and auth2 parameters, the connection security rule is created together with authentication parameters that are specified in the following order:

Auth1: ComputerKerb, ComputerCert, ComputerPSK, ComputerNTLM, Anonymous

Auth2: ComputerCert, UserKerb, UserCert, UserNTLM, Anonymous

For example, the following command creates a connection security rule that lists the ComputerKerb authentication method before the ComputerNTLM authentication method in the first authentication set:

netsh advfirewall consec add name=�Authentication Test� endpoint1=any endpoint2=any action=requestinrequestout auth1=computerntlm,computerkerb

Note: The netsh advfirewall consec set command also displays the same behavior when you use the auth1 or auth2 parameter with it.

On a Windows Vista-based computer, consider the following scenario:

• You use Wi-Fi Protected Access (WPA) together with Advanced Encryption Standard (AES) encryption to access wireless networks.
• A computer certificate is configured correctly on the computer.
• The computer has the correct permissions to access wireless networks.

In this scenario, you can see that a wireless network is available in the Connect to a network dialog box in the Network and Sharing Center. However, you cannot connect to the wireless network.

After you configure Internet Connection Sharing in Windows Vista, you may find that, although the network connection works correctly at first, the network connection stops working after one-to-two hours. For example, you may be unable to connect to the Internet, to other computers on the local area network (LAN), or to network resources on the LAN.

A system service on a Windows Vista-based computer uses named pipes to connect to a system service on another Windows Vista-based computer. Both services run under the local system account. However, when the system service on the first computer tries to connect to the system service on the second computer, you receive one of the following error messages:

Error message 1

Server1_name: cannot connect to machine “Server2_name” (0×00000005)!

Error message 2

Server1_name: cannot connect to machine “Server2_name” (0×00000035)!