I had an interesting customer request recently that I thought I would share with you. Prior to an upgrade to 2003 they had an account which was used for Remote Desktop Users. On upgrading to 2003 this account became replaced by a System Owned Object with exactly the same name. So their question to me was how do we rename a System Owned account without getting the following error.
"The attribute cannot be modified because it is owned by the system"
Carry out the following steps.
Warning: Make sure you fully test these in a pre-production environment before applying them to your live environment.
1 Launch LDP.exe and bind to the DS server you want to modify. Make sure you are schema admin, and admin over the partition you are modifying 2. After connecting and binding navigate to the browse menu and select the "Modify" option. 3. Leave the DN blank, type 'schemaUpgradeInProgress' into the Attribute field and in the values field type 1. 4. Click the Add operation and then click the enter button. This will add this command to the entry list. 5. Click the Run button. If you are successful you should see a successful modify message. 6. Go to View -> Tree. Connect to the appropriate base DN. NOTE: If your goal is to delete an object in AD that has child objects, then you will need to remove the child objects first. 7. Find the object, right click and select modify 8. In the attribute field, type "systemflags"; in the Values field, leave it blank; in the operation radio options, select delete 9. Then click Enter, then click Run to remove the system flags values 10. Perform the modification or deletion of the object 11. Set the systemflags value back to the original value, to make it owned by the system again 11. Once finished, run LDP again with the above steps, changing the schemaUpgradeInProgress value to 0 (to prevent unwanted schema/system changes)
Hello Jane, I found your blog while looking for a means to force a change onto the AD schema.
I made an error in defining a new custom objectClass in AD (2008R2 domain + forrest) to support sudo authorization from unix/linux clients
I made my objectClass an abstract class instead of a structural.
I'm now trying to rectify this issue, the change is straightforward:
Yet even with "schemaUpgradeInProgress" set to 1,
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\"Allow System Only Change" DWORD set to 1, using schema admin user, and a reboot made, the system rejects the change because:
"0x20b1 The attribute cannot be modified because it is owned by the system."
I have nothing else in the directory dependent on this objectClass now. Can you enlighten us as to a means of forcing changes on the directory's schema?
I accept that a force can be dangerous, I just want to be able to do it without being subjected to constraints.
Try using PSEXEC to launch LDP.EXE as the system account. To do this logon on to the DC and run. PSEXEC -s -h -i LDP.EXE