TechNet Magazine this month includes an article that discusses best practices in OU design. One great quote from early in the piece that I'm sure you've experienced yourself states, "A poorly planned OU structure tends to take on a life of its own."

So true. With a poorly planned OU structure, you spend more time looking for objects and troubleshooting Group Policy application than necessary. In every case so far in my own personal experience, the simpler the structure the more useable it is going to be. If you find yourself creating OUs for mere object separation without additional reasoning, you may find yourself with an end-result structure that's too complicated. The article breaks down the architecture determination process into three questions. Ask yourself these three questions when you're making decisions about when and where to create OUs:

1. Does this OU need to be created so a unique Group Policy Object (GPO) can be applied to it?
2. Does a particular group of administrators need to have permissions to the objects in this OU?
3. Will this new OU make it easier to administer the objects within it?

If the answer to any of these questions is "yes", then likely the OU creation is a good idea. If you find yourself answering "no" to all, then the OU creation may be extraneous. The article then goes on to a deep discussion about the different object models typically used by successful environments.

Get your copy of this excellent article at: http://technet.microsoft.com/en-us/magazine/cc462797.aspx