If your IT inventory has ever been complicated by corporate acquisitions or internal restructuring, you realize the importance of a scalable inventory solution. Competing in the arena of highly scalable inventory products is Tally Systems’ TS.Census 1.2 beta. This product uses an internal product-recognition database to gather software and hardware inventory data from your network systems. Administrators can update the database by downloading monthly updates from the TS.Census Web site and creating custom application fingerprints. TS.Census also provides report and query capabilities that you can use to generate data about license compliance, trend analysis, and application and hardware upgrades.
TS.Census can automatically collect inventory data from Windows 2000, Windows NT, and Windows 9x workstations and servers connected to the TS.Census Collection Server by a TCP/IP connection. The product also includes a module that can automate the inventory process for DOS and OS/2 machines, and TS.Census can remotely scan Novell NetWare servers but only in a manual mode. The software supports Microsoft Systems Management Server (SMS) integration through Management Information Format (.mif) options, and at an additional cost, offers a software development kit (SDK). The product doesn’t include support for the Macintosh and UNIX platforms. (During the product’s installation, a representative from Tally Systems’ Professional Services Group can be at the customer site to assist in the implementation and installation of TS.Census. The duration of the implementation can take 3 to 5 days, depending on the size of the customer site, and the average daily rate for the Professional Services Group assistance is $1500.)
TS.Census is available in desktop and client/server versions. Tally Systems designed the desktop version for small enterprise environments of 1000 clients or less. The client/server version, which I reviewed, uses a distributed architecture and granular security model. The vendor claims that the distributed architecture and granular security model let you scale the product to tens of thousands of PCs at multiple sites. Both the desktop and client/server versions consist of client-side collection software and three server modules: TS.Census Task Server, TS.Census Collection Server, and TS.Census Manager. TS.Census Task Server manages and runs database purges and handles all reports, which you can print or publish to the Web. TS.Census Collection Server collects inventory data and transfers that data to the database. TS.Census Manager is the interface you use to administer all inventory activities. In the desktop configuration, all three server modules and the file store reside on one machine. The client/server version lets you distribute multiple instances of server modules across an array of machines. The desktop version uses the Microsoft Data Engine (MSDE), which the desktop version of TS.Census includes, to store inventory data, whereas the client/server version requires you to supply Microsoft SQL Server 7.0 or SQL Server 6.5 for this purpose.
TS.Census client-side collection software consists of three applications: Collection Client, Collector, and Collection Editor. On each workstation Collection Client communicates with its assigned Collection Server to determine the time for a collection. At the time Collection Client determines a collection time, Collection Editor lets the workstation user review, add, and edit the inventory data gathered by the Collector application. The client software then sends the updated inventory list to its assigned Collection Server. In the 1.2 beta version I reviewed, Collection Client ran as an application. This setup meant that a workstation user had to be logged on for the software to scan the workstation. According to Tally Systems, in version 1.3, the client software will run as a service, letting you utilize Wake-on-LAN options to perform scans. The projected release date for this version is late February or early March 2001. Tally Systems plans to include Oracle support in TS.Census 2.0.
Setup
Setup for the client/server configuration of TS.Census took a bit of planning. I chose a 550MHz dual-Pentium III processor system running SQL Server 7.0 to act as the host for the TS.Census file store. Each TS.Census server module has a different set of system requirements, and all three require a TCP/IP connection to the file store. I gathered a small network of machines to host the server modules and established a connection with each machine to the SQL Server system. All three server modules ran on NT Server 4.0 with Service Pack 6 (SP6) systems. Each module needs access to the file store, so I shared a directory on the SQL Server system for this purpose. (Network accounts that you use to run the server modules must have full control access to the file store folder.)
I began the software’s installation from the machine I’d chosen to host the TS.Census Manager. The setup program requested and evaluated the required license disk that comes with the product, then started the Database Creation and Setup Tool. This tool asked me to select the database type (i.e., SQL Server 7.0 or SQL Server 6.5) and to provide the name of my SQL Server system and the username and password of an account on that system. At this point, the documentation and interface emphatically warned me that the user whose account I provide must be a member of the SQL SysAdmin group. However, this warning failed to mention that TS.Census requires authentication using a SQL Server account, not an NT account. So when I supplied the software with my domain administrator account, which has SQL SysAdmin privileges, the TS.Census Database Creation and Setup tool couldn’t establish a connection to the database server and wouldn’t let the installation proceed. A troubleshooting session with TS.Census technical support eventually uncovered the root of the problem, and I continued the installation process.
After the system established a connection to the database server, the setup program asked me to specify the database owner. I could choose to create a new user or select from a list of existing users. I chose to create a new user and supplied the setup tool with a new SQL login name and password.
The setup program walked me through the configuration of the database. It provided a Sizing Assistant to help me determine the initial size of the database, then asked me to specify the growth parameters. A similar series of steps then led me through the configuration of the transaction log file. After about 10 minutes, the initialization of the database was complete.
Next, the setup program presented me with the option of installing TS.Census components. I was at the machine that I had chosen to host the TS.Census Manager, so I opted to install this component. The installation was quick and uncomplicated.
I moved on to install TS.Census Collection Server on two machines and TS.Census Task Server on a third machine, and I was surprised to discover that the installation instructions for both modules asked me to stop all services on the machines on which I was installing the software. A quick call to tech support confirmed that these instructions were erroneous, so I continued with the installations without further problems.
After checking the TS.Census Manager interface to determine that the other three servers were connected and functioning properly, I distributed the client-side collection software. To do so, you can use Win2K group policies or NT system policies, place setup files on a Web server, use logon scripts, or simply install the client-side collection software directly from the product’s CD-ROM. I discovered that using a logon script with a silent installation option offered tight control and didn’t require user intervention. The installation files took only a few minutes to install, and the process was unobtrusive to the user. Distributing the software to various machines across multiple segments was straightforward and trouble-free.
Immediately after you install the client-side collection software, the software performs an initial scan of the client machine. The scanning process is virtually invisible. The only way I could tell that the software was scanning a workstation was to monitor the system’s CPU usage. During the minute or so that the software took to complete a scan, the CPU was more or less pegged.
After the software completes the initial scan, the client’s Collection Editor might run, depending on the configuration settings you establish at the TS.Census Manager. By default, Collection Editor runs on a workstation after every scan, but you can also choose to let the application run only on new workstations or never run. Among the software’s components, Collection Editor is one of the most valuable. This component lets the workstation user review, edit, and add to the workstation data that Collector has gathered. As the administrator, you can choose to require the user to add information such as his or her email address, telephone number, and department name, and you can restrict the user from editing certain fields. To promote a more consistent inventory, I created lists of possible entries for various fields. Figure 1 shows the interface I used to configure Collection Editor’s Workstation Tab Fields.
As Figure 2 shows, I configured collection options through the TS.Census Manager interface. Through this interface, I was able to monitor the status of TS.Census servers and configure inventory collection options. You can schedule inventories to run once or periodically, and you can scan a previously inventoried machine with one click of your mouse. Creating and administering logical domains and TS.Census users was effortless.
TS.Census Manager’s reporting component includes several built-in reports that you can customize to your liking. Using this component, I generated detailed reports about a variety of systems and found that the software consistently and correctly provided detailed information, such as processor type and speed, total memory, disk capacity, and available free space. In most cases, the software also correctly identified the hard disk and NIC make and model as well as information such as each system’s graphics adapter, BIOS information, and IP address. However, I discovered a few occasions in which the reports incorrectly reported the number of systems’ PCI slots and ISA slots. Further investigation into these errors revealed that one computer’s System Management BIOS (SMBIOS) contained incorrect information about the number of expansion slots, and two older 120MHz Pentium processor systems weren’t SMBIOS equipped. When reporting this type of information, TS.Census 1.2 beta relies on the contents of the SMBIOS exclusively.
TS.Census did a commendable job identifying the installed applications on my test systems. To identify resident applications, the software compares the files on each system’s hard disk against profiles, or fingerprints, for known applications in the software’s product-recognition database. The software reports files that it’s unable to identify under a Files Not Identified (FNI) category list. Among the systems that I inventoried, the amount of FNI data that TS.Census reported for each workstation varied. One of the Win2K machines yielded more than 10 pages of FNI files, about 400 files, and an NT system generated less than 1 page. Generally, the software detected and correctly reported installed software versions. The only unidentified applications were the Microsoft Windows 2000 Resource Kit, Microsoft Outlook Express, Research In Motion’s BlackBerry client, and, quite surprisingly, the TS.Census client-side software. Tally Systems later explained that the company waits until the final release before including fingerprints of its software.
One way you can clean up FNI data is to create new fingerprints for unassociated applications and add them to the product-recognition database. When the software didn’t recognize the BlackBerry client software, I used the reported FNI data to create a new fingerprint, as Figure 3 shows. The process to create a new fingerprint was fairly simple. On subsequent scans, the software correctly identified the BlackBerry client and the appropriate files disappeared from the FNI list.
Alternatively, you can clean up FNI data using the TS.Census ignore.dat file, which contains the list of files that TS.Census will ignore during the inventory process. TS.Census includes the names of many system files in ignore.dat, and you can add to or edit this list.
Although TS.Census Manager’s built-in reports cover a range of categories, available filter and sorting options for these reports are rather limited. The process of identifying the report category that contains all the fields that I wanted to use as filters was awkward and troublesome. I would have preferred the option to create a custom report, but this option isn’t available from within the TS.Census Manager interface. To create a custom report from scratch, you need to purchase a third-party report generator.
I was disappointed with TS.Census Manager’s custom-report creation features, but I found the software’s querying capabilities quite useful. The software automatically outputs query results to a screen in which you can group, sort, review, print, or export them in the form of a Comma Separated Values (.csv) file. TS.Census isn’t capable of performing subqueries, but overall the query feature seemed flexible.
Tally Systems designed this product for midsized to large enterprises, so I felt that Tally Systems’ scalability claims warranted attention, particularly regarding network traffic usage. I used NT 4.0’s Performance Monitor to measure the amount of traffic through a client’s NIC. Before the initial scan of the client, Performance Monitor reported about 10 seconds of heavy inbound traffic averaging roughly 4Mbps. Tally Systems explained that before the software scans a client for the first time, the client’s Collection Server must push Knowledge Base recognition files out to the client. Subsequent scans will only require this process if the recognition files have been updated (e.g., through the creation of additional fingerprints or product-recognition updates). After the client’s Collector finished gathering the client’s inventory information, Performance Monitor reported a spike of outbound network usage of about 1Mbps. This outbound traffic was generated when the client pushed the inventory data to its Collection Server and is typical for a routine scan.
In an effort to control potential surges in network bandwidth usage, the TS.Census Collection Server pushes inventory data to the database in a measured fashion. Tally Systems explained that when an inventory is initiated, the database must pass a particular database file along to each client, staggering the process among clients. However, clients have varying system resources and configurations, so the potential remains for several scans to complete simultaneously. Administrators of a TS.Census configuration that includes as many as 1000 clients per Collection Server should be mindful of the burden this product could place on their networks.
All Things Considered
With its distributed architecture and granular security model, TS.Census seems to be a good fit for large enterprises that don’t have large UNIX or Macintosh populations. The impressive level of detail and accuracy of the product’s scans, its scan-at-will option, and the ability to easily update the product-recognition database make TS.Census an effective inventory tool. The product’s reporting capability is its weakest link, and the documentation could have been better. However, if you’re willing to invest tens of thousands of dollars purchasing an inventory package for a large enterprise, then you’re probably willing to spend a few dollars on a third-party report generator.
According to Tally Systems, TS.Census 1.3, which should be available by the time this review is published, includes the ability to run the TS.Census as a service, which would eliminate the need for users to be logged on for the software to run a scan. Problems aside, TS.Census has a lot to offer.
| TS.Census 1.2 beta |
|
Contact: Tally Systems * 603-643-1300 Web: http://www.tallysystems.com Price: Contact vendor for pricing Decision Summary Pros: Distributed architecture and granular security model; scan-at-will option; ability to add custom application fingerprints to the product-recognition database; detailed inventory data Cons: Poor reporting features; errors in documentation; clients must be logged on to scan; doesn’t support Macintosh or UNIX platforms |
