The Windows Search Protocol relies on the SMB Protocol, as specified in [MS-SMB], for message transport. No other protocol depends directly on the Windows Search Protocol.
Prerequisites/Preconditions
The client is expected to have obtained the name of the server and a catalog name before this protocol is invoked. It is also assumed that the client and server have a security association usable with named pipes as specified in [MS-SMB].
The Windows Search Protocol is designed for querying and managing catalogs on a remote server from a client.
Versioning and Capability Negotiation
Windows Search Protocol has its own version ID that is used to communicate capabilities between the server and the client. There are two parts to this version ID: the version number, which is held in the least significant 2 bytes; and flags that are added to this number, comprising the remaining bytes. This version ID is added to the CPMConnectIn and CPMConnectOut messages, and can be used to check the versioning of the server or client throughout the transaction.
Starting with the release of Windows Search 4.0, messages include a checksum that must be validated by the server. The version number of this is 0x109.
If the version number is greater than 0x109, this means that the clients must include a checksum in all of their messages. Servers should check all of the client's messages against the checksum if such a version is given.
0x10000 is added to the version ID and is used when identifying whether the operating system is 32-bit or 64-bit. Offsets are changed depending on this aspect of the architecture of the operating system.
Value
|
Meaning
|
0x00000102
|
32-bit Windows Server 2008 operating system, or 32-bit Windows Vista operating system.
|
0x00000109
|
32-bit Windows XP operating system, 32-bit Windows Server 2003 operating system, 32-bit Windows Home Server server software, 32-bit Windows Vista with Windows Search 4.0, 32-bit Windows Server 2003 with Windows Search 4.0. All of these versions of Windows are running Windows Search 4.0.
|
0x00000700
|
32-bit Windows 7 operating system.
|
0x00010102
|
64-bit version of Windows Vista or Windows Server 2008.
|
0x00010109
|
64-bit version of Windows Vista or Windows Server 2008 with Windows Search 4.0 installed.
|
0x00010700
|
64-bit Windows 7 or Windows Server 2008 R2 operating system.
|
This protocol uses HRESULTs that are vendor-extensible. Vendors are free to choose their own values for this field, as long as the C bit (0x20000000) is set as specified in [MS-ERREF] section 2.1, indicating that the value is a customer code.
This protocol also uses NTSTATUS values taken from the NTSTATUS number space defined in [MS-ERREF]. Vendors SHOULD<1> reuse those values with their indicated meaning. Choosing any other value runs the risk of a collision in the future.
Property IDs
Properties are represented by IDs known as property IDs. Each property MUST have a GUID, as defined in [MS-DTYP] section 2.3.4.3. This identifier consists of a GUID representing a collection of properties called a property set plus either a string or a 32-bit integer to identify the property within the set. If the integer form of ID is used, then the values 0x00000000, 0xFFFFFFFF, and 0xFFFFFFFE are considered invalid.
Vendors can guarantee that their properties are uniquely defined by placing them in a property set defined by their own GUIDs.
Standards Assignments
This protocol has no standards assignments, only private assignments made by Microsoft using allocation procedures specified in other protocols.
Microsoft has allocated this protocol a named pipe as specified in [MS-SMB]. The pipe name is \pipe\MSFTEWDS.
The following sections specify how messages are transported and provide details of message syntax, including common structures and common error codes.
This protocol references commonly used data types as defined in [MS-DTYP].
Transport
All messages MUST be transported using a named pipe, as specified in [MS-SMB] or [MS-SMB2]. The following pipe name is used:
This protocol uses the underlying server message block (SMB) named pipe protocol to retrieve the identity of the caller that made the connection as specified in [MS-SMB] section 2.2.4.9.1. The client MUST set SECURITY_IMPERSONATION as the ImpersonationLevel in the request to open the named pipe.<2>
Message Syntax
Several structures and messages in the following sections refer to chapter or bookmark handles. A handle is a 32-bit long opaque structure that uniquely identifies a chapter or bookmark. Typically, client applications receive handle values via method calls. However, there are several well-known values that need not be obtained from a server, the meaning of which is specified in the following table.
Value
|
Meaning
|
DB_NULL_HCHAPTER
0x00000000
|
A chapter handle to the unchaptered rowset that contains all query results.
|
DBBMK_FIRST
0xFFFFFFFC
|
A bookmark handle to a bookmark that identifies the first row in the rowset.
|
DBBMK_LAST
0xFFFFFFFD
|
A bookmark handle to a bookmark that identifies the last row in the rowset.
|
|
