Drives not mapping in XP with profile path set in AD? Argh!

[Miscbrah]

Hi - got a really really odd problem that's been mashing my swede for a day now.

 

Building a new domain here, imported all users ok from our current domain and aiming to cut over during the summer. Have test vms of XP and Win7 clients.

 

What's weird is using the XP client (Win 7 clients untested as yet as their .v2 profiles aren't sorted), with GP extensions installed, will not map network drives either from the Preferences in GP nor from a startup script. Most file servers are Linux/Samba on the 'old', current domain, but usernames and passwords are the same and regularly updated so rights are not an issue.

 

Here's what I've found so far, and VERY odd it is:

 

- Administrators are unaffected by this crappery.

 

- When the user in question has no profile path set in AD, the drives map fine as per the script or Preferences or whichever method I turn on at the time. When it's set in AD though this happens.

 

- Application Log on the vm gives two odd errors ON ONE XP VM, BUT NOT A FRESH ONE:

Event ID: 1085 (GP client side extensions failed to execute)

Event ID: 8196 (client side extension unhandled exception 0xc0000005 in threadEntry : client main)

 

- UNC path to the batch file option of mapping works ok and the batch file runs BUT prompts for username and password before mapping the drives.

 

Anyone have any idea what on earth is going on? Never seen anything like this ever before, and I'm on day 2 of it now with no idea :/ Without that profile path (again to a Samba server) the drives just map fine!

 

Cheers for reading this far if you're not terrified yet!

Edited April 18, 2012 by Miscbrah

[Michael]

Have you installed the Group Policy Preference Client Side Extensions for Windows XP?

 

Edit: Re-reading your post it looks like you have. How have you created the profile and is it a mandatory profile?

Edited April 18, 2012 by Michael

[Miscbrah]

Hi! Oh jeez thanks for reading all that.

 

Roaming profile. Stored on a Samba server that's currently part of the old domain (which everyone is still on.) All accounts are now on the new domain which is having the problems, but which nobody's on yet. All accounts have the same usernames, members of identically named groups and all passwords are the same and update nightly - the locations themselves will map manually and the batch file that maps them (if I use the logon script way of working) does actually work, just won't do it on its own.

 

Experimented by copying a random test user's roaming profile over to the new dc and logging on as them but no joy there either.

 

Also had a go on a real life PC joined to the new domain, also still happening there.

[Michael]

Is there a trust between the two domains?

[Miscbrah]

No there's not... Am I walking into asking "should I set one of these up?"

 

...Am I a berk not to have (I'd believe you if you said yes)? :o

 

I like the sound of this. I'm about to go home and scream into a pillow but I'll do this first thing tomorrow! If it works I'll figure out a way to email you a pint also as it's been making me silly for so long now!

[Miscbrah]

Okay that wasn't it, but I've had a little more progress on butchering profiles and moving bits manually here and there and so on, so actually a different workaround presented itself, and (unhelpfully for anyone looking this up in future) I don't need a solution.

 

BUT - just in case anyone DOES encounter this in future and comes unstuck, I DID manage to get it working ok on my last attempt by stripping out Desktop items (and a few other bits) from my test user's profile, putting that in a new profile folder on a new server, and then redirecting the user account to that in their AD Profile settings. So if it's happening to you then do that and rummage from there says I.