You have a folder that is encrypted by the Encrypting File System (EFS) feature on a computer that is running Windows Vista. When you move the encrypted folder to a network share that is not encrypted, the folder and the files that are contained in the folder are moved successfully. However, an empty encrypted folder that has the same name as the encrypted folder remains on the source computer.

Consider the following scenario:

• As a domain administrator, you apply a Folder Redirection Group Policy object (GPO) to redirect a folder to a network share. For example, you redirect the “Documents” folder.
• You the Folder Redirection GPO to specify a new network share. Additionally, the new network share targets the same physical location as the existing network share.
• When you change the Folder Redirection GPO, you click to select the Move the contents of to the new location check box.
• You apply the Folder Redirection GPO to the domain users and to the client computers.
• A domain user logs on to a client computer that is running Windows Vista or Windows Server 2008.

In this scenario, the domain user finds that the redirected folder is empty.

Notes

• This issue typically occurs when you redirect a folder to a Distributed File System (DFS) link.
• For more information about how to configure the Folder Redirection GPO, see the More information section.

When printing to a shared printer, no output appears on the printer, and no print job shows up in the server’s print queue. This will occur if the following conditions are true:

1. The Print Server is running Windows Server 2008 R2 or Windows 7.
2. The Client is running Windows Vista.
3. The print driver used for the shared printer is an XPS-based print driver which utilizes Windows 7 specific APIs such as rasterization service.
4. The Sharing tab for the printer has “Render print jobs on client computers” selected.
5. The user on the client computer is not an administrator on the Print Server.

From a computer that is running Windows Vista or Windows Server 2008, you copy or write some small files into a shared folder that is hosted on a computer that is running Windows Vista or Windows Server 2008. In this situation, the writing performance is significantly reduced.

You find that there is a performance reduction when you compare this writing performance to the performance of the following operations:

• Copying or writing files from a computer that is running Windows Server 2003 into a shared folder that is hosted on a computer that is running Windows Server 2003.
• Copying or writing files from a network file system (NFS) client to an NFS server.

Additionally, you may find that the Server Message Block (SMB) 2.0 protocol is being used to copy or write files.

Consider the following scenario. On a computer that is running Windows Vista or Windows Server 2008, you set the registry entry SrvsvcDefaultShareInfo under the following registry subkey to configure the default share permissions for a network share:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\lanmanserver\DefaultSecurity\

In this scenario, after you restart the computer, you cannot access an administrative share on the computer.

For example, when a user tries to access drive C by using the “\\[computer name]\C$” command, the user receives the following error message:

Windows cannot access \\[computer name]\C$
Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problem, click Diagnose.
Details:
Error code: 0×80070005
Access is denied

On a computer that runs Windows Vista or Windows Server 2008, you have a network share that is hosted on a computer that runs Windows Vista or Windows Server 2008. In this scenario, after you rename, delete, or move the files in the network share, you may see that the original file names are still listed in the network share, although the operation that you performed on the files is successful.

For example, consider the following scenario:

• You have the following network share:
  \\Server\Share.
• You use the following command to move a file:
  Move \\Server\Share\Dir1\file.txt \\Server\Share\Dir2\file.txt
• You use the following command, and you see that the operation is executed successfully:
  Dir \\Server\Share\Dir2
• You use the following command to check the original directory:
  Dir \\Server\Share\Dir1

In this scenario, you may find that the original file.txt file name is still listed in the network share.

Notes

• This problem occurs if the network share is connected by using the Server Message Block (SMB) v2 protocol. The default network share protocol between Windows Vista or Windows Server 2008 is SMB v2.
• This problem also occurs if you try to rename, delete, or move the files by using an application that calls the MoveFileEx function.
• This problem no longer occurs after about 10 seconds. This means that after about 10 seconds, the file disappears from the original directory.

On a computer that is running Windows Vista or Windows Server 2008, you map a network drive to a Web share, and then you select the Reconnect at logon option. Then, you restart the computer, or you log off and then log back on again. In this situation, the mapped drive is displayed as a red X. Additionally, you may receive the following error message:

Could not reconnect all network drives

Additionally, when you double-click to the mapped drive to access it, you may receive the following error message:

An error occurred while reconnecting Drive: to https://localhost/share
Web Client Network: The operation being requested was not performed because the user has not been authenticated.
This connection has not been restored.

When this problem occurs, you have to disconnect and then remap the Web share.

This problem may occur if the Web share requires certificate-based Secure Sockets Layer (SSL) authentication.

On a Windows Vista or Windows Server 2008-based computer, when you try to perform certain operations on files that are located on a network share, the operations fail. Additionally, you may receive the following error message:

Access is Denied

This issue may occur when you try to access or delete the files. When this problem occurs, you have to restart the computer to resolve this problem.

This problem also affects applications or scripts that perform operations on files that are on the network share. For example, when you use BizTalk File Adapters to send and receive messages in the folders, the messages cannot be processed and are deleted on the network share.

On a Windows Vista-based or Windows Server 2008-based computer, you try to access a network share by typing the path of the share in the Run box. However, it may take more than 10 seconds for the network share to open in Windows Explorer.

For example, in the Run box, you type the universal naming convention (UNC) path of the share, such as \\ServerName\ShareName. When you do this, it takes the Windows Explorer more than 10 seconds to open the share.

This issue occurs if the firewall of the server on which the share resides blocks traffic on port 80.

Consider the following scenario:

• You create a shortcut for a network share in a Windows operating system that is earlier than Windows Vista, such as Windows XP.
• You upgrade the operating system to Windows Vista or Windows Server 2008.
• You open the shortcut in Windows Vista or in Windows Server 2008, and then you create a new file or folder in the network share to which the shortcut points.

In this scenario, the newly created file or folder does not appear until you update the screen.