MPS: Writes to User Property Database Do Not Occur

• Microsoft Commercial Internet System version 1.0 - Microsoft Personalization System
• Microsoft Site Server version 2.0 - Microsoft Personalization System

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

SYMPTOMS

The Message Personalization System (MPS) may not be able to write to the user property database when Windows NT Challenge/Response (NTLM) is the only configured authentication method on the Microsoft Internet Information Server (IIS).

CAUSE

MPS runs in the context of IIS, so when MPS attempts to write to the propdb, it does not impersonate the remote HTTP client when it is only configured for NTLM Challenge/Response. It impersonates the client when IIS is configured for basic authentication. Instead it uses a NULL username, because the configured service account is the local system account.

When the MPS calls the Win32 API CreateFile to write to the propdb, it does not pass any credential information with it. The MPS computer tries to connect to the file share where the propdb is located and fails, because NULL sessions are disallowed by default by the Windows NT Server service, even if the guest account is enabled. In a network trace, the SessionSetupAndX will have a NULL username, which results in the Access Denied response from the server.

The best way to see this problem is to use the Installation Verification script included with MPS. If a user is added to the propdb and the screen simply refreshes, then this problem is occurring. Run the script on a computer other than the one running MPS. A button to remove the user is displayed when the add is successful.

One caveat is if the HTTP client is local to the MPS box, then the security context of the logged-on user will be used, and the connection will succeed if the user has permissions to access the share.

WORKAROUND

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it.

Create a NULL session share for the location of the propdb. On the file server that is hosting the propdb share, run REGEDT32.EXE and make the following changes:

1. Open the Registry Editor, Regedt32.exe.

2. From the HKEY_LOCAL_MACHINE subtree, go to the key:

         \System
           \CurrentControlSet
             \Services
               \LanmanServer
                 \Parameters
                   \NullSessionShares
   
      NOTE: NullSessionShares is type REG_MULTI_SZ.
   
   

3. Create a new line within the NullSessionShares key, type in the share you want to access with a null session.

   On NullSessionsShares add the name of the share on the local box for the Propdb. For example, if your propdb is at "\\TheServer\PropDB", you would add "PropDB".

4. Stop and restart the server.