Microsoft KB Archive/174296
Article ID: 174296
Article Last Modified on 10/30/2003
- 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.
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.
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.
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:
- Open the Registry Editor, Regedt32.exe.
From the HKEY_LOCAL_MACHINE subtree, go to the key:
\System \CurrentControlSet \Services \LanmanServer \Parameters \NullSessionShares
NOTE: NullSessionShares is type REG_MULTI_SZ.
- 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".
- Stop and restart the server.
Additional query words: personalization personalisation prodMPS prodmcis1
Keywords: kbprb KB174296