Local Profiles Vs Domain Profiles.

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Ive started studying for the 70-290 now, and alot it it seems to make sense. But . . . . one thing has a question mark above it in my mind.

I know member servers and workstations can both have local users, which can be added using either the Computer management MMC or the Net user command line.

But . . . the Doman Controller which is holding the AD, cannot have local accounts added in these ways. I think that that's because a doman controller cannot actually have local accounts, simply because the only accounts it can have are those stored on the AD. (Excepting the possibility of the Administrator account, but isn't that one the AD too?)

Is this right?

Please, someone put me out of my misery and tell me i'm totally wrong.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Can't. You're right.

Also with the Adminstrator account the local one ceases to exist when you install AD. You do however still have to specify a password for the recovery console, which is local.

 

Excellent, cheers for that Simon.

I'm getting to grips with it ok, at the moment, I think.

I used to be the sole systems admin for two offices of a government department. I used to administer several *nix servers, and a Windows 2000 server, but both were using front end's. Apparently we couldn't be trusted.

So hopefully a lot of it will be fitting in the gaps.

 

Just thought that I'd point out that the title of this thread doesn't relate to the question that you posted.

Profiles, although a part of an account are something entirely different! You can still log onto a DC with a local profile, even though it is not a local account, in much the same way that you would log onto a PC in the Domain with a local profile with a domain account.

If your users log onto the same PC all of the time then there would be no need to implement roaming profiles, unless of course you have a policy in place that says that users must use a compulsory profile, which would be done on a roaming profile by changing the file NTUSER.dat to NTUSER.man.

You can also set all users to use the same profile by specifying in their profile path in their AD account to point to a centralised profile.

Anyway,

 

Hey Simon,

Looking back at the thread title and then the question, I see exactly what you mean.

With the AD DC then, if you log onto the DC with an AD account, I suppose it acts just like a normal Client then. ie. Downloading the profile from the AD so the user logging on can use it, and then placing it on the Client machine (Even though in this case the client is also the server) as a local profile. Is that right?

I've always liked the thought of NTuser.man. Giving everyone the same desktop and the same icons, then watching them fiddle about for hours to get it just the way they like it . . . then log out.

 

Yes, but, and I'm not entirely sure about this, by default only certain users have the right to 'log on locally' to a DC. You can of course change this in Group Policy. Hopefully someone else can clarify this before I have to go searching for the answer!

 

I'm confused about the part when you say logon with an account? What type of account are you talking about. Any AD accounts without administrative rights or built-in domain local group can not log on locally to the DC (loggin locally means physically sitting down at the DC server).
Accounts from built-in domain local groups such as Server Operators, Print Operators, Backup Operators, Administrator, etc. would be allowed to log in locally on Domain controllers. Built-in domain local groups is like machine local groups on domain controllers. These built-in domain local groups have pre-authorized rights and permissions to perform administration locally on the DC.

 

What I meant was . . . .

Hypothetically if you were to log into the DC (As an administrator account for instance) then I assumed that the profile for the related account would then be stored locally on the Server, as it would do on a normal client.

When I say log in, I actually mean by sitting at the DC with AD on it.

 

Yes, you are partly correct. Like Simon.. has stated, the Administrator on the local server ceased to exist when it become a domain controller. When you upgrade a server to Domain controller, that local group on that server has become Built-In domain local group in Active Directory, which is being shared by all domain controllers and not just that particular machine. Every DCs in the same domain now share that same Built-In domain local groups and group members; and cannot be deleted or moved.

 

But . . . It does still have a profile, right?

 

Yep, unless otherwise specified a Local Profile is always created.

 

yes. I would suggest the 'Mastering Windows Server 2003' by Mark Manasi to get a thorough understanding on most subject; which is what I'm currently reading for the server exam. I was studying on the Groups types and scopes subject but couldn't understand the ms press material; which is flimsy. After reading up on dozens of books to get a better understanding of it, I turned to Manasi book, and the whole explanation is all in there. I recommend for all examers to read this book if they need better explanation on things.

 

Can't agree more zenboy.

When reading it, it feels very badly explained. I've heard that the MS Press books usually explain things as though you have the 18 months or whatever, experience, but even then, the explanation is horrible.