When attempting to do an AD import, either incremental or full, we receive the error on the screen "The import rule has failed.  The object does not exist."  Most or all of our AD collections are now missing.  The logs show the following:

Priority: 1
Process: aexsvc.exe (2876)
Thread ID: 3820
Module: AltirisNativeHelper.dll
Source: Altiris.DirectoryServices.NSDirectoryItems.DirectoryImportTask.DoDirectoryImportTask
Description: While DoDirectoryImportTask for import rule Import Computer resources from x.x.x.x starting from Computers, Another sub OU and using the default column mappings. Import all computers on the specified schedules. System.Runtime.InteropServices.COMException caught in DoDirectoryImportTask. Reason: There is no such object on the server ( Unhandled exception.  Type=System.Runtime.InteropServices.COMException Msg=There is no such object on the server Src=System.DirectoryServices
StackTrace=
   at Altiris.DirectoryServices.NSDirectoryItems.DirectoryImportTask.DoDirectoryImportTask(String taskid, String importXml, Boolean bUpdateImport)
COM Exception errcode = -2147016656 )

This occurs when instead of selecting the entire AD tree, specific OU's are selected in the AD connector setup.  When one of those OU's is changed or removed, the AD connector attempts to enumerate the OU's it has listed within the Directory and can not find the OU you told it to import from.  The connector then throws an error and stops.  If this occurs during a full import, the entire tree is deleted in NS first, and then upon failing the import, all the data is simply gone.

This is currently working as designed.  To correct the problem, update the list of OU's in the connector settings whenever OU's touched by the connector are changed (i.e. deleted).

There are several factors involved.   The list of OU's selected in NS is a static list, not a dynamic link to AD.  If the base of the AD tree is selected, then the import can find this at any time and import all OU's under that.  However, if an OU is changed or deleted, NS does not have a dynamic link to the directory to "know" about this change, looks for the item on its list, and fails.

There are two current requests to be changed in the connector to further assist in this issue.  One is to somehow cache or otherwise "save" previous connector import information so that the initial deletion on a full import doesn't result in all information being missing if the connector fails for ANY reason.  Another is to ignore any OU that can't be found and continue with what CAN be found rather than simply stopping the process.