Thanks Erik. One other thing I can see that might be causing it and it's a bug that's been around since the original AD Provider. I see that you have it listed as Forest Level and then Domain Level. I'm assuming that means Forest Level (domain.com) and Domain Level (staff.domain.com) as an example. Which is the AD provider pointing to? domain.com or staff.domain.com? From what I remember from other posts role synchronization wouldn't work properly unless it was pointing to the branch in the forest it belonged to (in this example dc=staff, dc=domain, dc=com). I haven't got the facilities currently to build a forest in that format so I haven't been able to test or try code around it.

I can only speak on my experiences because it's darn near impossible, I think, to be able to match how everyone has setup their AD environment. Ours here at work was setup by another department and my test setup at home was setup by myself and these are the observations I've made:

Multiple domains in the forest: I can't speak to this because I don't have such a setup but I do remember this has never worked quite right (users can log on but roles don't get synched). It's something that I do want to look at down the road but there are other issues that need to be taken care of first (child portals for example).

However, in a single domain setup > 90% the reason I've found that are synchronization/DNN profile problems is related to impersonation (the local server's NETWORK SERVICE/ASPNET account can't read the active directory). I don't know if Tam's intention with the username/password on the setup page was intended to be the account that handles every interaction with the AD or if it was just for the initial setup. From what I've seen it's just the initial setup and Tam's not available to ask. I've yet to explore if it can be used for every interaction (another thing on my list).

That said, what I'd try to do is to uncomment <identity impersonate="true" /> from your production web.config and change it so that it looks like this: <identity impersonate="true" userName="domain\username" password="password" />. The user can be any domain user who has read access to the AD (all domain users do I believe) and it doesn't have to have any special administrator rights. That user does have to have the same permissions to the DNN directory that NETWORK SERVICE/ASPNET does however. I suspect in your situation that the access rights between the two AD installs (Test and Production) are different.