> Also one of the PCs listed in the console is showing only the (what appears to be) MAC address instead of name (is that means anything at this point...)
That's generally what's
supposed to happen when the code in machconf.dll can't make proper sense of the configuration data, instead of just falling over dead with an exception. This also happens for a client that is first discovered when the client is running in DOS, as from a Ghost Boot Partition, since in DOS we didn't have access to the registry to gather all all the Windows config data (we could change that now, since we have code that can extract registry information from an image or from DOS, but it's a ways down the priority list).
> What can I look for in the DB folder now? I actually opened all of the individual files in notepad (they all opened OK; nothing appeared visibly corrupt)
They probably won't be corrupt; it'll just be a logic bug in the code where it finds one (perfectly valid) registry setting and then blindly assumes that some other registry setting is also present without actually checking, and goes boom.
One way you can investigate this is to run the Sysinternals Process Monitor
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx which is a really useful tool for digging into all kinds of things.
What you should see when a machine is discovered is that a file in the db\data directory gets opened and written to, and closed - then machconf.dll loads and then the ngserver process reads from the file. Basically, whatever the last one it was reading from before it died was likely to be the problem.
If you were installing a client (this can happen later on), then usually what happens is that the problem file will be one of the highest-number ones. That's because the file numbers correspond to the internal database key, which for a newly-found machine is always just one higher than the last known one. The other way is to sort them by last modified date, and one of the most recently changed files will probably be the culprit.
If you can find the file, you'll probably be able to spot inside it the name of the problem client, and avoid that one until I can resolve the code problem.
Once we have the file, I'll still need you to send it to me; what I can do with it is load it here into a console on a test machine while I'm running the code under a debugger, which will just point me right at the line of code that has the problem (and then I can whip up a fixed DLL for you to test.
> Will that even work? If the PCs have the clients already installed, won't they start uploading to the server onceit goes active?
You're right, they'll all start hammering on the server. Basically, to get this working I need to find out what's wrong in the code and give you a fixed DLL file.