Хотелось бы увидеть более полный кусок логов апача.

(В ответ на комментарий №1)
> Хотелось бы увидеть более полный кусок логов апача.

[Tue Nov 24 09:31:05 2009] [error] [client 172.26.44.66] Invalid method in request \x1a
(В ответ на комментарий №1)
> Хотелось бы увидеть более полный кусок логов апача.

Вырезка из access.log (врямя появленя точно совпадает со временем попытки инвентаризации агентом):
"GET /ocsinventory/deploy/label HTTP/1.1" 400 1052
"POST /ocsinventory HTTP/1.1" 200 206
"POST /ocsinventory HTTP/1.1" 500 1142

В error.log ошибка перестала появляться. Сообщение "Invalid method in request \x1a" появлялось при использовании стандартного агента.

В логах агента (сейчас установлен агент с ftp.altlinux.ru) по прежнему сообщения:
HTTP SERVER: Creating CInternetSession to send inventory results...OK.
HTTP SERVER: Getting HTTP Connection to server 172.26.44.77 port 80 using no authentication...OK
HTTP SERVER: INV : SEND received, sending inventory...ERROR: HTTP status code 500
OK.
HTTP SERVER: INV : ERROR : No server answer concerning the account update
HTTP SERVER: Closing HTTP connection....OK.

Необходимо попробовать установить OCS_OPT_DBI_PRINT_ERROR в 1 в файле /etc/httpd2/conf/extra-available/ocsinventory.conf
перезапусть httpd2 и ocs и посмотреть что будет в error.log у апача при попытке инвентаризации с проблемных компьютеров.
Также неплохо вспомнить, что логи есть у самого OCS и они находятся в /var/log/ocsinventory-server :)

P.S. У меня, файл, который находится во вложении, успешно импортировался в OCS, при помощи Local import

(В ответ на комментарий №3)
> Необходимо попробовать установить OCS_OPT_DBI_PRINT_ERROR в 1 в файле
> /etc/httpd2/conf/extra-available/ocsinventory.conf
> перезапусть httpd2 и ocs и посмотреть что будет в error.log у апача при попытке
> инвентаризации с проблемных компьютеров.
Интересная ошибка появляется:
DBD::mysql::st execute failed: Data too long for column 'BVERSION' at row 1 at /usr/lib/perl5/vendor_perl/Apache/Ocsinventory/Server/Inventory/Update.
pm line 155.

> Также неплохо вспомнить, что логи есть у самого OCS и они находятся в
> /var/log/ocsinventory-server :)
Mon Nov 30 08:22:53 2009;31574;511;NA;172.26.44.66;OCS-NG_windows_client_Aug 28 2009;deploy;no_file
Mon Nov 30 08:22:53 2009;31574;515;NA;172.26.44.66;OCS-NG_windows_client_Aug 28 2009;end;bad_request
Mon Nov 30 08:22:53 2009;31615;103;VM-SERV-2009-11-27-08-54-24;172.26.44.66;OCS-NG_windows_client_v4054;prolog;new_deviceid
Mon Nov 30 08:22:53 2009;31615;100;VM-SERV-2009-11-27-08-54-24;172.26.44.66;OCS-NG_windows_client_v4054;prolog;accepted
Mon Nov 30 08:22:53 2009;31615;311;VM-SERV-2009-11-27-08-54-24;172.26.44.66;OCS-NG_windows_client_v4054;session;started
Mon Nov 30 08:23:04 2009;31575;319;VM-SERV-2009-11-27-08-54-24;172.26.44.66;OCS-NG_windows_client_v4054;session;found
Mon Nov 30 08:23:04 2009;31575;104;VM-SERV-2009-11-27-08-54-24;172.26.44.66;OCS-NG_windows_client_v4054;inventory;incoming
Mon Nov 30 08:23:04 2009;31575;528;VM-SERV-2009-11-27-08-54-24;172.26.44.66;OCS-NG_windows_client_v4054;accountinfos;missing
Mon Nov 30 08:23:04 2009;31575;515;VM-SERV-2009-11-27-08-54-24;172.26.44.66;OCS-NG_windows_client_v4054;end;error

Как я понял проблема в том, что версия биоса не влазит в поле bversion таблицы bios. 
Я увеличил длину поля с 255 до 300 и инвентаризация компьютера состоялась.

Найдена ещё одна ошибка агент-сервер.
На компьютере есть неформатированный логический диск на 100 гб.
Агент видит его как:
<DRIVES>
<LETTER>
<![CDATA[ E:/]]> 
</LETTER>
<TYPE>
<![CDATA[ Hard Drive ]]> 
</TYPE>
<FILESYSTEM>
<![CDATA[ N/A ]]> 
</FILESYSTEM>
<TOTAL>
<![CDATA[ 4294967295 ]]> 
</TOTAL>
<FREE>
<![CDATA[ 4294967295 ]]> 
</FREE>
<NUMFILES>
<![CDATA[ 0 ]]> 
</NUMFILES>
<VOLUMN>
<![CDATA[ N/A ]]> 
</VOLUMN>
</DRIVES>

Т.е. объём видится как 4294967295.
В БД такое, конечно не пишется. 
В логах апача:
DBD::mysql::st execute failed: Out of range value for column 'TOTAL' at row 1 at /usr/lib/perl5/vendor_perl/Apache/Ocsinventory/Server/Inventory/Update.pm line 143.

ocsinventory был удален из Сизифа