For older systems Windows XP/2003 you can create a couple Template accounts and simply copy the templates. When you copy the accounts many of the fields will start with the copied values. In your templates use variables like %USERNAME% instead of the username.
Another option is to script account creation with Powershell or vbscript. Look around there are many good examples of scripts that will add accounts to the directory and set most options.
For Vista/Windows 2008 computers. If the computers that profiles will be roaming on are in a OU or group that you can apply a Group Policy too then you can set the Roaming Profile Path per computer.
Open up your group policy editor and go to here.
Computer Configuration \ Administrative Templates \ System/User Profiles \ Set roaming profile path for all users on this computer.
The feature you're looking for is folder redirection. This feature, on it's own or in combination with roaming user profiles (I recommend using both) will allow you to keep the largest folders of the user's profiles on the server and speed up logon times.
I also recommend creating the folders and setting the permissions yourself on the destination folders. The OS default method seems buggy brain-damaged to me.
Edit:
My issue with the built-in functionality that allows clients to create the folders is that I stronly prefer not to have a world-writable folder for such a critical purpose (redirected user folders) on my server computers. I'm not sure that Microsoft has ever cleaned up the idiotic "feature" where the client blocks NTFS permission inheritance when it creates the user's folder and applies permission to it, either. I want to be in control of my filesystem permissions, I want inheritance turned on throughout the entire folder hierarchy, and I don't want a world-writable folder laying around on my servers.
I generally redirect "My Documents", "Desktop", and "Application Data". I always disable the idiotic "Grant the user exclusive access..." functionality (since it screws up my NTFS permission inheritance hierarchy). I may do redirection based on group membership if I have multiple destination file server computers and want all my redirection handled in a single GPO... that's more of a GPO design concern than a Folder Redirection configuration issue.
"AppData" redirection has been somewhat problematic. I've had issues with Adobe Reader 9.0 versions and the current Apple iTunes 9.2 versions not working properly when the user has a redirected AppData folders. Still, with the huge proliferation of small files that get created there, leaving "AppData" in the user's roaming user profile isn't an option if you want short logon / logoff times.
Generally I wouldn't exclude any "normal" users from Folder Redirection. Administrative and service account context users would be excluded, typically by being located elsewhere in the OU hierarchy such that the GPO applying Folder Redirection settings doesn't apply. WMI filters aren't useful because Folder Redirection is a user setting, and WMI filters only apply to computers.
Slow links and disconnected computers are good candidates for Offline Files. If a user isn't ever going to be connected to the LAN with high speed I might be apt not to use Folder Redirection at all, but I don't have any situations where that's the case in my current Customer base so I haven't really thought about it. Offline Files works very well in Windows 7 and Windows Vista. It works acceptably in Windows XP if the user's redirected folders are under 2GB in size. Anything more than 2GB and it starts working poorly because of a frustrating signed 32-bit integer size limit on the amount of data that will be automatically cached by Offline Files.
Best Answer
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.