Export (0) Print
Expand All

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 released service packs:

  • 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

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 only uses the values in [MS-ERREF] section 2.2.

<2> Section 1.9: Windows object resolver services always use the well-known endpoints specified in [MS-RPCE] section 2.1, and will never register their interfaces with the RPCendpoint mapper. Windows DCOM clients correctly interoperate with a server whose object resolver service registers its interfaces with the RPCendpoint mapper.

<3> Section 2.1: Windows DCOM servers register all the security providers supported by the server.

<4> Section 2.2.11: The DCOM versions supported by different platforms are:

Windows 95/98

Windows NT

Windows 2000

Windows XP

Windows Server 2003

Windows Vista

Windows Server 2008

Windows 7

Windows Server 2008 R2

Windows 8

Windows Server 2012

Windows 8.1

Windows Server 2012 R2

DCOM version supported

5.4

5.4

5.6

5.7

5.7

5.7

5.7

5.7

5.7

5.7

5.7

5.7

5.7

<5> Section 2.2.11: Windows uses version 5.7, not to indicate any change in DCOM, but rather in the marshaling of the UDT type specified in [MS-OAUT] section 2.2.28.1.

<6> Section 2.2.13.1: This specification defines two formats for the ORPC_EXTENT structure. See section 2.2.21.

<7> Section 2.2.18.2: Windows will not perform garbage collectionpinging for objects unmarshaled with SORF_NOPING.

<8> Section 2.2.18.6: Windows treats this field as the CLSID for an object that both implements the IMarshal interface and is capable of unmarshaling the pObjectData field. For more information, see [MSDN-IMarshal].

<9> Section 2.2.19.1: Windows does not order the STRINGBINDING structures in the decreasing order of preference. They are passed in an arbitrary order.

<10> Section 2.2.19.3: Windows supports a subset of the constants. For details, see section 3.1.2.3.

<11> Section 2.2.19.3: Windows servers accept other forms of the IPv4 address that are accepted by inet_addr as specified in [RFC3493] section 6.3.

<12> Section 2.2.20: Windows uses IID_IContext as the IID of an interface with the local IDL attribute.

<13> Section 2.2.20: Windows uses IID_IContext as the IID of an interface with the local IDL attribute.

<14> Section 2.2.20: Windows DCOM clients set this field to a value from the MSHLFLAGS enumeration. For more information, see [MSDN-MSHLFLAGS].

<15> Section 2.2.21.1: Windows DCOM clients and servers process the OBJREF supplied in the data field of this ORPC extension as a reference to an object that supports the IErrorInfo interface. For more information, see [MSDN-IERRORINFO].

<16> Section 2.2.21.2: Optionally specifies the index for a help topic in the help file specified by the HelpFile field.

<17> Section 2.2.21.2: Optionally specifies a human-readable string containing the name of the component returning the error.

<18> Section 2.2.21.2: Optionally specifies a human-readable string containing a description of the error.

<19> Section 2.2.21.2: Optionally specifies a path to a Windows Help file containing a Help topic that provides further information for the error.

<20> Section 2.2.21.4: Windows DCOM clients set this value to the size (in bytes) of the body of the RPC PDU containing this structure.

<21> Section 2.2.21.4: This field is used by applications or higher-layer protocols. Windows DCOM clients and servers ignore this field.

<22> Section 2.2.22.1: Windows DCOM clients set this field to MSHCTX_DIFFERENTMACHINE (0x00000002), which is a value from the MSHCTX enumeration. For more information, see [MSDN-MSHCTX].

<23> Section 2.2.22.2.1: Windows DCOM clients set this field to one or more values from the CLSCTX enumeration. For more information, see [MSDN-CLSCTX].

<24> Section 2.2.22.2.2: Windows DCOM clients set this field to TRUE if the client was impersonating when the activation request was originated, and to FALSE otherwise. Windows DCOM servers ignore this field. For more information, see [MSDN-CI].

<25> Section 2.2.22.2.2: Windows DCOM clients set this field to FALSE (0x00000000) if guidPartition is not set, and to TRUE (0x00000001) otherwise. Windows DCOM servers use the guidPartition field if fPartitionIDPresent is set to TRUE.

<26> Section 2.2.22.2.2: Windows DCOM clients set this field to an RPC authentication constant (see [MS-RPCE] section 2.2.1.1.8).

<27> Section 2.2.22.2.2: The value contains a GUID used by applications or higher-layer protocols.

<28> Section 2.2.22.2.2: Windows DCOM clients set this field to the unmodified CLSCTX value specified by the client when the activation request was originated. For more information, see [MSDN-CLSCTX].

<29> Section 2.2.22.2.2: Windows 2000, Windows XP and Windows Server 2003 use SpecialPropertiesData_Alternate.

<30> Section 2.2.22.2.3: Windows DCOM clients set this to a file name passed to the CoGetInstanceFromFile API. For more information, see [MSDN-CoGetInstanceFromFile].

<31> Section 2.2.22.2.3: Windows DCOM clients set this field to the unmodified STGM constant. For more information, see [MSDN-STGMC].

<32> Section 2.2.22.2.3: Windows DCOM clients set this to the IStorage reference passed to the CoGetInstanceFromIStorage API. For more information, see [MSDN-CoGetInstanceFromIStorage].

<33> Section 2.2.22.2.4.1: Windows DCOM clients set this field to the value 2.

<34> Section 2.2.22.2.7: Windows DCOM clients include this structure; Windows DCOM servers ignore it.

<35> Section 2.2.22.2.7: Windows DCOM clients send a COSERVERINFO structure in this field as specified. Windows DCOM servers ignore this field.

<36> Section 2.2.22.2.7.1: Windows DCOM clients set pwszName to the remote server name specified by the client when requesting the activation. Windows DCOM servers ignore this field.

<37> Section 2.2.22.2.8.1: Windows DCOM servers return an RPCauthentication level that denotes the minimum authentication level at which the object exporter can be called. Windows DCOM clients make calls to object exporters at an authentication level that is at least as high as the authnHint returned from the object server.

<38> Section 3: All Windows implementations support both roles simultaneously.

<39> Section 3.1.1.5.1: Windows servers will set the SORF_NOPING flag if the application specifies the MSHLFLAGS_NOPING flag in the mshlflags parameter to the CoMarshalInterface API. For more information, see [MSDN-CoMarshalInterface].

<40> Section 3.1.1.5.4: Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 DCOM servers return E_ACCESSDENIED if the ORPC invocation is for the IRemUnknown (section 3.1.1.5.6) interface or the IRemUnknown2 (section 3.1.1.5.7) interface. They return ERROR_ACCESS_DENIED for all other interfaces. Windows NT 4.0, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 DCOM servers return E_ACCESSDENIED for all interfaces.

<41> Section 3.1.1.5.4: Windows DCOM servers use the LegacyAuthenticationLevel value (see [MSDN-LegAuthLevel] for more information) as the object exporter's default authentication level setting.

<42> Section 3.1.1.5.4: Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 DCOM servers return E_ACCESSDENIED if the ORPC invocation is for the IRemUnknown (section 3.1.1.5.6) interface or the IRemUnknown2 (section 3.1.1.5.7) interface and if the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) allows anonymous clients. They return ERROR_ACCESS_DENIED for all other interfaces or if the MachineAccessRestriction does not allow anonymous clients. Windows NT 4.0, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 DCOM servers return E_ACCESSDENIED for all interfaces.

<43> Section 3.1.1.5.4: Windows DCOM servers for Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 use the DefaultAccessPermission (see [MSDN-DefAccPerms] for more information) or the AccessPermission of the object exporter (see [MSDN-AccPerms] for more information) as the default value of the permissions.

For Windows DCOM servers on Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, the default value of the permissions consists of both:

<44> Section 3.1.1.5.4: Windows object exporters use an application-specified message filter. For more information, see [MSDN-IMessageFilter].

<45> Section 3.1.1.5.4: Windows DCOM server object exporters supply the well-known ORPC extensions (see section 2.2.21), if present, to applications and higher-layer protocols.

<46> Section 3.1.1.5.4: Windows DCOM server object exporters return the extensions field supplied by the well-known ORPC extensions (see section 2.2.21), if present.

<47> Section 3.1.1.5.4: Windows 2000, Windows XP, Windows XP SP1, Windows XP SP2, Windows Server 2003, and Windows Server 2003 with SP1 DCOM servers optionally append extra data to the end of an ORPC response. This is due to a coding error and the extra data, if present, has no meaning and is ignored by Windows recipients. Whether the data is sent or not does not affect interoperability, and the protocol functions correctly. Windows XP SP3, Windows Server 2003 SP2, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 DCOM servers do not have this coding error and do not append extra data.

<48> Section 3.1.1.5.6.1.2: Windows DCOM server object exporters require security on a RemAddRef call that specifies private reference counts. They will associate the private reference counts with the security identity of the client that makes the RemAddRef call.

<49> Section 3.1.1.5.6.1.3: Windows DCOM server object exporters require security on a RemRelease call that specifies private reference counts. They will verify that the security identity of the client that makes the RemRelease call has previously allocated at least that many private reference counts in the IPID entry.

<50> Section 3.1.1.5.8: Opnums reserved for local use apply to Windows as follows.

opnum

Description

0-2

Not used by Windows. Returns a failure if called.

Windows clients internally map the three IUnknown interface methods to the three methods of the IRemUnknowninterface.

<51> Section 3.1.2.3: By default, Windows object resolvers listen by way of the following RPC protocols.

Windows NT

Windows 2000

Windows XP

Windows Server 2003

Windows Vista

Windows Server 2008

Windows 7

Windows Server 2008 R2

Windows 8

Windows Server 2012

Windows 8.1

Windows Server 2012 R2

ncacn_ip_tcp

X

X

X

X

X

X

X

X

X

X

X

X

ncacn_spx

X

X

X

                 

ncacn_nb_nb

X

X

X

                 

ncacn_nb_ipx

X

X

X

                 

Ncadg_ip_udp

X

                     

Ncadg_ipx

X

                     

<52> Section 3.1.2.5.1.1: Windows DCOM servers return the minimum accepted authentication level of the object exporter in this field. Windows DCOM clients by default make calls to the object exporter, at least at this level of authentication.

<53> Section 3.1.2.5.1.1: Windows DCOM servers for Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 do not check permissions when processing this call.

Windows DCOM servers for Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 check permissions when processing this call. They use the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) as the default value of the permissions.

<54> Section 3.1.2.5.1.2: Windows DCOM servers for Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 do not check permissions when processing this call.

Windows DCOM servers for Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 check permissions when processing this call. They use the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) as the default value of the permissions.

<55> Section 3.1.2.5.1.3: Windows DCOM servers return a PingBackoffFactor of zero; Windows DCOM clients ignore any value returned by the server.

<56> Section 3.1.2.5.1.3: Windows DCOM servers for Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 do not check permissions when processing this call.

Windows DCOM servers for Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 check permissions when processing this call. They use the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) as the default value of the permissions.

<57> Section 3.1.2.5.1.5: Windows DCOM servers return the minimum accepted authentication level of the object exporter in this field. Windows DCOM clients by default make calls to the object exporter, at least at this level of authentication.

<58> Section 3.1.2.5.1.7: Windows object resolvers wait for up to 14 minutes before removing the OID entry from the OID table.

<59> Section 3.1.2.5.2.2: Opnums reserved for local use apply to Windows as follows.

opnum

Description

0-2

Not used by Windows. Returns a failure if called.

<60> Section 3.1.2.5.2.3: All server versions of the DCOM protocol for Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 use the DefaultLaunchPermission (see [MSDN-DefLnchPerms] for more information) or the LaunchPermission that is specific to the object exporter (see [MSDN-LaunchPerms] for more information) as the default value of the permissions.

For Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 versions of the DCOM protocol, the default value of the permissions consists of the following:

<61> Section 3.1.2.5.2.3: Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 DCOM servers return ERROR_ACCESS_DENIED if the MachineLaunchRestriction or the MachineAccessRestriction does not allow access to the client's credentials.

Windows NT 4.0, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 DCOM servers return E_ACCESSDENIED if the DefaultLaunchPermission or the LaunchPermission that is specific to the object exporter does not allow access to the client's credentials.

<62> Section 3.1.2.5.2.3: Windows 2000 object resolvers ignore the SPD_FLAG_USE_CONSOLE_SESSION flag and create the object exporter in the logon session specified in the dwSessionID field, if it is not 0xFFFFFFFF. If the dwSessionID field contains 0xFFFFFFFF, then object resolvers create the object exporter in any logon session.

<63> Section 3.1.2.5.2.3: Windows 2000 object resolvers ignore the SPD_FLAG_USE_CONSOLE_SESSION flag and create the object exporter in the logon session specified in the dwSessionID field, if it is not 0xFFFFFFFF. If the dwSessionID field contains 0xFFFFFFFF, then object resolvers create the object exporter in any logon session.

<64> Section 3.1.2.5.2.3: Windows object resolvers determine the configuration of the identity of the object exporter as described in [MSDN-RunAs].

<65> Section 3.1.2.5.2.3: Windows 2000 and Windows XP object resolvers ignore the ACTVFLAGS_ACTIVATE_32_BIT_SERVER and the ACTVFLAGS_ACTIVATE_64_BIT_SERVER flags and create the object exporter in the 32-bit address space.

<66> Section 3.1.2.5.2.3: Windows 2000 and Windows XP object resolvers ignore the ACTVFLAGS_ACTIVATE_32_BIT_SERVER and the ACTVFLAGS_ACTIVATE_64_BIT_SERVER flags and create the object exporter in the 32-bit address space.

<67> Section 3.1.2.5.2.3: Windows 2000, Windows XP, and Windows Server 2003 object resolvers ignore the ACTVFLAGS_NO_FAILURE_LOG flag and log errors during activation. Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 object resolvers log only permission failure errors when the ACTVFLAGS_NO_FAILURE_LOG flag is set and do not log any other errors.

<68> Section 3.1.2.5.2.3.1: Windows DCOM clients set this to a file name passed to the CoGetInstanceFromFile API. For more information, see [MSDN-CoGetInstanceFromFile].

<69> Section 3.1.2.5.2.3.1: Windows DCOM clients set this to the IStorage reference passed to the CoGetInstanceFromIStorage API. For more information, see [MSDN-CoGetInstanceFromIStorage].

<70> Section 3.1.2.5.2.3.1: Windows DCOM clients set this field to the value 2.

<71> Section 3.1.2.5.2.3.1: If the DCOM application passes a file name to the CoGetInstanceFromFile API. For more information, see [MSDN-CoGetInstanceFromFile].

<72> Section 3.1.2.5.2.3.1: Windows DCOM servers return the minimum accepted authentication level of the object exporter in this field. Windows DCOM clients by default make calls to the object exporter at least at this level of authentication.

<73> Section 3.1.2.5.2.3.2: Windows uses IID_IActivationPropertiesIn as the IID of an interface with the local IDL attribute.

<74> Section 3.1.2.5.2.3.2: Windows DCOM clients send all the properties (including optional properties) listed in the following table, except InstanceInfoData. InstanceInfoData is sent only when the DCOM application makes a persistent activation request.

Property Name

Section

Required or Optional

InstantiationInfoData

2.2.22.2.1

Required

ScmRequestInfoData

2.2.22.2.4

Required

LocationInfoData

2.2.22.2.6

Required

SecurityInfoData

2.2.22.2.7

Optional

ActivationContextInfoData

2.2.22.2.5

Optional

InstanceInfoData

2.2.22.2.3

Optional

SpecialPropertiesData

2.2.22.2.2

Optional

<75> Section 3.1.2.5.2.3.2: Windows uses IID_IActivationPropertiesOut as the IID of an interface with the local IDL attribute.

<76> Section 3.1.2.5.2.3.3: Windows uses IID_IActivationPropertiesIn as the IID of an interface with the local IDL attribute.

<77> Section 3.1.2.5.2.3.3: Windows DCOM clients send all the properties (including Optional properties) listed in the following table, except InstanceInfoData. InstanceInfoData is sent only when the DCOM application makes a persistent activation request.

Property name

Section

Required or optional

InstantiationInfoData

2.2.22.2.1

Required

ScmRequestInfoData

2.2.22.2.4

Required

LocationInfoData

2.2.22.2.6

Required

SecurityInfoData

2.2.22.2.7

Optional

ActivationContextInfoData

2.2.22.2.5

Optional

InstanceInfoData

2.2.22.2.3

Optional

SpecialPropertiesData

2.2.22.2.2

Optional

<78> Section 3.1.2.5.2.3.3: Windows uses IID_IActivationPropertiesOut as the IID of an interface with the local IDL attribute.

<79> Section 3.2: For details on which versions of Windows support which version of the DCOM Remote Protocol, see section 2.2.11.

<80> Section 3.2.4.1.1.2: Windows DCOM clients for Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 specify RPC_C_AUTHN_LEVEL_CONNECT (see [MS-RPCE] section 2.2.1.1.8) as the default authentication level value for the call.

Windows DCOM clients for Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 specify the higher of the LegacyAuthenticationLevel value (for more information, see [MSDN-LegAuthLevel]) and RPC_C_AUTHN_LEVEL_CONNECT (see [MS-RPCE] section 2.2.1.1.8) as the default authentication level value for the call.

<81> Section 3.2.4.1.1.2: Windows DCOM clients specify RPC_C_IMPL_LEVEL_IMPERSONATE (see [MS-RPCE] section 2.2.1.1.9) as the default impersonation level value for the call.

<82> Section 3.2.4.1.2: Windows clients will acquire an object reference for the IID specified by the application.

<83> Section 3.2.4.1.2.2: Windows DCOM clients specify RPC_C_AUTHN_LEVEL_CONNECT (see [MS-RPCE] section 2.2.1.1.8) as the authentication level for the call.

<84> Section 3.2.4.1.2.2: Windows DCOM clients specify RPC_C_IMPL_LEVEL_IDENTIFY (see [MS-RPCE] section 2.2.1.1.9) as the impersonation level for the call.

<85> Section 3.2.4.2: Windows DCOM clients use the LegacyAuthenticationLevel value (see [MSDN-LegAuthLevel] for more information) as the client's authentication level value.

<86> Section 3.2.4.2: Windows DCOM clients use the LegacyImpersonationLevel value (see [MSDN-LegIMPERSLVL] for more information) as the default impersonation level value.

<87> Section 3.2.4.2: Windows DCOM clients specify the extensions field if well-known ORPC Extensions (section 2.2.21) are supplied by the application.

<88> Section 3.2.4.2: Windows XP SP3, Windows Server 2003 SP2, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 DCOM clients do not have this coding error and do not append extra data.

<89> Section 3.2.4.2: Windows DCOM clients return the extensions field to the application if well-known ORPC Extensions are present in the ORPCTHAT structure.

<90> Section 3.2.4.4.1: Windows DCOM clients use private references when the secure reference counting feature is enabled in the DCOM application using the EOAC_SECURE_REFS capability. For more information, see [MSDN-EOLE_AUTHENTICATION_CAPABILITIES]).

<91> Section 3.2.4.4.2: Windows DCOM clients use private reference counts when the secure reference counting feature is enabled using the EOAC_SECURE_REFS capability. For more information, see [MSDN-EOLE_AUTHENTICATION_CAPABILITIES]).

<92> Section 3.2.6.1: Windows DCOM clients specify RPC_C_AUTHN_LEVEL_CONNECT (see [MS-RPCE] section 2.2.1.1.8) as the authentication level for the call.

<93> Section 3.2.6.1: Windows DCOM clients specify RPC_C_IMPL_LEVEL_IDENTIFY (see [MS-RPCE] section 2.2.1.1.9) as the impersonation level for the call.

<94> Section 5.1: If the application enables the EOAC_SECURE_REFS capability. For more information, see [MSDN-EOLE_AUTHENTICATION_CAPABILITIES]. The default Windows security configuration requires the client to specify security on the activation requests and ORPC requests.

 
Show:
© 2014 Microsoft