ADMT is Microsoft’s Active Directory Migration Tool. This is their free solution to perform Active Directory domain migrations, either for mergers or divestitures. It’s not the most robust, up-to-date, or simple to use tool. But, it’s free and it may be all you need in some cases.
During migration, you may notice that the ADMT log has errors. Are some of these safe to ignore? Maybe! However, it is important to know why this error is there first.
I was performing a migration the other day and noticed this error at the top of my log that stated the following:
Unable to store default excluded system properties in database. Unspecified error (0x80004005)
Everything seemed to work fine though. The default system attributes were being excluded properly.
ADMT has a list of attributes it will never migrate, even if they are not in the exclusion list specifically. These are:
- Object globally unique identifier (GUID)
- SIDs (Although SIDs can be added to the SID history of the object in the target domain.)
Additionally, the first time an ADMT migration runs, ADMT tries to determine all of the attributes that should be excluded from being copied/migrated.
ADMT builds the list of attributes that it should exclude based on the following:
- mail and proxyAddresses are automatically added to the exclusion list
- All attributes that were not part of the base schema in the target domain (such as Exchange attributes)
These attributes are compiled into a list and saved in the SQL database. Unfortunately, the SQL database attribute field for this value only holds 8000 bytes.
The problem is, in a lot of cases, the list of excluded attributes that ADMT builds may exceed the size of the SQL field.
This means, because it’s never able to save the field, it will try to save it every time a migration is run and at the top of each migration log you will have a line that states “Unable to store default excluded system properties in database. Unspecified error (0x80004005)”.
Additionally, this means you shouldn’t try to manually change the exclusion list. If you do, ADMT will not automatically exclude the attributes it’s supposed to exclude as mentioned above (except for the attributes that are always excluded). Why? Because those attributes wouldn’t be able to be included in the field, as the field is too small to store the amount of attributes required to be excluded. ADMT only tries to build the field in SQL when the field doesn’t already exist. Once you manually add something to it (such as using the supported VB scripts), ADMT will see the field exists and only exclude the attributes in that field and no longer automatically generate the list of attributes to exclude.
If you are ok with just using the default exclusion list, as long as you never manually add anything to the list, and as long as this ‘error’ always shows up at the top of your log files, everything should work fine from my experience. If all of a sudden that error goes away, it’s likely someone added something to the exclusion list manually, and now this means you won’t be excluding everything that should be excluded.
I’m not aware of any supported fix. You might be able to alter the SQL database and change the data type of the field that holds the attribute, but I have not tested that and it would likely be unsupported.
If you do run into this issue/limitation, you may want to look into alternate migration utilities such as the Quest Migration Manager for Active Directory.