ADSI and User Account Control
Windows and Windows Server have User Account Control, which has ramifications for applications that use Active Directory Service Interfaces (ADSI). Specifically, these interfaces were designed to be run by a user account with administrator privileges on the local computer.
Every time an application connects to the directory and attempts to create an ADSI object, the Active Directory Schema is checked for changes. If it has changed since the last connection, the schema is downloaded and stored in a cache on the local computer. In versions of Windows prior to Windows Vista, the default location for this cache was
However, applications run by standard (that is, non-administrator) accounts will not have access to this directory, and consequently, applications that use ADSI interfaces that are run in this mode will download the schema on every connection, which will impact throughput and performance.
Single user - To resolve this issue, there are new ADSI Provider registry control keys that determine the registry locations and file locations for cached Active Directory Schema objects. If the registry key
is set to 0 (zero), each user will have a different storage location for ADSI; registry keys will be stored in
and cache files will be stored in
These settings are the default settings on computers running Windows Server 2008 or Windows Vista.
Multi-user - If you are running ADSI applications on a computer with many user accounts (for example, a web server), then it's preferable not to have many copies of the Active Directory Schema cache using up large amounts of disk space. Setting the registry key
to 1 (one) will revert ADSI to the previous behavior; all Active Directory Schema objects will be stored in their previous locations; the registry key will be in
and the cache file will be in
In this case, administrator accounts should run the application, which will cause the schema file to be cached in the global location for future use by the less privileged users.