We don't usually use roaming profiles, but we need to test some code of ours to make sure we work with this. This led us to set up a roaming profile and then try to use the program in question.
On all but one machine we tried this on, all was well. On that machine, the product failed. We traced the failures to two phenomena: it couldn't create any COM object, and it couldn't read Scripting.Dictionary.
Further diagnosis revealed the proximate cause: a restrictive ACL on HKLM protected HKEY_CLASSES_ROOT against Domain Users. It didn't even grant read access.
The guy who ran into this did:
secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose
net localgroup users accountname /add
and everything got better.
I suspected that there's some domain policy involved that needs to be set for Roaming Profiles to be useful that causes this ACL to be set more permissively by default. Of course, that's because I was assuming that it was somehow normal for this ACL to be set this way by default on adding a machine to the domain.
On the other hand, the admin here swears that we have no policies that could explain this. I'm afraid that we've been hit by a cosmic ray.
Your original post, and the quesiton you asked Ben Z-B don't make sense to me. Your edit make things a bit more clear, but I'm still a bit fuzzy on what you're seeing (more below).
It sounds like you don't know what Roaming User Profiles actually do.
Each user on an NT-based operating system has their own personal "HKEY_CURRENT_USER" registry hive, stored in the "NTUSER.DAT" file in their user profile (stored in either "C:\Users\username" or "C:\Documents and Settings\username", by default and depending on the Windows version). This registry hive is attached to HKEY_USERS at logon-time, and detatched at logoff time. This behaviour is the same, regardless of the local / romaing status of a user's profile.
This "per-user" behaviour of "HKEY_CURRENT_USER" allows programs to store user-specific configuration information in the registry in a location that is the same for every user (i.e. the registry path doesn't refer to the user's account name), but at the same time allows different users to have different configuration information since each user gets their "own" version of "HKEY_CURRENT_USER".
The "roaming" part of Roaming User Profiles comes from the functionality to upload the user's profile data (including the "NTUSER.DAT" file) to a server after logoff, and to download it and cache it locally prior to logon. This upload / download behaviour doesn't change the basic behaviour of the per-user registry functionality in Windows. It's just an adjunct capability that allows user's personalized settings to "follow" them from computer to computer.
The "HKEY_LOCAL_MACHINE" subtree of the registry remains specific to the machine, irrespective of the user who is logged-on. ACLs protect the settings stored in this area from modification by unprivileged users because this is the location of machine-specific configuration information. These ACLs are there for a reason!
The functonality that Ben Z-B mentions in his answer is a common method that we use to alter registry permissions on (potentially large numbers of) computers when poorly written software requires unprivileged users to have less restrictive permission in "HKEY_LOCAL_MACHINE", etc. Further, the functionality he spoke about has NO ramification for roaming user profiles at all, since roaming user profiles are concerned with the "HKEY_USERS" and "HKEY_CURRENT_USER" registry hives-- neither of which can be modified by the functionality he describes.
Edit:
I certainly don't mean to offend. Having dealt with a significant quantity of software, throughout the years developed w/o any regard for proper use of the registry I'm a bit more defensive, perhaps, than I need to be. I've edited my answer to be a bit less preachy and, hopefully, more succinct.
No modification to the ACL at the root of "HKEY_CLASSES_ROOT" (or to "HKEY_LOCAL_MACHINE", for that matter) occurs upon joining a computer to a domain. Your posting doesn't describe the specific ACE(s) that you're seeing added to the ACL at the root of "HKEY_CLASSES_ROOT", so it's a bit difficult to speak to your specific situation.
Any ACL referring to your domain appearing in the registry almost certainly speaks to third-party modification. Microsoft is very, very good about using well-known SIDs and local groups in ACEs they place in the registry.
It sounds as if you've got a group policy object in your domain that's making changes (using the functionality that B-Z describes or by way of a script) to the registry. Using the "Resultant Set of Policy" (RSoP) management console snap-in would probably be helpful to see if any startup scripts, registry security policy, etc are applying (though you could have "trap door" startup scripts running that only execute on the first boot after joining the domain that would no longer be visible in RSoP after that boot).
You could also verify the change is happening by disjoining the machine from the domain, applying the default security template (as you indicate in your comment to B-Z), , then re-joining the domain, examining the ACL before rebooting after joining the domain, and examining the ACL after rebooting again. That would narrow down when the change is occurring.
The use of roaming user profiles doesn't make any changes to the machine's configuration. The flag related to whether a user's profile should be considered romaing is obtained from Active Directory at logon-time and cached in the per user subkey of "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList".
See http://technet.microsoft.com/en-us/library/cc756952(WS.10).aspx :-)