Mandatory profile issue

[mrbios]

Seem to be having an issue here, i've got the students profile working, they can log on and off happily

 

But the teachers mandatory profile they can only log on once, once they log off and try again you get the error "User profile service failed the logon, user profile could not be loaded" i can go in as adminstrator to remove the profile manually then it logs them in once again, it seems all the settings are coming accross ok

 

any ideas what im missing?

 

EDIT: i didn't explain that very well, too many interruptions, the profiles are exactly the same, i copied the one i made for students to use for the teachers, but one works one doesnt

 

Same permissions on both (though in completely different locations) straight copy of both folders, i dont get it!

Edited April 29, 2010 by mrbios

[timzim]

Are teachers all sharing the same profile? Are GPO settings the same for both Students and Teachers? Need more info.

[mrbios]

about 80% of teachers load this same profile, i've gone through group policy and while students and teachers are similar teachers just have less restrictions

[sted]

are your gpos set to remove roaming profiles on logout?

[mrbios]

Ah solved it, ownership on the folder wasn't set to domain\administrators, damn permissions, such fussy things!

[mrbios]

Ok another problem, i can't set DOMAIN\Administrators as the owner, i can set DOMAIN\Domain Admins, or administrator, but not the administrators builtin group, any ideas?

 

Now it's logging them on all the time, except it's creating a TEMP profile and not picking up all the GPs

Edited April 29, 2010 by mrbios

[timzim]

Which folder are we talking about? On the server or the workstation?

[mrbios]

On the server,

 

Studentprofile is on a replicated DFS share which is held on DCs, this works perfectly, has domain\administrators as the owner and kids are logging in and out fine

Teacherprofile is on a non-replicated DFS share which is held on the fileserver, this won't allow me to set domain\adminsitrators as the owner, tells me it doesn't exist, i've tried setting it from different places as well

[timzim]

If it's the server copy of the profile it'll need System:F, Domain Admins:F, Domain Users:RX

[timzim]

Can you not shove the teacher profile on the same DFS share as the pupil profile?

[mrbios]

Can you not shove the teacher profile on the same DFS share as the pupil profile?

 

Well that's one way to do it but for now im going to keep that as a last resort if i can't fix it any other way though

[mrbios]

If i set the ownership back to FS1\Administrators (FS1 being the file server it's on) the profile loads properly but goes back to only working once then failing the logon every other time

 

If i set the owner to Domain Admins then the profile loads properly so long as domain users have FULL access rights

 

If i set the owner to Domain Admins with the access rights set to read and execute for domain users the profile fails to load properly

[mrbios]

Moved the profile to the same folder as the student one and it works, so i know it's definately down to that one permission setting, just need to know how to set DOMAIN\Administrators as the owner of a folder on something other than a DC and i'll be all sorted!!!!

[timzim]

If the server is a member server and you're logged on as a member of Domain Admins you should be able to do this. You might not be able to if you're only logged on as local admins.

[mrbios]

I've tried setting it logged in as domain admin, local admin, doing it remotely from a DC and remotely from my PC, as far as the servers concerned domain\administrators isn't a choice it's allowing me to make >_<

[timzim]

v.odd. I'd leave the profile off that server altogether then. Does it need to be on there?

[mrbios]

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

[mrbios]

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!

[timzim]

Use Group Policy Modelling & Results in the GP Management module to see which policy(s) is causing the problem.

[azrael78]

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.

 

E.g.

 

FS1\Administrators <-- Would apply to Local Admins on FS1, but wouldn't necessarily cover Domain Users.

 

HTH,

 

Az

[mrbios]

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

[ajbritton]

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

[timzim]

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.

 

 

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.

[ajbritton]

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.

 

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

 

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)

Edited May 4, 2010 by ajbritton