DNA ("Dynamic Network Administration") enables network managers to monitor hardware and software inventories on the desktop machines in their organisations. Although there are optional helpdesk and remote control options, we're concentrating on the desktop management component of the package here. The package has three components: the server (which is where the actual data resides); the management package (which the network manager uses to configure the system) and the client application (a little system extension that sits on each client). The server package holds all the information that is gathered about the organisation's systems and sits on top of a Microsoft SQL Server or MSDE database (MSDE is a cut-down, free version of SQL Server which will be fine for all but the largest installations). The installer does all the work of copying the files and creating the database tables, of which there are about 60 in all. The admin program is what you use to manage the devices on the network and the server, and you install it on the PCs of whoever's going to be doing the actual system management. Although it can sit on the same machine as the server package, the latter will probably be a server in a cupboard somewhere, so you'd probably put the admin package on the system managers' own PCs. You can install the client onto the desktop machines in a couple of ways. The simplest is to deploy it over the network from the admin console, which will go out and discover clients either by scanning IP address ranges or by using Windows file sharing-style broadcasts to locate machines. We did the latter, and it instantly found the four machines (one of which was the server) on our lab network. An alternative to networked deployment is to simply stroll round the machines with a CD (or to make the installer available via a network share) and to run the setup program by hand on each workstation. Console
The admin console is where most of the work happens. You have the obligatory Explorer-style approach, with a small pane on the left showing the various computers on the network, and a larger pane on the right that shows the detail on whatever you've clicked in the left-hand pane. In the left-hand pane, systems are collected into two types of grouping: physical collections of machines (by default they're grouped by workgroup or Windows domain name, though you can define your own and drag things about) and "dynamic groups". The latter are based on machine-specific criteria you define yourself – so you could, for instance, have a group "Windows XP Systems" and tell the system to include all machines whose operating system is Windows XP. It's a clever idea, actually, because you can also do things like collecting all machines with less than 256MB RAM into a group – as you upgrade the RAM in your computers, they'll gradually vanish from this group and so you can keep track of what's left to do. When you've selected something in the left-hand pane, you're shown its detail in the right-hand one. If you select a single computer you'll be shown its parameters in gory detail; if you select a group, you'll see a graphical representation detailing the variety of alternatives installed on machines within that group. So, for example, if you select a group of machines and click "Hardware->Video adaptors", you'll get a graph showing all the various types of video adaptor in use on the network, along with a count of how many machines have each type; alongside the graph is a textual section that lets you see precisely which machines have each type of adaptor. The information sections are broken down into hardware and software, with the hardware section further split into hardware types (network cards, CD drives, etc). The next level of complexity after basic hardware and software version information is software usage. The system keeps track not just of what packages are installed where, but also who actually uses them, and for how long (you can tell the system to report on all usage forever, or just on a particular period, by the way). This is a very neat idea, although in some ways it's a little too detailed: there's a report entry for each time a program was run on a particular machine, whereas we'd like to have seen a simple summary for each computer so that we could find out at a glance, the number of computers a program was run on, and for how long it was used. Cool feature, though. Incidentally, as well as watching what's used, you can also define restrictions on what people are allowed to run and when – so you could let people play games at lunchtime but not at other times of the day, for instance. Next is Internet usage monitoring and we're getting into scary Big Brother territory here. Just as the software monitor watches who ran what, it also watches who's going to what Web sites. Oh, and you can restrict which sites are accessible and which aren't. The report is broken down by site, which means that if a site looks dodgy, you can click on it and instantly see who's been visiting it. It would be nice to be able to choose how you view the data (for instance, I'd like to be able to look at a specific PC and list all the sites it's visited) but even so, it's a potentially useful feature. Finally, we have the package deployment tool, which allows you to define "packages" of files, folders and applications and have them automatically sent out around the network. This can be achieved via a "push" (where the system manager initiates the sending of the files) or via a "pull" (where the system manager "advertises" the files to the clients, but the clients choose to download them). Package deployment is a nice idea but it doesn't seem very flexible – you don't seem to be able, for instance, to send out an MSI installer file and have it auto-run when it gets to the other end. Nor does it seem to let you do things like adding items to the Start menu or the startup items list. Conclusion
NetSupport DNA is a very interesting package, and we do quite like a lot of its features. The software and hardware inventory features are excellent and well implemented, and the Internet and application usage bits are superb. We were rather disappointed at the over-rigid implementation of the detail screens (you're stuck with viewing things the way the developers decided you should see them – go talk to NetBotz, guys, and they'll show you how to do a GUI). We'd like to see more clickable stuff (for instance, in the list of Web sites visited, it's a no-brainer to add the ability to click on an entry and be sent to the site so you can examine its content for yourself). The bit we found disappointing was the package distribution (hint to NetSupport – make it work like the deployment bit of Visual Studio .NET and we'll be happy). But our feeling is that the underlying architecture is a good one, and it shouldn't be too hard to rectify these few issues.

OUR VERDICT

Although there are more established packages out there such as ManageWise and Microsoft SMS, there's no harm in considering independent packages, particularly when they include asset tracking, deployment and usage monitoring in a single package.