Receiving a RopGetOwningServers ROP Request

If the operation is performed against a private mailbox message store, the server can fail the operation, or it can compute a correct answer for the client. If the public folder specified by the FolderId field cannot be found in the public folder database, the server MUST fail the operation with 0x8004010F (ecNotFound) in the ReturnValue field.

Each public folder has associated configuration information, including which servers are configured to actually hold content of the folder. This specific configuration indicates one of several potential states for each replica server. An "Active" replica contains content and is expected to serve that content to clients. Servers in other replica states do not serve content to clients. These other replica states are implementation-specific, but possible definitions are as follows:

  • An "Inactive" replica contains content, but is not going to serve that content to clients.

  • A "Deleted" replica once contained content and presently does not.

Each server in the organization's network has a tangible communication cost due to the following implementation-dependent factors: network hardware costs, the cost of the network connectors (various WAN versus LAN costs and so forth), and the perceived cost of using the network for certain applications, and so on.

The server retrieves the current replica information for the specific public folder specified by the FolderId field. This replica information is a list, each entry consisting of at least a server identifier and the replication state for this folder on that server (Active/Inactive/Deleted/etc.). The server obtains the network cost for each server in the list, if that cost information isn't already in the list. The source used to determine these network costs can be whatever configuration source the server finds most appropriate.<38> The network cost values are expressed relative to the server servicing the request, not the client making the request.

The server removes entries from the list that are not active replicas. The server can remove entries from the list which, at its discretion, it determines to be too expensive for the client to reach. The algorithm used to determine the servers that are too expensive is implementation-defined.<39> The server can remove entries if another configuration indicates that the client be prohibited from attempting a connection, if such a configuration exists. If the resulting trimmed list is empty, the operation MUST fail with a ReturnValue of 0x00000469.

The server sorts the list according to the cost information, least expensive items sorting to the front of the list. Servers with the same cost can appear in any order, but the server SHOULD ensure that the same list values sort to the same order every time.

The server counts the number of lowest-cost servers at the front of the list that all have the same cost value, as described previously in this section. The resultant value is the number of cheapest, equally costed servers (the CheapServersCount value returned in the response), in terms of the tangible communication cost, relative to the server servicing the request.

The current total list length constitutes the OwningServersCount value returned in the response. The list contents of server identifiers constitute the value in the OwningServers field. The server MUST map whatever identifier moniker for each server it has into an ESSDN string to return to the client.

The following specific error codes apply to this ROP. Other possible error codes are specified in [MS-OXCDATA] section 2.4.









There are no active replicas for the folder OR the only available replicas have been deemed "too expensive" to reach or are otherwise deemed "unavailable" by the server implementation.



The FID could not be found in the public folder database.