The ADSI Schema Cache revealed Part II

  • Article

Today's topic:

The ADSI Schema Cache revealed Part II

We have been talking about the ADSI Schema Cache implementation, it's benefits and several buts in the first part covering this topic <The ADSI Schema Cache revealed>. The conclusion was - utilize the sample code attached to the blog entry and 'really, finally it’s cool now – without any but'.

Unfortunately - in some circumstances - I must confess: there is still a but.

This time the but is not related to server side behavior but client / user related. The scenarios we are looking at are:

  • Remote Desktop Sessions
  • Published Applications
  • any multiple users machine (ex: cash desk PCs)

Why a but (?):
Until Windows XP / Windows Server 2003 R2 we stored the Schema Cache file in %systemroot%\SchCache, the timestamp of the last downloaded Schema Cache was stored in HKLM\Software\Microsoft\ADs\Providers\LDAP\ -> a per machine store. Both targets do not grant write access for non-administrative users -> we downloaded the schema cache on every non-administrative ADSI session to the RAM and had to discard the data.

This was fixed beginning with Windows Vista by a per user store. We now store the Schema Cache file in %localappdata% \Microsoft\Windows\SchCache\domaindsnname.sch and the timestamp here: HKCU\Software\Microsoft\ADs\Providers\LDAP\subschemaSubEntry -> Time. This ensures that every user is able to store the necessary data.

But (here it is) - if a user logs on to a Terminal Server farm, uses published applications from a Terminal Server farm or is constantly moving from one machine to another he has to download the Schema Cache into his profile on all machines involved.
Talking about Terminal Servers - this may result in some amount of users that download and store exactly same data multiple times on each machine. If we delete the TS profiles after logoff we worsen the issue and the Terminal Servers are #1 target for ADSI Schema Cache downloads all day long - for no clever reason.

Workaround: You may force a fallback to the per machine store by setting the REG-DWORD PerMachine in the registry path HKLM\SYSTEM\CurrentControlSet\Services\ADSI\Cache to the value 1.
Additionally you must grant write access on %systemroot%\SchCache and HKLM\Software\Microsoft\ADs\Providers\LDAP to Authenticated Users. Since we may have ADSI calls from 32bit applications on a 64bit operating system, we need to grant the same permission on HKLM\SOFTWARE\Wow6432Node\Microsoft\ADs\Providers\LDAP as well.

One wee caveat - you open your ADSI client for possible machine-wide obstruction:
Someone may alter the timestamp in the registry to a date in the far future and put corrupted data in the Schema Cache file -> this will break most of the ADSI Client functionalities since we do not download proper Schema Cache info anymore. It's definitely not a hacking attack vector but may cause strange help desk calls.

This time it's a quite short posting but I thought it may come in handy for you guys and - trying to be honest - I cannot say 'really, finally it’s cool now – without any but' - but we have a workaround.

All the best

Michael

PFE | Have keyboard. Will travel.

 

History:
8/2/2016 - added info about registry key for 32bit applications on 64bit operating systems.