After a server is restarted or a Web service is restarted, an application that ran correctly before the restart now does not run. You may receive the following error message:

The Active Directory directory service schema is not correctly cached by ADSI. For additional information about how ADSI caches the schema of an LDAP server, click the following article number to view the article in the Microsoft Knowledge Base: The previous article describes how ADSI tries to cache the schema one time for each process. This information is important because Microsoft ASP.NET runs under a single Aspnet_wp.exe process in Microsoft Windows 2000. If you have some Web users who experience the double-hop authentication limitation and some Web users who do not experience the double-hop authentication limitation, this problem may be caused by the first user who runs an ASP.NET page that uses ADSI on that server.

Typically, you notice that an application works by launching a Web browser locally. The Web site is now live and the Web site works until the server is restarted or the Web service is restarted. When the server is restarted or the Web service is restarted, the ASP.NET application stops responding. This problem occurs because the user who is experiencing the double-hop authentication limitation is the user who accessed the server first, and ADSI did not cache the schema correctly.

The schema that ADSI uses is stored in the cn=Aggregate object in the schema namespace. The Pre-Windows 2000 Compatible Access built-in group does not have permissions to this aggregate object. The Everyone principal also does not have permissions to this aggregate object. Therefore, schema information is not accessible. There is a property in the cache that was retrieved from the server, and ADSI knows nothing about this property. Because ADSI cannot determine the type of the property, ADSI cannot convert that property to a string, to an integer, to a security descriptor, or to other data formats, and you may receive the error message that is mentioned in the "Symptoms" section.

For additional information about possible resolutions to this problem, including using Kerberos delegation, see the Windows 2000 Resource Kit.

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

This behavior is by design.

You may not receive a permission denied entry or a property not found entry in the cache error log. Typically, this problem occurs because of how Active Directory directory service is installed. When the first domain controller in the domain is promoted, the Active Directory Installation Wizard prompts you for access permissions to verify the following:

• Are the access permissions compatible with Microsoft Windows NT 4.0?
• Are the access permissions compatible with Windows 2000?

If the access permissions are not changed, the access permissions are compatible with Windows NT 4.0. This adds the security principal to the Pre-Windows 2000 Compatible Access built-in group.

For additional information, see the "Directory Service Configuration" topic in the Windows 2000 Resource Kit.

If you add the security principal to the Pre-Windows 2000 Compatible Access built-in group, this is significant. By default, the Pre-Windows 2000 Compatible Access group has List Contents permissions and the Read All Properties permissions for many objects in the directory. Because an anonymous user accesses the Active Directory directory service with Everyone permissions, if you select the Windows NT 4.0 option during install, you receive many attributes returned in a query.