7 Appendix B: Product Behavior

  • Article

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.

Microsoft Outlook

  • Microsoft Office Outlook 2003

  • Microsoft Office Outlook 2007

  • Microsoft Outlook 2010

  • Microsoft Outlook 2013

  • Microsoft Outlook 2016

Microsoft Exchange Server

  • Microsoft Exchange Server 2003

  • Microsoft Exchange Server 2007

  • Microsoft Exchange Server 2010

  • Microsoft Exchange Server 2013

  • Microsoft Exchange Server 2016

Windows Server

  • Windows 2000 Server operating system

  • Windows Server 2003 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.3: The NSPI client is provided by Microsoft Outlook. The NSPI server is provided by Microsoft Exchange Server.

<2> Section 2.1: When Microsoft Exchange is running on Windows 2000 Server and Windows Server 2003, the NSPI server enforces a target level of 5.0.

<3> Section 2.1: The NSPI server applies local security policies. All versions limit access to data, both read and modification access, based on these security policies. All versions apply local security policies on a per property, per object, and per container basis, as outlined in section 5. These policies render some data inaccessible to some clients. All versions use the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable via the NSPI Protocol.

<4> Section 2.1: When Microsoft Exchange is running on Windows Server 2003 and later, the NSPI server limits the maximum allowable RPC packet to be 13 megabytes.

<5> Section 2.2.10: When Microsoft Exchange is running on Windows 2000 Server, the NSPI server does not support the SortTypePhoneticDisplayName sort order.

When Microsoft Exchange is running on Windows Server 2003 and later, the NSPI server supports the SortTypePhoneticDisplayName sort order, but only for the LCID_JAPANESE LCID, and only when the server has been configured to do so. This is not configurable via the NSPI Protocol.

<6> Section 2.3.8.3: The NSPI server allows an object's distinguished name (DN) to be modified. There is no mechanism for performing this modification via the NSPI Protocol. When an object's DN is modified, the NSPI server continues to map Permanent Entry IDs containing the old DN to the original object.

<7> Section 3.1.1.2.3: The NSPI server applies special handling to the string representations of the following properties when specified by the server to the client:

  • PidTag7BitDisplayName

    • This value is natively of type PtypString8. The NSPI server constructs this value as follows:

      1. If the server has a stored value for this property, the value is used.

      2. If step 1 did not yield a value, the server reads the value of the property with the Property ID 0x8202. This value is natively Unicode. The server converts this value to an 8-bit character representation in the codepage specified by the client. If the server can convert the Unicode representation to an 8-bit character representation without the use of any default characters, the converted value is used.

      3. If step 2 did not yield a value, the constant 8-bit character string "Unavailable" is used.

  • PidTagTransmittableDisplayName

  • PidTagDisplayName

    • These values are natively of type PtypString. The NSPI server constructs these values as follows:

      1. If the server has a stored value for this property, the value is used.

      2. If step 1 did not yield a value, the server obtains the value of PidTag7BitDisplayName and converts the 8-bit representation to a Unicode representation and uses the converted value.

      3. If the client requests the PtypString8 version of these properties, the server converts the Unicode representation to an 8-bit representation in the client's codepage. If the server can convert the Unicode representation to an 8-bit character representation without the use of any default characters, the converted value is used. Otherwise, the value of PidTag7BitDisplayName is used.

When these properties are specified by the client to the server, no such conversion is done. It is therefore possible for a client to read these properties from an object and then apply the value read as a restriction, and have the resultant set of objects returned from the server be empty.

<8> Section 3.1.1.2.5.1: When Microsoft Exchange is running on Windows 2000 Server, the NSPI server does not support locating a closest LCID. If the server does not support the explicit LCID specified by the client, the results of the string representation conversions are undefined. All comparing and sorting of strings is done using the protocol's required default LCID.

When Microsoft Exchange is running on Windows Server 2003 and later, the NSPI server locates a closest supported LCID as follows:

  1. If the server supports the LCID specified by the client, the server uses that LCID. Otherwise:

  2. The server removes any sublocale information from the LCID specified by the client. If the server supports the resultant LCID, the server uses that LCID. Otherwise:

  3. The server uses the server's default LCID.

The LCID chosen by the server is not discoverable via the NSPI Protocol.

<9> Section 3.1.1.4.2: For the NSPI server, approximate positioning in tables (both in servicing client position requests and in reporting approximate numeric positions) has no upper bound on the possible error of the approximation. That is, the server cannot guarantee where in a table it has actually set current position when applying an approximate location received from the client. Also, it cannot guarantee that the approximate position reported to the client is accurate.

<10> Section 3.1.4: The gaps in the opnum numbering sequence apply to the products as follows.

Opnum

Description

15

Used only locally, never remotely.

<11> Section 3.1.4.1: When Microsoft Exchange is running on Windows Server 2008 and later, the NSPI server limits the number of simultaneous NSPI connections from a single client. The limit is not configurable or discoverable via the NSPI Protocol.

<12> Section 3.1.4.1: When Microsoft Exchange is running on Windows 2000 Server, the NSPI server always honors the fAnonymous flag for the NspiBind method.

When Microsoft Exchange is running on Windows Server 2003 and later, the NSPI server can be configured to honor or ignore the fAnonymous flag. This setting is not configurable or discoverable via the NSPI Protocol.

<13> Section 3.1.4.1: When verifying an RPC client, the NSPI server authenticates RPC clients by verifying the client's identity as a member of the Windows domains Authenticated Users well known group.

<14> Section 3.1.4.1: The NSPI server uses a single GUID for multiple NSPI sessions for as long as the server can guarantee no object's Minimal Entry ID (MId) has changed. Modifications to the data stored in the NSPI server by mechanisms outside of the NSPI Protocol can result in the modification of an object's MId. These modifications can only take place while there are no active NSPI sessions.

<15> Section 4: When processing the NspiQueryRows method, the NSPI server enforces time and size constraints, limiting the number of rows returned to be less than the number of rows requested, if the limits of the constraints are reached. These constraints are local policy and are not configurable or discoverable via the NSPI Protocol.

<16> Section 5.1: The NSPI server applies local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI Protocol.