Windows 7 provides a device abstraction layer such that, assuming your fingerprinter reader's manufacturer has written the appropriate driver software, the reader itself will "just work" with Windows. Microsoft's goal in doing this was to provide a consistent user experience re: enrolling biometric data. (The "provider" functionality in Windows 7 supports only fingerprints. The framework is extensible, by Microsoft, to support other types of biometric data, but only fingerprint UI has been added in Windows 7. No retinal scanners for you... >smile<)
From the scant articles that I'm finding, it appears that the biometric-based logon becomes available after at least one user has "enrolled" their fingerprints, and will work for both local user accounts and domain user accounts.
It's unclear to me where Microsoft is actually storing the biometric data and the user's password. Since it has to be accessible prior to logon, my guess is that they're encrypting it with some machine-specific key and packing it away in the computer's registry somewhere. (Yeah-- per this article that appears to be what's happening...)
It certainly looks like Microsoft hasn't thought at all about how to deploy this functionality across groups of computers. I see no method for "pre-loading" biometric data into groups of machines. My guess is that if, for example, you wanted "enterprise-wide" biometric logon capability you'd need each employee to "enroll" their fingerprints on each computer they were going to logon to.
If, indeed, centralized biometric credential distribution (which, arguably, presents a lot of fun security challenges) isn't a part of the biometric authentication functionality in Windows 7 then, arguably, it's of little use.
Best Answer
You might want to look at achieving this via two separate methods, i.e. one to set FF as default, the other to launch it at login.
That said, in case you want to know, default browser setting is stored in the registry under
Use your preferred method for setting registry entries (with your server and client systems you can do this directly in group policy without scripting, or you can use a batch script to import the registry key, or you can use Powershell to edit the registry directly. Take your pick). For editing the user portion of the registry (HKCU rather than HKLM) elevated permissions are not required.
There is a system default stored in the same place under HKLM, but the user preference takes priority.