This is definitely strange. It sounds like Admin Arsenal can see the computers in AD but they either aren't being added to the database or they are in the database but not being displayed.

For troubleshooting, if you make a copy of your database file before you start testing changing the root OU you'll be sure to never lose any inventory. The database file is in your local AppData directory (the exact location depends on the version of Windows, in Vista and Windows 7 it's in c:\Users\[user]\AppData\Roaming\Brisworks\Admin Arsenal).  Just make a copy of Main.sdf so that you can copy it back if something goes wrong.

Also, try deleting the Main.sdf file (back it up, of course) and run Admin Arsenal. You will be prompted to create a new database just like the first time you ran it, and then you can select the root container. See if the missing computers are synced up that way, if so it'll help point us to where the problem is.

Oh, right, all the settings are in the database, so I can just shut AA down and make a file copy of it.

Ok, I now find that with a brand new database, with the same AD credentials, I can start with the AD root in the Domain Controllers node and I get the right count, and the Dynamic Collections, Inventory, and Reports all work as expected. I then try to change the root and find the same experience as before: I can change the root, sync shows the correct count for the computers objects, but the GUI doesn't show any more objects than before.

Opening and closing AA does not help it store/find/display the objects from the new OU.

Is there an alternate way to access the data in the main.sdf file to see if the new computer objects are being stored?

The main.sdf that has only my Domain Controllers is about 2 MB, whereas the one containing the bulk of the computer objects is 99 MB.

When you force a sync, does the sync window close on its own or do you close it? Looking at your database it looks like AA reads the computers in your AD and then gets stuck before it can write anything to the database.  You might not notice this if you close the sync window, since it would happen in the background.

Also, check in the application event log to see if there are any errors reported by Admin Arsenal. If the sync process does eventually error out, it will write something there.

Hey, Adam.

I've recently come back to this error. You were right, I was cancelling out of the sync popup box, not waiting long enough for it to close by itself.

The popup box shows the correct number of computers in the AD and a "Close" button, and then about 100 seconds later, the popup changes to show an error number message:

Error: Unknown error (0x80005000)

And there is no error written to the Application Event Log. Memory consumption rises during this sync to 300 MB for 1,259 computers. Once the Error is displayed, the popup does not close itself (as opposed to the normal behaviour, where there is no error and the popup closes itself after displaying the number of computers).

During a background sync, the error is written to the Application Event Log:

Unknown error (0x80005000)
   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_IsContainer()
   at System.DirectoryServices.DirectoryEntries.ChildEnumerator..ctor(DirectoryEntry container)
   at System.DirectoryServices.DirectoryEntries.GetEnumerator()
   at Brisworks.AdminArsenal.ActiveDirectory.Reader.GetChildren(String dn)
   at Brisworks.AdminArsenal.ActiveDirectory.Importer.ReadDirectory(IReader directory, ADObject parent, List`1 containers, List`1 computers)
   at Brisworks.AdminArsenal.ActiveDirectory.Importer.ReadDirectory(IReader directory, ADObject parent, List`1 containers, List`1 computers)
   at Brisworks.AdminArsenal.ActiveDirectory.Importer.ReadDirectory(IReader directory, ADObject parent, List`1 containers, List`1 computers)
   at Brisworks.AdminArsenal.ActiveDirectory.Importer.Import(IReader directory, String rootDN)
   at Brisworks.AdminArsenal.ActiveDirectory.Importer.Import()
   at Brisworks.AdminArsenal.BackgroundWorker.ADImportProcess.Run()
System.Runtime.InteropServices.COMException

Peeking at the traffic with WireShark it looks like all groups are queried for any child objects, including the CN=System and that each objects is sequentially queried for all attributes ... and this may be providing more results than AA wants to actually use.

Using SysInternals' ADInsight gives better decoding; the last part of the LDAP traffic logged to/from AA shows the contents of the Users container being queried (alphabetically, it is the last container in my AD). Once the error is shown in the sync popup, there is a 45 second pause in the ADInsight log, and then 302 "abandon search page" lines appear in 31 milliseconds as AA closes LDAP queries.

By shutting down AA and then moving the main.sdf database somewhere safe, then starting AA afresh, I have confirmed that this is the behaviour with AA when it is pointed to the root of my AD, and is not about changing, from say, CN=Computers to OU=Domain Controllers.

On a fresh database, there is a an error "Unknown error (0x80005000)" logged during the "Test Computers" stage, while the "Reading computers from Active Directory..." activity bar is showing, and before the Finish button becomes available. At that point, the "Waiting" activity bar, the "Show detail when wizard closes" etc are all greyed out.

The time it takes to produce the Unknown error on a fresh "Initialize Database" like this is the same or similar to the sync when the LDAP root is changed from a container to the AD root.

Thanks for all of that detail testing. There appears to be an object, right near the bottom on the tree that is throwing an Unknown Error (or, possibly the AD search code is throwing the error during clean up.)  It could be a problem in the AD database or within the AD libraries themselves.

Now that we know what and where the error is, I can get a build of AA that will bypass the error allowing the rest of the data to be properly synchronized. I'll get a link to you with the special build in a couple of days, if you would like to give it a try. If it works, I'll get it rolled into a future release.

That's great, Adam. I'm game if you are.

Email me at the address previously used for support whenever you're ready.