7 Appendix B: Product Behavior
The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.
The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.
Windows NT operating system
Windows 2000 operating system
Windows XP operating system
Windows Server 2003 operating system
Windows Vista operating system
Windows Server 2008 operating system
Windows 7 operating system
Windows Server 2008 R2 operating system
Windows 8 operating system
Windows Server 2012 operating system
Windows 8.1 operating system
Windows Server 2012 R2 operating system
Windows 10 operating system
Windows Server 2016 operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows 11 operating system
Windows Server 2025 operating system
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.
Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.
<1> Section 1.8: Windows uses only the values in [MS-EERR].
<2> Section 2.1: Windows uses the identity of the caller to perform method-specific access checks.
<3> Section 2.2.2.1: Windows-based SMB clients set this field based on the version and service pack level of the Windows operating system. Windows Vista operating system and later, windows_server_2008 operating system and later, set this field to an empty string. The following table specifies the Sessionclient string and corresponding Windows operating system version.
|
Sessionclient String |
Windows Operating System Version |
|---|---|
|
"Administration Tools Pack" |
Windows Server 2003 operating system with Service Pack 1 (SP1) |
|
"Windows 2002 Service Pack 2" |
Windows XP operating system Service Pack 2 (SP2) |
|
"Windows 5.0" |
Windows 2000 |
|
"Windows NT 1381" |
Windows NT 4.0 operating system |
|
"Windows 4.0" |
Windows 98 operating system and Windows 98 operating system Second Edition |
|
"DOS LM 1.0" |
LAN Manager for MS-DOS 1.0 clients |
|
"DOS LM 2.0" |
LAN Manager for MS-DOS 2.0 clients |
|
"OS/2 LM 1.0" |
LAN Manager for MS-OS/2 1.0 clients |
|
"OS/2 LM 2.0" |
LAN Manager for MS-OS/2 2.0 clients |
<4> Section 2.2.2.1: Windows-based servers currently do not enforce any limits on the Sessionclient string size and will accept any string containing 0 or more characters. The existing Windows clients limit the size to less than 256 bytes.
<5> Section 2.2.2.6: Use PLATFORM_ID_NT for Windows NT Server operating system operating system and later, Windows 2000 operating system and later.
<6> Section 2.2.2.6: Windows clients treat any PlatformID values not specified in the table as unknown platforms.
<7> Section 2.2.2.13: Entry refers to a Windows NT, Windows 2000, or Windows XP server.
<8> Section 2.2.3.7: The ServerInfo103 parameter and SERVER_INFO_103 structure are applicable to Windows Server 2008 R2 operating system operating system and later.
<9> Section 2.2.4.13: Windows-based SMB clients set this field based on the version and service pack level of the Windows operating system. Windows Vista operating system and later, Windows Server 2008 operating system and later, set this field to an empty string. The following table specifies the Sessionclient string and corresponding Windows version.
|
Sessionclient String |
Windows Operating System Version |
|---|---|
|
"Administration Tools Pack" |
Windows Server 2003 with SP1 |
|
"Windows 2002 Service Pack 2" |
Windows XP SP2 |
|
"Windows 5.0" |
Windows 2000 |
|
"Windows NT 1381" |
Windows NT 4.0 |
|
"Windows 4.0" |
Windows 98 and Windows 98 Second Edition |
|
"DOS LM 1.0" |
LAN Manager for MS-DOS 1.0 clients |
|
"DOS LM 2.0" |
LAN Manager for MS-DOS 2.0 clients |
|
"OS/2 LM 1.0" |
LAN Manager for MS-OS/2 1.0 clients |
|
"OS/2 LM 2.0" |
LAN Manager for MS-OS/2 2.0 clients |
<10> Section 2.2.4.15: Windows-based SMB clients set this field based on the version and service pack level of the Windows operating system. Windows Vista operating system and later, Windows Server 2008 operating system and later set this field to an empty string. The following table specifies the Sessionclient string and corresponding Windows operating system version.
|
Sessionclient String |
Windows Operating System Version |
|---|---|
|
"Administration Tools Pack" |
Windows Server 2003 with SP1 |
|
"Windows 2002 Service Pack 2" |
Windows XP SP2 |
|
"Windows 5.0" |
Windows 2000 |
|
"Windows NT 1381" |
Windows NT 4.0 |
|
"Windows 4.0" |
Windows 98 and Windows 98 Second Edition |
|
"DOS LM 1.0" |
LAN Manager for MS-DOS 1.0 clients |
|
"DOS LM 2.0" |
LAN Manager for MS-DOS 2.0 clients |
|
"OS/2 LM 1.0" |
LAN Manager for MS-OS/2 1.0 clients |
|
"OS/2 LM 2.0" |
LAN Manager for MS-OS/2 2.0 clients |
<11> Section 2.2.4.29: SHI1005_FLAGS_ACCESS_BASED_DIRECTORY_ENUM is supported only on servers running Windows Server 2003 with SP1, Windows Server 2008 operating system and later, Windows 7 operating system and later.
<12> Section 2.2.4.29: SHI1005_FLAGS_FORCE_LEVELII_OPLOCK is supported on Windows Server 2008 R2 operating system and later.
<13> Section 2.2.4.29: SHI1005_FLAGS_ENABLE_HASH is supported on Windows Server 2008 R2 operating system and later.
<14> Section 2.2.4.29: SHI1005_FLAGS_ENABLE_CA is supported on Windows Server 2012 operating system and later.
<15> Section 2.2.4.29: SHI1005_FLAGS_ENCRYPT_DATA is supported on Windows 8 operating system and later, Windows Server 2012 operating system and later.
<16> Section 2.2.4.29: SHI1005_FLAGS_COMPRESS_DATA is supported on Windows 10 v21H1 operating system and later and Windows Server 2022 and later.
<17> Section 2.2.4.31: SHARE_INFO_1501_I is supported after Windows 2000.
<18> Section 2.2.4.43: The following values are returned by Windows-based servers for different versions of the Windows operating system.
|
Operating system |
Major version |
|---|---|
|
Windows NT 4.0 |
4 |
|
Windows 2000 |
5 |
|
Windows XP |
5 |
|
Windows Server 2003 |
5 |
|
Windows Vista |
6 |
|
Windows Server 2008 |
6 |
|
Windows 7 |
6 |
|
Windows Server 2008 R2 |
6 |
|
Windows 8 |
6 |
|
Windows Server 2012 |
6 |
|
Windows 8.1 |
6 |
|
Windows Server 2012 R2 |
6 |
|
Windows 10 and later |
10 |
|
Windows Server 2016 and later |
10 |
<19> Section 2.2.4.43: The following values are returned by Windows-based servers for different versions of the Windows operating system.
|
Operating system |
Minor version |
|---|---|
|
Windows NT 4.0 |
0 |
|
Windows 2000 |
0 |
|
Windows XP |
1 |
|
Windows Server 2003 |
2 |
|
Windows Vista |
0 |
|
Windows Server 2008 |
0 |
|
Windows 7 |
1 |
|
Windows Server 2008 R2 |
1 |
|
Windows 8 |
2 |
|
Windows Server 2012 |
2 |
|
Windows 8.1 |
3 |
|
Windows Server 2012 R2 |
3 |
|
Windows 10 and later |
0 |
|
Windows Server 2016 and later |
0 |
<20> Section 2.2.4.43: SRV_HASH_GENERATION_ACTIVE is enabled only if SRV_SUPPORT_HASH_GENERATION is enabled.
<21> Section 2.2.4.46: The allowed range of values on Windows NT 4.0 is 1 to 2,048, inclusive.
<22> Section 2.2.4.46: The allowed range of values for get operations on Windows NT 4.0 and Windows 2000 is 512 to 65,535, inclusive.
<23> Section 2.2.4.46: The allowed range of values for get operations on Windows NT 4.0 is 1 to 20, inclusive.
<24> Section 2.2.4.46: The allowed range of values in Windows is from 0x00100000 to 0xFFFFFFFF, inclusive.
<25> Section 2.2.4.46: The allowed range of values in Windows is from 0x00100000 to 0xFFFFFFFF, inclusive.
<26> Section 2.2.4.46: The allowed range of values for Windows NT 4.0, Windows 2000, and Windows XP is 2 to 32, inclusive.
<27> Section 2.2.4.46: The allowed range of values for Windows NT 4.0, Windows 2000, and Windows XP is 2 to 100, inclusive.
<28> Section 2.2.4.96: Following are examples of values that this field can have for Microsoft-supported protocols:
NETBT (NetBIOS over TCP/IP)
On Windows 2000 operating system and later, Windows Server 2003 operating system and later, the format is as follows, where the value between braces is the GUID of the underlying physical interface that is generated by the operating system at installation time: \Device\NetBT_Tcpip_{2C9725F4-151A-11D3-AEEC-C3B211BD350B}
On Windows NT 4.0, the format is as follows, where DC21X41 is the name for the adapter chosen by the manufacturer: \Device\NetBT_DC21X41
Direct hosting of SMB over TCP/IP (NetBIOS-less SMB)
This protocol is available only on Windows 2000 operating system and later, Windows Server 2003 operating system and later. The format is: \Device\NetbiosSmb
Nwlnk (the Microsoft version of the Novell IPX/SPX Protocol [NWLINK])
This protocol is not installed by default. It provides the following two transports: \Device\NwlnkIpx and \Device\NwlnkNb
NetBEUI
This protocol is supported only on Windows 2000 and Windows NT 4.0. The value between braces is the GUID of the underlying physical port generated by the operating system at installation time. The NdisWanNbfOut/NdisWanNbfIn devices correspond to bindings between the NetBEUI transport and NDISWAN driver. The format options are:
\Device\Nbf_{868B258E-252B-4F65-A383-18803360701F}
\Device\Nbf_NdisWanNbfOut{77C17309-B558-4096-8A2B-2D1E9E4FC932}
\Device\Nbf_NdisWanNbfIn{331BB986-F9B0-406C-9FA2-36425F52CC05}
<29> Section 2.2.4.96: This member is usually the NetBIOS name that the server is using, or it can represent an SMB/IPX name.
<30> Section 2.2.4.96: The server normalizes this to 16 characters by truncating the given length to this value if it is larger, or padding the transport address buffer with the blank character (0x20) until the length is 16.
<31> Section 2.2.4.96: Following are examples of values this field can have for Microsoft-supported protocols:
NETBT (NetBIOS over TCP/IP)
The MAC address of the n/w device, for example: 00065b5da43f
NetBIOS over SMB
000000000000
Nwlnk (the Microsoft version of the Novell IPX/SPX Protocol [NWLINK])
The MAC address of the n/w device, for example: 00065b5da43f
NetBEUI
The MAC address of the n/w device for the non-NdisWan devices, for example: 00065b5da43f
For the NdisWan devices, this pointer is an index into internal connection tables of the driver. The first two characters are generated randomly by using the current system tick count and the next two by using the current system time at installation. The last eight characters are always 20524153 and stand for the string "RAS" including the leading blank. For example: d2e820524153.
<32> Section 3.1.1: In Windows, virtual shares are implemented in DFS, which is a referral service to SMB shares, as specified in [MS-DFSC]. The DFS abstract model is specified in [MS-DFSC]. DFS is a special type of share that is relevant to the Windows client.
<33> Section 3.1.1: By default, Windows-based SMB and SMB2 servers are configured to listen on both Direct TCP as specified in [MS-SMB] sections 1.9 and 2.1, and NetBIOS over TCP as specified in [MS-CIFS] section 2.1.1.2. Windows-based CIFS servers are configured to listen on additional NetBIOS-based transports as specified in [MS-CIFS] section 2.1, when the appropriate link layers are available. These settings can also be obtained via policy or DHCP configuration.
<34> Section 3.1.1: Windows-specific transport names are as specified in the product behavior note for svti3_transportname in section 2.2.4.96.
<35> Section 3.1.1: Windows stores the list of all active shares that are identified by a share identifier in the registry, at the path HKEY_LOCAL_MACHINE|SYSTEM\CurrentControlSet\Services\lanmanserver.
<36> Section 3.1.1.7: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<37> Section 3.1.3: Windows-based servers set this flag to SV_TYPE_NT.
<38> Section 3.1.3: Windows stores these named pipes in the registry at the path "\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes".
The following table lists the named pipe names that an anonymous user is allowed to open. The default behavior of Windows in allowing anonymous access to certain pipes has become more restrictive over time.
|
Operating system |
Pipes |
|---|---|
|
Windows NT 4.0 |
comnap, comnode, sql\query, spoolss, epmapper, locator, lsarpc, samr, netlogon, wkssvc, srvsvc, and browser |
|
Windows 2000 |
comnap, comnode, sql\query, spoolss, epmapper, locator, trkwks, trksvr, lsarpc, samr, netlogon, wkssvc, srvsvc, and browser |
|
Windows XP |
comnap, comnode, sql\query, spoolss, browser |
|
Windows Server 2003 |
comnap, comnode, sql\query, spoolss, netlogon, lsarpc, samr, browser |
|
Windows Vista, Windows Server 2008 |
browser |
|
Windows Server 2008 R2 operating system and later, Windows 7 operating system and later |
No pipes are allowing anonymous access |
<39> Section 3.1.3: In Windows, the dependency chain for a service group ensures that the server service starts before the SMB and SMB2 services.
<40> Section 3.1.3: By default, Windows sets the values as follows:
sv103_version_major is set to 3.
sv103_version_minor is set to 10.
sv103_comment is set to empty string.
sv103_users is set to 0xFFFFFFFF.
sv103_disc is set to 15.
sv103_hidden is set to FALSE.
sv103_announce is set to 240.
sv103_anndelta is set to 3000.
<41> Section 3.1.3: By default, Windows sets the values as follows:
sv599_sessopens is set to 2048.
sv599_sessvcs is set to 1.
sv599_opensearch is set to 2048.
sv599_sizreqbuf is set to 4356.
sv103_disc is set to 15.
sv599_initworkitems is set to 4.
sv599_maxworkitems is set to 16.
sv599_rawworkitems is set to 4.
sv599_irpstacksize is set to 11.
sv599_maxrawbuflen is set to 65535.
sv599_sessusers is set to 2048.
sv599_sessconns is set to 2048.
sv599_maxpagedmemoryusage is set to 0xFFFFFFFF.
sv599_maxnonpagedmemoryusage is set to 0xFFFFFFFF.
sv599_enablesoftcompat is set to TRUE.
sv599_enableforcedlogoff is set to TRUE.
sv599_timesource is set to FALSE.
sv599_acceptdownlevelapis is set to TRUE.
sv599_lmannounce is set to FALSE.
sv599_domain is set to "DOMAIN".
sv599_maxcopyreadlen is set to 8192.
sv599_maxcopywritelen is set to 0.
sv599_minkeepsearch is set to 480.
sv599_maxkeepsearch is set to 3600.
sv599_minkeepcomplsearch is set to 240.
sv599_maxkeepcomplsearch is set to 600.
sv599_threadcountadd is set to 2.
sv599_numblockthreads is set to 2.
sv599_scavtimeout is set to 30.
sv599_minrcvqueue is set to 2.
sv599_minfreeworkitems is set to 2.
sv599_xactmemsize is set to 0x100000.
sv599_threadpriority is set to 1.
sv599_maxmpxct is set to 50.
sv599_oplockbreakwait is set to 35.
sv599_oplockbreakresponsewait is set to 35.
sv599_enableoplocks is set to TRUE.
sv599_enableoplockforceclose is set to FALSE.
sv599_enablefcbopens is set to TRUE.
sv599_enableraw is set to TRUE.
sv599_enablesharednetdrives is set to FALSE.
sv599_minfreeconnections is set to 2.
sv599_maxfreeconnections is set to 2.
sv599_initsesstable is set to 4.
sv599_initconntable is set to 8.
sv599_initfiletable is set to 16.
sv599_initsearchtable is set to 8.
sv599_alertschedule is set to 5.
sv599_errorthreshold is set to 10.
sv599_networkerrorthreshold is set to 5.
sv599_diskspacethreshold is set to 10.
sv599_maxlinkdelay is set to 60.
sv599_minlinkthroughput is set to 0.
sv599_linkinfovalidtime is set to 60.
sv599_scavqosinfoupdatetime is set to 300.
sv599_maxworkitemidletime is set to 30.
<42> Section 3.1.4: In Windows Server 2003 operating system and later, messages that are discussed in section NetrDfsGetVersion (Opnum 43) (section 3.1.4.35) through section NetrDfsManagerReportSiteInfo (Opnum 52) (section 3.1.4.43) (that is, all messages whose names begin with NetrDfs) have been deprecated. Calling them on Windows Server 2003 operating system and later returns an implementation-specific error code.
<43> Section 3.1.4: Windows implementation uses the RPC protocol to retrieve the identity of the caller specified in [MS-RPCE] section 3.3.3.4.3. The server uses the underlying Windows security subsystem to determine the permissions for the caller. If the caller does not have the required permissions to execute a specific method, the method call fails with an implementation-specific error code.
<44> Section 3.1.4.1: The Windows implementation checks to see whether the caller is a member of the Administrator, Server or Print Operator, or Power User local group.
<45> Section 3.1.4.1: If the caller is not a member of the Administrator, Server or Print Operator, or Power User local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<46> Section 3.1.4.2: The Windows implementation checks to see whether the caller is a member of the Administrator or Server Operator local group.
<47> Section 3.1.4.2: If the caller is not a member of the Administrator or Server Operator local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<48> Section 3.1.4.3: The Windows implementation checks to see whether the caller is a member of the Administrator or Server Operator local group.
<49> Section 3.1.4.3: If the caller is not a member of the Administrator or Server Operator local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<50> Section 3.1.4.4: The Windows implementation checks to see whether the caller is a member of the Administrator or Server Operator local group.
<51> Section 3.1.4.4: If the caller is not a member of the Administrator or Server Operator local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<52> Section 3.1.4.5: The Windows implementation checks to see whether the caller is a member of the Administrator or Server Operator local group.
<53> Section 3.1.4.5: If the caller is not a member of the Administrator or Server Operator local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<54> Section 3.1.4.6: The Windows implementation checks to see whether the caller is a member of the Administrators or Server Operators local group.
<55> Section 3.1.4.6: If the caller is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<56> Section 3.1.4.7: If the requested share is a file share, the Windows implementation checks whether the caller is a member of the Administrators, System Operators, or Power Users local group. If the requested share is a printer share, the Windows implementation checks whether the caller is a member of the Print Operators group.
<57> Section 3.1.4.7: Only members of the Administrators, System Operators, or Power Users local group can add file shares with a call to the NetrShareAdd method. A member of the Print Operators group can add printer shares. If this condition is not met, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<58> Section 3.1.4.8: The Windows implementation checks to see whether the caller is a member of the Administrator or Server Operator local group.
<59> Section 3.1.4.8: If the caller is not a member of the Administrator or Server Operator local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<60> Section 3.1.4.9: The server stores information about sticky shares in the Windows registry.
<61> Section 3.1.4.10: If the requested level is 2, 502, or 503, the Windows implementation checks to see whether the caller is in the Administrators, Server or Print Operators, or Power Users local group. No special group membership is required for other levels.
<62> Section 3.1.4.10: Only members of the Administrators, Server or Print Operators, or Power Users local group can successfully execute the NetrShareGetInfo message at levels 2, 502, or 503. No special group membership is required for the other levels. If this condition is not met, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<63> Section 3.1.4.11: If the value of Level is 1005, the shi1005_flags parameter contains SHI1005_FLAGS_ENABLE_HASH, and the server does not support branch cache, the server fails the call with the error code ERROR _NOT_SUPPORTED. This error is supported in Windows Server 2008 R2 operating system and later.
<64> Section 3.1.4.11: If the value of Level is 1005, the shi1005_flags parameter contains SHI1005_FLAGS_ENABLE_HASH, and the server does not install the branch cache component, the server fails the call with the error code ERROR_SERVICE_DOES_NOT_EXIST. This error is supported in Windows Server 2008 R2 operating system and later.
<65> Section 3.1.4.11: If Level=1005 and shi*_type do not have the flag STYPE_DISKTREE, the server fails the call by using an implementation-specific error code.
<66> Section 3.1.4.11: Windows checks whether the caller is a member of the Administrators or Server Operators local group.
<67> Section 3.1.4.11: If the caller is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<68> Section 3.1.4.12: Windows uses the registry as permanent storage.
<69> Section 3.1.4.12: Windows-based clients set this field to an arbitrary value. The actual value does not affect server behavior because the server is required to ignore this field.
<70> Section 3.1.4.12: If the specified share is a file share, the Windows implementation checks to see whether the caller is a member of the Administrators, Server Operators, or Power Users local group. If the specified share is a printer share, the Windows implementation checks to see whether the caller is a member of the Print Operator group.
<71> Section 3.1.4.12: Only members of the Administrators, Server Operators, or Power Users local group can successfully delete file shares by using a NetrShareDel message call. The Print Operator can delete printer shares. If the caller does not meet these requirements, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<72> Section 3.1.4.13: Windows-based clients set this field to an arbitrary value. The actual value does not affect server behavior because the server is required to ignore this field.
<73> Section 3.1.4.13: Windows uses the registry as the permanent storage.
<74> Section 3.1.4.13: If the specified share is a file share, the Windows implementation checks to see whether the caller is a member of the Administrators, Server Operators, or Power Users local group. If the specified share is a printer share, the Windows implementation checks to see whether the caller is a member of the Print Operator group.
<75> Section 3.1.4.13: Only members of the Administrators, Server Operators, or Power Users local group can successfully delete file shares with a NetrShareDelSticky message call. The Print Operator can delete printer shares. If the caller does not meet these requirements, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<76> Section 3.1.4.14: If the specified share is a file share, the Windows implementation checks to see whether the caller is a member of the Administrators, Server Operators, or Power Users local group. If the share that is specified is a printer share, the Windows implementation checks to see whether the caller is a member of the Print Operator group.
<77> Section 3.1.4.14: Only members of the Administrators, Server Operators, or Power Users local group can successfully delete file shares with a NetrShareDelStart message call. The Print Operator can delete printer shares. If the caller does not meet these requirements, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<78> Section 3.1.4.17: The value 103 is supported in Windows Server 2008 R2 operating system and later.
<79> Section 3.1.4.17: The SERVER_INFO_103 structure is supported in Windows Server 2008 R2 operating system and later.
<80> Section 3.1.4.17: If the level is 503, the Windows implementation checks whether the caller is a member of the Administrators or Server Operators local group. If the level is 102 or 502, the Windows implementation checks whether the caller is a member of one of the groups previously mentioned or is a member of the Power Users local group.
<81> Section 3.1.4.17: If the caller is not a member of the Administrators or Server Operators local group and the level is 503, the server fails the calls with an implementation-specific error code. If the caller is not a member of one of the groups previously mentioned, the caller is not a member of the Power Users local group, and the level is 102 or 502, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<82> Section 3.1.4.18: This information is stored in the Windows registry.
<83> Section 3.1.4.18: If any member of the structure ServerInfo is found invalid, the server fails the call with an implementation-specific error code.
<84> Section 3.1.4.18: The Windows implementation checks whether the client is a member of the Administrators or Server Operators local group.
<85> Section 3.1.4.18: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<86> Section 3.1.4.19: The Windows implementation checks to see whether the client is a member of the Administrators or Server Operators local group.
<87> Section 3.1.4.19: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<88> Section 3.1.4.20: The Windows implementation checks to see whether the client is a member of the Administrators or Server Operators local group.
<89> Section 3.1.4.20: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<90> Section 3.1.4.21: No special group membership is required to successfully execute this message.
<91> Section 3.1.4.21: No special group membership is required to successfully execute this message.
<92> Section 3.1.4.22: The Windows implementation checks to see if the client is a member of the Administrators or Server Operators local group.
<93> Section 3.1.4.22: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<94> Section 3.1.4.23: The Windows implementation checks to see whether the client is a member of the Administrators or Server Operators local group.
<95> Section 3.1.4.23: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<96> Section 3.1.4.24: The Windows implementation checks to see whether the caller is a member of the Administrators, Server Operators, or Power Users local group.
<97> Section 3.1.4.24: If the caller is not a member of the Administrators, Server Operators, or Power Users local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<98> Section 3.1.4.25: The Windows implementation checks to see if the client is a member of the Administrators or Server Operators local group.
<99> Section 3.1.4.25: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<100> Section 3.1.4.26: Windows Vista operating system and later, Windows Server 2008 operating system and later return 0x00000000 even when the transport that is being deleted does not exist or has already been deleted.
<101> Section 3.1.4.26: The method NetrServerTransportDelEx is defined only on Windows XP operating system and later, Windows Vista operating system and later.
<102> Section 3.1.4.26: The Windows implementation checks to see whether the client is a member of the Administrators or Server Operators local group.
<103> Section 3.1.4.26: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<104> Section 3.1.4.27: Windows-based servers fail the call with an ERROR_INVALID_PARAMETER if the file does not exist.
<105> Section 3.1.4.27: In order to read the owner, group, or discretionary access control list (DACL) [MS-DTYP] from the security descriptor for the specified file or directory or the DACL for the file or directory, the caller has to have READ_CONTROL access, or the caller has to be the owner of the file or directory. In order to read the system access control list (SACL) [MS-DTYP] of a file or directory, the SE_SECURITY_NAME privilege [MS-DTYP] has to be enabled for the calling process.
<106> Section 3.1.4.27: If the caller does not meet the security measures that are specified for the Windows implementation, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<107> Section 3.1.4.28: This message executes successfully only if the following conditions are met:
If the owner of the object is being set, the client has to either have WRITE_OWNER permission or be the owner of the object.
If the DACL of the object is being set, the client has to either have WRITE_DAC permission or be the owner of the object.
If the SACL of the object is being set, the SE_SECURITY_NAME privilege has to be enabled for the client.
<108> Section 3.1.4.28: If the server does not meet the security measures that are specified for the Windows implementation, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<109> Section 3.1.4.29: No security restrictions are imposed by Windows implementations on the caller.
<110> Section 3.1.4.29: No security restrictions are imposed by Windows implementations on the caller.
<111> Section 3.1.4.30: Windows-based servers fail the call with an ERROR_INVALID_PARAMETER error code if the value of Flags is other than 0x00000000, 0x00000001, 0x80000000, or 0x80000001.
<112> Section 3.1.4.30: Windows uses "\" as the path separator.
<113> Section 3.1.4.30: Windows uses "\" as the path separator. The Windows implementation does the following during canonicalization:
All macros in the input file name (\., .\, \.., ..\) are removed and replaced by path components.
Any required translations are performed on the path specification:
UNIX-style "/" converted to DOS-style "\"
Specific transliteration
Note The input case is NOT converted. The underlying file system can be case insensitive. The path is passed through, with the case exactly as presented by the caller.
Device names (that is, namespace controlled by the server) are canonicalized by converting device names to uppercase and removing trailing colons in all but disk devices.
<114> Section 3.1.4.30: No security restrictions are imposed by Windows-based server implementations on the caller.
<115> Section 3.1.4.30: No security restrictions are imposed by Windows-based server implementations on the caller.
<116> Section 3.1.4.31: If the Flags parameter is 1, the server ignores the PathType parameter.
<117> Section 3.1.4.31: The server does a standard C string comparison on the canonicalized path names and returns the result.
<118> Section 3.1.4.31: No security restrictions are imposed by Windows-based server implementations on the caller.
<119> Section 3.1.4.31: No security restrictions are imposed by Windows-based server implementations on the caller.
<120> Section 3.1.4.32: Windows-based servers fail the call with ERROR_INVALID_PARAMETER if the value of Flags is other than 0x00000000 and 0x80000000.
<121> Section 3.1.4.32: No security restrictions are imposed by Windows-based server implementations on the caller.
<122> Section 3.1.4.32: No security restrictions are imposed by Windows implementations on the caller.
<123> Section 3.1.4.33: No security restrictions are imposed by Windows-based server implementations on the caller.
<124> Section 3.1.4.33: No security restrictions are imposed by Windows-based server implementations on the caller.
<125> Section 3.1.4.34: The server does a string comparison and returns the results for all NameTypes except NAMETYPE_COMPUTER, NAMETYPE_WORKGROUP, and NAMETYPE_DOMAIN. For these, the server first converts the names to the corresponding OEM character set for the local environment and then does a string comparison on the resultant strings.
<126> Section 3.1.4.34: No security restrictions are imposed by Windows-based server implementations on the caller.
<127> Section 3.1.4.34: No security restrictions are imposed by Windows-based server implementations on the caller.
<128> Section 3.1.4.35: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<129> Section 3.1.4.35: This method is supported only in Windows 2000 and Windows XP. Otherwise, it returns an ERROR_FILE_NOT_FOUND error code.
<130> Section 3.1.4.35: The server always sets the Version parameter to zero.
<131> Section 3.1.4.35: No security restrictions are imposed by Windows-based server implementations on the caller.
<132> Section 3.1.4.35: No security restrictions are imposed by Windows-based server implementations on the caller.
<133> Section 3.1.4.36: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<134> Section 3.1.4.36: Windows implementations use the CoCreateGuid() API to create a unique GUID. For more information about the CoCreateGuid() API, see [MSDN-CoCreateGuid].
<135> Section 3.1.4.36: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<136> Section 3.1.4.36: Both ShortName and EntryPrefix are used to match a DFS path. If the latter does not match but the first matches, the server tries to use that.
<137> Section 3.1.4.36: No security restrictions are imposed by Windows-based server implementations on the caller.
<138> Section 3.1.4.36: No security restrictions are imposed by Windows-based server implementations on the caller.
<139> Section 3.1.4.37: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<140> Section 3.1.4.37: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<141> Section 3.1.4.37: No security restrictions are imposed by Windows-based server implementations on the caller.
<142> Section 3.1.4.37: No security restrictions are imposed by Windows-based server implementations on the caller.
<143> Section 3.1.4.38: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<144> Section 3.1.4.38: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<145> Section 3.1.4.38: No security restrictions are imposed by Windows-based server implementations on the caller.
<146> Section 3.1.4.38: No security restrictions are imposed by Windows-based server implementations on the caller.
<147> Section 3.1.4.39: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<148> Section 3.1.4.39: The ShortPrefix parameter is only supported in Windows 2000 and Windows XP. When supported, ShortPrefix has one leading backslash instead of the usual two, and is without a terminating null character. If the ShortPrefix size is greater than the size specified in ShortPrefixLen, it returns a NULL (zero-length) string and does not fail. Otherwise, it returns ERROR_NOT_SUPPORTED.
<149> Section 3.1.4.39: This method is supported only in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<150> Section 3.1.4.39: No security restrictions are imposed by Windows-based server implementations on the caller.
<151> Section 3.1.4.39: No security restrictions are imposed by Windows-based server implementations on the caller.
<152> Section 3.1.4.40: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<153> Section 3.1.4.40: This method is supported only in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<154> Section 3.1.4.40: No security restrictions are imposed by Windows-based server implementations on the caller.
<155> Section 3.1.4.40: No security restrictions are imposed by Windows-based server implementations on the caller.
<156> Section 3.1.4.41: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<157> Section 3.1.4.41: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<158> Section 3.1.4.41: No security restrictions are imposed by Windows-based server implementations on the caller.
<159> Section 3.1.4.41: No security restrictions are imposed by Windows-based server implementations on the caller.
<160> Section 3.1.4.42: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<161> Section 3.1.4.42: The target is specified in the form of a Windows NT path name. Windows subsystem DLLs add the prefix "\??" to names that are passed by Windows applications that reference objects in \DosDevices. "\DosDevices" represents a symbolic link to a directory in the object manager namespace that stores MS-DOS device names as \DosDevices\DosDeviceName. An example of a device with an MS-DOS device name is the serial port, COM1. It has the MS-DOS device name \DosDevices\COM1. Likewise, the C: drive has the name \DosDevices\C:.
<162> Section 3.1.4.42: This method is supported only in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<163> Section 3.1.4.42: Windows subsystem DLLs add the prefix "\??" to names that are passed by Windows applications that reference objects in \DosDevices. "\DosDevices" represents a symbolic link to a directory in the object manager namespace that stores MS-DOS device names.
<164> Section 3.1.4.42: No security restrictions are imposed by Windows-based server implementations on the caller.
<165> Section 3.1.4.42: No security restrictions are imposed by Windows-based server implementations on the caller.
<166> Section 3.1.4.43: Windows allows the server administrator to configure a static list of site names to be returned by this method. If the Active Directory administrator changes site names and the server administrator does not update the static list, or the server administrator makes an error, this method will return names that are not current Active Directory site names.
<167> Section 3.1.4.43: This method is only supported in Windows 2000 and Windows XP. Otherwise, it returns an implementation-specific error code.
<168> Section 3.1.4.43: Windows implementations first seek within the registry subkey SYSTEM\CurrentControlSet\Services\DfsDriver\CoveredSites for a value that matches the ServerName parameter. If that value is present and a REG_MULTI_SZ value, its contents form the list returned by the method. Otherwise, the list is formed in the next two steps.
First, the implementation makes a call to the local Netlogon Remote Protocol server using the DsrGetSiteName method, as specified in [MS-NRPC] section 3.5.4.3.6. In this call, a NULL ComputerName argument is provided. If successful and a site name is returned, this name forms part of the response. This site name will be marked with the DFS_SITE_PRIMARY flag, as specified in section 2.2.4.109 of this document.
Second, the implementation seeks the registry value SYSTEM\CurrentControlSet\Services\DfsDriver\CoveredSites\CoveredSites . If that value is present and a REG_MULTI_SZ value, its contents form the rest of the list returned by the method.
<169> Section 3.1.4.43: No security restrictions are imposed by Windows-based server implementations on the caller.
<170> Section 3.1.4.43: No security restrictions are imposed by Windows-based server implementations on the caller.
<171> Section 3.1.4.44: The Windows implementation checks to see if the client is a member of the Administrators or Server Operators local group.
<172> Section 3.1.4.44: If the client is not a member of the Administrators or Server Operators local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<173> Section 3.1.4.45: The Windows implementation checks to see if the caller is a member of the Administrator or Server Operator local group.
<174> Section 3.1.4.45: If the caller is not a member of the Administrator or Server Operator local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<175> Section 3.1.4.46: If the specified share is a file share, the Windows implementation checks to see whether the caller is a member of the Administrators, Server Operators, or Power Users local group. If the specified share is a printer share, the Windows implementation checks to see whether the caller is a member of the Print Operator group.
<176> Section 3.1.4.46: Only members of the Administrators, Server Operators, or Power Users local group can successfully delete file shares by using a NetrShareDel message call. The Print Operator can delete printer shares. If the caller does not meet these requirements, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<177> Section 3.1.4.47: Windows uses the registry as permanent storage.
<178> Section 3.1.4.47: If the specified share is a file share, the Windows implementation checks to see whether the caller is a member of the Administrators, Server Operators, or Power Users local group. If the specified share is a printer share, the Windows implementation checks to see whether the caller is a member of the Print Operator group.
<179> Section 3.1.4.47: Only members of the Administrators, Server Operators, or Power Users local group can successfully delete file shares by using a NetrShareDel message call. The Print Operator can delete printer shares. If the caller does not meet these requirements, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.
<180> Section 3.1.6.13: The Windows implementation checks to see whether the caller is a member of the Administrator, Server Operator, or Power User local group.
<181> Section 3.1.6.13: If the caller is not a member of the Administrator, Server Operator, or Power User local group, Windows-based servers fail the call with the error code ERROR_ACCESS_DENIED.