Nesting OUs

[Tom Penharston]

I'm running Server 2003 Standard in mixed mode. I know that I can nest
OUs, Is there any reason why I shouldn't create an OU for each
individual computer?

 

[Al Mulnick]

Why limit the answer to just one reason?

OU's are for management purposes as in easing management by allowing you to
group like items, similarly managed items, or some other delineation that
makes sense to you. The key there is 'group.' There is overhead associated
with creating and putting items in OUs and there is no reason to think that
creating a separate OU for each computer would a) ease the management burden
on the administrator or b) be worth the overhead incurred.

OU's are a LDAP concept. You can ask the same question of any LDAP
directory and the same answer applies.

What makes you ask?

 

[Tom Penharston]

Here's a good example; I can set a group policy to deploy an MSI
package to an OU of several computers. In this case it's a site
licensed app and all of the computers get the same serial number via an
ini file.

However, if I have an application that is only licensed per machine,
with unique serial numbers, then I'd want to build a unique MSI for
each computer that provides the individualized serials. Of course it
takes time to build each individual MSI, but at least I'm doing that
work 'off-line'. When I'm actually in the room with the clients I'm
taking up very little time to verify that my policy is taking effect on
restart.

 

[Jaap de Koning]

I must say creating individual OU's for every computer kind of misses
the points. You could try working with a WMI filter to deliver specific
MSI files to specific computers.

 

[Guest]

If you are that desperate to do it this way don't create an individual ou per
machine but create multiple gpo's and only assign apply policy to the
machines you want the gpo to apply to.

This sounds like a really nightmare to maintain but it is your network and
your nightmare.

http://support.microsoft.com/?kbid=322176

 

[Jason Meyer]

If you are that desperate to do it this way don't create an individual ou per
machine but create multiple gpo's and only assign apply policy to the
machines you want the gpo to apply to.

This sounds like a really nightmare to maintain but it is your network and
your nightmare.

http://support.microsoft.com/?kbid=322176

Consider using many GPOs, then give the individual computer read access
and remove everyone/read access. This might be easier to do, plus then
if you want to add more computers, just give them rights to the GPO.

 

[Tom Penharston]

Thanks. Now that I've looked into filters, I'm still wondering.

2. Individual OUs are still a valid possiblity for me. I could script
the creation of OUs. Using individual OUs, the nestings are always
visable in AD Users and Computers.

1. WMI Filters take me longer to create than a bunch of OUs. (Can I
script the creation of WMI Filters?) In Active Directory Users and
Computers the syntax of each filter is somewhat burried in that tiny
dialog box making them less visable.

 

[Tom Penharston]

If I do decide to use WMI Filters, can I script the creation of WMI
Filters?

 

[Guest]

There has been some discussions in here in the past on this and the best way
to perform this was to allow read but not apply. From experiences defined
the users would hang attempting to read gpo's that they didn't have read
access to. Having read and not apply they are able to just move on.

 

[Jason Meyer]

There has been some discussions in here in the past on this and the best way
to perform this was to allow read but not apply. From experiences defined
the users would hang attempting to read gpo's that they didn't have read
access to. Having read and not apply they are able to just move on.

i knew i forgot something, yeah need to be able to apply also.

 

[Al Mulnick]

http://msdn.microsoft.com/library/d.../policy/group_policy_reference.asp?frame=true

Reading this thread, I'm not sure that's the type of usage that OU's were
intended to fill nor what "group" policy is intended for (individual
workstations are just that: individual. Group Policy is intended for groups
of like managed objects). I think you're trying to do something unnatural
and unwieldy.
The management of such a configuration is not going to scale and would
contain more moving parts than I would prefer when it comes to making
reliable systems. I see what you're talking about, and my instinct tells me
that you need a better way to deploy software for these machines than group
policy. Or better licensing for those apps.

Whichever solution you end up using, good luck with it. Hopefully I'm wrong
about the administration of the solution you're looking at.

Al

 

[Tom Penharston]

Thanks to Mulnick and Meyer for the responses above. Without getting
into the details, we'll say the vendors offer no alternative to
individual serial numbers.

Any one else? Who has an efficient, centralized, way to deploy apps
with unique serials?

 

[Tom Penharston]

Thanks to Mulnick and Meyer for the responses above. Without getting
into the details, we'll say the vendors offer no alternative to
individual serial numbers.

Any one else? Who has an efficient, centralized, way to deploy apps
with unique serials?

 

[Jaap de Koning]

Isn't there a way to deploy the application, and enter the serial after
it's installed?

 

[Andrew Morton]

Thanks to Mulnick and Meyer for the responses above. Without getting
into the details, we'll say the vendors offer no alternative to
individual serial numbers.

Any one else? Who has an efficient, centralized, way to deploy apps
with unique serials?

How about sending the users an email with the location to install from and
their own serial numbers?

If you make the email sound enthusiastic, they might even enjoy installing
it.

Dear <username>,

We are delighted to inform you that we have obtained a copy of <software>
specially for you.

Please run the setup.exe program at <location>.

Your personalized serial number is <sn>.

Andrew