Microsoft KB Archive/174296

From BetaArchive Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Knowledge Base


Writes to User Property Database Do Not Occur

Article ID: 174296

Article Last Modified on 10/30/2003



APPLIES TO

  • Microsoft Commercial Internet System 1.0 Service Pack 2
  • Microsoft Site Server 2.0 Standard Edition



This article was previously published under Q174296

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 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) computer.

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. It impersonates the client when IIS is configured for basic authentication. Instead it uses a NULL user name, 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 user name, 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. If you are running Windows NT, you should also update your Emergency Repair Disk (ERD).

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 add "PropDB".
  4. Stop and restart the server.




Additional query words: personalization personalisation prodMPS prodmcis1

Keywords: kbprb KB174296