Protect object from accidental deletion

Question

When I first tested this, I noticed that protect object from accidental deletion adds and explicit deny for everyone to delete and delete subtree for that object only. However, after testing a bit further, I noticed that if you create a protected OU inside
another protected OU, the parent OU will also gain the ACE deny Delete All Child Objects for the everyone group.
Now, why on earth would that be a good thing?? I know most of you will answer "because of accidental deletion" but if that's the case then the child OU should also have the same rights (and all the problems that are inherited with the having of
these rights).
A move of an object is a create on the target OU and a delete on the parent OU. This basically means that if you have:
An OU named "Groups" that is protected from deletion, with a child OU called "Specific Groups" also protected from deletion, with a Group called "My Test Group" under "Groups" OU and another group called "My Specific
Test Group" under "Specific Groups" OU then "My Test Group" cannot be moved, deleted, etc whilst "My Specific Test Group" can, despite the fact that both OUs are protected from deletion. Even if you then delegate rights to
Create, Move and Delete groups because the deny takes precedence the delegation would be useless...
Unless you are an organization where you never have an OU inside an OU containing other objects, how would you possibly benefit from this, and is there a way (without doing it manually) protect ONLY OU's from deletion without protecting child objects?
Johh

Answer 1

Hi Marcin,
It does facilitate OU protection, but by default in 2008 R2 when you create an OU it is set to be protected. Ensuring people untick the box and then manually protect that OU (by assigning rights directly to it rather than ticking the box) every time an OU
is created for something as futile as preventing an OU from being deleted is almost a complete waste of time and the effort vs utility almost dictates that we'd be better off not having the prevent accidental deletions there at all. After all, we've survived
Windows 2000 and 2003 without this functionality...
As for the scenario, I'll give you a very simple example:
You have Workstations under Workstations>Department Name>Desktops. You obviously have several GPOs linked at either one of those 3 places. All of a sudden, as part of testing a new deployment, you are required to add another GPO to the existing ones.
As part of the testing phase, you create a Dev OU under Desktops and link the new GPO to the new Dev OU. At the same time that you do this, do you really go and create a new OU under Desktops to hold all the already existing objects under desktops and therefore
prevent having any leaf-level objects and an child OU under the same parent OU? You could claim that a better way of doing it would be to create a Test OU at the top level of Workstations, but then you'd have to work out the effective permissions and GPOs
at the other OU level and replicate it on the newly created one...