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



|
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.
- 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.
- Copy the following files to Inventory$ root folder.
- OCSInventoryCSV.exe
- psapi.dll
- sysinfo.dll
- winio.dll
- run_ocs.bat
- Config.csv
- Apps.csv
- 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.
- 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.
- 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].
- Create a folder to store the logs of the Import Utility, for example in
[Path to OCS Inventory database folder]\Logs.
- Next deploy OCS Inventory with CSV only support as described in the previous paragraph.
- 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.
|