INFO: Services and Redirected Drives

Article translations Article translations
Article ID: 180362 - View products that this article applies to.
This article was previously published under Q180362
Expand all | Collapse all

On This Page

SUMMARY

A service should not directly access local or network resources through mapped drive letters. Additionally, a service should not use the WNetXXXXXXX APIs to add, remove, or query any mapped drive letters. Although the WNetXXXXXXX APIs may return successfully, the results will be incorrect. A service (or any process that is running in a different security context) that must access a remote resource should use the Universal Naming Convention (UNC) name to access the resource. UNC names do not suffer from the limitations described in this article.

MORE INFORMATION

When the system establishes a redirected drive, it is stored on a per-user basis. Only the user himself can manipulate the redirected drive. The system keeps track of redirected drives based on the user's Logon Security Identifier (SID). The Logon SID is a unique identifier for the user's Logon Session. A single user can have multiple, simultaneous logon sessions on the system.

If a service is configured to run under a user account, the system will always create a new logon session for the user and then launch the service in that new logon session. Thus, the service cannot manipulate the drive mappings that are established within the user's other session(s).

Redirected Drives on Microsoft Windows NT and Microsoft Windows 2000

On Windows NT and on Windows 2000, drive letters are global to the system. All users on the system share the letters A-Z. Each user does not get their own set of drive letters. This means a user can access the redirected drives of another user if they have the appropriate security access.

If a user tries to redirect a drive letter that is used by another user (such as WNetAddConnection2()), the error ERROR_ALREADY_ASSIGNED will be returned. Although the redirected drive is global to all users, only the user who established it can manipulate it. Another example is if a user tries to remove or query information on a redirected drive that was established by a different user. The WNetGetConnection() function and the WNetCancelConnection2() function will return the following error message:
ERROR_NOT_CONNECTED
If a user tries to enumerate the list of redirected drives through WNetOpenEnum() and WNetEnumResource(), the functions only list redirected drives that were established by that user. Drives that were redirected by other users will not be visible.

Windows NT File Manager and Windows NT Explorer can see all the redirected drives because they call the GetDriveType() function on each drive, and they display an icon for each drive that is found. Windows NT File Manager and Windows NT Explorer create an icon for redirected drives that are created by all users because drive letters are global to the system. However, the interactive user cannot use Windows NT File Manager or Windows NT Explorer to disconnect the drive because the drive was created in a different logon session.

If a service that is running in the LocalSystem security context establishes a drive mapping, only that service or another process running in the LocalSystem account can call WNetCancelConnection2() to disconnect the drive.

Note All processes that are running in the LocalSystem account are running in the same logon session.

Redirected Drives on Microsoft Windows XP

On Windows XP and on Microsoft Windows Server 2003, each logon session receives its own set of drive letters, A through Z. Therefore, redirected drives cannot be shared between processes that are running under different user accounts. Additionally, a service (or any process that is running in its own logon session) cannot access the drive letters that are established in a different logon session. However, drive letters that are mapped from a service that is running under the local System account are visible to all logon sessions.

Properties

Article ID: 180362 - Last Review: November 21, 2006 - Revision: 5.3
APPLIES TO
  • Microsoft Win32 Application Programming Interface, when used with:
    • Microsoft Windows NT 4.0
    • the operating system: Microsoft Windows 2000
    • the operating system: Microsoft Windows XP
    • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
Keywords: 
kbapi kbfileio kbinfo kbkernbase kbservice KB180362

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com