So correct me if I am
wrong but what you are saying is that even though I have given them the right
over the OU to add computer objects I would still have to go to the Domain
Policy and specify the groups that can add workstations to the
domain?
From:
Sullivan, Kevin [mailto:[EMAIL PROTECTED]
Sent: 16 July, 2003 18:20 PM
To:
[EMAIL PROTECTED]
Hmmm, what error?
When the computer joins the domain?... I wonder if it is a permissions issue
on the "join domain" part. The user actually joining from the computer need to
have that right this can be done through GP. The right is given by default
with the msDsMachineAccountQuota. Every user, by default, can add 10 computers
to the domain if this has been turned off or the 10 limit has been reached you
need to give the rights our for individuals to 'Join Computers to
Domain'...
Kevin
From: Mayet,
Yusuf Y [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 12:01
PM
To:
'[EMAIL PROTECTED]'
Well seeing this
discussion has started I would like to throw a curve ball.
In my environment I
have chosen the route to train the junior lads into pre-creating the computer
account into the relative OU.
I have delegated the
following permission over "Computer Objects" to "Add and Remove computer
objects"
The problem I am
experiencing is that if the computer account already exists in the OU the
error received is "access Denied"
Thanks in
advance
Yusuf
From:
Sullivan, Kevin [mailto:[EMAIL PROTECTED]
Sent: 16 July, 2003 17:14 PM
To:
[EMAIL PROTECTED]
You don't need to
give them account operator rights. You give them 'specific' delegated rights.
There could be some complex solutions that involve automating the process of
looking through the computers container and moving computer account to the
appropriate container (that is if you know the appropriate container via a
name designation or something). This can be automated and scheduled but if you
are too understaffed I doubt you will be able to find the time to develop this
kind of solution. To have full functionality to address some of the
complexities of AD management easily you will probably want to evaluate third
part administrative tools. (<plug>Oh, yeah, my company has
one.</plug>)
Kevin
Sullivan
Aelita
Software
www.aelita.com
From: Chris
Flesher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 11:07
AM
To:
[EMAIL PROTECTED]
I saw that out on
Technet. That's great as long as there is a person/group to handle that. We
are understaffed and are looking for the OU admins to take care of this
without giving them Account Operator rights.
Chris Flesher
The University of
Chicago
NSIT/DCS
1-773-834-8477
-----Original
Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rakes, Brandon A. NMIMC
Contractor
Sent: Wednesday,
July 16, 2003 9:58 AM
To:
'[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Adding
machines to OU directly
The way we have
done it is to delegate administrative rights to the OU and then create the
computer account in that OU first and then add the computer. If there is
another way to automatically make it go in the desired OU I would love to
hear how.
Brandon
-----Original
Message-----
From: Chris
Flesher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 10:33
AM
To:
[EMAIL PROTECTED]
Subject: [ActiveDir] Adding machines to
OU directly
Is there a way to delegate to a
user the right to not only add machines to a domain, but place the user into
the OU of their choice? I'm looking for an easy way to allow OU
administrators to add machines and then instead of having the machine going
into the computers container, go directly into the OU. Maybe I'm making this
too complicated......
Chris Flesher
The University of
Chicago
NSIT/DCS
1-773-834-8477
__________________________________________________________________________________________________________________________________
For information about the Standard Bank group visit
our web site <www.standardbank.co.za>
__________________________________________________________________________________________________________________________________
Disclaimer
and confidentiality note
Everything in this e-mail and any attachments
relating to the official business of Standard Bank Group Limited is
proprietary to the group.
It is confidential, legally privileged and
protected by law.
Standard Bank does not own and endorse any other
content. Views and opinions are those of the sender unless clearly stated as
being that of the group.
The person addressed in the e-mail is the sole
authorised recipient. Please notify the sender immediately if it has
unintentionally reached you and do not read,
disclose or use the content
in any way.
Standard Bank can not assure that the integrity of this
communication has been maintained nor that it is free of errors, virus,
interception or interference.
___________________________________________________________________________________________________________________________________
For information about the Standard Bank group visit our web site <
www.standardbank.co.za>
__________________________________________________________________________________________________________________________________
Disclaimer
and confidentiality note
Everything in this e-mail and any attachments
relating to the official business of Standard Bank Group Limited is
proprietary to the group.
It is confidential, legally privileged and
protected by law.
Standard Bank does not own and endorse any other
content. Views and opinions are those of the sender unless clearly stated as
being that of the group.
The person addressed in the e-mail is the sole
authorised recipient. Please notify the sender immediately if it has
unintentionally reached you and do not read,
disclose or use the content
in any way.
Standard Bank can not assure that the integrity of this
communication has been maintained nor that it is free of errors, virus,
interception or interference.
___________________________________________________________________________________________________________________________________
