Roaming Profiles
HI;
I have long standing problems with roaming profiles.
1: When new user is created in AD and roaming folder path is given to it after some times the complete profile resets and all the initials settings appears on the screen, it cannot be solved unless the roaming profile is deleted from the server and the new one is created.
2: Every time user logs in to PC, in Documents and settings each time new local profile folder is created for him. Such as
user.domain.001
Upon next login
user.domain.002
New folders are created every time upon login.
Kindly help me to solve these problems.
Any help is highly appreciated.
Thanks
I have long standing problems with roaming profiles.
1: When new user is created in AD and roaming folder path is given to it after some times the complete profile resets and all the initials settings appears on the screen, it cannot be solved unless the roaming profile is deleted from the server and the new one is created.
2: Every time user logs in to PC, in Documents and settings each time new local profile folder is created for him. Such as
user.domain.001
Upon next login
user.domain.002
New folders are created every time upon login.
Kindly help me to solve these problems.
Any help is highly appreciated.
Thanks
ASKER
i use windows XP Pro. I checked for all necessary permissions those all are correct in my point of view. Can you please tell me what specifically i have to check in userenv.log
Where are you storing the profile......is it on a server? I think that is what morse is trying to say. You referenced roaming. That would mean that the user profile location that needs the permissions is on the server not the PC. I hope that makes sense.
And as far as the PC is concerned, yes when you have a roaming profile it SHOULD create an entry on the local pc. Now the next question you would is ask is , A new profile?. That shouldn't be the case.
ASKER
if the permissions are needed on server then the profile would not load on the pc but it loads with different names such as
user.domain.001
and second when new profile is created for some days it works fine suddenly it resets all the settings are lost and every thing is changed.
user.domain.001
and second when new profile is created for some days it works fine suddenly it resets all the settings are lost and every thing is changed.
Hi aib_it
Sorry I haven't been able to get back to you before now.
You are looking for errors in the userenv.log leading to the creation of the new profile folders.
Have you compared the permissions on the server with those given in the white paper?
Sorry I haven't been able to get back to you before now.
You are looking for errors in the userenv.log leading to the creation of the new profile folders.
Have you compared the permissions on the server with those given in the white paper?
ASKER
HI:
I have compared the permissions those are ok. I don't understand a profile working for a year suddenly resets.
I have compared the permissions those are ok. I don't understand a profile working for a year suddenly resets.
On re-reading your question, you answered my query about operating system as XP Pro. What are you using on the server?
What errors were there in the userenv.log, please?
What errors were there in the userenv.log, please?
ASKER
the server is windows 2003 with SP1. the errors what i see are
LoadUserProfile: lpProfileInfo->lpUserName = <NetworkService>
LoadUserProfile: NULL central profile path
LoadUserProfile: NULL default profile path
Reconciling roaming profile with local profile the exclusion on both server and client are same:
LoadUserProfile: lpProfileInfo->lpUserName = <NetworkService>
LoadUserProfile: NULL central profile path
LoadUserProfile: NULL default profile path
Reconciling roaming profile with local profile the exclusion on both server and client are same:
OK
Can I just check that you have the following set:
Profiles$ folder:
SHARE permissions:
Administrators = Full Control,
Domain Users = Change & Read
NTFS Security permissions, (before setting any permissions, make sure that you click on ADVANCE, un-check the "ALLOW INHERITABLE PERMISSIONS ......", click on REMOVE, and then click on OK.)
Administrators = Full Control (This Folder, Subfolder, and Files)
Creator Owner = Full Control (Sub Folder and Files)
Domain User = Read + Write (This folder, Subfolders, and Files)
To map the Profiles$ folder to the user account, open up Active Directory Users and Computers, double-click on the user(s), select the Profiles tab, and in the PROFILE PATH field type \\<The name of your server>\Profiles$\%usernam
Make sure that the path to the profile folder is typed in UNC format like above, and not in absolute format. Once you have typed the profile path, click OK.
IF all those are ok, do you recall if the start of the problem coincides with anything such as installation of a firewall or update of one?
Can you update group policies from a client? - At command prompt, type gpupdate /force
If the policies update OK, you should see an application log entry of:
Event Type: Information
Event Source: SceCli
Event Category: None
Event ID: 1704
Date: 18/12/2006
Time: 02:41:46
User: N/A
Computer: AML-PC05
Description:
Security policy in the Group policy objects has been applied successfully.
Can I just check that you have the following set:
Profiles$ folder:
SHARE permissions:
Administrators = Full Control,
Domain Users = Change & Read
NTFS Security permissions, (before setting any permissions, make sure that you click on ADVANCE, un-check the "ALLOW INHERITABLE PERMISSIONS ......", click on REMOVE, and then click on OK.)
Administrators = Full Control (This Folder, Subfolder, and Files)
Creator Owner = Full Control (Sub Folder and Files)
Domain User = Read + Write (This folder, Subfolders, and Files)
To map the Profiles$ folder to the user account, open up Active Directory Users and Computers, double-click on the user(s), select the Profiles tab, and in the PROFILE PATH field type \\<The name of your server>\Profiles$\%usernam
Make sure that the path to the profile folder is typed in UNC format like above, and not in absolute format. Once you have typed the profile path, click OK.
IF all those are ok, do you recall if the start of the problem coincides with anything such as installation of a firewall or update of one?
Can you update group policies from a client? - At command prompt, type gpupdate /force
If the policies update OK, you should see an application log entry of:
Event Type: Information
Event Source: SceCli
Event Category: None
Event ID: 1704
Date: 18/12/2006
Time: 02:41:46
User: N/A
Computer: AML-PC05
Description:
Security policy in the Group policy objects has been applied successfully.
You might also like to try this:
Create a log file of all roaming profile transactions using the checked version of UserEnv.dll.
The checked version of the dll is the same as the retail version, except that it contains debug flags that can be set and used with the kernel debugger. It is included in both the Windows Device Driver Kit (DDK) and the NT Software Development Kit (SDK).
On an affected client:
1. Rename the Userenv.dll file in the %systemroot%\System32 directory to Usernv.org.
C:\> rename %systemroot%\system32\user
2. Copy the checked version of Userenv.dll to the %systemroot%\System32 directory of the client computer that you want to debug.
****The checked version of the Userenv file must match the version of the operating system being used.****
C:\> copy userenv.chk %systemroot%\system32\user
3. Apply the following registry hack:
Hive: HKEY_LOCAL_MACHINE
Key: SOFTWARE\Microsoft\Windows
Name: UserEnvDebugLevel
Type: REG_DWORD
Value: 10002
A log file of the roaming profile transactions will be written to userenv.log to the root of the C: drive. Post it here, please.
Create a log file of all roaming profile transactions using the checked version of UserEnv.dll.
The checked version of the dll is the same as the retail version, except that it contains debug flags that can be set and used with the kernel debugger. It is included in both the Windows Device Driver Kit (DDK) and the NT Software Development Kit (SDK).
On an affected client:
1. Rename the Userenv.dll file in the %systemroot%\System32 directory to Usernv.org.
C:\> rename %systemroot%\system32\user
2. Copy the checked version of Userenv.dll to the %systemroot%\System32 directory of the client computer that you want to debug.
****The checked version of the Userenv file must match the version of the operating system being used.****
C:\> copy userenv.chk %systemroot%\system32\user
3. Apply the following registry hack:
Hive: HKEY_LOCAL_MACHINE
Key: SOFTWARE\Microsoft\Windows
Name: UserEnvDebugLevel
Type: REG_DWORD
Value: 10002
A log file of the roaming profile transactions will be written to userenv.log to the root of the C: drive. Post it here, please.
When looking at the error your stated. 1. Does the ".00#" profile go away after you log off with that user? 2. When you log into the system in question can you open the shared folder from windows explorer.... e.g. "\\servername\foldername" ? So far most of what I can find relating to your error is referencing name resolution and the ability to "resolve" the host\path for the profile directory.
ASKER
yes after logging off from the user .00# profile is removed and upon next login it is created with another .00# profile. I can open the shared folder from windows explorer.
One other thing, are you also trying to perform the My Documents redirection within a GPO? It seems that you might be having a conflict of sorts there.
Or
Are your clients logging in using Wireless connections? Apparently this is a known problem when logging in as soon as the Login Prompt shows... Microsoft claims that if you wait at least 30 seconds from the login prompt before providing credentials. The problem supposedly results because the machine account has not had a chance to register and authenticate.
Just another thought.
Or
Are your clients logging in using Wireless connections? Apparently this is a known problem when logging in as soon as the Login Prompt shows... Microsoft claims that if you wait at least 30 seconds from the login prompt before providing credentials. The problem supposedly results because the machine account has not had a chance to register and authenticate.
Just another thought.
ASKER
well there is no my document redirection within GPO. And for the next statement i think i have waited more than 10 minutes but result is the same.
One thing which i know is the roaming profiles got problem when i updated the symantec anti virus from 10.0 to 10.1 this what i think may have created the problem becuase right after the updates next morning i had problems with my profile and many other user got had too.
what are the possible solution for this kind of problem such as profile resets to its old shape and creating different forlder on local .00# etc.
One thing which i know is the roaming profiles got problem when i updated the symantec anti virus from 10.0 to 10.1 this what i think may have created the problem becuase right after the updates next morning i had problems with my profile and many other user got had too.
what are the possible solution for this kind of problem such as profile resets to its old shape and creating different forlder on local .00# etc.
I have seen lots of reports on EE about this update causing problems in many kinds of ways. Have you checked Symantec's site to see if there is any info there?
You could try a system restore on a client machine to a date prior to the update and see if the problem disappears - at least that will help to tie the problem down.
Did you try the logging option I offered to see what the particular cause is?
You could try a system restore on a client machine to a date prior to the update and see if the problem disappears - at least that will help to tie the problem down.
Did you try the logging option I offered to see what the particular cause is?
ASKER
yes i did try instead i waited for longer even 10 minutes before i provide my credentials
Are you confusing me with eric_bender?
My suggestion was to use the alternative version of userenv.dll to enable logging. Have you created a log? If so, please post it here.
I also asked if the problem could have coincided with a firewall installation of upgrade & it seems that it may have done. Have you tried my mostrecent two suggestions?
My suggestion was to use the alternative version of userenv.dll to enable logging. Have you created a log? If so, please post it here.
I also asked if the problem could have coincided with a firewall installation of upgrade & it seems that it may have done. Have you tried my mostrecent two suggestions?
ASKER
i cannot see any thing different in logs no permission errror etc. Your second question was regarding system restore that option has been disabled.
Can you post the log here, please?
ASKER
i will post the logs. I have downloaded DDK but i have not found the checked version of Userenv.dll. Can you provide me the link for the required file.
Thanks
Thanks
Hi
This is from MS - you should have UserEnv.chk in the DDK.
Once you have renamed your existing userenv.dll, you need to copy userenv.chk to %systemroot%\system32\user
TROUBLESHOOTING USER PROFILES WITH THE USERENV.LOG FILE
==========================
The Userenv.log is an invaluable tool for troubleshooting the process of loading and unloading User Profiles. Each step in the User Profile process is recorded in the log, including informational and error-related messages.
The checked version of the UserEnv.dll is the same dynamic link library (.dll) as the retail version, except that it contains debug flags that you can set and use with the kernel debugger.
This file, which is included in both the Windows NT Device Driver Kit (DDK) and the Windows NT Software Development Kit (SDK), when used in conjunction with a registry entry, generates a log file that can be used in troubleshooting and debugging problems with roaming profiles and system policies on Windows NT 4.0 clients.
To enable logging:
1. Rename the file UserEnv.dll in the %systemroot%\SYSTEM32 directory to
Userenv.old or to a unique name of your choice.
2. Copy the checked version of UserEnv.dll to the %systemroot%\SYSTEM32
directory of the client machine that you want to debug. The checked
version of the UserEnv file must match the version of the operating
system and Service Pack installed on the client computer.
3. Start REGEDT32 and locate the following path:
HKEY_LOCAL_MACHINE\SOFTWAR
\Winlogon
4. Create a new value called UserEnvDebugLevel as a REG_DWORD type. Assign
the hex value 10002.
5. Reboot the computer.
Logging information will be recorded in the root directory of the C drive as UserEnv.log. You can use Notepad to view the log file.
Cheers
Steve
This is from MS - you should have UserEnv.chk in the DDK.
Once you have renamed your existing userenv.dll, you need to copy userenv.chk to %systemroot%\system32\user
TROUBLESHOOTING USER PROFILES WITH THE USERENV.LOG FILE
==========================
The Userenv.log is an invaluable tool for troubleshooting the process of loading and unloading User Profiles. Each step in the User Profile process is recorded in the log, including informational and error-related messages.
The checked version of the UserEnv.dll is the same dynamic link library (.dll) as the retail version, except that it contains debug flags that you can set and use with the kernel debugger.
This file, which is included in both the Windows NT Device Driver Kit (DDK) and the Windows NT Software Development Kit (SDK), when used in conjunction with a registry entry, generates a log file that can be used in troubleshooting and debugging problems with roaming profiles and system policies on Windows NT 4.0 clients.
To enable logging:
1. Rename the file UserEnv.dll in the %systemroot%\SYSTEM32 directory to
Userenv.old or to a unique name of your choice.
2. Copy the checked version of UserEnv.dll to the %systemroot%\SYSTEM32
directory of the client machine that you want to debug. The checked
version of the UserEnv file must match the version of the operating
system and Service Pack installed on the client computer.
3. Start REGEDT32 and locate the following path:
HKEY_LOCAL_MACHINE\SOFTWAR
\Winlogon
4. Create a new value called UserEnvDebugLevel as a REG_DWORD type. Assign
the hex value 10002.
5. Reboot the computer.
Logging information will be recorded in the root directory of the C drive as UserEnv.log. You can use Notepad to view the log file.
Cheers
Steve
ASKER
i am still confused i have installed Microsoft Platform SDK, windows driver development kit, SDk for windows vista but i have not found Windows NT Software Development Kit and device driver kit. I have searched in all these packages but could not found userenv.chk.
any idea
any idea
I've missed a trick, here.
Because you have XP and SBS2003, you can use a resultant set of policies report. On an affected client machine, click 'Start' > 'Run' then type rsop.msc which will give you the report and you can check the secutiry settings actually being employed by both the machine & the user.
Alternatively, you can turn on logging from the existing userenv.dll by hacking the registry:
1. Log onto the client computer as the administrator and run Regedit.
2. Locate the following key: HKEY_LOCAL_MACHINE\Softwar
3. Right click Winlogon, select New, and then click DWORD Value.
4. Enter the following name for the DWORD Value: UserEnvDebugLevel.
5. Enter 30002 as the hexadecimal value. This writes the userenv into userenv.log, located in the \%windir%\debug directory.
6. Run "gpupdate /force" to ensure a full listing of total Group Policy processing.
Cheers
Steve
Because you have XP and SBS2003, you can use a resultant set of policies report. On an affected client machine, click 'Start' > 'Run' then type rsop.msc which will give you the report and you can check the secutiry settings actually being employed by both the machine & the user.
Alternatively, you can turn on logging from the existing userenv.dll by hacking the registry:
1. Log onto the client computer as the administrator and run Regedit.
2. Locate the following key: HKEY_LOCAL_MACHINE\Softwar
3. Right click Winlogon, select New, and then click DWORD Value.
4. Enter the following name for the DWORD Value: UserEnvDebugLevel.
5. Enter 30002 as the hexadecimal value. This writes the userenv into userenv.log, located in the \%windir%\debug directory.
6. Run "gpupdate /force" to ensure a full listing of total Group Policy processing.
Cheers
Steve
BTW....I still believe that the SAV upgrade is responsible for your troubles and it should be up to their tech support to help you to put it right. Have you discussed this with them at all?
Cheers
Steve
Cheers
Steve
ASKER
well i have not discussed this with them actually in there new version of SAV they have mentioned that one of roaming problems will be solved. So i am trying to get new pack of SAV.
good. Let's hope it will solve your problem. :-)
ASKER
I have enabled the debug and here is few lines
32:33:593 GetGPOInfo: Local GPO's gpt.ini is not accessible, assuming default state.
USERENV(398.39c) 08:35:42:515 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Introdu
USERENV(398.39c) 08:35:42:577 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Introdu
USERENV(398.39c) 08:35:42:592 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\PIF Editor.lnk> with 3
USERENV(398.39c) 08:35:42:592 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Control
USERENV(398.39c) 08:35:42:608 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\File Manager.lnk> with 3
USERENV(398.39c) 08:35:42:608 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Command
i see the following line almost every where in the debug file.
32:33:593 GetGPOInfo: Local GPO's gpt.ini is not accessible, assuming default state.
please check and revert
32:33:593 GetGPOInfo: Local GPO's gpt.ini is not accessible, assuming default state.
USERENV(398.39c) 08:35:42:515 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Introdu
USERENV(398.39c) 08:35:42:577 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Introdu
USERENV(398.39c) 08:35:42:592 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\PIF Editor.lnk> with 3
USERENV(398.39c) 08:35:42:592 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Control
USERENV(398.39c) 08:35:42:608 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\File Manager.lnk> with 3
USERENV(398.39c) 08:35:42:608 ProcessFiles: Failed to deleted <C:\Documents and Settings\testuser\Start Menu\Programs\main\Command
i see the following line almost every where in the debug file.
32:33:593 GetGPOInfo: Local GPO's gpt.ini is not accessible, assuming default state.
please check and revert
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
for time being i have not contacted symantec
I strongly advise that you do. At present, this is a VERY likely suspect for the cause of your problem and we need to either eliminate it or confirm it.
We could go on forever and get nowhere if we don't answer this question properly.
We could go on forever and get nowhere if we don't answer this question properly.
ASKER
well i have contacted symantec and they provided new pack ver 10.1.5.5000 and i have installed that it seems that now the users profiles are fine but no 100%. Still i can see that i have two profiles on %name% and second as %name001%.
Good. I suggest you remove the duplicate profiles and see how it goes.
Can you accept my answer above, please?
Cheers
Can you accept my answer above, please?
Cheers
ASKER
Yes sure i will accept let me check wether every thing is ok or not (Profiles)
It will help to know which operating system your are using but it seems, on the face of it, that it could be a permissions issue - i.e. without the permissions to write to the profile folder, a new one is created.
Try this:
The first troubleshooting step should be to examine the Application event log on the client computer, and determine the error. If this is a roaming profile, be sure to check for the correct permissions (these can be found in the User Data and Settings white paper - http://www.microsoft.com/windowsxp/pro/techinfo/administration/userdata/default.asp) — one of the most common causes of roaming user profile errors is incorrect permissions on the profile share.
In addition to logging events in the Application Event log, User Profiles can provide a detailed log to aid troubleshooting. To create a detailed log file for user profiles:
• Start regedit and locate the following path: HKEY_LOCAL_MACHINE\Softwar
• Create a new value called UserEnvDebugLevel as a REG_DWORD, and set the value to 30002 in hexadecimal format.
• The log file can be found at: %windir%\debug\usermode\us
Cheers
Steve