8 Appendix B: Product Behavior

Artículo
06/24/2021

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs.

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.

The following tables show the relationships between Microsoft product versions or supplemental software and the roles they perform.

Windows Client releases	Client role	Server role
Windows 2000 Professional operating system	Yes	Yes
Windows XP operating system	Yes	Yes
Windows Vista operating system	Yes	Yes
Windows 7 operating system	Yes	Yes
Windows 8 operating system	Yes	Yes
Windows 8.1 operating system	Yes	Yes
Windows 10 operating system	Yes	Yes
Windows 11 operating system	Yes	Yes

Windows Server releases	Client role	Server role
Windows 2000 Server operating system	Yes	Yes
Windows Server 2003 operating system	Yes	Yes
Windows Server 2003 R2 operating system	Yes	Yes
Windows Server 2008 operating system	Yes	Yes
Windows Server 2008 R2 operating system	Yes	Yes
Windows Server 2012 operating system	Yes	Yes
Windows Server 2012 R2 operating system	Yes	Yes
Windows Server 2016 operating system	Yes	Yes
Windows Server operating system	Yes	Yes
Windows Server 2019 operating system	Yes	Yes
Windows Server 2022 operating system	Yes	Yes
Windows Server 2025 operating system	Yes	Yes

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 2.1: Applicable Windows Server releases listen only on the RPC-over-TCP protocol sequence. Windows clients attempt to connect using only the RPC-over-TCP protocol sequence.

<2> Section 2.2.2: Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 AD DS DCs do not store the "RPC" SPN.

<3> Section 2.2.3: Windows implements DC-to-DC interaction with an SPN with service class "E3514235-4B06-11D1-AB04-00C04FC2DCD2". See DRS_SPN_CLASS.

<4> Section 2.2.4.2: SPN "ldap/<NetBIOS hostname>/<NetBIOS domain name>" is available in Windows Server 2008 R2 and later.

<5> Section 4.1: All IDL methods and their associated concrete types have existed in the drsuapi RPC interface since Windows 2000 operating system except those listed in the following table. All IDL methods and their associated concrete types continue to exist in this interface in subsequent versions of Windows according to the applicability list at the beginning of this section.

Data type or IDL method	Section	Introduced in Windows Server release
DRS_MSG_GETCHGREQ_V7 support	4.1.10.2.5	Windows Server 2003
DRS_MSG_GETREPLINFO_REQ_V2	4.1.13.1.3	Windows Server 2003
DRS_MSG_DCINFOREPLY_V3	4.1.5.1.6	Windows Server 2008
DS_DOMAIN_CONTROLLER_INFO_3W	4.1.5.1.10	Windows Server 2008
DRS_MSG_GETCHGREQ_V8 support	4.1.10.2.6	Windows Server 2003
DRS_MSG_GETCHGREQ_V10 support	4.1.10.2.7	Windows Server 2008 R2
DRS_MSG_GETCHGREPLY_V6 support	4.1.10.2.12	Windows Server 2003
DRS_MSG_GETCHGREPLY_V7 support	4.1.10.2.13	Windows Server 2003
DRS_MSG_GETCHGREPLY_V9 support	4.1.10.2.14	Windows Server 2016
DRS_MSG_ADDENTRYREQ_V3 support	4.1.1.1.4	Windows Server 2003
DRS_MSG_ADDENTRYREPLY_V3 support	4.1.1.1.8	Windows Server 2003
IDL_DRSGetObjectExistence	4.1.12	Windows Server 2003
IDL_DRSReplicaVerifyObjects	4.1.24	Windows Server 2003
IDL_DRSFinishDemotion	4.1.7	Windows Server 2008
IDL_DRSInitDemotion	4.1.14	Windows Server 2008
IDL_DRSReplicaDemotion	4.1.21	Windows Server 2008
IDL_DRSAddCloneDC	4.1.29	Windows Server 2012
IDL_DRSWriteNgcKey	4.1.30	Windows Server 2016
IDL_DRSReadNgcKey	4.1.31	Windows Server 2016
DRS_MSG_GETCHGREQ_V11 support	4.1.10.2.8	Windows Server v1803 operating system
DRS_MSG_REPADD_V3 support	4.1.19.1.4	Windows Server v1803
DRS_MSG_REPSYNC_V2 support	4.1.23.1.3	Windows Server v1803
DRS_MSG_UPDREFS_V2 support	4.1.26.1.3	Windows Server v1803

<6> Section 4.1.1.1.2: Though this request version appears in the IDL, Windows DCs do not support it. It was never supported in any of the applicable Windows Server releases.

<7> Section 4.1.1.1.6: Though this response version appears in the IDL, Windows DCs do not support it.

<8> Section 4.1.1.3: This operation is only supported by AD LDS and AD DS in Windows Server 2008 and later.

<9> Section 4.1.2.2.6: The function determines whether auditing is enabled on the server by querying the LSA information policy on the server associated with ctx and by confirming that the information policy is set to generate both success and failure audits for the "account management" audit category. To achieve this, the LsarOpenPolicy2, LsarQueryInformationPolicy, and LsarClose messages in [MS-LSAD] are used ([MS-LSAD] sections 3.1.4.4.1, 3.1.4.4.4, and 3.1.4.9.4). The srcDomainController variable in the IDL_DRSAddSidHistory method is used as the SystemName parameter to LsarOpenPolicy2, and the DesiredAccess parameter to LsarOpenPolicy2 is set to (POLICY_VIEW_AUDIT_INFORMATION + POLICY_VIEW_LOCAL_INFORMATION). On success, the PolicyHandle acquired from the LsarOpenPolicy2 message is passed to LsarQueryInformationPolicy with PolicyAuditEventsInformation as the information class. The check to determine whether success and failure audits are enabled for "account management" is achieved by performing the following evaluation:

 PolicyInformation^.PolicyAuditEventsInfo.EventAuditingOptions[6] ∩
   { POLICY_AUDIT_EVENT_SUCCESS, POLICY_AUDIT_EVENT_FAILURE } =
 { POLICY_AUDIT_EVENT_SUCCESS, POLICY_AUDIT_EVENT_FAILURE }

where PolicyInformation is the result from the LsarQueryInformationPolicy message. PolicyHandle is then closed by using the LsarClose message.

The function generates an audit on the DC associated with ctx by adding the source principal (pmsgIn^.V1.SrcPrincipal, where pmsgIn is a parameter to the IDL_DRSAddSidHistory method, which in turn calls this method) to the group srcDomainFlatName$$$ on the DC associated with ctx, where srcDomainFlatName is the NetBIOS name of the domain to which the source principal belongs. After adding the principal to the group, it then removes the principal from the group, leaving the group in its original state but having generated an audit event as a side effect of manipulating the group's membership.

<10> Section 4.1.2.2.13: This test is implemented in two steps. First, it is determined if the DC associated with ctx is running at least Windows 2000. This is determined by whether a SamrConnect5 or SamrConnect4 API call (as specified in [MS-SAMR]) to the DC is successful. If it is, the DC is running at least Windows 2000, and the function returns true.

Otherwise, the DC is considered to be running Windows NT 4.0 operating system. The function then connects to the registry service on the DC named in ctx and queries the value of the "CSDVersion" registry value on the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" registry key. If the value is not equal to any of the following strings, the function returns true; otherwise, it returns false:

Service Pack 0
Service Pack 1
Service Pack 2
Service Pack 3

If the registry service on the DC could not be contacted, or if the registry key or registry value does not exist, the function returns false.

<11> Section 4.1.3.1: Windows non-DC client callers always pass NTDSAPI_CLIENT_GUID in puuidClientDsa. If a Windows DC client caller uses the returned DRS_HANDLE for subsequent calls to the IDL_DRSWriteSPN method, then the client passes NTDSAPI_CLIENT_GUID in puuidClientDsa. In any other cases, Windows DC client callers pass DC!serverGuid in puuidClientDsa.

<12> Section 4.1.3.1: Windows non-DC client callers always set the dwFlags field of the DRS_EXTENSIONS_INT structure to zero. Windows non-DC client callers always set the SiteObjGuid field of the DRS_EXTENSIONS_INT structure to the NULL GUID value. Windows non-DC client callers always set the Pid field of the DRS_EXTENSIONS_INT structure to an implementation-specific, client-local process identifier (PID).

Windows non-DC clients do not include the following fields in the DRS_EXTENSIONS_INT structure. In addition, the following fields are included by Windows DC clients only if the clients are running the corresponding versions of Windows.

Field	Included by
ConfigObjGUID	Windows DC clients running Windows Server 2003 R2 (AD LDS only) and Windows Server 2008 and later.
dwFlagsExt	Windows DC clients running Windows Server 2003 R2 (AD LDS only) and Windows Server 2008 and later.
dwExtCaps	Windows DC clients running Windows Server 2012 R2 and later.

<13> Section 4.1.3.2: The ConfigObjGUID and dwFlagsExt fields in the DRS_EXTENSIONS_INT structure are included only by servers running Windows Server 2003 R2 (AD LDS only) and Windows Server 2008 and later.

<14> Section 4.1.5.2: All of the information levels listed in section 4.1.5.2 have existed in the drsuapi RPC interface since Windows 2000, except as noted in the following table.

Infolevel	Introduced in Windows Server release
3	Windows Server 2008

<15> Section 4.1.6.3: The Windows implementation of this method puts the KCC execution requests in a local-machine work queue. If DS_KCC_FLAG_DAMPED is specified in the call to IDL_DRSExecuteKCC and there is already a request pending, the execution request is not added to the queue in order to reduce redundant requests.

<16> Section 4.1.7.3: The Windows implementation of the IDL_DRSFinishDemotion method causes the underlying RPC protocol [MS-RPCE] to throw an RPC_S_INVALID_TAG exception when returning ERROR_INVALID_PARAMETER.

<17> Section 4.1.10.1.1: The Windows implementation never declares msgIn.uuidInvocIdSrc and msgIn.usnvecFrom that are otherwise valid to be stale.

<18> Section 4.1.10.1.1: The internal format of USN_VECTOR identifies the start of a cycle.

<19> Section 4.1.10.1.2: The goal is advanced on each request of a cycle.

<20> Section 4.1.10.1.2: c.usnHighPropUpdate is never set to 0.

<21> Section 4.1.10.1.3: The Request Role extended operation is supported by Windows 2000 Server and later.

<22> Section 4.1.10.1.3: The Abandon Role extended operation is supported by Windows 2000 Server and later.

<23> Section 4.1.10.1.3: The Allocate RIDs extended operation is supported by Windows 2000 Server and later.

<24> Section 4.1.10.1.3: The Replicate Single Object extended operation is supported by Windows Server 2003 and later.

<25> Section 4.1.10.1.3: The Replicate Single Object including Secret Data extended operation is supported by Windows Server 2008 and later.

<26> Section 4.1.10.2.2: Though this request version appears in the IDL, Windows DCs never send this request version by means of RPC. It exists solely to support SMTP replication (see [MS-SRPL]).

<27> Section 4.1.10.2.3: Although this request version appears in the IDL, Windows DCs never send this request version using RPC. It exists solely to support SMTP replication ([MS-SRPL]).

<28> Section 4.1.10.2.5: Though this request version appears in the IDL, Windows DCs never send this request version using RPC. It exists solely to support SMTP replication ([MS-SRPL]).

<29> Section 4.1.10.2.19: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 enforce the following range for the cbCompressedSize member: "[range(1,10485760)]".

<30> Section 4.1.10.5.7: The server tests the response against the limits after adding each object and link to the response, unless the object is a parent object that is being included because of the Ancestors predicate (see the GetReplChanges method). If the test shows that the response has exceeded one of the limits, the server stops adding to the response. The server might return more objects or bytes than the limits.

<31> Section 4.1.10.6.6: Windows DCs assign the remainder of the bits in values of o!instanceType for a given object o as follows:

IT_UNINSTANT: Set if and only if o is an NC root and its NC replica is not present on the DC.
IT_NC_ABOVE: Set if and only if o is an NC root and the DC has an NC replica with NC root p such that p is the parent of o.
IT_NC_COMING: Set if and only if o is an NC root and the DC has not yet completed the first replication cycle for that NC replica.
IT_NC_GOING: Set if and only if o is an NC root and the DC is in the process of removing its replica of the NC.

<32> Section 4.1.12.3: Windows uses count = 1000.

<33> Section 4.1.14.2: The Windows implementation of the IDL_DRSInitDemotion method causes the underlying RPC protocol (as specified in [MS-RPCE]) to throw an RPC_S_INVALID_TAG exception when returning ERROR_ACCESS_DENIED.

<34> Section 4.1.15.1.2: Although this request version appears in the IDL, Windows DCs do not support it. It was never supported in any of the applicable Windows Server releases.

<35> Section 4.1.15.1.5: Although this response version appears in the IDL, Windows DCs do not support it.

<36> Section 4.1.16.3: The server returns the error ERROR_DS_GENERIC_ERROR if the Intersite Messaging Service is not running on the server.

<37> Section 4.1.24.3: The Windows implementation of the for loop uses IDL_DRSGetObjectExistence to determine if object o exists at refDsa, and logs a message to the Windows Event Log.

<38> Section 5.39: In Windows 2000 Server, the cb field contains the count of bytes in the fields dwFlags through Pid, inclusive, which is the size of the structure in that version minus the 4 bytes of the cb field.

<39> Section 5.39: In AD DS and AD LDS servers running Windows Server 2003, and in AD DS servers running Windows Server 2003 R2, the cb field contains the count of bytes in the fields dwFlags through dwReplEpoch, inclusive, which is the size of the structure in those versions minus the 4 bytes of the cb field.

<40> Section 5.39: In Windows Server 2003 R2 (AD LDS only), Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, the cb field contains the count of bytes in the fields dwFlags through ConfigObjGUID, inclusive, which is the size of the structure in those versions minus the 4 bytes of the cb field.

<41> Section 5.39: Client callers set dwFlags to zero.

<42> Section 5.39: This field contains the process ID of the client or server process, depending on which is current.

<43> Section 5.39: The dwReplEpoch field in the DRS_EXTENSIONS_INT structure is included only by servers running Windows Server 2003 and later.

<44> Section 5.39: The ConfigObjGUID and dwFlagsExt fields in the DRS_EXTENSIONS_INT structure are included only by AD DS servers running Windows Server 2008 and later, and by AD LDS servers running Windows Server 2003 R2 and later.

<45> Section 5.39: The ConfigObjGUID and dwFlagsExt fields in the DRS_EXTENSIONS_INT structure are included only by AD DS servers running Windows Server 2008 and later, and by AD LDS servers running Windows Server 2003 R2 and later.

<46> Section 5.39: The dwExtCaps field in the DRS_EXTENSIONS_INT structure is included only by AD DS and AD LDS servers running Windows Server 2012 R2 and later.

<47> Section 5.41: All the DRS_OPTIONS listed in section 5.41 have existed in the drsuapi RPC interface since Windows 2000 except those listed in the following table.

Flag	Introduced in Windows Server release
DRS_SYNC_PAS	Windows Server 2003

This flag is ignored inbound on the operating systems that are prior to its introduction.

All the DRS_OPTIONS listed in section 5.41 continue to exist in this interface in subsequent versions of Windows according to the applicability list at the beginning of this section, except those listed in the following table.

Flag	Deprecated in Windows Server release
DRS_SYNC_ALL	Windows Server 2012

This flag is not to be used on the operating system from which it was removed or on subsequent versions of the operating system. If this flag is used on a deprecated platform, the error code ERROR_DS_DRA_INVALID_PARAMETER will be returned.

The following pseudocode specifies how to unmask the flags that are unsupported for each operating system.

 msgReq.ulFlags &= msgReq.ulFlags & allowedFlagsForSpecificOS

<48> Section 5.50: No range is supported on any member of DSNAME in Windows 2000 Server. A range of 0 to 10485760 is supported on the NameLen member of DSNAME in Windows Server 2003 and Windows Server 2003 R2. A range of 0 to 10485761 is supported on the StringName member of DSNAME in Windows Server 2008 and later.

<49> Section 5.170: Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2 AD DS DCs have a value of 1 in the dwVersion field. Windows Server 2008 and later AD DS DCs have a value of 2 in the dwVersion field. Windows Server 2003 R2 and later AD LDS DCs have a value of 2 in the dwVersion field.

<50> Section 5.171: Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2 AD DS DCs have a value of 1 in the dwVersion field. Windows Server 2008 and later AD DS DCs have a value of 2 in the dwVersion field. Windows Server 2003 R2 and later AD LDS DCs have a value of 2 in the dwVersion field.

<51> Section 5.212: Windows Server 2008 and Windows Server 2008 R2 do not raise an ERROR_INVALID_PARAMETER exception when opnum==26 and IsAdlds() == false. Instead, the method IDL_DRSReplicaDemotion (section 4.1.21) executes, and the effects vary depending on the NC specified in pmsgIn.V1.pNC.

If pmsgIn.V1.pNC contains the DSNAME of the default NC, then:

The return code from IDL_DRSReplicaDemotion is ERROR_SUCCESS.
Only the FSMO roles contained within the domain NC, as described in [MS-ADTS] section 3.1.1.1.11, FSMO Roles, are transferred to a replication partner.
pmsgIn.V1.pNC!repsFrom values are not removed.

If pmsgIn.V1.pNC contains the DSNAME of the config NC, then:

The return code from IDL_DRSReplicaDemotion is ERROR_INVALID_DOMAINNAME.
No FSMO roles are transferred.
pmsgIn.V1.pNC!repsFrom values are not removed.

If pmsgIn.V1.pNC contains the DSNAME of the schema NC, then:

The return code from IDL_DRSReplicaDemotion is ERROR_INVALID_DOMAINNAME.
No FSMO roles are transferred.
pmsgIn.V1.pNC!repsFrom values are not removed.

If pmsgIn.V1.pNC contains the DSNAME of a domain NC and pmsgIn.V1.pNC!instanceType does not contain IT_WRITE, then:

The return code from IDL_DRSReplicaDemotion is ERROR_NO_SUCH_DOMAIN.
No FSMO roles are transferred.
pmsgIn.V1.pNC!repsFrom values are not removed.

If pmsgIn.V1.pNC contains the DSNAME of an application NC, then:

The return code from IDL_DRSReplicaDemotion is ERROR_NO_SUCH_DOMAIN.
No FSMO roles are transferred.
pmsgIn.V1.pNC!repsFrom values are not removed.

Compartir a través de

8 Appendix B: Product Behavior

Recursos adicionales