Personal Web Pages Setup Fails with 800A0005 in Setuplog.txt (226486)
The information in this article applies to:
- Microsoft Commercial Internet System 2.5
This article was previously published under Q226486 SYMPTOMS
During the setup of Personal Web Pages, the Setup program states that it cannot continue. After setup failure, the Setuplog.txt file in the Temp directory contains entries similar to the following:
2/18/99,17:55:46, "Configure PWP/FTP", ""
2/18/99,17:55:50, "Can NOT config Maps object", "Code=800A0005,"
2/18/99,17:55:50, "5:46, "", "Exit Setup"
CAUSE
Even though the log states "Can NOT config Maps object," the problem is not related to MAPS. The Dsschemaconfig object came from MAPS, but is used by the Personal Web Pages installation to configure the schema of the directory and add the necessary attributes and container. During the Personal Web Pages installation, a dialog box asks you for the LDAP information. This information is used to modify the schema. If the schema modification fails at this point, setup terminates and the Setuplog.txt file logs the error.
WORKAROUND
There are many reasons why a schema config might fail. It is almost always related to the LDAP server. Use the following list to troubleshoot the problem:
- Verify connectivity, name resolution by pinging all servers by the name from each server. Also verify SQL Server and Site Server setup with Site Server and MCIS documentation (for example, make sure named pipes and TCP/IP sockets are chosen, at least SQL Server SP4 with 297 hotfix, SS3SP2, Windows NT 4.0 SP4 on membership servers, and so on).
- Verify the information provide for the LDAP server during the Personal Web Pages setup. The server name should be the server that has the LDAP instance running and not an AUO-only instance. The port must be correct for the LDAP instance. Also verify that the credentials provided are the membership SUPERBROKER and not a Windows NT administrator account. The account specified must have the directory privileges attribute set to SUPERBROKER. This provides the right to bypass ACEs and modify the schema.
- On the LDAP server, verify that the LDAP service is running in Control Panel Services. From the MMC on the LDAP server, expand the membership instance and verify that the LDAP instance has a status of "Running." If either one of these is not running, stop and restart the service in Control Panel Services. Verify in both places that they are running. If any problems occur, check Event Viewer logs.
- If you are confident that the LDAP setup information is correct and LDAP is fine, the problem may be in the LDAP instance. Create a new SQL Server database called "test" and configure it per the Site Server documentation. On the LDAP server, create a new LDAP instance on an unused port such as 1002, 1003, or so on, and provide the SQL Server information for the new test database. Try the Personal Web Pages install again, and this time provide LDAP information for a new LDAP instance. This will narrow the problem down to the LDAP instance or membership database. Delete the new LDAP instance and "test" database. Re-create the new LDAP instance and point it to the existing database that did not work initially. Uninstall the Personal Web Pages and try Setup again against the new LDAP instance. If it works, then the problem was in the initial LDAP instance. Deleting the instance and re-creating it will solve the problem if this was the case. If it still does not work, a SQL Server trace will need to be obtained for further examination.
- Make sure the SP2 Mcis2upd.sql file is run against the membership database. This script is in the Scripts folder, which is under the install point of the Site Server 3.0 SP2 directory. Consult the SQL Server documentation on how to run a SQL Server script against a database.
Modification Type: | Major | Last Reviewed: | 10/24/2003 |
---|
Keywords: | kbpending kbprb KB226486 |
---|
|