The most common schema issues encountered are with upgrading the schema. The first place to look when you receive an error message while upgrading is the Schupgr.log file located in the system32 folder.
Some common problems reported with the Schema upgrade process are the following:
- Insufficient rights error: Usually Schema Upgrade LDIF files contain changes for both the schema and configuration directory partitions. By default, only Schema Admins can modify objects in the schema directory partition, and only enterprise administrators or root domain administrators can modify objects in the configuration directory partition.
The user must be logged in as a member of Schema Admins and Enterprise Admins because Schupgr.exe runs within the security context of the current logged-on user.
The user needs to be logged on as a member of both because schupgr runs with current logged in user credentials. Sometimes the user is logged in as a member of both, but still reports an insufficient rights error. This is usually caused by the unavailability of a global catalog when the user logged in. Schema/Enterprise admin group membership evaluation requires a global catalog. If a global catalog is not available, those might not be in the user's token. Make sure the Global Catalog is running, and then log off and log on again.
An example of insufficient rights would be the following:
Opened Connection to BARDOK2SSPI Bind succeededFound Naming Context DC=bardok2,DC=comFound Naming Context CN=Schema,CN=Configuration,DC=itreskit,DC=comFound Naming Context CN=Configuration,DC=itreskit,DC=comCurrent Schema Version is 11Upgrading schema to version 12Converting DNs in file C:\WINNT\System32\sch12.ldf ERROR: Failed to read current FSMO role owner: 50 (Insufficient Rights)
Error in importing: ldifde.exe generates two files, ldif.log and ldif.err (in case of an error only). Check the files to see which entry is in error and what error code is returned. You can then try to import it manually through ldp or a separate ldif file that contains only this entry. Next capture a sniffer trace, and figure out from the error information what the problem is.
Schupgr runs but doesn't update the schema version: The version number. is updated as the last entry in the ldif file. If anything else fails before, the version is not updated. If no errors are reported from Schupgr.log file, and the version number is still not updated, it is usually a problem with ldifde. Make sure ldifde is running correctly. The instances when this occurs is when ldifde access violates when loading.
Schupgr error: Cannot obtain schema version to upgrade to:
You are missing a file that winnt32 would have copied to your computer when running schupgr to upgrade to the current build. To resolve the problem, run winnt32 to upgrade; it blocks detecting the schema mismatch and copies down the two to three files that you need. Then run schupgr.
"ERROR: Failed to transfer the schema FSMO role: 52 (Unavailable)" in the schupgr log. This means the current domain controller is not the schema FSMO role owner, and trying to transfer the role from the other domain controller (whoever is the FSMO role owner) to this domain controller failed. The error unavailable can come for various reasons; it can't reach the other domain controller or the other domain controller didn't respond and so on. You can retry after some time if there is any temporary network problems and so on.
To check who is the current schema fsmo role owner, use either the Schema snap-in or the ntdsutil tool to view the current Schema FSMO role owner.
If the previous suggestions do not yield the Schema FSMO role owner use the LDP or ADSIEdit tool to look at the fsmo-role-owner attribute on the schema container (cn=schema,cn=configuration,...). The fsmoRoleOwner attribute contains the name of the server that is the schema-fsmo role owner.
To increase the DS diagnostics logging level (which logs schema failures to the event log, sometimes providing clues as to why a schema operation is rejected) increase the value of the Internal Processing entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics to Level 3.