Share via

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.

Comments

  • Anonymous
    May 04, 2015
    Today's topic:

    The ADSI Schema Cache revealed
    Like mentioned in the first article of this
  • Anonymous
    August 02, 2016
    Hello Michael,"Additionally you must grant write access on %systemroot%\SchCache and HKLM\Software\Microsoft\ADs\Providers\LDAP to Authenticated Users"Is this will be done on client side ? is there a way to do this via GPO if I have Bulk client machines ?
    • Anonymous
      August 02, 2016
      Hi Gamil,yes - should be done on the client side.You can achieve this via GPO - see:for the registry keys:Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Registry (Add Key...)for the folder:Computer Configuration -> Policies -> Windows Settings -> Security Settings -> File System (Add File...)All the bestMichaelPFE | Have keyboard. Will travel.
  • Anonymous
    August 03, 2016
    Many Thanks, Worked fine with me :)I'll check the clients behavior after applying these steps just an issue not related to the topic ... the below update need to be fixed, it just in the future :)History: 8/12/2016 – added info about registry key for 32bit applications on 64bit operating systems.
    • Anonymous
      August 03, 2016
      glad I could help.thx for the hint about the update date -> fixed