text: Alashhars
  The one suggested by alashhar - deleting all of the profile entries in the registry - and then creating a new profile. We'll have to see if it holds....
  Better solution
  For anyone battling this type of problem, I have found a somewhat better solution than Alashars on another forum. In Alashar's solution, you - of course - wind up blowing the profile away and it requires you to rebuild the users profile - copy all their old stuff over, etc.
  The following procedure avoids that and seems to fix the problem, and can be executed remotely with a little effort, without bothering the user:
  1 Get the SID of logged in user that has experienced the problem - I do this by remotely executing whoami.exe using OWexec.exe (a tool similar to psexec but runs under logged in users credentials)
  2 remotely connect to the user's registry and go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID from above>.
  3) Note the value for ProfileImagePath
  4) Check the value of ProfileImagePath for each of the other SIDs in CurrentVersion\ProfileList to see if they are the same value as noted in step 3.
  a) NOTE: %systemDrive%\documents and settings\(profile) is the same path as C:\documents and settings\(profile)
  b) If a duplicate value exists:
  i) export the registry key and save it to c
  drive of that machine just in case.
  ii) Then Delete the key containing the duplicate path and disconnect from the remote registry.
  So far this has worked for the machines I've implemented it on (over 30). But I would LOVE to have an explanation of what is going on here.
  Remember that these are :
  1) clients migrated from an NT4 domain to an AD domain
  2) running xp and win2k
  3) not running terminal services
  4) a 2-way trust exists between NT and AD domains
  5) Does not occur to every PC every day ? only about half of the migrated PCs have exhibited the problem. Some of those occaisionally ? some regularly.
  NT domains and Active Directory domains don't intergrate
  this one, because of the way you migrated from NT to Active Directory using ADMT, I think is a security permissions problem.
  0226 userenv 1054
  0628 userenv 1508
  Windows was unable to load the registry. This is often caused by insufficient memory or insufficient security rights.
  This one probably is probably the same as the one above. A security permissions issue. BUT it might be profile related. again because of how you migrated them from NT to Active Directory
  2 sec later userenv 1502
  Windows cannot load the locally stored profile. Possible causes of this error include insufficient security rights or a corrupt local profile. If this problem persists, contact your network administrator.
  This one, seems as though it's looking for the Active Directory profile and can't find it. There is an account in Active Directory but no associated profile for it.
  <1sec later userenv 1511
  Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off..
  and this one is related to the one above:
  0033 userenv 1054
  Windows cannot obtain the domain controller name for your computer network. (A socket operation was attempted to an unreachable host. ). Group Policy processing aborted.
  note: NT domain users must use the NT domain PDC or BDC to authenticate to the NT domain. They can not use the Active Directory domain to authenticate with. NT Domain users can not log on to the Active Directory domain using their NT domain profiles ..and.. their workstations have to be members of the NT domain. If their workstations are joined to the Active Directory domain, they have to use the Active Directory domain user profiles. If you want to keep NT domain user profiles in the Active Directory domain, the ADMT might not work as planned, and you'll have to use the fix corrupt profile method of creating a clean profile, then moving over the old profile settings into the new clean profile and leaving out the these 3 files from the old profile.
  Ntuser.dat
  Ntuser.dat.log
  Ntuser.ini
  DNS problem resolved
  .
  "
  No what we actually did was just create an AD DNS server and move the IP address only, of the old DNS server that was serving the NT domain, over to the new DNS server on the AD domain. In this way, all of those static clients pointing to x.x.x.30 for DNS would still find a DNS server there - only now it is a different server running on an AD domain. So it's just like you said, an AD server serving up DNS to an NT domain.
  "note: NT domain users must use the NT domain PDC or BDC to authenticate to the NT domain. They can not use the Active Directory domain to authenticate with. "
  Right, and that is exactly how it is. The NT users authenticate to NT4 PDC and BDC. The AD users authenticate to an AD PDCE and DC.
  And, I found the issue with the strange DNS Suffix! Taking a very close look at the packet captures from pinging NTPDC.NTDOM.COM vs just pinging NTPDC, I finally noticed that there was a semicolon at the end of the created fqdn in the latter case (ntpdc.ntdom.com
  . I checked the search suffix on the client and even replaced that entry, though it looked fine. Still had the issue. I took a close look at the DHCP server. That's when I found the blurb about microsoft not supporting DNS suffix order - Is that true? But in any case, I noticed that the suffix search order in DHCP option 119 was separated with semicolons. That made me suspicious (not sure if semicolons are allowed there or if it has to be commas)
  but then I remembered that somebody long ago(not that long ago) had specified a suffix search order in group policy. So I took a look at that and it was separated by semicolons as well, and on that one, the descrpition specifically says to separate with commas.
  So I changed that, forced a gpupdate on a few clients, did an IPconfig /flushdns, repeated my pings, and this time it correctly resolved with ntpdc.ntdom.com.
  One little mystery solved but I don't think it will help us with the profile issue.
  btw. I have been assuming all along, that running an RSOP would show any failed permission issues for group policy. Is this true or am I swimming under a false assumption?
  Thanks for all your help
  k
  the result of all policies applied.
  you want logging mode to see how the GPOs are applied to users/computers/groups of em. eg if you've got 5 GPOs applying to an OU or a combination of nested OUs you can see the result.
  Planning mode allows you to see a result without applying the GPO. Great for what ifs.
  RSPO doesn't really tell you conflicts per se eg this policy conflicts with this policy, because conflicts are handled by order of precedence eg local, site, domain and OU in that order so a conflict at the OU level with local machine level, OU applies with the exceptions of block and no override.
  If you have 3 GPOs at the OU level and they apply in order 1,2,3 RSPO will show you the results of those GPOs being applied in that order.
  And back to NT domains. Much of what admins could do in NT domains, they couldn't do in Active Directory domains. Some of the older NT guys really disliked Active Directory domains because many of the scripts, configurations, tweeks, and waaahaaas to keep NT working right no longer work. Just like the open source debate with programmers hating standardized applications. They can't do their magic or tweeks, or little code changes they like to do.
  so while NT scripts are ok for NT machines, they may not be ok for AD domains. same with importing group policies from NT to AD. Especially going from NT to W2003.
  and I would still try that corrupt profile method for moving NT profiles to AD profiles if desktop setting for the user environment is a necessity.
  added thoughts....
  typically, microsoft's best practice of moving from an NT domain to an Active Directory domain is to upgrade the NT domain to Active Directory. The upgrade process juggles all the seperate security domains in the NT domain, into, basically, one big security domain. While the upgrade process tries to incorporate some of the security domains into child domains, sometimes that doesn't work well. So those security domains end up like these seperate domains in a different forest. Weird but it happens, especially if there are a bunch of security domains with different names [non contigious names]. The upgrade process also changes the schema which is really at the core of the differences in NT and Active Directory. The way Active Directory names objects is different and the way those objects are cataloged is different than NT.
  No Control over the guilty apps
  it shouldn't matter provided that your using W2K and above. you can actually turn off NetBIOS over TCP/IP and run a pure TCP/IP network with DNS......and you might want to consider WINS for pre W2K stuff and go with a simple computer name to ip address resolution rather than some Group Policy stuff that may or may not work reliably.
  but if your mixing and matching domains in a non contigious namespace using trusts, and the domains are NT and W2003/2008 Active Directory, I wouldn't mix and match users unless it's done simply to access shared resources where share and NTFS permissions apply.
  and after I thought about it, I wouldn't mix and match users in the domains. Either 1 or the other and they access stuff through the trust or remote access, but not access by span domains and with mapped drives, I'd screw the names and stick strictly with ip address. \\ip address\share name.. least with that, you either get a credential box popup or the trust allows access.
  if it's remote, you know, least painful way, use Remote Access to control it. and that's until someone comes up with a plan to move all data and all users/compters from the NT domain to the Active Directory domain.
  The 2 domains are just making a big headache and costing money..