OU vs Domain

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all Please bare with me on this one.

We are about to upgrade our domain to 2003 AD, currently we have control
over our own NT domain, all the other domains in the company have trusts with
eachother. We have around 300 computers and 250 users in our NT domain. The
parent company has decided that when we migrate to 2003 AD they are going to
make us an OU in the top level domain, and they are going ot give us admin
rights to this OU. This is not what we want, we want to be our own domain in
the company forest, so we can keep control over our own policies, DNS, ect,
ect.

We are currently running exchagne 5.5 and SUS server VFM/DFS for replicating
data. I mention DFS/FVM becasue this app users a global namespace to
replicate data to other servers around our network, and this is one of the
reasons why we would like to take control over our oun DNS and DHCP servers.
WE are also responsible for 6 remote sites all rangin from 10 emploeeys to 80.

I gues my questions are how can i plead my case so we can be in our own
domain instead of being placed on an OU? what administrative rights do we
lose if we are only able to administer an OU? and lastly if we are admins
over the OU that has all of our users, servers, and workstations in the OU
can we fully manage all items in this OU including using ADUC to add users,
delet users, set policies? what do we give up being in an OU vs being in our
own domain?

Thanks very much for any help with this I know this is a bit of a complex
question to answer, but i appreciate any advice on this matter
 
I don't think you really do need your own domain. This is a common
resistance from admins from NT resource domains during an upgrade to AD.

If you are the admin of your own OU you will be given complete control over
it and will be able to add any objects in it, including child OU's, Group
Policies, users, computers etc.

You will lose complete control over DHCP as you need to be an enterprise
administrator to authorise this, but once this has been authorised by the
central admins you can then be given rights to create new scopes and fully
manage the server.

You will also lose full control of DNS, but this is not a bad thing given
the new importance of DNS in AD. If you have a different namespace for your
location, you can ask the central admins to create a sub-domain or new zone
for you over which you could have control.

About the only thing that would justify a new domain in your case would be a
requirement for different security policies from the main domain.
 
When you say security policys, if we are in an OU we lose the ability to
create a pasword policy, and rest passwords evan if the users are in our OU?

Thanks again
 
Skipster said:
When you say security policys, if we are in an OU we lose the ability to
create a pasword policy, and rest passwords evan if the users are in our
OU?

Thanks again
Click to expand...


Password policies such as minimum length, complexity requirements, expiry
times etc can only be set at the domain level. The interface can sort of
make it look like you can do it for OUs but it doesn't actually work like
that.

You can be delegated the permissions to add, delete and modify user
accounts. This would include resetting passwords.

I agree that you don't really need a separate domain here. All it does is
introduce more complexity and expense (for additional server licenses) than
is necessary.
 
Well said Collin..:-)
I had the same concern , however after doing some reseach I discovered that
moving to A/D will complement my enviroment and remove the complexity etc..
-Darren
 
In addition to what the others have said, you really can't have complete
control on your DNS without creating an administrative burden on others who
you want to trust your domain, or be trusted by it.

Unless you need separate password policies, I can't think of a really
persuasive argument for separate domains. You're better off cooperating and
being admin of your own OU.

Oli
 
Back
Top