Banner.gif (5609 octets)


Project Home
OCS Inventory
   What is it ?
   What's New
   Todo
   Features
   Setup instructions
   Usage
   Build instructions
   Help FAQ
   Contributors

Report Bugs or request new features for OCS Inventory
OCS Inventory Discussion Forums
Email OCS Developer Team and mailing lists

OCS Inventory HELP and FAQ

1. For the Agent.

If the agent crash on client computer, that's because it cannot open the database in DAO or CSV mode for one of the follwing reasons.

  • The database does not exist or is not in the same directory as the agent.
  • One or more required sub directories for CSV support are missing (see Setup instructions).
  • The server share is write protected for client computers or for some users.
  • Wrong permissions on the server filesystem. The application folder and its subfolders must be writable to all your users. Here is a working security configuration (R= read, W = write, X = execute) :
    • Application folder : RW to all users, including web server account if needed. All your users must be able to create/delete a file (MS Access .ldb concurrent access control file or log file) in this directory.
    • Apps.csv and Config.csv : RW for all Administrators, Managers and web server account, R for all your users.
    • OCSInventory.mdb : RW to all users.
    • OCSInventory.exe, OCSInventoryCSV.exe, sysinfo.dll, psapi.dll, winio.dll, OCSLang*.dll, run_ocs.bat : RX for all you users.
    • OCSInventoryManager.exe, ImportCSV.exe : RX for all Administrators, Managers and Operators.
    • Drivers subfolder : RX for all your users if you want they be able to setup BiosInfo.exe tool, WinIO driver or use DumpDMI.exe.
    • AccessLogs, BIOS, Graphics, Hardware, LogicalDrives, Network, Printers, Results subfolders : RW for all your users. All your users must be able to create/update/replace a file in these directories.

You can have a log of the Agent execution by running it in debug mode with the "/DEBUG" or "-DEBUG" command line switch (see Agent usage).

If all is good, try to setup DAO 3.5 on crashing client computers. See below.

If the agent does not retreive informations about network adapters on Windows 95 computers, you must setup the Winsock 2 update from Microsoft.

If the agent do not retreive logged on user on Windows 9X/Me computers, this comes from Windows which do not update as quickly as required the system value. A workaround is to delay the execution of the agent for at least 60 seconds. You can either use the delayexec freeware package (many thanks to Eric Starrett !), or Bill Kristoph OCS Timer Visual Basic utility available in the addons download page.

 

2. For the Windows Manager.

The Windows Management GUI "OCS Inventory Manager" requires up to date MDAC and Jet/DAO 3.5 components.

DAO 3.5 components are provided by Microsft Office 97, Microsoft Visual Basic/C++ 5.0/6.0. THEY ARE NOT INCLUDED IN WINDOWS MILLENIUM / 2000 / XP, OR PROVIDED BY MICROSOFT OFFICE 2000 / XP !

If you want to setup DAO 3.5, you can download and setup Microsoft Jet 3.5 Service Pack 3, available at the following address  http://www.microsoft.com/technet/archive/default.asp?url=/TechNet/archive/office/office97/support/of97sr2b.asp, and register DAO 3.5 by downloading DAO 3.5 for OCS Inventory ZIP file, copying "DAO350.DLL" and "DAO2535.TLB" to the folder "C:\Program Files\Shared Files\Microsoft Shared\DAO" and running the DAO/DAO350.bat command file.

 

Otherwise, you must download at least MDAC 2.1 or higher at the following address http://www.microsoft.com/data/download.htm.
CAUTION ! MDAC 2.6 does not provide Jet/DAO components. You must download them from the same address and setup them separately, after installing MDAC 2.6.

Then, you have to register the DAO 3.5 and perhaps Jet 3.5 components as described below (an InstallShield setup is available for download on OCS Inventory web site, but it does not work on all computers, depending already setup components).

Jet 3.5/DAO 3.5 is comprised of the following core files. These files must be installed for DAO 3.5 to function (see http://support.microsoft.com/support/kb/articles/Q167/5/23.ASP):

File Description Installed Registered Directory
DAO350.DLL DAO version 3.5 Shared Yes Program Files\Common Files\Microsoft Shared\DAO
DAO2535.TLB Type Library Companion to DAO350.DLL No Program Files\Common Files\Microsoft Shared\DAO
MSJET35.DLL Microsoft Jet engine version 3.5 System Yes Windows\System or WinNT\System32
MSRD2X35.DLL MDB files from Microsoft Access 97 and earlier Companion to MSJET35.DLL Yes Windows\System or WinNT\System32
MSJTER35.DLL Microsoft Jet 3.5 (and DAO) error message DLL System No Windows\System or WinNT\System32
MSJINT35.DLL Localized Microsoft Jet 3.5 (and DAO) error strings System No Windows\System or WinNT\System32
VBAJET32.DLL VBA-Microsoft Jet Expression service System No Windows\System or WinNT\System32
VBAR332.DLL VBA Runtime System No Windows\System or WinNT\System32
MSVCRT40.DLL Microsoft C Runtime DLL Version 4.0 System No Windows\System or WinNT\System32


If you encounter this case, check that this files exist.

  • If files do not exist, download MDAC 2.1 or higher (MDAC 2.6 AND Jet 4.0 components) and setup them on the computer. Then, copy the missing files from DAO 3.5 folder into the appropriate folder of the client computer and run the "DAO 3.5\DAO350.bat" batch command.

    This will unregister DAO 3.5 from the registry, and then register it again.

    CAUTION ! Windows 2000/Millenium workstations include MDAC 2.5 and Jet 4.0/DAO 3.6 components, but they don't provide DAO 3.5. Therefore you have just to copy Dao350.dll and Dao2535.tlb and register DAO 3.5.

  • If files exist, just register DAO 3.5 by running the "DAO 3.5\DAO350.bat" batch command.

    This will unregister DAO 3.5 from the registry, and then register it again. If an error occurs, then you must setup up to date MDAC and Jet 3.5/4.0 components.

Many thanks to James McClure for the batch command !

 

3. For servers that host Web Manager.

Setup do not configure the database installation path in the "includes/config.inc" file of the WebManager folder. Open it in a text editor and update the INVENTORY_FOLDER value.

If you encounter OLE DB errors when opening Web Manager with your browser:

  • Make sure that the web server account (IUSR_MACHINE with IIS 4+) has read/write access on the "Application" folder.
  • Make sure that you have MDAC 2.1 or higher on your web server. You can download the latest version of MDAC at the following address http://www.microsoft.com/data/download.htm.
    CAUTION ! MDAC 2.6 does not provide OLE DB Jet 4.0 components. You must download them from the same address and setup them separately, after installing MDAC 2.6.
  • If even it doesn't work, take a look in the content of the includes/config.inc file. the default configuration of this file use OleDB Jet 4.0 driver to access the database. But it contains commented lines (begining with ' character) to use either OleDB Jet 3.5 driver or an ODBC data source. You can uncomment the required lines to use the corresponding method.

If you're unable to export configuration to CSV files, it's probably because the web server account (IUSR_MACHINE_NAME with Microsoft IIS) cannot write to the "Application" folder. Make sure that the web server account have write permissions on the Application folder. In general, the web server account is only a local computer account and cannot access to the network. So, you must setup the Web Manager on the same computer as the one which contains the OCS Inventory database.

 

4. Setting up OCS Inventory in a huge network.

NB: Remenber that for the moment, OCS Inventory only use MS Access database. So, it may be very slow to manage more than 1500 devices. It works (some users report us that they have more than 2500 devices in the database), but it can be very, very slow ! Don't ask OCS inventory to be as quick as MS SMS, or other products of the same "standing". Perhaps when it will support any database server with ODBC or XML-RPC...

Consider a company with a huge network which contains many differents sites, with local network and a file server (probably a Windows Backup Domain Controler) on each, connected through WAN links or VPN links.

If all users use the same central location to run the inventory through windows share, it will at least slow the network, most probably saturate the WAN links when at 09:00, they all open a session !

To avoid encountering this case, it's better to set one OCS Inventory installation per site. Yes, but how to consolidate inventories for all the company if there is one MS Access database per site ?

The workaround is to use only the CSV support on each local network, and synchronize the CSV inventory results of each sites with only one central Access database.

On each site.

Consider the site X. We will build the local CSV repository as follow.

  1. Create a shared folder (Inventory$ for example) as for a normal OCS Inventory setup on the file server (called SRVSITEX for example) and the following sub directories structure.
    • AccessLogs : CSV format computers access logs.
    • BIOS : CSV format computers BIOS informations.
    • Drivers and all the contents : WinIO driver and tools.
    • Graphics : CSV format computers graphic adapters informations.
    • Hardware : CSV format computers hardware informations.
    • LogicalDrives : CSV format lcomputers ogical drives informations.
    • Network : CSV format computers network adapters informations.
    • Printers : CSV format computers printers informations.
    • Results : CSV format computers softwares informations.
  2. Copy the following files to Inventory$ root folder.
    • OCSInventoryCSV.exe
    • psapi.dll
    • sysinfo.dll
    • winio.dll
    • run_ocs.bat
    • Config.csv
    • Apps.csv
  3. The run_ocs.bat will have the following content for example.

    @echo off
    REM --------------- BEGIN CONFIG ------------------------
    REM Update the following values to match your need
    REM -----------------------------------------------------
    
    REM Set the server network share you are using for OCS Inventory.
    REM This script assume that it is the Application folder which is shared.
    REM So, the Drivers folder is just under the network share.
    SET SERVER_SHARE="\\SRVSITEX\Inventory$"
    
    REM Set the drive letter you want to use to connect the server network share.
    SET DRIVE_LETTER=Z:
    
    REM Update the following destination directory to match your need.
    REM It must be the same directory under Win9X/ME/NT/2000/XP.
    SET DEST_FOLDER=C:\BIOSINFO
    
    REM --------------- END OF CONFIG -----------------------
    REM Do not modify below unless you know what you are doing.
    REM -----------------------------------------------------
    
    REM Test is not already done.
    if exist %DEST_FOLDER%\BiosInfo.exe goto NO_SETUP
    
    REM Setup BiosInfo.exe is required.
    echo.
    echo Setting up BIOSINFO Tool.
    echo BIOSINFO Tool, by Daniel Arbour.
    echo.
    
    REM Connect the server network share to a drive letter.
    net use %DRIVE_LETTER% %SERVER_SHARE% /PERSISTENT:NO
    
    REM Create the destination directory.
    md %DEST_FOLDER%
    
    REM Copy executable to dest dir.
    copy /v %DRIVE_LETTER%\Drivers\BiosInfo.exe %DEST_FOLDER%
    
    REM Disconnect the drive letter from server network share.
    net use %DRIVE_LETTER% /DELETE
    
    echo.
    echo BIOSINFO Tool successfully setup.
    echo.
    
    :NO_SETUP
    
    REM Call BIOSINFO Tool to store results in a file named BIOS.CSV
    %DEST_FOLDER%\BiosInfo.exe BIOS %DEST_FOLDER%\Bios.csv
    
    REM Launch OCS Inventory with import of BIOSINFO results.
    %SERVER_SHARE%\OCSInventoryCSV.exe /BIOS=%DEST_FOLDER%\BIOS.CSV
    
    REM Nothing else to do.
       	

    It's very important that the server share used was on the local server SRVSITEX, to avoid using the WAN links.
  4. Create a logon script for each users of site X that call this run_ocs.bat on the server SRVSITEX and associate it with each user of the site X.

On central site.

  1. Setup OCS Inventory as a normal setup, with the web manager for allowing access to remote site administrators through a low bandwidth protocol (see Setup).
    The Application folder will have the path [Path to OCS Inventory database folder].
  2. Create a folder to store the logs of the Import Utility, for example in [Path to OCS Inventory database folder]\Logs.
  3. Next deploy OCS Inventory with CSV only support as described in the previous paragraph.
  4. Last, use the OCS Inventory Import Utility to synchronize the CSV repository of each sites and the central one with a script as follow, run through the system scheduler when the WAN trafic is very low (during the night for example).

    @echo off
    REM Synchronize CSV files for site 1
    [Path to OCS Inventory database folder]\ImportCSV.exe \\SRVSITE1\Inventory$\ /EXPORT_CONFIG > [Path to OCS Inventory database folder]\Logs\Site1.log
    
    REM Synchronize CSV files for site 2
    [Path to OCS Inventory database folder]ImportCSV.exe \\SRVSITE2\Inventory$\ /EXPORT_CONFIG > [Path to OCS Inventory database folder]\Logs\Site1.log
    
    ....
    
    REM Synchronize CSV files for site N
    [Path to OCS Inventory database folder]\ImportCSV.exe \\SRVSITEN\Inventory$\ /EXPORT_CONFIG > [Path to OCS Inventory database folder]\Logs\Site1.log
        	

    This script must be run under a user account which have the ability to read/write/delete files on the CSV repository of server of each remote site.
    As is, every night, it will import the CSV inventory results from remote CSV repositories, and update the configuration files of each remote CSV repository.

You can also use other synchronization tool, like using FTP through scripts or any other way you want. This is one solution, but it's not the only one.