Windows 7 Thread, Mandatory profile issue in Technical; v.odd. I'd leave the profile off that server altogether then. Does it need to be on there?...
29th April 2010, 12:41 PM #16
v.odd. I'd leave the profile off that server altogether then. Does it need to be on there?
29th April 2010, 12:59 PM #17
Well after some testing it seems it hasnt worked in the new location so domain\adminstrators isn't the cause of my problem, i've just tried doing a copyto on a default profile again and starting fresh, added domain users to the permissions within the registry hive, logged on fine, logged off and tried to log on again and it fails
This laptops going out the window in a minute
29th April 2010, 01:19 PM #18
Applied the profile to a user, but moved the user out of the OU it was in and into one that doesn't load group policys and it works, so it seems there is a policy that is making it get stuck!! GETTING CLOSER!
29th April 2010, 01:29 PM #19
Use Group Policy Modelling & Results in the GP Management module to see which policy(s) is causing the problem.
30th April 2010, 10:30 AM #20
In a domain there is no DOMAIN\Administrators group.
You only have BUILTIN\Administrators.
DOMAIN\Domain Admins should suffice - as by default Domain Admins are Administrators on all member servers, DCs and workstations in a domain.
If you really want to use the 'administrators' group - then it would have to be a local server or workstation group.
FS1\Administrators <-- Would apply to Local Admins on FS1, but wouldn't necessarily cover Domain Users.
30th April 2010, 10:38 AM #21
Cheers azrael, i think i've sorted it now, i pretty much replicated everything the students were using (which was working fine) set that up and then just adapted thatto the teachers settings, all seems to be working, going to get a few teachers to test it soon though
1st May 2010, 12:30 AM #22
When you create the original mandatory profile, how did you make the initial copy? Unless you use the Copy Profile utility built into Windows and set permissions in the profile (not the file/folder permissions), the profile will never work properley. See 'Creating Mandatory Profiles' here: Mandatory Profiles - Wiki
4th May 2010, 09:27 AM #23
Originally Posted by ajbritton
I can't say that's true Andy - we've a few perfectly working Mandatory Profiles which were never copied using that utility. It may well set the correct permissions for you, which may or may not save you time, but there's no reason you can't do that yourself. A profile is just a bunch of files & folders with appropriate permissions - they don't need divine power granted them by the OS to work correctly. IMHO it makes it easier to troubleshoot profiles if you can get away from this way of thinking.
4th May 2010, 01:03 PM #24
Not true I'm afraid. One of the files in the profile (NTUSER.DAT) contains the registry for the HKEY_CURRENT_USER hive. This has permissions on the registry structure INSIDE the file. This is unconnected with the ACL on the file itself. Using CopyTo will modify these permissions. If you don't do this, the only option is to use RegEdit to manually connect to registry settings in NTUSER.DAT and modify the permissions. However, since there is no documentation as to what permissions should be set across all the keys under HKEY_CURRENT_USER, it's best to let the OS do it for you in the way that is known to work and as Microsoft intended. IMHO
Originally Posted by timzim
I've lost track of the number of times I've had to explain this to people. That's one of the reason I wrote up the WIKI article in the first place. I've certainly seen failures to apply group policy due to this issue on several occasions and if you think about it, it's logical. When Windows creates a new profile, it grants the user who creates it permissions to the files and in the registry. If you then copy the profile and try to let someone else use it, that user won't have the necessary permissions to update it. Looking at the registry permissions on HKEY_CURRENT_USER\Software\Policies on my PC shows me that the only users with access are Administrators, System and myself. Since the group policy extensions run under the security context of whoever logs on, that user must have the necessary rights to write to the registry or policy settings cannot be applied.
Another option might be to enable verbose USERENV logging (http://support.microsoft.com/kb/221833). This gives a wealth of information on what goes on during logon but can be rather tedious to pick through.
It might also be worth disabling caching on the share (http://support.microsoft.com/kb/287566)
Last edited by ajbritton; 4th May 2010 at 01:21 PM.
By adamchapman in forum Windows
Last Post: 4th February 2011, 03:29 PM
By NickDay85 in forum How do you do....it?
Last Post: 4th March 2009, 12:49 PM
By dtakias in forum Windows
Last Post: 3rd March 2009, 11:35 AM
By Monkey-Boy in forum Windows
Last Post: 20th September 2008, 12:23 AM
By Neville in forum Windows
Last Post: 16th September 2008, 11:21 AM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)