active directory structure and replication for dummies
Solution 1:
Your plan looks fine. Ish.
10 Domain Controllers for less than 100 users is a very high ratio of DCs to users. Strictly speaking, you don't need a Domain Controller at every office.
- Not having a Domain Controller at a site will result in increased traffic across the site link, as a result of authentication and other domain service traffic traversing the link
- Domain services will be unavailable if the site link goes down (which may or may not be a problem for you)
A single domain without subdomains sounds right. Microsoft doesn't recommend the use of subdomains anymore, except in a few rare use cases anyway.
- There's a good answer here for your questions about Child Domains and OUs, and for a that matter, the whole thread is probably worth a look, since you don't seem to have any Active Directory experience.
- There's a good answer here for your questions about Child Domains and OUs, and for a that matter, the whole thread is probably worth a look, since you don't seem to have any Active Directory experience.
You cannot selectively replicate OUs between domain controllers. You don't want to either.
It's a common convention not to use the built-in
UsersorComputerscontainers. (And note that they're containers, not OUs.) These are the locations where new users and computers go by default, and so it makes life easier if they're not used for anything else. Using them as a root container for your hierarchy is generally not a good idea.
Solution 2:
I'm sorry, in advance, for the rambling nature of my commentary.
I want to use one domain for all of the users without subdomains. Am I right? Actually I don't see the advantage of using more domains, not even subdomains.
Single-domain is nearly always the way to go for organizations of almost any size, large or small (especially since Microsoft added fine-grained password policy). Single-domain is the easiest configuration to administer, by far.
Domain Controller Computers
If there are local resources that users in each physical office can access to keep working in the event of WAN failure then putting a Domain Controller (DC) in every physical office is certainly nice. If all the resources they access are remote anyway then it might not make sense to deploy so many DCs.
If your plan is to use the DC in each office as a file server, too, I'd strongly recommend using Hyper-V to host the DC as a separate VM guest. You should try to isolate DCs to providing domain-related services and nothing else, if at all possible. It decreases your attack surface.
Think about what happens if somebody steals a DC from one of the offices and plan for that. You should read-up on Read Only Domain Controllers (RoDC) to see if it fits the bill for your needs. If an RoDC gets stolen the passwords on that RoDC are compromised. If a traditional read/write DC gets stolen all passwords (and the krbtgt hash) are compromised and you will need to reset all passwords (and reset the krbtgt hash and reboot all the domain member computers).
Sites, Subnets, Replication
You'll want to configure Sites and Subnets to allow AD to properly manage the replication topology.
Can I replicate only subtrees between DCs? Like "OU=country1, OU=Internal, CN=Users"?
Don't worry about any selective replication of AD. You have so little data that any attempts to selectively replicate (which is what child domains are about, primarily) will just cause a lot more grief than benefit.
Be aware that intersite replication latency (15 minutes between sites, by default) will make you want to get in the habit of connecting your remote administration tools directly to the DC in an office when you want to make changes that are immediately "visible" to users in that site. (There is an option to enable a change notification protocol for intersite replication that will speed replication dramatically, but that's not the default behavior of the product.)
OU Structure
Delegation of administrative control is the first design constraint you should use in determining an OU structure. For example, if there will be users in each remote office who can act as "helpdesk" and reset passwords for local users then you'll want a geographically-oriented OU structure (as you've proposed). In some companies the OU structure breaks down first by departmental / business-unit lines because delegated administration is handled at the departmental / business-unit level. Even if you're not planning for any delegation of control now think about how the company might grow in the future and try to plan for that. (Geographic is generally the way people go.) Delegation of control amounts of access control lists (ACLs) applied to objects in the directory. Since an object can only have a single ACL applied, and since it inherits its ACL from the container (OU, in most cases) it's placed into, by default, the getting the location of the object is pretty important.
The second design constraint should be application of Group Policy. Since you're new to AD you should take some time to read-up on Group Policy. Unlike delegation of control, Group Policy is more flexible about applying to objects that are "spread out" in subordinate containers (through a feature called "Security Filtering"), so it's less critical that your OU structure reflect your planned Group Policy application strategy (though, when you can just link GPOs to OUs without any security filtering things are much simpler).
I saw somewhere an AD where they didn't use the CN=Users for the "normal" users, but a new CN="Company Users" in the root. Is it a common convention? I don't see any good reason to don't use the original CN=Users subtree.
The practical reason is that the "CN=Users" object is a "Container" object (not an OU-- compare the difference in the icons in "Active Directory Users and Computers" to "Users" versus "Domain Controllers") and cannot have Group Policy applied to it, nor can it have OUs created beneath it. The same holds true for the "CN=Computers" container. Practically speaking, nobody who uses Group Policy uses these containers for anything other than the default user accounts and groups placed in "CN=Users" (which, in general, you shouldn't move!).
You can't create the OU structure you're looking for below "CN=Users" because you're not allowed to create OUs there. The typical convention is to create a domain-level OU and place all your OUs, users, computers, groups, etc, under that OU.
It looks like you're off to a solid start, but I'd spend some time playing with this in a lab and thinking about common administration scenarios. Spend a little money and time on reading about AD in general and Group Policy, in particular, and I think you'll have a reasonable time of it.