This how I fix this on 2003 - May help.
- Make sure that there are no group policy rules still being applied to that user.
- Delete the profile stored locally, as in on the desktop system.
- Delete the roaming profile from the network.
- Run gpupdate /force on the desktop.
- Reboot the desktop.
Log on as the user - The roaming profile should not kick in.
Then add the user to the appropriate OU's and all done :)
I would, initially, think that the user's profile isn't loading properly and a temporary profile is being created on each logon. You're not seeing other settings in the user's profile not applying, though, so that makes me think that it's not a temporary profile creation issue.
Since you're not getting any warnings about the user's profile not being accessible and a temporary profile being created, during logon, it sounds to me like the "Delete cached copies of roaming profiles" feature has been enabled in Group Policy.
I say this because, assuming this feature has been enabled, the cached copy of the user's profile would be deleted from the local disk of the client computer after logoff. Since Google Chrome is installed into a non-roaming area ("Local Settings") of the user's profile the behaviour you describe re: Chrome being "gone" on a subsequent logon would jibe with profile caching being disabled. I believe the "Windows Desktop Search" index is also located in the "Local Settings" portion of the user's profile.
You can check this using the Resultant Set of Policy tool (Start / Run / RSOP.msc) and looking under "Computer Configuration", "Administrative Templates", "System", and "User Profiles".
Having the cached profile deleted also jibes with the logon taking a long time, since the entire contents of the profile is being copied down on each logon.
Edit:
My psychic powers pay off again... >smile<
I can't advise you to enable / disable the feature since I don't know who enabled it in the first place or why it was enabled. RSoP will show you, via the "Precedence" tab on the "Delete cached copies of roaming user profiles" setting which GPOs are affecting the setting. Presumably, since you weren't aware that the feature was enabled, you aren't responsible for the GPOs that might be enabling the setting. I'd contact whoever your Group Policy / Active Directory administrator is and see if they can explain the rationale for the setting.
Best Answer
If the SunOS server is the only server in the equation, it's probably configured using SAMBA as a PDC and has the user profiles shared from it as well. The procedure to do this is documented, but not ideal. If you can use a Windows Server instead of a Linux server, you'll have many more features. SAMBA4 adds a lot of options, but it's still nowhere near feature competitive with full-blown AD.