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.
Client
Windows NT operating system
Windows 2000 operating system
Windows XP operating system
Windows Vista operating system
Windows 7 operating system
Windows 8 operating system
Windows 8.1 operating system
Windows 10 operating system
Windows 11 operating system
Server
Windows Server 2003 operating system
Windows Server 2003 R2 operating system
Windows Server 2008 operating system
Windows Server 2008 R2 operating system
Windows Server 2012 operating system
Windows Server 2012 R2 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 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.4: Windows implementations use the DsrGetDcNameEx2 method of the local Netlogon Remote Protocol server ([MS-NRPC] section 3.4.5.1.1) to locate a domain controller when communication to a domain controller is specified.
<2> Section 1.4: Windows implementations use LDAP as a client when queries or modifications to directory objects are specified.
<3> Section 1.8: Windows only uses the values in [MS-ERREF].
<4> Section 2.1: Windows implementations use the identity of the caller to perform method-specific access checks.
<5> Section 2.2.5.8: Windows server implementations represent the name of the device in the form "\Device\<device_name>", where <device_name> is a local device in the NT namespace. Examples:
\Device\NetbiosSmb
\Device\NetBT_Tcpip_{E30E2FF4-044F-403B-9906-8E58FDFAD018}
Note that the names are driver-specific.
<6> Section 2.2.5.8: Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2003 R2 implementations set the wkti0_transport_address parameter for the NetBIOS over TCP/IP (NetBT) transport protocol to a string that represents the IEEE 802.1 Media Access Control (MAC) address [IEEE802.1X] of the transport protocol. The string is formatted as described in IEEE 802.1 but with separator characters removed. For example, the MAC address "00-0F-FE-51-DE-3B" results in the wkti0_transport_address string "000FFE51DE3B".
<7> Section 2.2.5.9: In Windows implementations, the account name that was used to authenticate (2) the user on the computer is used as the user name.
<8> Section 2.2.5.11: In Windows implementations, the RawReadsDenied parameter contains an indeterminate value on send and is ignored on receipt, except on Windows NT, on which the value is undefined.
<9> Section 2.2.5.11: In Windows implementations, the RawWritesDenied parameter contains an indeterminate value on send and is ignored on receipt, except on Windows NT, on which the value is undefined.
<10> Section 2.2.5.19: The JOINPR_ENCRYPTED_USER_PASSWORD_AES structure is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 operating system with Service Pack 1 (SP1) and later, and Windows Server 2008 R2 operating system and later) and is recommended.
<11> Section 3.2.1.1: The NetSecurityDescriptor security descriptor is not defined on the following versions of Windows: Windows NT, Windows 2000, Windows XP operating system Service Pack 1 (SP1), and Windows Server 2003 before the release of Windows Server 2003 operating system with Service Pack 1 (SP1).
<12> Section 3.2.1.2: Windows versions implement alternate-computer-names (section 3.2.1.2), except on Windows NT, and Windows 2000, where the default state for this list is empty.
<13> Section 3.2.1.3: Windows versions retrieve OtherDomainsInitialization, (section 3.2.1.3), from the registry and return an empty list. Windows 2000, Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, and Windows Server 2008 servers retrieve OtherDomainsInitialization from local registry values.
<14> Section 3.2.1.6: Domains on Windows NT do not have DNS names, so DomainName.FQDN is not established in that case.
<15> Section 3.2.3: Windows server implementations initialize this value to 1023. Windows 2000, Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, and Windows Server 2008 servers initialize this value to 45.
<16> Section 3.2.3: Windows server implementations initialize this value to 600 seconds.
<17> Section 3.2.3: Windows server implementations initialize this value to 50.
<18> Section 3.2.3: Windows server implementations initialize this value to 0x000001F4, which is the value for Windows (section 2.2.5.1).
<19> Section 3.2.3: Windows server implementations initialize this value to 60 seconds.
<20> Section 3.2.3: Windows server implementations initialize this value to the major version number of the server operating system.
<21> Section 3.2.3: Windows server implementations initialize this value to the minor version number of the server operating system.
<22> Section 3.2.3: Windows server implementations set this to hexadecimal string representation of the 6-byte physical address of the interface.
<23> Section 3.2.3: Windows server implementations use the name of the transport device name associated with the transport specified in the WKSTA_TRANSPORT_INFO_0 structure (section 2.2.5.8).
<24> Section 3.2.3: Windows server implementations set this to any value.
<25> Section 3.2.3: Windows server implementations set this to TRUE for NetBIOS transports.
<26> Section 3.2.4: Windows: The underlying security subsystem is used to determine the permissions for the caller.
<27> Section 3.2.4: Gaps in the opnum numbering sequence apply to Windows as follows:
|
Opnum |
Description |
|---|---|
|
3 |
Only used locally by Windows, never remotely. |
|
4 |
Only used locally by Windows, never remotely. |
|
8 |
Only used locally by Windows, never remotely. |
|
9 |
Only used locally by Windows, never remotely. |
|
10 |
Only used locally by Windows, never remotely. |
|
11 |
Only used locally by Windows, never remotely. |
|
12 |
Only used locally by Windows, never remotely. |
|
14 |
Only used locally by Windows, never remotely. |
|
15 |
Only used locally by Windows, never remotely. |
|
16 |
Just returns ERROR_NOT_SUPPORTED. It is never used. |
|
17 |
Just returns ERROR_NOT_SUPPORTED. It is never used. |
|
18 |
Just returns ERROR_NOT_SUPPORTED. It is never used. |
|
19 |
Just returns ERROR_NOT_SUPPORTED. It is never used. |
|
21 |
Just returns ERROR_NOT_SUPPORTED. It is never used. |
Windows error codes are specified in [MS-ERREF] section 2.2.
<28> Section 3.2.4: Windows implementations do not establish SMB sessions or SMB share connections during message processing, except on Windows NT and Windows 2000.
<29> Section 3.2.4.1: Windows server implementations require that the caller be a member of the Administrators group if the Level parameter is equal to 0x00000066 or 0x000001F6. If the caller is not a member of the Administrators group, the server (2) fails the method with ERROR_ACCESS_DENIED.
<30> Section 3.2.4.1: Windows server implementations set wki502_dormant_file_limit to zero, except on Windows NT.
<31> Section 3.2.4.2: Windows server implementations fail the call with ERROR_INVALID_PARAMETER.
<32> Section 3.2.4.2: Windows implementations use the values of these members to configure the SMB redirector, except where noted. The server stores the value and returns it when the client requests it.
<33> Section 3.2.4.2: Windows requires that the caller is a member of the Administrators group; otherwise, the server fails the method with ERROR_ACCESS_DENIED.
<34> Section 3.2.4.3: Windows implementations return the zero-based index of the user to be enumerated from the list of currently logged-on users.
<35> Section 3.2.4.3: Windows requires that the caller is a member of the Administrators group.
<36> Section 3.2.4.3: Windows server implementations identify every active user by a logon number. Logon numbers are monotonically increasing in order. Active users are enumerated in increasing order of logon number. ResumeHandle stores the logon number of the last user returned to the client. If NetrWkstaUserEnum (section 3.2.4.3) is called with a nonzero ResumeHandle, the server only enumerates those active users who have a logon number greater than the ResumeHandle.
<37> Section 3.2.4.4: Windows implementations return the zero-based index of the transport protocol to be enumerated from the list of currently enabled transport protocols.
<38> Section 3.2.4.4: Windows server implementations do not enforce this security measure.
<39> Section 3.2.4.4: Windows implementations maintain an array of transport protocols currently enabled for use by the SMB network redirector. Currently enabled transport protocols are enumerated starting at the beginning of this array. ResumeHandle stores the position in this array of the last transport protocol returned to the client. If NetrWkstaTransportEnum (section 3.2.4.4) is called with a non-zero ResumeHandle, the server begins enumerating the array from one position ahead of the ResumeHandle. If transport protocols are added or deleted from this array in-between calls to NetrWkstaTransportEnum, some transports might not be enumerated at all, or some transports might be enumerated multiple times.
<40> Section 3.2.4.4: Windows implementations set the TotalEntries value to zero.
<41> Section 3.2.4.5: This method is deprecated on Windows releases. If the Level parameter is set to zero and the caller belongs to the Administrators group, Windows server implementations return ERROR_INVALID_FUNCTION without any further processing.
This method is not deprecated on Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2.
<42> Section 3.2.4.5: Windows NT requires that the caller be a member of the Administrators group.
<43> Section 3.2.4.6: This method is deprecated on Windows releases. If the ForceLevel parameter is set to 0x00000000, 0x00000001, or 0x00000002, and the caller belongs to the Administrators group, Windows implementations return ERROR_INVALID_FUNCTION.
This method is not deprecated on Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2.
<44> Section 3.2.4.6: Windows NT requires that the caller be a member of the Administrators group.
<45> Section 3.2.4.7: Although Windows implementations, expose this RPC call to remote callers, it is called only by processes on the local machine. Windows clients do not issue this RPC call to a remote machine.
<46> Section 3.2.4.7: Windows requires the caller to be a member of either the Administrators or standard user group.
<47> Section 3.2.4.8: Although Windows server implementations expose this RPC call to remote callers, it is intended to be called only by processes on the local machine. Windows clients do not issue this RPC call to a remote machine.
<48> Section 3.2.4.8: Windows requires the caller to be a member of the Administrators or standard user group.
<49> Section 3.2.4.9: Windows server implementations expose this RPC call to remote callers, but it is intended to be called only by processes on the local machine. Windows clients do not issue this RPC call to a remote machine.
<50> Section 3.2.4.9: Windows callers are members of either the Administrators or standard user group.
<51> Section 3.2.4.10: Windows server implementations expose this RPC call to remote callers, but it is intended to be called only by processes on the local machine. Windows client implementations on do not issue this RPC call to a remote machine.
<52> Section 3.2.4.10: Windows requires the caller to be a member of either the Administrators or standard user group.
<53> Section 3.2.4.10: Windows implementations return the zero-based index of the user to be enumerated from the list of currently logged-on users.
<54> Section 3.2.4.11: Windows requires that the caller is a member of the Administrators or standard user group.
<55> Section 3.2.4.11: Windows implementations use these values as counters for the number of I/Os performed for each type. For information on paging, and the I/O system for background on these values, see [WININTERNALS] chapters 7 and 9.
<56> Section 3.2.4.12: Windows implementations enforce the verification of the proper RPC protocol sequence, except in the following versions: Windows NT, Windows 2000, and Windows XP without service packs.
<57> Section 3.2.4.13: This method is not available on Windows NT.
<58> Section 3.2.4.13: Besides the values defined in the table in this section, the following option is applicable only to Windows server implementations.
|
Value/code |
Meaning |
|---|---|
|
NETSETUP_WIN9X_UPGRADE 0x00000010 |
The join operation occurs as part of an upgrade from Windows 95 operating system to Windows NT, Windows 98 operating system to Windows 2000, or Windows Millennium Edition operating system, or Windows XP. |
<59> Section 3.2.4.13: Windows NT and Windows 2000 do not implement this behavior.
<60> Section 3.2.4.13: Windows implementations do not update the DnsHostName and SPN properties on the computer during message processing when NETSETUP_DEFER_SPN_SET is specified. The values are updated in a subsequent call to NetrRenameMachineInDomain2 (section 3.2.4.15).
Windows NT and Windows 2000 do not implement this behavior.
<61> Section 3.2.4.13: Windows implementations do not update the DnsHostName and SPN properties on the computer during message processing when NETSETUP_DEFER_SPN_SET is specified. The values are updated in a subsequent call to NetrRenameMachineInDomain2 (section 3.2.4.15).
Windows NT and Windows 2000 do not implement this behavior.
<62> Section 3.2.4.13: Windows implementations continue message processing of a domain join when the domain-object already exists, and that object is a domain controller account and NETSETUP_JOIN_DC_ACCOUNT is specified.
Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not implement this behavior.
<63> Section 3.2.4.13: Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 implementations do not support NETSETUP_JOIN_DC_ACCOUNT.
Windows client implementations pass NETSETUP_JOIN_DC_ACCOUNT, which servers on Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 ignore. Clients on Windows NT do not support this behavior.
When setting this flag, Windows client implementations locate a domain controller on a server. The location mechanism is specified in the DsrGetDcNameEx2 method ([MS-NRPC] section 3.5.4.3.1); the flag description for DS_FULL_SECRET_DOMAIN_6_FLAG is specified in [MS-ADTS] section 6.3.3.2.
The use of DS_FULL_SECRET_DOMAIN_6_FLAG ensures the location of a domain controller on applicable Windows server implementations. Windows 2000 Server operating system, Windows Server 2003, and Windows Server 2003 R2 server implementations do not support this behavior.
<64> Section 3.2.4.13: Windows implementations use the most recently set computer name during a domain join when NETSETUP_JOIN_WITH_NEW_NAME is specified. Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not implement this behavior.
In the Windows implementation of a computer rename, a computer is restarted before a new name can be used. This flag allows the new name to be used for a join before a restart. For example, processing a NetrRenameMachineInDomain2 message (section 3.2.4.15) would change the persisted abstract state ComputerName (section 3.2.1.2), but the change would not be effective until after a machine restart. Specifying this flag would cause the join operation to use the new ComputerName when joining the domain.
<65> Section 3.2.4.13: Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not implement this option.
<66> Section 3.2.4.13: Windows implementations indicate that concurrent calls to this method are not supported. Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not implement this behavior.
<67> Section 3.2.4.13.1: Windows implementations pass NETSETUP_MACHINE_PWD_PASSED or NETSETUP_DEFER_SPN. This flag is ignored by Windows NT and Windows 2000 implementations.
<68> Section 3.2.4.13.1: Windows implementations define NETSETUP_IGNORE_UNSUPPORTED_FLAGS but do not set the flag. This flag is ignored by Windows NT, Windows 2000, and Windows XP server implementations.
<69> Section 3.2.4.13.1: Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not support NETSETUP_JOIN_DC_ACCOUNT.
When setting the NETSETUP_JOIN_DC_ACCOUNT flag, clients on Windows server implementations locate a domain controller on other Windows server implementations. Windows NT Server operating system, Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2 do not support this behavior.
Using the DS_FULL_SECRET_DOMAIN_6_FLAG flag ([MS-ADTS] section 6.3.3.2) ensures locating a domain controller with that version.
<70> Section 3.2.4.13.1: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<71> Section 3.2.4.13.1: Windows Vista Home Basic and Windows Vista Home Premium implementations return ERROR_NOT_SUPPORTED if this method is invoked.
<72> Section 3.2.4.13.2: Windows implementations find and set the described state through the following sequence:
1. The computer account object is created at a writable domain controller (writable DC) using the SamrCreateUser2InDomain method ([MS-SAMR] section 3.1.5.4.4).
2. The LDAP attributes userAccountControl and unicodePwd ([MS-ADA3] section 2.342 and [MS-ADA3] section 2.332, respectively) are set using the SamrSetInformationUser2 method of [MS-SAMR] section 3.1.5.6.4.
3. The LDAP attributes dNSHostName and servicePrincipalName ([MS-ADTS] section 3.1.1.3.2.4 or [MS-ADA1] section 2.185, and [MS-ADA3] section 2.253, respectively) are set using the LDAP protocol ([RFC2252] and [RFC2253]).
<73> Section 3.2.4.13.3: Windows implementations send an LsarOpenPolicy2 request to a domain controller and, using the returned policy handle [MS-LSAD], query for the domain name and SID by sending an LsarQueryInformationPolicy2 request for InformationClass PolicyDnsDomainInformation, followed by sending an LsarQueryInformationPolicy request for InformationClass PolicyPrimaryDomainInformation.
<74> Section 3.2.4.13.3: Windows implementations use the algorithm specified in [FIPS186-2] for generating each byte of the machine password. [FIPS186-2] Appendix 3.1 describes a pseudo-random number generator (PRNG) that can use either DES or SHA-1. Windows implementations use a SHA-1–based PRNG to satisfy FIPS 140-2 level 2 cryptographic module certification requirements [FIPS140].
In the PRNG description of [FIPS186-2] Appendix 3.1, G is constructed from SHA-1 with the first parameter as the initial value for the SHA-1 registers, whereas the second parameter is the data input to be hashed.
Integer b is replaced with 160.
XKEY is determined by a call to an RC4-based PRNG.
The variable q is not used in the general-purpose version of [FIPS186-2] (Appendix 6.9 General Purpose Random Number Generation).
XSEEDj is also determined by a call to an RC4-based PRNG for every block output by the [FIPS186-2] PRNG.
The variable m is the number of blocks that can be output by the [FIPS186-2] PRNG before a non-NULL value is passed to XSEEDj. Windows implementations set it to the shortest possible value, which is 1.
<75> Section 3.2.4.13.3: Windows implementations store the Internet host name of the computer locally based on a local, configurable setting, which, by default, is set to store the name.
<76> Section 3.2.4.14: This method is not available on Windows NT.
<77> Section 3.2.4.14: Windows NT, Windows 2000, and Windows XP do not support this flag.
<78> Section 3.2.4.14: Windows implementations save the original state in memory for the duration of message processing before making any changes, and when message processing encounters an error, the original state is restored before returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
Persisted state manipulations are performed using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis; if an error is encountered during the restoration process, the computer is left in a different state than it was immediately before the call was processed.
<79> Section 3.2.4.14: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1.
<80> Section 3.2.4.14: Windows implementations update the Internet host name of the computer locally based on a local configurable setting, which, by default, is set to store the name.
<81> Section 3.2.4.15: This method is not available on Windows NT.
<82> Section 3.2.4.15: Only Windows 2000 implementations return this error.
<83> Section 3.2.4.15: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
Persisted state manipulations are performed using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis: if an error is encountered during the restoration process, the server is left in a state different than it was in immediately prior to the call being processed.
<84> Section 3.2.4.15: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1.
<85> Section 3.2.4.15: Windows uses a syntactic/textual conversion. This conversion limits computer names to be the common subset of the names. Specifically, the name's leftmost label is truncated to 15-bytes of OEM characters in uppercase.
<86> Section 3.2.4.15: Windows populates the DNS suffix using Group Policy from the domain. Group Policy updates the following registry key:
HKLM\Software\Policies\Microsoft\System\DNSclientNV PrimaryDnsSuffix
If this setting is not available, the TCP/IP setting for the domain is queried and is used as the DNS suffix.
If that is not available either, the fully qualified domain name (FQDN) (2) of the domain is used as the DNS suffix.
<87> Section 3.2.4.16: This method is not available on Windows NT.
<88> Section 3.2.4.16: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1.
<89> Section 3.2.4.16: Windows implementations verify that the caller is local and return RPC_E_REMOTE_DISABLED if not, except on Windows NT, Windows 2000, Windows XP, and Windows XP SP1.
<90> Section 3.2.4.16: Windows implementation: The name is added as a NetBIOS group name. If the operation succeeds, the name is verified as valid; the name [RFC1001] is deleted to undo the addition of the name. Otherwise, the name is not valid; ERROR_INVALID_PARAMETER is returned.
<91> Section 3.2.4.16: Windows implementation: The name is added as a NetBIOS unique name. If the operation succeeds, the name is verified as valid and not in use; the name [RFC1001] is deleted to undo the addition of the name. Otherwise, the name is not valid; ERROR_DUP_NAME is returned if the name [RFC1001] is already in use.
<92> Section 3.2.4.16: Windows implementation: The DsrGetDcNameEx2 method of the local [MS-NRPC] server is used to verify that a domain controller can be found for the domain. If the locator succeeds in finding any domain controller in the domain, this condition is verified. Otherwise, ERROR_NO_SUCH_DOMAIN is returned.
<93> Section 3.2.4.16: Windows implementation: The DsrGetDcNameEx2 method of the local [MS-NRPC] server is used to determine if a domain controller can be found for the domain. If the locator finds a domain controller in the domain, ERROR_DUP_NAME is returned. Otherwise, this condition is verified.
<94> Section 3.2.4.17: This method is not available on Windows NT.
<95> Section 3.2.4.17: Windows implementations return this error to indicate that the password is incorrect.
<96> Section 3.2.4.17: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1.
<97> Section 3.2.4.17: Windows implementations verify that the caller is local, except on Windows NT, Windows 2000, Windows XP, and Windows XP SP1.
<98> Section 3.2.4.17: Windows implementations fail this call on a domain controller, and NERR_InvalidAPI is returned.
<99> Section 3.2.4.18: This method is not available on Windows NT and Windows 2000.
<100> Section 3.2.4.18: Windows NT, Windows 2000, and Windows XP implementations do not check the NET_IGNORE_UNSUPPORTED_FLAGS bit.
<101> Section 3.2.4.18: Windows NT, Windows 2000, Windows XP, and Windows Server 2003 do not indicate that concurrent calls to this method are not supported.
<102> Section 3.2.4.18: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call. Persisted state manipulations are performed using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis: if an error is encountered during the restoration process, the computer is left in a different state than it was before the call was processed.
<103> Section 3.2.4.18: Windows implementations enforce the verification of the proper RPC protocol sequence. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<104> Section 3.2.4.18: Windows clients return ERROR_NOT_SUPPORTED if this method is invoked.
<105> Section 3.2.4.18: Windows uses a syntactic/textual conversion. This conversion limits the names of computers to be the common subset of the names. Specifically, the leftmost label of the name is truncated to 15 bytes of OEM characters in uppercase.
<106> Section 3.2.4.19: This method is not available on Windows NT and Windows 2000.
<107> Section 3.2.4.19: Windows NT, Windows 2000, and Windows XP implementations do not check the NET_IGNORE_UNSUPPORTED_FLAGS bit.
<108> Section 3.2.4.19: Windows implementations indicate that concurrent calls to this method are not supported:
<109> Section 3.2.4.19: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error, the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
Persisted state manipulations are performed by using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis: If an error is encountered during the restoration process, the computer is left in a different state than it was before the call was processed.
<110> Section 3.2.4.19: Windows implementations enforce the verification of the proper RPC protocol sequence. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<111> Section 3.2.4.19: Windows client return ERROR_NOT_SUPPORTED if this method is invoked.
<112> Section 3.2.4.19: Windows uses a syntactic/textual conversion. This conversion limits the names of computers to the common subset of the names. Specifically, the leftmost label of the name is truncated to 15-bytes of OEM characters in uppercase.
<113> Section 3.2.4.20: This method is not available on Windows NT and Windows 2000.
<114> Section 3.2.4.20: Windows NT, Windows 2000, and Windows XP implementations do not check the NET_IGNORE_UNSUPPORTED_FLAGS bit.
<115> Section 3.2.4.20: Windows implementations indicate that concurrent calls to this method are not supported.
<116> Section 3.2.4.20: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error, the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
Persisted state manipulations are performed by using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis: If an error is encountered during the restoration process, the computer is left in a different state than it was before the call was processed.
<117> Section 3.2.4.20: Windows implementations enforce the verification of the proper RPC protocol sequence. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<118> Section 3.2.4.20: Windows clients return ERROR_NOT_SUPPORTED if this method is invoked.
<119> Section 3.2.4.20: Windows server implementations use a syntactic/textual conversion. This conversion limits the names of computers to the common subset of the names. Specifically, the leftmost label of the name is truncated to 15 bytes of OEM characters in uppercase.
<120> Section 3.2.4.21: This method is not available on Windows NT and Windows 2000.
<121> Section 3.2.4.21: Windows NT, Windows 2000, and Windows XP implementations do not check the NET_IGNORE_UNSUPPORTED_FLAGS bit.
<122> Section 3.2.4.21: Windows implementations enforce the verification of the proper RPC protocol sequence.
<123> Section 3.2.4.21: When this method is invoked, Windows implementations return ERROR_NOT_SUPPORTED.
<124> Section 3.2.4.22: The NetrJoinDomain3 method is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 SP1 and later, and Windows Server 2008 R2 and later) and is recommended.
<125> Section 3.2.4.22: Besides the values defined in the table in this section, the following option is applicable only to Windows server implementations.
|
Value/code |
Meaning |
|---|---|
|
NETSETUP_WIN9X_UPGRADE 0x00000010 |
The join operation occurs as part of an upgrade from Windows 95 operating system to Windows NT, Windows 98 operating system to Windows 2000, or Windows Millennium Edition operating system, or Windows XP. |
<126> Section 3.2.4.22: Windows NT and Windows 2000 operating system do not implement this behavior.
<127> Section 3.2.4.22: Windows implementations do not update the DnsHostName and SPN properties on the computer during message processing when NETSETUP_DEFER_SPN_SET is specified. The values are updated in a subsequent call to NetrRenameMachineInDomain2 (section 3.2.4.15).
<128> Section 3.2.4.22: Windows implementations do not update the DnsHostName and SPN properties on the computer during message processing when NETSETUP_DEFER_SPN_SET is specified. The values are updated in a subsequent call to NetrRenameMachineInDomain2 (section 3.2.4.15).
Windows NT and Windows 2000 do not implement this behavior.
<129> Section 3.2.4.22: Windows implementations continue message processing of a domain join when the domain-object already exists, and that object is a domain controller account and NETSETUP_JOIN_DC_ACCOUNT is specified.
<130> Section 3.2.4.22: Windows NT, Windows 2000, Windows XP operating system, Windows Server 2003 operating system, and Windows Server 2003 R2 implementations do not support NETSETUP_JOIN_DC_ACCOUNT.
Windows client implementations pass NETSETUP_JOIN_DC_ACCOUNT, which servers on Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 ignore. Clients on Windows NT do not support this behavior.
When setting this flag, Windows client implementations locate a domain controller on a server. The location mechanism is specified in the DsrGetDcNameEx2 method ([MS-NRPC] section 3.5.4.3.1); the flag description for DS_FULL_SECRET_DOMAIN_6_FLAG is specified in [MS-ADTS] section 6.3.3.2.
The use of DS_FULL_SECRET_DOMAIN_6_FLAG ensures the location of a domain controller on applicable Windows server implementations. Windows 2000 Server operating system operating system, Windows Server 2003, and Windows Server 2003 R2 implementations do not support this behavior.
<131> Section 3.2.4.22: Windows implementations use the most recently set computer name during a domain join when NETSETUP_JOIN_WITH_NEW_NAME is specified. Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not implement this behavior.
In the Windows implementation of a computer rename, a computer is restarted before a new name can be used. This flag allows the new name to be used for a join before a restart. For example, processing a NetrRenameMachineInDomain2 message (section 3.2.4.15) would change the persisted abstract state ComputerName (section 3.2.1.2), but the change would not be effective until after a machine restart. Specifying this flag would cause the join operation to use the new ComputerName when joining the domain.
<132> Section 3.2.4.22: Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not implement this option.
<133> Section 3.2.4.22: Windows implementations indicate that concurrent calls to this method are not supported. Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not implement this behavior.
<134> Section 3.2.4.22.1: Windows implementations pass NETSETUP_MACHINE_PWD_PASSED or NETSETUP_DEFER_SPN. This flag is ignored by Windows NT and Windows 2000 implementations.
<135> Section 3.2.4.22.1: Windows implementations define NETSETUP_IGNORE_UNSUPPORTED_FLAGS but do not set the flag. This flag is ignored by Windows NT, Windows 2000, and Windows XP server implementations.
<136> Section 3.2.4.22.1: Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 do not support NETSETUP_JOIN_DC_ACCOUNT.
When setting the NETSETUP_JOIN_DC_ACCOUNT flag, clients on Windows server implementations locate a domain controller on other Windows server implementations. Windows NT Server operating system, Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2 do not support this behavior.
Using the DS_FULL_SECRET_DOMAIN_6_FLAG flag ([MS-ADTS] section 6.3.3.2) ensures locating a domain controller with that version.
<137> Section 3.2.4.22.1: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<138> Section 3.2.4.22.1: Windows Vista Home Basic operating system and Windows Vista Home Premium operating system implementations return ERROR_NOT_SUPPORTED if this method is invoked.
<139> Section 3.2.4.22.2: Windows implementations find and set the described state through the following sequence:
1. The computer account object is created at a writable domain controller (writable DC) using the SamrCreateUser2InDomain method ([MS-SAMR] section 3.1.5.4.4).
2. The LDAP attributes userAccountControl and unicodePwd ([MS-ADA3] section 2.342 and 2.332, respectively) are set using the SamrSetInformationUser2 method of [MS-SAMR] section 3.1.5.6.4.
3. The LDAP attributes dNSHostName and servicePrincipalName ([MS-ADTS] section 3.1.1.3.2.4 or [MS-ADA1] section 2.185, and [MS-ADA3] section 2.253, respectively) are set using the LDAP protocol ([RFC2252] and [RFC2253]).
<140> Section 3.2.4.23: The NetrUnJoinDomain3 method is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 SP1 and later, and Windows Server 2008 R2 and later) and is recommended.
<141> Section 3.2.4.23: Windows NT, Windows 2000, and Windows XP do not support this flag.
<142> Section 3.2.4.23: Windows implementations save the original state in memory for the duration of message processing before making any changes, and when message processing encounters an error, the original state is restored before returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
Persisted state manipulations are performed using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis; if an error is encountered during the restoration process, the computer is left in a different state than it was immediately before the call was processed.
<143> Section 3.2.4.23: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1.
<144> Section 3.2.4.23: Windows implementations update the Internet host name of the computer locally based on a local configurable setting, which, by default, is set to store the name.
<145> Section 3.2.4.24: This method is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 SP1 and later, and Windows Server 2008 R2 and later) and is recommended.
<146> Section 3.2.4.24: Only Windows 2000 implementations return this error.
<147> Section 3.2.4.24: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
Persisted state manipulations are performed using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis: if an error is encountered during the restoration process, the server is left in a state different than it was in immediately prior to the call being processed.
<148> Section 3.2.4.24: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1.
<149> Section 3.2.4.24: Windows uses a syntactic/textual conversion. This conversion limits computer names to be the common subset of the names. Specifically, the name's leftmost label is truncated to 15-bytes of OEM characters in uppercase.
<150> Section 3.2.4.24: Windows populates the DNS suffix using Group Policy from the domain. Group Policy updates the following registry key:
HKLM\Software\Policies\Microsoft\System\DNSclientNV PrimaryDnsSuffix
If this setting is not available, the TCP/IP setting for the domain is queried and is used as the DNS suffix.
<151> Section 3.2.4.25: This method is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 SP1 and later, and Windows Server 2008 R2 and later) and is recommended.
<152> Section 3.2.4.25: Windows implementations enforce the verification of the proper RPC protocol sequence, except on Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 before Windows Server 2003 with SP1.
<153> Section 3.2.4.25: Windows implementations verify that the caller is local and return RPC_E_REMOTE_DISABLED if not, except on Windows NT, Windows 2000, Windows XP, and Windows XP SP1.
<154> Section 3.2.4.25: Windows implementation: The name is added as a NetBIOS group name. If the operation succeeds, the name is verified as valid; the name [RFC1001] is deleted to undo the addition of the name. Otherwise, the name is not valid; ERROR_INVALID_PARAMETER is returned.
<155> Section 3.2.4.25: Windows implementation: The name is added as a NetBIOS unique name. If the operation succeeds, the name is verified as valid and not in use; the name [RFC1001] is deleted to undo the addition of the name. Otherwise, the name is not valid; ERROR_DUP_NAME is returned if the name [RFC1001] is already in use.
<156> Section 3.2.4.25: Windows implementation: The DsrGetDcNameEx2 method of the local [MS-NRPC] server is used to verify that a domain controller can be found for the domain. If the locator succeeds in finding any domain controller in the domain, this condition is verified. Otherwise, ERROR_NO_SUCH_DOMAIN is returned.
<157> Section 3.2.4.25: Windows implementation: The DsrGetDcNameEx2 method of the local [MS-NRPC] server is used to determine if a domain controller can be found for the domain. If the locator finds a domain controller in the domain, ERROR_DUP_NAME is returned. Otherwise, this condition is verified.
<158> Section 3.2.4.26: This method is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 SP1 and later, and Windows Server 2008 R2 and later) and is recommended.
<159> Section 3.2.4.26: Windows NT, Windows 2000, and Windows XP implementations do not check the NET_IGNORE_UNSUPPORTED_FLAGS bit.
<160> Section 3.2.4.26: Windows NT, Windows 2000, Windows XP, and Windows Server 2003 do not indicate that concurrent calls to this method are not supported.
<161> Section 3.2.4.26: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call. Persisted state manipulations are performed using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis: if an error is encountered during the restoration process, the computer is left in a different state than it was before the call was processed.
<162> Section 3.2.4.26: Windows implementations enforce the verification of the proper RPC protocol sequence. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<163> Section 3.2.4.26: Windows clients return ERROR_NOT_SUPPORTED if this method is invoked.
<164> Section 3.2.4.26: Windows uses a syntactic/textual conversion. This conversion limits the names of computers to be the common subset of the names. Specifically, the leftmost label of the name is truncated to 15 bytes of OEM characters in uppercase.
<165> Section 3.2.4.27: This method is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 SP1 and later, and Windows Server 2008 R2 and later) and is recommended.
<166> Section 3.2.4.27: Windows NT, Windows 2000, and Windows XP implementations do not check the NET_IGNORE_UNSUPPORTED_FLAGS bit.
<167> Section 3.2.4.27: Windows implementations indicate that concurrent calls to this method are not supported.
<168> Section 3.2.4.27: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error, the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
<169> Section 3.2.4.27: Windows implementations enforce the verification of the proper RPC protocol sequence. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<170> Section 3.2.4.27: Windows clients return ERROR_NOT_SUPPORTED if this method is invoked.
<171> Section 3.2.4.27: Windows uses a syntactic/textual conversion. This conversion limits the names of computers to the common subset of the names. Specifically, the leftmost label of the name is truncated to 15-bytes of OEM characters in uppercase.
<172> Section 3.2.4.28: This method is available after the [MSFT-CVE-2022-21924] security update (applies to Windows 7 SP1 and later, and Windows Server 2008 R2 and later) and is recommended.
<173> Section 3.2.4.28: Windows NT, Windows 2000, and Windows XP implementations do not check the NET_IGNORE_UNSUPPORTED_FLAGS bit.
<174> Section 3.2.4.28: Windows implementations indicate that concurrent calls to this method are not supported.
<175> Section 3.2.4.28: Windows implementations save the original state in memory for the duration of message processing prior to making any changes, and when message processing encounters an error, the original state is restored prior to returning to the caller. This state is not persisted or retained beyond the processing duration of a call.
Persisted state manipulations are performed by using local services or other network protocols as referenced in the message processing section. This is done on a best-effort basis: If an error is encountered during the restoration process, the computer is left in a different state than it was before the call was processed.
<176> Section 3.2.4.28: Windows implementations enforce the verification of the proper RPC protocol sequence. If the server identifies a previous RPC call that is modifying the identity of the machine, the server returns RPC_S_CALL_IN_PROGRESS.
<177> Section 3.2.4.28: Windows clients return ERROR_NOT_SUPPORTED if this method is invoked.
<178> Section 3.2.4.28: Windows server implementations use a syntactic/textual conversion. This conversion limits the names of computers to the common subset of the names. Specifically, the leftmost label of the name is truncated to 15 bytes of OEM characters in uppercase.