In fact, I’m pretty sure scredir client support is available all they way back to Win2K, as long as the latest compatible TS client package is installed.  Server-side scredir support first appeared as the Remote Desktop feature in XP. 

That said, scredir did undergo some architectural changes in Vista.  Shivaram discusses some of them here - http://blogs.msdn.com/shivaram/archive/2007/02/26/smart-card-logon-on-windows-vista.aspx.  I’ve got an old post about smart card service-specific changes here - http://blogs.msdn.com/dangriff/archive/2005/06/01/423955.aspx, although that’s not really redirection-specific.  Another pre-Vista post is here - http://blogs.msdn.com/spatdsg/archive/2006/10/16/smartcard-logon-over-terminal-services-rdp-redirection.aspx. 

The most significant bits, regarding scredir changes in Vista, are:

*  Redirection is now impersonation context based, rather then process-wide.  This is why it’s important, if you’re implementing a smart card or certificate/private key aware service, to impersonate the session that you’re working on behalf of before making calls to WinSCard or Crypto API.

*  scredir.dll was eliminated.  That binary used to be consumed by winscard.dll in smart card client applications to handle the routing of redirected calls into RDP, rather than the local Smart Card Resource Manager (SCRM) service.  Now it’s all rolled into one.

*  The session change notification logic in winscard, including rundown/cleanup (since winscard supports being dynamically unloaded), was migrated to the new threadpool API.  This was actually an interesting architectural challenge, since the WinSCard public interface didn’t include an API which allowed the consumer to say, in effect, "I’m about to unload you, so clean everything up."  As a result, WinSCard process detach logic had to play some tricks here, since DllMain always came as a surprise, so to speak.  In general, with the old threadpool API in that situation, you had a choice between maybe deadlocking on the loader lock, or maybe getting unloaded with a callback still queued!  The new threadpool API, however, solves that problem by allowing you to say "even if my ref count goes to zero, pin me in memory until all of my callbacks clear out safely."  See, for example, SetThreadpoolCallbackLibrary (http://msdn2.microsoft.com/en-us/library/ms686258.aspx).

*  Finally, redirected support for new WinSCard APIs, including the data caching related ones.