| Author | Messages | |
amulnick
Posts:163
 | | 03/13/2007 12:49 PM |
| Sure. It adds to the complexity and overhead, but it should work assuming you can work out the rights properly. My only thought on that is that it doesn't make a lot of sense to me to do it that way because you should be placing them in their appropriate OU structure vs. deploying a script that you maintain to the masses to correct the process. If you have that many changes, I'm not sure that this is the right level to fix the issue at is it? What am I missing in the bigger picture?
On 3/13/07, Harding, Devon wrote:
Hmm…you just gave me an idea. I'll simply create a vbscript 'Startup
Script' that will analyze the computer account and if it's not in the 'Servers'
OU, it will simply just move it. Will this work?
From:
ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On
Behalf Of Bart Van den Wyngaert
Sent: Tuesday, March 13, 2007 6:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Use the netdom utility from a VBScript? That's the way we do
it.
Yes naming conventions are changed, but the process needs to
keep in mind such things. So you put the correct people in the review process
of that naming convention.
We work same way for secure environments: they are moved at
the end of the process to a seperate OU with max. restrictions. During install
they end up in their default OU based on our environment parameters. These kind
of exceptions will always exist and I don't see a way to automate this, except
that your build tool is configured to handle these kind of parameters.
Best starting point is to see, even when you're doing the
moves manually, that your process and procedures are correct and that you have
a standard. This is an absolute needed basis to start with. Then you can start
thinking about automating the stuff. Example: a DB where the parameters are set
and retrieved by your scripts, a webinterface to view, edit, add, ... these
parameters. Or based on the OS and naming convention, but then you have to make
sure that you also have covered exceptions, either manually either by standard
(naming convention).
Our build tool is selfmade tool btw, but if you're a little
bit familiar with unattended installations, it isn't that hard... Depends on
environment ofcourse. Before that we used RAT (by INS), but we modified a bit
too much. Then the decission was taken to create the next version internally
instead of bying a tool and completely modify it... Nice but not in every
environment applicable. For another client I use a totally different way, no DB
or anything involved as they have only 5 pc's, so that totally overkill. But
that client can (re)install themselves a PC if I put a small .ini file in
place, so they are very happy with it. Larger environments may require a build
app with DB.
Look around and keep in mind your total process, they go
hand-in-hand !
Regards,
Bart
On 3/12/07, Al Mulnick wrote:
yeah, I've seen it done this way. But the danger that
comes with that in most orgs is pretty big. That's because the assumption
is that the naming convention is uniformly applied and retrofitted. Many
orgs change their naming standards too often. Since this thread is not
about those issues and what it leads to, I think I'll let that drop. :)
The bit that still gets me about this thread, is that the
poster asked to not use a command line tool but rather wanted a script.
Did I misread that? Netdom doesn't fit if that's the case and the usage
of netdom is something that wouldn't be any easier or harder than using a
process to pre-create the machines in the appropriate ou. More of a
sacred cow process from the sound of it. I could be wrong, but that's how
I interpret the use of netdom to place a machine in it's appropriate OU in many
situations. In some larger orgs (global, 50K desktops or better) it might make
more sense to let the workstation do it's own OU designation if you have multiple
workstation images. If not, then I doubt you'll get the benefit from one vs.
the other to make it worth the time.
My $0.04 anyway.
On 3/12/07, Eric C. Jones
wrote:
Adding my little bit too…
The way the gentleman does it below is an
excellent way to do it. In a previous life I wrote a VBScript to do just
that. I used a string function to move servers based on naming
convention. I initially ran it in a polling manner, running every 2
minutes. The script was very lightweight and just queried our
[redirected] default OU. It operated in 2 stages. It would move the
computer object based OS + naming convention. If the naming convention
wasn't followed or if we just had a new type for me to account for…it would
move the computer (server) object to a special OU where only general
configuration policies applied, but not our full security enforcement.
>From there I let others police what should happen to the servers in the "Rogue"
OU. I eventually modified the script to run only when new computer
objects were added to the redirected OU.
I personally prefer VBScript, as generalist,
however you could achieve the same with a combination of "ADFind" and
"DSmod".
Thanks,
-Eric
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Monday, March 12, 2007 2:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
What tool are you using to
automate this process. This is exactly what I'm looking for.
-Devon
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Monday, March 12, 2007 12:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Automating this requires simply the correct parameters. Don't know how you
guys build machines, but in most automated build processes you use parameters
(not?).
We for example have a default OU when we're building a server (which seems
logic to me). As last step of our building process, the script moves the object
in AD to the correct OU, depending on the parameter specified. This parameter
depends actually on the type of server (application, IIS, SQL, ...) and is
included in the naming convention. Result is that this parameter is automatically
derived...
So we have 2 steps:
- Join domain to default OU (netdom command)
- Move object in AD to final OU
As already indicated earlier, look at your process. The key is in there!
Best regards,
Bart
On 3/12/07, Harding, Devon
wrote:
See, I didn't want to have to
1. Create the Object in the correct OU ahead of time or 2. Use a command line
tool to add a computer to the domain. I also don't want to redirect the
Computers container to an OU as I have different OUs for different
computers. Are there any scripting options?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: Thursday, March 08, 2007 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Personally, I prefer this method. The reason for that is that it
causes the installer to think before adding to the domain. I have often
just delegated full rights to the OU to the installer for computer objects, so
the step about delegating themselves rights to join the machine wasn't
necessary. But the process works well and I've even gone so far as to
write a utility for the group to be able to add en masse (it's a migration
after all) via text file. It keeps the computer accounts where they belong.
Could you write a script to do this? Sure. But how do you know
what OU to move it to? If it's the same each time, then check out the
other posts that talk about redirecting the default container. If you have to
divide them into different OU's depending on some criteria, then you may want
to consider Aaron's method because it doesn't require any funny timing, or
scheduling or somebody to remember to run a script to move computer
objects. It happens, or the computer doesn't join the domain.
Simple. Secure. Fast.
Al
On 3/8/07, Aaron Steele wrote:
Devon,
This is not necessary. If you use
delegated join whereby you delegate rights on the target OU to the personnel in
charge of adding the machines to the domain to "Create" computer
objects within the OU. They create the objects, give themselves rights to join
it to the domain. Active Directory matches based on NetBIOS name when a
machine attempts to join, and you have a server, joined to the domain, with its
"Server Object" in the correct OU.
Hope that helps.
/aaron
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Thursday, March 08, 2007 4:25 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Auto move to OU
Is it possible to create a script or GPO that will auto move a server object
to a different OU after its been joined to a domain?
-Devon
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic communication.
Thank you.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you. | | | |
| ericcjones
Posts:0
| | 03/13/2007 12:50 PM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
You could do that… But also
consider this… More than just “if” it can be done one may
consider more of the overall methodology with regards to such automation. Limiting
policy processing to the essentials makes life simpler. Since what you want to
affect in this scenario is more so from the handling of an object within Active
Directory rather than from the perspective of resources local to the object
being manipulated (servers in this case) then centralizing such controls in
some script or tool outside of policy may be a better long-term approach.
Appling the same logic to other mass manipulations that you do in/to AD would
result in at least two distinct approaches to automation. For the mass manipulation
of computer or user objects and their respective attributes as observable from
within AD…do the centralized automation either from a script or tool.
For the controlled manipulation of resources local and/or specific to
computers/servers themselves…such as ensuring specific settings…or
kicking off specific actions synchronously (or asynchronously) then the
startup/shutdown…logon/logoff scripts may be the way to go. In both
cases, the mass manipulation could be handled centrally using Tivoli, SMS,
Unicenter…etc but $$$ aren’t always there.
(Heck..if you have one of the big
boy tools then you could *really* do some mass automation based on
inventory information w/o scripting…etc…but that’s a whole
OTHER thread!)
Thanks,
-Eric
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of Harding, Devon
Sent: Tuesday, March 13, 2007 12:12 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
Hmm…you just gave me an idea. I’ll simply
create a vbscript ‘Startup Script’ that will analyze the computer
account and if it’s not in the ‘Servers’ OU, it will simply
just move it. Will this work?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Bart Van den
Wyngaert
Sent: Tuesday, March 13, 2007 6:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Use the netdom utility from a VBScript? That's the way we do
it.
Yes naming conventions are changed, but the process needs to
keep in mind such things. So you put the correct people in the review process
of that naming convention.
We work same way for secure environments: they are moved at
the end of the process to a seperate OU with max. restrictions. During install
they end up in their default OU based on our environment parameters. These kind
of exceptions will always exist and I don't see a way to automate this, except
that your build tool is configured to handle these kind of parameters.
Best starting point is to see, even when you're doing the
moves manually, that your process and procedures are correct and that you have
a standard. This is an absolute needed basis to start with. Then you can start
thinking about automating the stuff. Example: a DB where the parameters are set
and retrieved by your scripts, a webinterface to view, edit, add, ... these
parameters. Or based on the OS and naming convention, but then you have to make
sure that you also have covered exceptions, either manually either by standard
(naming convention).
Our build tool is selfmade tool btw, but if you're a little
bit familiar with unattended installations, it isn't that hard... Depends on
environment ofcourse. Before that we used RAT (by INS), but we modified a bit
too much. Then the decission was taken to create the next version internally
instead of bying a tool and completely modify it... Nice but not in every
environment applicable. For another client I use a totally different way, no DB
or anything involved as they have only 5 pc's, so that totally overkill. But
that client can (re)install themselves a PC if I put a small .ini file in
place, so they are very happy with it. Larger environments may require a build
app with DB.
Look around and keep in mind your total process, they go
hand-in-hand !
Regards,
Bart
On 3/12/07, Al Mulnick wrote:
yeah, I've seen it done this way. But the danger that
comes with that in most orgs is pretty big. That's because the assumption
is that the naming convention is uniformly applied and retrofitted. Many
orgs change their naming standards too often. Since this thread is not
about those issues and what it leads to, I think I'll let that drop. :)
The bit that still gets me about this thread, is that the
poster asked to not use a command line tool but rather wanted a script.
Did I misread that? Netdom doesn't fit if that's the case and the usage
of netdom is something that wouldn't be any easier or harder than using a
process to pre-create the machines in the appropriate ou. More of a
sacred cow process from the sound of it. I could be wrong, but that's how
I interpret the use of netdom to place a machine in it's appropriate OU in many
situations. In some larger orgs (global, 50K desktops or better) it might make
more sense to let the workstation do it's own OU designation if you have
multiple workstation images. If not, then I doubt you'll get the benefit from
one vs. the other to make it worth the time.
My $0.04 anyway.
On 3/12/07, Eric C. Jones
wrote:
Adding my little bit too…
The way the gentleman does it below is an
excellent way to do it. In a previous life I wrote a VBScript to do just
that. I used a string function to move servers based on naming
convention. I initially ran it in a polling manner, running every 2
minutes. The script was very lightweight and just queried our
[redirected] default OU. It operated in 2 stages. It would move the
computer object based OS + naming convention. If the naming convention
wasn't followed or if we just had a new type for me to account for…it
would move the computer (server) object to a special OU where only general
configuration policies applied, but not our full security enforcement.
>From there I let others police what should happen to the servers in the
"Rogue" OU. I eventually modified the script to run only when
new computer objects were added to the redirected OU.
I personally prefer VBScript, as generalist,
however you could achieve the same with a combination of "ADFind" and
"DSmod".
Thanks,
-Eric
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Monday, March 12, 2007 2:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
What tool are you using to
automate this process. This is exactly what I'm looking for.
-Devon
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Monday, March 12, 2007 12:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Automating this requires simply the correct parameters. Don't know how you
guys build machines, but in most automated build processes you use parameters
(not?).
We for example have a default OU when we're building a server (which seems
logic to me). As last step of our building process, the script moves the object
in AD to the correct OU, depending on the parameter specified. This parameter
depends actually on the type of server (application, IIS, SQL, ...) and is
included in the naming convention. Result is that this parameter is
automatically derived...
So we have 2 steps:
- Join domain to default OU (netdom command)
- Move object in AD to final OU
As already indicated earlier, look at your process. The key is in there!
Best regards,
Bart
On 3/12/07, Harding, Devon
wrote:
See, I didn't want to have to
1. Create the Object in the correct OU ahead of time or 2. Use a command line
tool to add a computer to the domain. I also don't want to redirect the
Computers container to an OU as I have different OUs for different
computers. Are there any scripting options?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: Thursday, March 08, 2007 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Personally, I prefer this method. The reason for that is that it
causes the installer to think before adding to the domain. I have often
just delegated full rights to the OU to the installer for computer objects, so
the step about delegating themselves rights to join the machine wasn't
necessary. But the process works well and I've even gone so far as to
write a utility for the group to be able to add en masse (it's a migration
after all) via text file. It keeps the computer accounts where they belong.
Could you write a script to do this? Sure. But how do you know
what OU to move it to? If it's the same each time, then check out the
other posts that talk about redirecting the default container. If you have to
divide them into different OU's depending on some criteria, then you may want
to consider Aaron's method because it doesn't require any funny timing, or
scheduling or somebody to remember to run a script to move computer
objects. It happens, or the computer doesn't join the domain.
Simple. Secure. Fast.
Al
On 3/8/07, Aaron Steele wrote:
Devon,
This is not necessary. If you use delegated
join whereby you delegate rights on the target OU to the personnel in charge of
adding the machines to the domain to "Create" computer objects within
the OU. They create the objects, give themselves rights to join it to the
domain. Active Directory matches based on NetBIOS name when a machine
attempts to join, and you have a server, joined to the domain, with its
"Server Object" in the correct OU.
Hope that helps.
/aaron
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Thursday, March 08, 2007 4:25 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Auto move to OU
Is it possible to create a script or GPO that will auto move a server object
to a different OU after its been joined to a domain?
-Devon
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any
attachments) is intended only for the use of the individual or entity to which
it is addressed and may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under applicable law or may
constitute as attorney work product. If you are not the intended recipient, you
are hereby notified that any use, dissemination, distribution, or copying of
this communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and (i) destroy this
message if a facsimile or (ii) delete this message immediately if this is an
electronic communication.
Thank you. | | | |
| dharding
Posts:39
| | 03/13/2007 12:53 PM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
That’s exactly what I’m trying to accomplish.
What I want the script to do is first check to see if the server object is
already in the ‘Servers’ OU, if so, then quit, if not then move it
from the Computers container to the ‘Servers’ OU. Also, if
the computer account is NOT in the ‘Servers’ OU or the ‘Computers’
container, then quit.
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of neil.ruston@uk.nomura.com
Sent: Tuesday, March 13, 2007 12:17 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
FWIW: I've seen that done before, where a script ran at startup and
analysed the computer name.
Based upon the name, the script moved the computer object to the
correct OU.
neil
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Harding, Devon
Sent: 13 March 2007 16:12
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
Hmm…you just gave me an idea. I’ll simply
create a vbscript ‘Startup Script’ that will analyze the computer
account and if it’s not in the ‘Servers’ OU, it will simply
just move it. Will this work?
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of Bart Van den Wyngaert
Sent: Tuesday, March 13, 2007 6:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Use the netdom utility from a VBScript? That's the way we do
it.
Yes naming conventions are changed, but the process needs to
keep in mind such things. So you put the correct people in the review process
of that naming convention.
We work same way for secure environments: they are moved at
the end of the process to a seperate OU with max. restrictions. During install
they end up in their default OU based on our environment parameters. These kind
of exceptions will always exist and I don't see a way to automate this, except
that your build tool is configured to handle these kind of parameters.
Best starting point is to see, even when you're doing the moves
manually, that your process and procedures are correct and that you have a
standard. This is an absolute needed basis to start with. Then you can start
thinking about automating the stuff. Example: a DB where the parameters are set
and retrieved by your scripts, a webinterface to view, edit, add, ... these
parameters. Or based on the OS and naming convention, but then you have to make
sure that you also have covered exceptions, either manually either by standard
(naming convention).
Our build tool is selfmade tool btw, but if you're a little
bit familiar with unattended installations, it isn't that hard... Depends on
environment ofcourse. Before that we used RAT (by INS), but we modified a bit
too much. Then the decission was taken to create the next version internally
instead of bying a tool and completely modify it... Nice but not in every
environment applicable. For another client I use a totally different way, no DB
or anything involved as they have only 5 pc's, so that totally overkill. But
that client can (re)install themselves a PC if I put a small .ini file in
place, so they are very happy with it. Larger environments may require a build
app with DB.
Look around and keep in mind your total process, they go
hand-in-hand !
Regards,
Bart
On 3/12/07, Al Mulnick wrote:
yeah, I've seen it done this way. But the danger that
comes with that in most orgs is pretty big. That's because the assumption
is that the naming convention is uniformly applied and retrofitted. Many
orgs change their naming standards too often. Since this thread is not
about those issues and what it leads to, I think I'll let that drop. :)
The bit that still gets me about this thread, is that the
poster asked to not use a command line tool but rather wanted a script.
Did I misread that? Netdom doesn't fit if that's the case and the usage
of netdom is something that wouldn't be any easier or harder than using a process
to pre-create the machines in the appropriate ou. More of a sacred cow
process from the sound of it. I could be wrong, but that's how I
interpret the use of netdom to place a machine in it's appropriate OU in many
situations. In some larger orgs (global, 50K desktops or better) it might make
more sense to let the workstation do it's own OU designation if you have
multiple workstation images. If not, then I doubt you'll get the benefit from
one vs. the other to make it worth the time.
My $0.04 anyway.
On 3/12/07, Eric C. Jones
wrote:
Adding my little bit too…
The way the gentleman does it below is an
excellent way to do it. In a previous life I wrote a VBScript to do just
that. I used a string function to move servers based on naming
convention. I initially ran it in a polling manner, running every 2
minutes. The script was very lightweight and just queried our
[redirected] default OU. It operated in 2 stages. It would move the
computer object based OS + naming convention. If the naming convention
wasn't followed or if we just had a new type for me to account for…it
would move the computer (server) object to a special OU where only general
configuration policies applied, but not our full security enforcement.
>From there I let others police what should happen to the servers in the
"Rogue" OU. I eventually modified the script to run only when
new computer objects were added to the redirected OU.
I personally prefer VBScript, as generalist,
however you could achieve the same with a combination of "ADFind" and
"DSmod".
Thanks,
-Eric
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Monday, March 12, 2007 2:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
What tool are you using to
automate this process. This is exactly what I'm looking for.
-Devon
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Monday, March 12, 2007 12:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Automating this requires simply the correct parameters. Don't know how you
guys build machines, but in most automated build processes you use parameters
(not?).
We for example have a default OU when we're building a server (which seems
logic to me). As last step of our building process, the script moves the object
in AD to the correct OU, depending on the parameter specified. This parameter
depends actually on the type of server (application, IIS, SQL, ...) and is
included in the naming convention. Result is that this parameter is
automatically derived...
So we have 2 steps:
- Join domain to default OU (netdom command)
- Move object in AD to final OU
As already indicated earlier, look at your process. The key is in there!
Best regards,
Bart
On 3/12/07, Harding, Devon
wrote:
See, I didn't want to have to
1. Create the Object in the correct OU ahead of time or 2. Use a command line
tool to add a computer to the domain. I also don't want to redirect the
Computers container to an OU as I have different OUs for different
computers. Are there any scripting options?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: Thursday, March 08, 2007 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Personally, I prefer this method. The reason for that is that it
causes the installer to think before adding to the domain. I have often
just delegated full rights to the OU to the installer for computer objects, so
the step about delegating themselves rights to join the machine wasn't
necessary. But the process works well and I've even gone so far as to
write a utility for the group to be able to add en masse (it's a migration
after all) via text file. It keeps the computer accounts where they belong.
Could you write a script to do this? Sure. But how do you know
what OU to move it to? If it's the same each time, then check out the
other posts that talk about redirecting the default container. If you have to
divide them into different OU's depending on some criteria, then you may want
to consider Aaron's method because it doesn't require any funny timing, or
scheduling or somebody to remember to run a script to move computer
objects. It happens, or the computer doesn't join the domain.
Simple. Secure. Fast.
Al
On 3/8/07, Aaron Steele wrote:
Devon,
This is not necessary. If you use
delegated join whereby you delegate rights on the target OU to the personnel in
charge of adding the machines to the domain to "Create" computer
objects within the OU. They create the objects, give themselves rights to join
it to the domain. Active Directory matches based on NetBIOS name when a
machine attempts to join, and you have a server, joined to the domain, with its
"Server Object" in the correct OU.
Hope that helps.
/aaron
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Thursday, March 08, 2007 4:25 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Auto move to OU
Is it possible to create a script or GPO that will auto move a server object
to a different OU after its been joined to a domain?
-Devon
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any
attachments) is intended only for the use of the individual or entity to which
it is addressed and may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under applicable law or
may constitute as attorney work product. If you are not the intended recipient,
you are hereby notified that any use, dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and (i) destroy this
message if a facsimile or (ii) delete this message immediately if this is an
electronic communication.
Thank you.
PLEASE
READ: The information contained in this email is confidential and
intended
for the named recipient(s) only. If you are not an intended
recipient
of this email please notify the sender immediately and delete your
copy
from your system. You must not copy, distribute or take any further
action
in reliance on it. Email is not a secure method of communication and
Nomura
International plc ('NIplc') will not, to the extent permitted by law,
accept
responsibility or liability for (a) the accuracy or completeness of,
or
(b) the presence of any virus, worm or similar malicious or disabling
code
in, this message or any attachment(s) to it. If verification of this
email
is sought then please request a hard copy. Unless otherwise stated
this
email: (1) is not, and should not be treated or relied upon as,
investment
research; (2) contains views or opinions that are solely those of
the
author and do not necessarily represent those of NIplc; (3) is intended
for
informational purposes only and is not a recommendation, solicitation or
offer
to buy or sell securities or related financial instruments. NIplc
does
not provide investment services to private customers. Authorised and
regulated
by the Financial Services Authority. Registered in England
no.
1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London,
EC1A 4NP. A member of the Nomura group of companies.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you. | | | |
| amulnick
Posts:163
| | 03/14/2007 1:06 AM |
| Note: I completely disagree with the concept of trying to deploy and manage that kind of application architecture. There's no reason to try and deploy this to the user level and have them be responsible for it IMHO. If you're intent on going down that path, read on. Otherwise, feel free to delete the message now.
You use something like these tools: http://www.joeware.net/win/free/tools/cpau.htmhttp://www.robotronic.de/runasspcEn.html
You *could* use a local runas but if it's script that's not a good idea. You could also write a compiled app that uses other functions depending on the language you choose.
On 3/14/07, Harding, Devon wrote:
How would I elevate the script to run?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Tuesday, March 13, 2007 6:42 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
You would need to elevate the script to run in a context that can
make these changes, or you'd need to mdoify the ACL on every computer account
to grant SELF the rights to do the move which would be fairly easy to exploit
and delete computer accounts one by one.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From:
ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Harding, Devon
[dharding@SOUTHERNWINE.com]
Sent: Tuesday, March 13, 2007 12:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
Hmm…you just gave me an idea. I'll simply create a
vbscript 'Startup Script' that will analyze the computer account and if it's
not in the 'Servers' OU, it will simply just move it. Will this work?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Bart Van den
Wyngaert
Sent: Tuesday, March 13, 2007 6:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Use the netdom utility from a VBScript? That's the way we do
it.
Yes naming conventions are changed, but the process needs to
keep in mind such things. So you put the correct people in the review process
of that naming convention.
We work same way for secure environments: they are moved at
the end of the process to a seperate OU with max. restrictions. During install
they end up in their default OU based on our environment parameters. These kind
of exceptions will always exist and I don't see a way to automate this, except
that your build tool is configured to handle these kind of parameters.
Best starting point is to see, even when you're doing the
moves manually, that your process and procedures are correct and that you have
a standard. This is an absolute needed basis to start with. Then you can start
thinking about automating the stuff. Example: a DB where the parameters are set
and retrieved by your scripts, a webinterface to view, edit, add, ... these
parameters. Or based on the OS and naming convention, but then you have to make
sure that you also have covered exceptions, either manually either by standard
(naming convention).
Our build tool is selfmade tool btw, but if you're a little
bit familiar with unattended installations, it isn't that hard... Depends on
environment ofcourse. Before that we used RAT (by INS), but we modified a bit
too much. Then the decission was taken to create the next version internally
instead of bying a tool and completely modify it... Nice but not in every
environment applicable. For another client I use a totally different way, no DB
or anything involved as they have only 5 pc's, so that totally overkill. But
that client can (re)install themselves a PC if I put a small .ini file in
place, so they are very happy with it. Larger environments may require a build
app with DB.
Look around and keep in mind your total process, they go
hand-in-hand !
Regards,
Bart
On 3/12/07, Al Mulnick wrote:
yeah, I've seen it done this way. But the danger that
comes with that in most orgs is pretty big. That's because the assumption
is that the naming convention is uniformly applied and retrofitted. Many
orgs change their naming standards too often. Since this thread is not
about those issues and what it leads to, I think I'll let that drop. :)
The bit that still gets me about this thread, is that the
poster asked to not use a command line tool but rather wanted a script.
Did I misread that? Netdom doesn't fit if that's the case and the usage
of netdom is something that wouldn't be any easier or harder than using a
process to pre-create the machines in the appropriate ou. More of a
sacred cow process from the sound of it. I could be wrong, but that's how
I interpret the use of netdom to place a machine in it's appropriate OU in many
situations. In some larger orgs (global, 50K desktops or better) it might make
more sense to let the workstation do it's own OU designation if you have
multiple workstation images. If not, then I doubt you'll get the benefit from
one vs. the other to make it worth the time.
My $0.04 anyway.
On 3/12/07, Eric C. Jones wrote:
Adding my little bit too…
The way the gentleman does it below is an
excellent way to do it. In a previous life I wrote a VBScript to do just
that. I used a string function to move servers based on naming
convention. I initially ran it in a polling manner, running every 2
minutes. The script was very lightweight and just queried our
[redirected] default OU. It operated in 2 stages. It would move the
computer object based OS + naming convention. If the naming convention
wasn't followed or if we just had a new type for me to account for…it would
move the computer (server) object to a special OU where only general
configuration policies applied, but not our full security enforcement.
>From there I let others police what should happen to the servers in the "Rogue"
OU. I eventually modified the script to run only when new computer
objects were added to the redirected OU.
I personally prefer VBScript, as generalist,
however you could achieve the same with a combination of "ADFind" and
"DSmod".
Thanks,
-Eric
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Monday, March 12, 2007 2:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
What tool are you using to
automate this process. This is exactly what I'm looking for.
-Devon
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Monday, March 12, 2007 12:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Automating this requires simply the correct parameters. Don't know how you
guys build machines, but in most automated build processes you use parameters
(not?).
We for example have a default OU when we're building a server (which seems
logic to me). As last step of our building process, the script moves the object
in AD to the correct OU, depending on the parameter specified. This parameter
depends actually on the type of server (application, IIS, SQL, ...) and is
included in the naming convention. Result is that this parameter is
automatically derived...
So we have 2 steps:
- Join domain to default OU (netdom command)
- Move object in AD to final OU
As already indicated earlier, look at your process. The key is in there!
Best regards,
Bart
On 3/12/07, Harding, Devon
wrote:
See, I didn't want to have to
1. Create the Object in the correct OU ahead of time or 2. Use a command line
tool to add a computer to the domain. I also don't want to redirect the
Computers container to an OU as I have different OUs for different
computers. Are there any scripting options?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: Thursday, March 08, 2007 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Personally, I prefer this method. The reason for that is that it
causes the installer to think before adding to the domain. I have often
just delegated full rights to the OU to the installer for computer objects, so
the step about delegating themselves rights to join the machine wasn't necessary.
But the process works well and I've even gone so far as to write a utility for
the group to be able to add en masse (it's a migration after all) via text
file. It keeps the computer accounts where they belong.
Could you write a script to do this? Sure. But how do you know
what OU to move it to? If it's the same each time, then check out the
other posts that talk about redirecting the default container. If you have to
divide them into different OU's depending on some criteria, then you may want
to consider Aaron's method because it doesn't require any funny timing, or
scheduling or somebody to remember to run a script to move computer
objects. It happens, or the computer doesn't join the domain.
Simple. Secure. Fast.
Al
On 3/8/07, Aaron Steele
wrote:
Devon,
This is not necessary. If you use
delegated join whereby you delegate rights on the target OU to the personnel in
charge of adding the machines to the domain to "Create" computer
objects within the OU. They create the objects, give themselves rights to join
it to the domain. Active Directory matches based on NetBIOS name when a
machine attempts to join, and you have a server, joined to the domain, with its
"Server Object" in the correct OU.
Hope that helps.
/aaron
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Thursday, March 08, 2007 4:25 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Auto move to OU
Is it possible to create a script or GPO that will auto move a server object
to a different OU after its been joined to a domain?
-Devon
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any
attachments) is intended only for the use of the individual or entity to which
it is addressed and may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under applicable law or
may constitute as attorney work product. If you are not the intended recipient,
you are hereby notified that any use, dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and (i) destroy this
message if a facsimile or (ii) delete this message immediately if this is an
electronic communication.
Thank you.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you. | | | |
| dharding
Posts:39
| | 03/14/2007 1:24 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Maybe, you’re right. I’ll put this in a logon script so only
domain admins can do this.
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On
Behalf Of Al Mulnick
Sent: Wednesday, March 14, 2007 1:06 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Note: I completely disagree
with the concept of trying to deploy and manage that kind of application
architecture. There's no reason to try and deploy this to the user level
and have them be responsible for it IMHO. If you're intent on going down
that path, read on. Otherwise, feel free to delete the message now.
You use something like these tools:
http://www.joeware.net/win/free/tools/cpau.htm
http://www.robotronic.de/runasspcEn.html
You *could* use a local runas but if it's script that's not a good idea.
You could also write a compiled app that uses other functions depending on the
language you choose.
On 3/14/07, Harding, Devon
wrote:
How would I elevate the script
to run?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Brian Desmond
Sent: Tuesday, March 13, 2007 6:42 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
You would need to elevate the
script to run in a context that can make these changes, or you'd need to mdoify
the ACL on every computer account to grant SELF the rights to do the move which
would be fairly easy to exploit and delete computer accounts one by one.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon [dharding@SOUTHERNWINE.com]
Sent: Tuesday, March 13, 2007 12:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
Hmm…you just gave me an
idea. I'll simply create a vbscript 'Startup Script' that will analyze
the computer account and if it's not in the 'Servers' OU, it will simply just
move it. Will this work?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Tuesday, March 13, 2007 6:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Use the netdom utility from a VBScript? That's the way we do it.
Yes naming conventions are changed, but the process needs to keep in mind
such things. So you put the correct people in the review process of that naming
convention.
We work same way for secure environments: they are moved at the end of the
process to a seperate OU with max. restrictions. During install they end up in
their default OU based on our environment parameters. These kind of exceptions
will always exist and I don't see a way to automate this, except that your
build tool is configured to handle these kind of parameters.
Best starting point is to see, even when you're doing the moves manually,
that your process and procedures are correct and that you have a standard. This
is an absolute needed basis to start with. Then you can start thinking about
automating the stuff. Example: a DB where the parameters are set and retrieved
by your scripts, a webinterface to view, edit, add, ... these parameters. Or
based on the OS and naming convention, but then you have to make sure that you
also have covered exceptions, either manually either by standard (naming
convention).
Our build tool is selfmade tool btw, but if you're a little bit familiar
with unattended installations, it isn't that hard... Depends on environment
ofcourse. Before that we used RAT (by INS), but we modified a bit too much.
Then the decission was taken to create the next version internally instead of
bying a tool and completely modify it... Nice but not in every environment
applicable. For another client I use a totally different way, no DB or anything
involved as they have only 5 pc's, so that totally overkill. But that client
can (re)install themselves a PC if I put a small .ini file in place, so they
are very happy with it. Larger environments may require a build app with DB.
Look around and keep in mind your total process, they go hand-in-hand !
Regards,
Bart
On 3/12/07, Al Mulnick wrote:
yeah, I've seen it done this way. But the danger that comes with that
in most orgs is pretty big. That's because the assumption is that the
naming convention is uniformly applied and retrofitted. Many orgs change
their naming standards too often. Since this thread is not about those
issues and what it leads to, I think I'll let that drop. :)
The bit that still gets me about this thread, is that the poster asked to
not use a command line tool but rather wanted a script. Did I misread
that? Netdom doesn't fit if that's the case and the usage of netdom is
something that wouldn't be any easier or harder than using a process to
pre-create the machines in the appropriate ou. More of a sacred cow
process from the sound of it. I could be wrong, but that's how I
interpret the use of netdom to place a machine in it's appropriate OU in many
situations. In some larger orgs (global, 50K desktops or better) it might make
more sense to let the workstation do it's own OU designation if you have
multiple workstation images. If not, then I doubt you'll get the benefit from
one vs. the other to make it worth the time.
My $0.04 anyway.
On 3/12/07, Eric C. Jones wrote:
Adding my little bit too…
The way the gentleman does it below is an
excellent way to do it. In a previous life I wrote a VBScript to do just
that. I used a string function to move servers based on naming
convention. I initially ran it in a polling manner, running every 2
minutes. The script was very lightweight and just queried our
[redirected] default OU. It operated in 2 stages. It would move the
computer object based OS + naming convention. If the naming convention
wasn't followed or if we just had a new type for me to account for…it would
move the computer (server) object to a special OU where only general
configuration policies applied, but not our full security enforcement.
>From there I let others police what should happen to the servers in the
"Rogue" OU. I eventually modified the script to run only when
new computer objects were added to the redirected OU.
I personally prefer VBScript, as generalist,
however you could achieve the same with a combination of "ADFind" and
"DSmod".
Thanks,
-Eric
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Monday, March 12, 2007 2:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
What tool are you using to
automate this process. This is exactly what I'm looking for.
-Devon
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Monday, March 12, 2007 12:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Automating this requires simply the correct parameters. Don't know how you
guys build machines, but in most automated build processes you use parameters
(not?).
We for example have a default OU when we're building a server (which seems
logic to me). As last step of our building process, the script moves the object
in AD to the correct OU, depending on the parameter specified. This parameter
depends actually on the type of server (application, IIS, SQL, ...) and is
included in the naming convention. Result is that this parameter is
automatically derived...
So we have 2 steps:
- Join domain to default OU (netdom command)
- Move object in AD to final OU
As already indicated earlier, look at your process. The key is in there!
Best regards,
Bart
On 3/12/07, Harding, Devon
wrote:
See, I didn't want to have to
1. Create the Object in the correct OU ahead of time or 2. Use a command line
tool to add a computer to the domain. I also don't want to redirect the
Computers container to an OU as I have different OUs for different
computers. Are there any scripting options?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: Thursday, March 08, 2007 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Personally, I prefer this method. The reason for that is that it
causes the installer to think before adding to the domain. I have often
just delegated full rights to the OU to the installer for computer objects, so
the step about delegating themselves rights to join the machine wasn't
necessary. But the process works well and I've even gone so far as to
write a utility for the group to be able to add en masse (it's a migration
after all) via text file. It keeps the computer accounts where they belong.
Could you write a script to do this? Sure. But how do you know
what OU to move it to? If it's the same each time, then check out the
other posts that talk about redirecting the default container. If you have to
divide them into different OU's depending on some criteria, then you may want
to consider Aaron's method because it doesn't require any funny timing, or
scheduling or somebody to remember to run a script to move computer
objects. It happens, or the computer doesn't join the domain.
Simple. Secure. Fast.
Al
On 3/8/07, Aaron Steele wrote:
Devon,
This is not necessary. If you use
delegated join whereby you delegate rights on the target OU to the personnel in
charge of adding the machines to the domain to "Create" computer
objects within the OU. They create the objects, give themselves rights to join
it to the domain. Active Directory matches based on NetBIOS name when a
machine attempts to join, and you have a server, joined to the domain, with its
"Server Object" in the correct OU.
Hope that helps.
/aaron
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Thursday, March 08, 2007 4:25 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Auto move to OU
Is it possible to create a script or GPO that will auto move a server object
to a different OU after its been joined to a domain?
-Devon
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message
(including any attachments) is intended only for the use of the individual or
entity to which it is addressed and may contain information that is non-public,
proprietary, privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product. If you are not the
intended recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If you
have received this communication in error, notify us immediately by telephone
and (i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you. | | | |
| amulnick
Posts:163
| | 03/14/2007 1:36 AM |
| Logon scripts run under the context of the user that executes it. On 3/14/07, Harding, Devon > wrote:
Maybe, you're right. I'll put this in a logon script so only
domain admins can do this.
From:
ActiveDir-owner@mail.activedir.org [mailto:
ActiveDir-owner@mail.activedir.org] On
Behalf Of Al Mulnick
Sent: Wednesday, March 14, 2007 1:06 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Note: I completely disagree
with the concept of trying to deploy and manage that kind of application
architecture. There's no reason to try and deploy this to the user level
and have them be responsible for it IMHO. If you're intent on going down
that path, read on. Otherwise, feel free to delete the message now.
You use something like these tools:
http://www.joeware.net/win/free/tools/cpau.htm
http://www.robotronic.de/runasspcEn.html
You *could* use a local runas but if it's script that's not a good idea.
You could also write a compiled app that uses other functions depending on the
language you choose.
On 3/14/07, Harding, Devon
wrote:
How would I elevate the script
to run?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Brian Desmond
Sent: Tuesday, March 13, 2007 6:42 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
You would need to elevate the
script to run in a context that can make these changes, or you'd need to mdoify
the ACL on every computer account to grant SELF the rights to do the move which
would be fairly easy to exploit and delete computer accounts one by one.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From:
ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon [dharding@SOUTHERNWINE.com]
Sent: Tuesday, March 13, 2007 12:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
Hmm…you just gave me an
idea. I'll simply create a vbscript 'Startup Script' that will analyze
the computer account and if it's not in the 'Servers' OU, it will simply just
move it. Will this work?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Tuesday, March 13, 2007 6:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Use the netdom utility from a VBScript? That's the way we do it.
Yes naming conventions are changed, but the process needs to keep in mind
such things. So you put the correct people in the review process of that naming
convention.
We work same way for secure environments: they are moved at the end of the
process to a seperate OU with max. restrictions. During install they end up in
their default OU based on our environment parameters. These kind of exceptions
will always exist and I don't see a way to automate this, except that your
build tool is configured to handle these kind of parameters.
Best starting point is to see, even when you're doing the moves manually,
that your process and procedures are correct and that you have a standard. This
is an absolute needed basis to start with. Then you can start thinking about
automating the stuff. Example: a DB where the parameters are set and retrieved
by your scripts, a webinterface to view, edit, add, ... these parameters. Or
based on the OS and naming convention, but then you have to make sure that you
also have covered exceptions, either manually either by standard (naming
convention).
Our build tool is selfmade tool btw, but if you're a little bit familiar
with unattended installations, it isn't that hard... Depends on environment
ofcourse. Before that we used RAT (by INS), but we modified a bit too much.
Then the decission was taken to create the next version internally instead of
bying a tool and completely modify it... Nice but not in every environment
applicable. For another client I use a totally different way, no DB or anything
involved as they have only 5 pc's, so that totally overkill. But that client
can (re)install themselves a PC if I put a small .ini file in place, so they
are very happy with it. Larger environments may require a build app with DB.
Look around and keep in mind your total process, they go hand-in-hand !
Regards,
Bart
On 3/12/07, Al Mulnick wrote:
yeah, I've seen it done this way. But the danger that comes with that
in most orgs is pretty big. That's because the assumption is that the
naming convention is uniformly applied and retrofitted. Many orgs change
their naming standards too often. Since this thread is not about those
issues and what it leads to, I think I'll let that drop. :)
The bit that still gets me about this thread, is that the poster asked to
not use a command line tool but rather wanted a script. Did I misread
that? Netdom doesn't fit if that's the case and the usage of netdom is
something that wouldn't be any easier or harder than using a process to
pre-create the machines in the appropriate ou. More of a sacred cow
process from the sound of it. I could be wrong, but that's how I
interpret the use of netdom to place a machine in it's appropriate OU in many
situations. In some larger orgs (global, 50K desktops or better) it might make
more sense to let the workstation do it's own OU designation if you have
multiple workstation images. If not, then I doubt you'll get the benefit from
one vs. the other to make it worth the time.
My $0.04 anyway.
On 3/12/07, Eric C. Jones wrote:
Adding my little bit too…
The way the gentleman does it below is an
excellent way to do it. In a previous life I wrote a VBScript to do just
that. I used a string function to move servers based on naming
convention. I initially ran it in a polling manner, running every 2
minutes. The script was very lightweight and just queried our
[redirected] default OU. It operated in 2 stages. It would move the
computer object based OS + naming convention. If the naming convention
wasn't followed or if we just had a new type for me to account for…it would
move the computer (server) object to a special OU where only general
configuration policies applied, but not our full security enforcement.
>From there I let others police what should happen to the servers in the
"Rogue" OU. I eventually modified the script to run only when
new computer objects were added to the redirected OU.
I personally prefer VBScript, as generalist,
however you could achieve the same with a combination of "ADFind" and
"DSmod".
Thanks,
-Eric
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Monday, March 12, 2007 2:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
What tool are you using to
automate this process. This is exactly what I'm looking for.
-Devon
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Monday, March 12, 2007 12:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Automating this requires simply the correct parameters. Don't know how you
guys build machines, but in most automated build processes you use parameters
(not?).
We for example have a default OU when we're building a server (which seems
logic to me). As last step of our building process, the script moves the object
in AD to the correct OU, depending on the parameter specified. This parameter
depends actually on the type of server (application, IIS, SQL, ...) and is
included in the naming convention. Result is that this parameter is
automatically derived...
So we have 2 steps:
- Join domain to default OU (netdom command)
- Move object in AD to final OU
As already indicated earlier, look at your process. The key is in there!
Best regards,
Bart
On 3/12/07, Harding, Devon
wrote:
See, I didn't want to have to
1. Create the Object in the correct OU ahead of time or 2. Use a command line
tool to add a computer to the domain. I also don't want to redirect the
Computers container to an OU as I have different OUs for different
computers. Are there any scripting options?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: Thursday, March 08, 2007 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Personally, I prefer this method. The reason for that is that it
causes the installer to think before adding to the domain. I have often
just delegated full rights to the OU to the installer for computer objects, so
the step about delegating themselves rights to join the machine wasn't
necessary. But the process works well and I've even gone so far as to
write a utility for the group to be able to add en masse (it's a migration
after all) via text file. It keeps the computer accounts where they belong.
Could you write a script to do this? Sure. But how do you know
what OU to move it to? If it's the same each time, then check out the
other posts that talk about redirecting the default container. If you have to
divide them into different OU's depending on some criteria, then you may want
to consider Aaron's method because it doesn't require any funny timing, or
scheduling or somebody to remember to run a script to move computer
objects. It happens, or the computer doesn't join the domain.
Simple. Secure. Fast.
Al
On 3/8/07, Aaron Steele wrote:
Devon,
This is not necessary. If you use
delegated join whereby you delegate rights on the target OU to the personnel in
charge of adding the machines to the domain to "Create" computer
objects within the OU. They create the objects, give themselves rights to join
it to the domain. Active Directory matches based on NetBIOS name when a
machine attempts to join, and you have a server, joined to the domain, with its
"Server Object" in the correct OU.
Hope that helps.
/aaron
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Thursday, March 08, 2007 4:25 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Auto move to OU
Is it possible to create a script or GPO that will auto move a server object
to a different OU after its been joined to a domain?
-Devon
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message
(including any attachments) is intended only for the use of the individual or
entity to which it is addressed and may contain information that is non-public,
proprietary, privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product. If you are not the
intended recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If you
have received this communication in error, notify us immediately by telephone
and (i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you. | | | |
| dharding
Posts:39
| | 03/14/2007 11:41 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
How would I elevate the script to run?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Tuesday, March 13, 2007 6:42 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
You would need to elevate the script to run in a context that can
make these changes, or you'd need to mdoify the ACL on every computer account
to grant SELF the rights to do the move which would be fairly easy to exploit
and delete computer accounts one by one.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Harding, Devon
[dharding@SOUTHERNWINE.com]
Sent: Tuesday, March 13, 2007 12:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
Hmm…you just gave me an idea. I’ll simply create a
vbscript ‘Startup Script’ that will analyze the computer account and if it’s
not in the ‘Servers’ OU, it will simply just move it. Will this work?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Bart Van den
Wyngaert
Sent: Tuesday, March 13, 2007 6:08 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Use the netdom utility from a VBScript? That's the way we do
it.
Yes naming conventions are changed, but the process needs to
keep in mind such things. So you put the correct people in the review process
of that naming convention.
We work same way for secure environments: they are moved at
the end of the process to a seperate OU with max. restrictions. During install
they end up in their default OU based on our environment parameters. These kind
of exceptions will always exist and I don't see a way to automate this, except
that your build tool is configured to handle these kind of parameters.
Best starting point is to see, even when you're doing the
moves manually, that your process and procedures are correct and that you have
a standard. This is an absolute needed basis to start with. Then you can start
thinking about automating the stuff. Example: a DB where the parameters are set
and retrieved by your scripts, a webinterface to view, edit, add, ... these
parameters. Or based on the OS and naming convention, but then you have to make
sure that you also have covered exceptions, either manually either by standard
(naming convention).
Our build tool is selfmade tool btw, but if you're a little
bit familiar with unattended installations, it isn't that hard... Depends on
environment ofcourse. Before that we used RAT (by INS), but we modified a bit
too much. Then the decission was taken to create the next version internally
instead of bying a tool and completely modify it... Nice but not in every
environment applicable. For another client I use a totally different way, no DB
or anything involved as they have only 5 pc's, so that totally overkill. But
that client can (re)install themselves a PC if I put a small .ini file in
place, so they are very happy with it. Larger environments may require a build
app with DB.
Look around and keep in mind your total process, they go
hand-in-hand !
Regards,
Bart
On 3/12/07, Al Mulnick wrote:
yeah, I've seen it done this way. But the danger that
comes with that in most orgs is pretty big. That's because the assumption
is that the naming convention is uniformly applied and retrofitted. Many
orgs change their naming standards too often. Since this thread is not
about those issues and what it leads to, I think I'll let that drop. :)
The bit that still gets me about this thread, is that the
poster asked to not use a command line tool but rather wanted a script.
Did I misread that? Netdom doesn't fit if that's the case and the usage
of netdom is something that wouldn't be any easier or harder than using a
process to pre-create the machines in the appropriate ou. More of a
sacred cow process from the sound of it. I could be wrong, but that's how
I interpret the use of netdom to place a machine in it's appropriate OU in many
situations. In some larger orgs (global, 50K desktops or better) it might make
more sense to let the workstation do it's own OU designation if you have
multiple workstation images. If not, then I doubt you'll get the benefit from
one vs. the other to make it worth the time.
My $0.04 anyway.
On 3/12/07, Eric C. Jones wrote:
Adding my little bit too…
The way the gentleman does it below is an
excellent way to do it. In a previous life I wrote a VBScript to do just
that. I used a string function to move servers based on naming
convention. I initially ran it in a polling manner, running every 2
minutes. The script was very lightweight and just queried our
[redirected] default OU. It operated in 2 stages. It would move the
computer object based OS + naming convention. If the naming convention
wasn't followed or if we just had a new type for me to account for…it would
move the computer (server) object to a special OU where only general
configuration policies applied, but not our full security enforcement.
>From there I let others police what should happen to the servers in the "Rogue"
OU. I eventually modified the script to run only when new computer
objects were added to the redirected OU.
I personally prefer VBScript, as generalist,
however you could achieve the same with a combination of "ADFind" and
"DSmod".
Thanks,
-Eric
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Monday, March 12, 2007 2:10 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Auto move to OU
What tool are you using to
automate this process. This is exactly what I'm looking for.
-Devon
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Bart Van den Wyngaert
Sent: Monday, March 12, 2007 12:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Automating this requires simply the correct parameters. Don't know how you
guys build machines, but in most automated build processes you use parameters
(not?).
We for example have a default OU when we're building a server (which seems
logic to me). As last step of our building process, the script moves the object
in AD to the correct OU, depending on the parameter specified. This parameter
depends actually on the type of server (application, IIS, SQL, ...) and is
included in the naming convention. Result is that this parameter is
automatically derived...
So we have 2 steps:
- Join domain to default OU (netdom command)
- Move object in AD to final OU
As already indicated earlier, look at your process. The key is in there!
Best regards,
Bart
On 3/12/07, Harding, Devon
wrote:
See, I didn't want to have to
1. Create the Object in the correct OU ahead of time or 2. Use a command line
tool to add a computer to the domain. I also don't want to redirect the
Computers container to an OU as I have different OUs for different
computers. Are there any scripting options?
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Al Mulnick
Sent: Thursday, March 08, 2007 7:37 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Auto move to OU
Personally, I prefer this method. The reason for that is that it
causes the installer to think before adding to the domain. I have often
just delegated full rights to the OU to the installer for computer objects, so
the step about delegating themselves rights to join the machine wasn't necessary.
But the process works well and I've even gone so far as to write a utility for
the group to be able to add en masse (it's a migration after all) via text
file. It keeps the computer accounts where they belong.
Could you write a script to do this? Sure. But how do you know
what OU to move it to? If it's the same each time, then check out the
other posts that talk about redirecting the default container. If you have to
divide them into different OU's depending on some criteria, then you may want
to consider Aaron's method because it doesn't require any funny timing, or
scheduling or somebody to remember to run a script to move computer
objects. It happens, or the computer doesn't join the domain.
Simple. Secure. Fast.
Al
On 3/8/07, Aaron Steele
wrote:
Devon,
This is not necessary. If you use
delegated join whereby you delegate rights on the target OU to the personnel in
charge of adding the machines to the domain to "Create" computer
objects within the OU. They create the objects, give themselves rights to join
it to the domain. Active Directory matches based on NetBIOS name when a
machine attempts to join, and you have a server, joined to the domain, with its
"Server Object" in the correct OU.
Hope that helps.
/aaron
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]
On Behalf Of Harding, Devon
Sent: Thursday, March 08, 2007 4:25 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Auto move to OU
Is it possible to create a script or GPO that will auto move a server object
to a different OU after its been joined to a domain?
-Devon
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any attachments) is
intended only for the use of the individual or entity to which it is addressed
and may contain information that is non-public, proprietary, privileged,
confidential, and exempt from disclosure under applicable law or may constitute
as attorney work product. If you are not the intended recipient, you are hereby
notified that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, notify us immediately by telephone and (i) destroy this message if a
facsimile or (ii) delete this message immediately if this is an electronic
communication.
Thank you.
This message (including any
attachments) is intended only for the use of the individual or entity to which
it is addressed and may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under applicable law or
may constitute as attorney work product. If you are not the intended recipient,
you are hereby notified that any use, dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and (i) destroy this
message if a facsimile or (ii) delete this message immediately if this is an
electronic communication.
Thank you.
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you. | | | |
|
|