7 Appendix B: Product Behavior

Article
06/24/2021

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.

Windows Client

Windows NT 4.0 operating system
Windows 2000 Professional operating system
Windows XP operating system
Windows Vista operating system
Windows 7 operating system
Windows 8 operating system
Windows 8.1 operating system
Windows 10 operating system
Windows 11 operating system

Windows Server

Windows NT 4.0
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 3.1.4.1: Transferring sensitive data without IIS IMSAdminBaseW Remote Protocol-level encryption.

Windows NT operating system supports a mode where client and server can exchange sensitive data (see section 3.1.4.1) over the IIS IMSAdminBaseW Remote Protocol without having a valid secure session negotiated. That mode applies to only machines with the French locale.

To negotiate cleartext mode of operation, client and server still go through the secure session negotiation. They have to handle R_KeyExchangePhase1 and R_KeyExchangePhase2 but with the following changes:

Any key exchange public key BLOB is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains the "KeYk" string without the terminating null character.
Any signature public key BLOB is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains the "SiGk" string without the terminating null character.
Any session key BLOB is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains the "SeSk" string without the terminating null character.
Any hash exchanged is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains one byte set to 0x00.

Sensitive data will not be encrypted in this mode of operation. Instead of using a IIS_CRYPTO_BLOB structure with the BlobSignature field set to ENCRYPTED_DATA_SIGNATURE, the sensitive data will be placed into a IIS_CRYPTO_BLOB structure with the BlobSignature field set to CLEARTEXT_DATA_SIGNATURE in a call to R_SetData, R_GetData, R_EnumData, and R_GetAllData.

Decryption does not apply in this mode of operation. Instead of decrypting data store in a IIS_CRYPTO_BLOB structure, the data is simply retrieved from the IIS_CRYPTO_BLOB instance with a CLEARTEXT_DATA_SIGNATURE signature.

<2> Section 3.1.4.1: Windows Server 2003, Windows Vista, and Windows Server 2008 take advantage of the RPC/COM packet privacy feature. It provides a protective layer over the weak encryption used to protect data that is part of the IMSAdminBaseW Remote Protocol. Note that RPC/COM packet privacy is not a replacement of the IIS IMSAdminBaseW Remote Protocol security features.

<3> Section 3.1.4.2: On Windows Vista and later, and on Windows Server 2008 and later, the /LM/W3SVC path and all its child paths do not implement the locking behavior described in 3.1.1. OpenKey calls on these paths will succeed and will not return ERROR_PATH_BUSY even if other keys are open to parent or child paths.

<4> Section 3.1.4.4: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of the metabase handle used in the AddKey method for metabase paths under and including /LM/W3SVC.

<5> Section 3.1.4.5: On Windows Vista and later, and on Windows Server 2008 and later, the implementation of CopyKey does not check that the destination handle is opened with write permissions for metabase paths under and including /LM/W3SVC. Instead, the implementation checks the source handle for write access. This will cause valid calls to CopyKey to fail with E_ACCESSDENIED.

<6> Section 3.1.4.6: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of the metabase handle used in the DeleteKey method for metabase paths under and including /LM/W3SVC.

<7> Section 3.1.4.7: On Windows Vista and later, and on Windows Server 2008 and later, all calls to the DeleteChildKeys method return ERROR_INVALID_HANDLE for the "/LM/W3SVC" path and all its child paths.

<8> Section 3.1.4.8: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of the metabase handle used in the DeleteData method for metabase paths under and including /LM/W3SVC.

<9> Section 3.1.4.9: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of the metabase handle used in the DeleteAllData method for metabase paths under and including /LM/W3SVC.

<10> Section 3.1.4.9: On Windows Vista and later, and on Windows Server 2008 and later, the server does not treat ALL_METADATA as matching the user type of data in the DeleteAllData method for metabase paths under and including /LM/W3SVC. The dwMDUserType parameter has to exactly match the data to be deleted.

<11> Section 3.1.4.10: The CopyData method returns ERROR_PATH_NOT_FOUND on Windows NT 4.0 operating system Service Pack 2 (SP2), Windows 2000 Professional, Windows 2000 Server, Windows XP, and Windows Server 2003 when the destination path specified by pszMDDestPath does not exist.

For destination paths under and including /LM/W3SVC, the CopyData method does not return an error on Windows Vista and later, and on Windows Server 2008 and later when the destination path specified by pszMDDestPath path does not exist.

<12> Section 3.1.4.11: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of metabase handle used in the EnumKeys method for paths under and including /LM/W3SVC. There is also no permission check performed for EnumKeys when enumerating the path /LM if dwMDEnumObjectIndex is 0 or 1.

<13> Section 3.1.4.12: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of the metabase handle used in the R_EnumData method for paths under and including /LM/W3SVC.

<14> Section 3.1.4.16: On Windows Vista and later, and on Windows Server 2008 and later, the ChangePermissions method returns E_INVALIDARG for the "/LM/W3SVC" path and all its child paths.

<15> Section 3.1.4.20: Windows Vista and later, and Windows Server 2008 and later do not store a separate change time for the metabase path /LM/W3SVC or any child paths. GetLastChangeTime returns the same modification time for all paths at or below /LM/W3SVC.

<16> Section 3.1.4.21: On Windows Vista and later, and on Windows Server 2008 and later, two separate system change numbers are kept, one for paths under and including /LM/W3SVC and another for all other paths. The system change number for /LM/W3SVC and child paths is not persisted. Changes made to these paths will increment the system change number as long as the metabase service process, iisadmin, is running. When the service is restarted this record of changes is lost.

When the GetSystemChangeNumber method is called, the sum of these two numbers is returned. When the system change number is returned from a GetHandleInfo call, only the change number corresponding to the path of the open handle is returned.

<17> Section 3.1.4.27: Windows Vista and later, and Windows Server 2008 and later do not check the state of the METADATA_SECURE flag on existing data items in the R_SetData method for paths under and including /LM/W3SVC.

<18> Section 3.1.4.28: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of the metabase handle used in the RenameKey method for paths under and including /LM/W3SVC.

<19> Section 3.1.4.30: On Windows Vista and later, and on Windows Server 2008 and later, open write handles to paths under and including /LM/W3SVC do not interfere with the SaveData operation.

<20> Section 3.1.4.31: On Windows Vista and later, and on Windows Server 2008 and later, there is no check of the permission level of the metabase handle used in the SetLastChangeTime method for paths under and including /LM/W3SVC.

<21> Section 3.1.4.31: Windows Vista and later, and Windows Server 2008 and later do not update the change time on demand for the metabase path /LM/W3SVC or any child paths. SetLastChangeTime succeeds but has no effect for all paths at or below /LM/W3SVC.

<22> Section 3.3.4.2: Default path is %windir%\system32\inetsrv\history.

<23> Section 3.3.4.3: On Windows Vista and later, and on Windows Server 2008 and later, the server returns ERROR_NOT_SUPPORTED for the metabase path /LM/W3SVC or any child paths which map to nodes in the data hierarchy.

<24> Section 3.3.4.4: On Windows Vista and later, and on Windows Server 2008 and later, the IMSAdminBase2::Import method is not supported for the destination metabase path /LM/W3SVC or any child paths. The server will return an error when an Import is attempted with one of these paths.

<25> Section 3.3.4.5: The default history path on Windows Server 2003 is "%windir%\system32\inetsrv\history".

<26> Section 3.7.4.1: The metabase path for a web application is valid if it is below the root node of a website. A website metabase path is a numeric key underneath the Web service key, "/LM/W3SVC". For example, "/LM/W3SVC/1" defines a website with site id 1. The root of the website is a key with the name "ROOT". For example, "/LM/W3SVC/2/ROOT" is the root node of the website with site id 2. The <AppCreate> method will allow applications to be created on valid web application paths as well as on paths underneath the Web service key that are not under a website. On Windows NT 4.0 SP2, Windows 2000 Professional, Windows 2000 Server, Windows XP, and Windows Server 2003 the <AppCreate> method will allow applications to be created on any child path of the Web service key, "/LM/W3SVC". Attempts to create an application on an invalid path will return an error.

<27> Section 3.7.4.4: For Windows Vista and later, and for Windows Server 2008 and later, IWamAdmin methods are not able to query or modify the running state of an application.

<28> Section 3.8.4.1: The metabase path for a website application is valid if it is below the root node of a website. A website metabase path is a numeric key underneath the Web service key, "/LM/W3SVC". For example, "/LM/W3SVC/1" defines a website with site id 1. The root of the website is a key with the name "ROOT". For example, "/LM/W3SVC/2/ROOT" is the root node of the website with site id 2. The <AppCreate> method will allow applications to be created on valid website application paths as well as on paths underneath the Web service key that are not under a website. On Windows NT 4.0 SP2, Windows 2000 Professional, Windows 2000 Server, Windows XP, and Windows Server 2003, the <AppCreate> method will allow applications to be created on any child path of the Web service key, "/LM/W3SVC". Attempts to create an application on an invalid path will return an error.

<29> Section 3.9.4.1: The metabase path for a web application is valid if it is below the root node of a website. A website metabase path is a numeric key underneath the Web service key, "/LM/W3SVC". For example, "/LM/W3SVC/1" defines a website with site id 1. The root of the website is a key with the name "ROOT". For example, "/LM/W3SVC/2/ROOT" is the root node of the website with site id 2. The <AppCreate> method will allow applications to be created on valid web application paths as well as on paths underneath the Web service key that are not under a website. On Windows NT 4.0 SP2, Windows 2000 Professional, Windows 2000 Server, Windows XP, and Windows Server 2003, the <AppCreate> method will allow applications to be created on any child path of the Web service key, "/LM/W3SVC". Attempts to create an application on an invalid path will return an error.

<30> Section 3.10.4: Returns ERROR_NOT_IMPLEMENTED. Opnum 7 is never used.

<31> Section 3.10.4: Returns ERROR_NOT_IMPLEMENTED. Opnum 8 is never used.

<32> Section 3.10.4: Returns ERROR_NOT_IMPLEMENTED. Opnum 9 is never used.

<33> Section 3.10.4.1: The format of the InstanceName string in the Windows implementation is "/LM/W3SVC/N" where N is a number which identifies the particular web server instance and W3SVC represents the web server. For example, "/LM/W3SVC/1" indicates the default web server instance.

<34> Section 3.10.4.4: The Issuer field is searched using the Windows API function CertGetNameString using CERT_NAME_SIMPLE_DISPLAY_TYPE and CERT_NAME_ISSUER_FLAG to specify the Issuer field. This API will return an attribute value from the Issuer field by looking for the first occurrence of the Common Name, Organizational Unit Name, Organization Name, or RSA Email Address. If one of these attributes is not found, it uses the Issuer Alternative Name extension. If there is still no match, it uses the first attribute.

<35> Section 3.10.4.4: The Windows implementation performs the date to string conversion using the Windows API function GetDateFormat and passing the flag DATE_AUTOLAYOUT. On Windows 7 and later, and on Windows Server 2008 R2 operating system and later, Unicode bidirectional ordering control characters are inserted into the resulting date string. One of the Unicode characters 0x200E (left-to-right mark) or 0x200F (right-to-left mark), depending on the server’s system locale setting, will appear in the date string immediately before each numeric component of the date.

<36> Section 3.10.4.4: The Windows implementation retrieves a descriptive name for the extended key usage OID using the CryptFindOIDInfo Windows API function. A complete example of the string built by the GetCertInfoRemote method might be the following:

 1.2.840.113549.1.9.1=somebody@microsoft.com
 2.5.4.3=testcert
 2.5.4.11=IIS
 2.5.4.10=Microsoft
 2.5.4.7=Redmond
 2.5.4.8=WA
 2.5.4.6=US
 4=RSACERTSRV
 6=7/7/2009
 2.5.29.37=Server Authentication

<37> Section 3.10.4.5: The Windows implementation uses the PFXImportCertStore API when importing a certificate via ImportFromBlob or ImportFromBlobGetHash. If the bAllowExport parameter is set to 1 or VARIANT_TRUE, the CRYPT_EXPORTABLE flag is set in dwFlags parameter in the call to PFXImportCertStore.

<38> Section 3.10.4.5: The Windows implementation exports certificates using the PFXExportCertStoreEx API. The encryption method of the exported data is dependent on the implementation of this API. On import via ImportFromBlob or ImportFromBlobGetHash, the password is validated using PFXVerifyPassword, and the import is performed by PFXImportCertStore.

<39> Section 3.10.4.6: Memory is allocated in the Windows implementation using CoTaskMemAlloc and is released by the client using CoTaskMemFree.

<40> Section 3.10.4.6: The Windows implementation uses the PFXImportCertStore API when importing a certificate via ImportFromBlob or ImportFromBlobGetHash. If the bAllowExport parameter is set to 1 or VARIANT_TRUE, the CRYPT_EXPORTABLE flag is set in dwFlags parameter in the call to PFXImportCertStore.

<41> Section 3.10.4.6: The Windows implementation exports certificates using the PFXExportCertStoreEx API. The encryption method of the exported data is dependent on the implementation of this API. On import via ImportFromBlob or ImportFromBlobGetHash the password is validated using PFXVerifyPassword and the import is performed by PFXImportCertStore.

<42> Section 3.10.4.6: The IDL attributes of pCertHash will not allow the entire certificate hash buffer to be returned to remote clients. Because no size is indicated in the parameter attributes for pCertHash, the RPC/DCOM implementation will return a single byte of data to the client when the method is called remotely. A correct IDL specification for this parameter might have been [out, size_is(*pcbCertHashSize)].

<43> Section 3.10.4.7: Memory is allocated in the Windows implementation using CoTaskMemAlloc and has to be released by the client using CoTaskMemFree.

<44> Section 3.10.4.7: The Windows implementation uses the PFXExportCertStoreEx API to export the certificate and optional chain and private key data. The specific format of the exported data blob does not affect client interoperability as long as a server implementation is capable of passing data blobs between import and export methods.

<45> Section 3.10.4.7: The pBlobBinary parameter is specified as a [string] in the IDL. The RPC/DCOM layer will marshal the data buffer created on the server up to the first null (0x00) byte encountered. The Windows implementation does not null-terminate the encoded data buffer, so remote clients might receive a null-terminated buffer with some arbitrary number of additional bytes. The pcbSize parameter correctly indicates the number of valid bytes in the returned buffer.

<46> Section 4.1: A Windows implementation of this protocol requires the RPC_C_IMP_LEVEL_IMPERSONATE impersonation level to be set.

<47> Section 5.1: Windows Server 2003, Windows Vista, and Windows Server 2008 take advantage of the RPC/COM packet privacy feature RPC_C_AUTHN_LEVEL_PKT_PRIVACY. This feature provides a protective layer over the weak encryption, as described in section 3.1.4.1.1.

7 Appendix B: Product Behavior

Additional resources