• HP 3.6V Ni-MH Battery Pack - Из Гонк-Конга “с любовью”…

    imageИмея в своём хозяйстве несколько SCSI контроллеров HP Smart Array 6400 и старенькие, но вполне ещё работающие “в полный рост” дисковые полки типа HP MSA 500 G2, озаботился как-то вопросом замены батарей питающих модули кэш-памяти на этих контроллерах, так как с определённым сроком эксплуатации эти батарейные модули вырабатывают свой ресурс… А когда наступает этот грустный момент, встроенные средства диагностики контроллера блокируют использование неисправной батареи. Вот так выглядит оригинальный батарейный модуль, требующий замены: image

    По информации, которую слили нам местные коммерсы, выпуск таких батарейных модулей давно завершён и сейчас в качестве их замены используются какие-то другие модули той же ёмкости и форм-фактора, стоимость которых варьируется в пределах 8 тысяч рублей. И так получилось, что совершенно случайно, в интернете наткнулся на информацию о том что для этих батарейных модулей есть ещё и китайский аналог от “конторы” под названием CameronSino Technology под номером модели CS-RAC6400SL. При этом цена оказалась более чем в два раза меньше, чем просили за оригинальный батарейный модуль от HP. Выглядит этот “чудо-аналог” так:

    image

    Обратите внимание на искусно приписанные парт-номера HP…

    Для пробы было решено сначала приобрести несколько таких модулей… Когда модули были получены и я принялся выполнить их установку на место отслуживших свой срок модулей, то с разочарованием для себя обнаружил, что штырьки фиксации на плате - у китайской батарейки были смещены в сторону примерно на миллиметр, что не позволило устанавливать их на плату без предварительного “тюнинга” с помощью монтажного ножа.

    image

    Но это не самое грустное в этой истории, самое грустное оказалось то, что контроллеры HP ни в какую не захотели распознать китайские батарейный модули как работающие, хотя вольтметр уверенно показывал на каждом модуле напряжение в 3.8V

    Самое смешное то, что в интернете можно увидеть то, что коммерсы довольно бойко на многих сайтах предлагают эти самые китайские батарейные модули как реальную альтернативу оригинальным модулям от HP.

    Так и напрашивается старая пословица “Скупой платит дважды”…

  • PCI-X Riser для HP ProLiant DL360 G5 – Финт ушами :)

    Не так давно пришлось заказывать переходную плату для установки PCI-X плат в сервер HP ProLiant DL360 G5. Выглядит это чудо примерно так..

    image

    Как обычно я забрался в HP Product Bulletin, нашёл там P/N соответствующей железки и сделал заказ по этому номеру…Местные коммерсы  согласились привезти такую железку по цене порядка 100$… Заказ был сделан, и когда я получил железку на руки то совершенно случайно обратил внимание на то что P/N указанный на самой железке совпадает с P/N имеющейся у меня под руками переходной платы от сервера более старшего поколения - HP ProLiant DL360 G4. Тут же разумеется нарисовался план проверить совместимость и с удивлением для себя я обнаружил что на переходной плате снятой с G4 и установленной в G5 как ни в чём не бывало работает PCI-X контроллер…При этом нигде в спецификации к G5 я не нашёл упоминаний о такой совместимости Riser-платы..

    Если вы будете делать заказ такой переходной платы как опцию для G4 то можете снизить стоимость заказа как минимум вдвое.. А тем более если у вас эксплуатируются сервера G5 и есть выведенные из эксплуатации сервера G4 – вы сами сможете это проверить, если не ссыкотно.

    С одной стороны это выглядит как маркетинговый фокус вендора, а с другой…ну не знаю..решать Вам Улыбка

  • Digi AccelePort RAS 4 не работает на Windows x64

    Имеется на руках интересная железка - Мультимодемная плата Digi AccelePort RAS 4 Europe (4 x Modem RJ-11 ports) PCI (P/N #77000617).

    image

    В былые времена она использовалась для организации сервера служб RAS, теперь появилось желание заюзать её для организации сервера факсов. Разумеется, первым делом я пошёл на сайт разработчика,… и с огорчением для себя обнаружил что поддержка этой платы уже прекращена и к тому же из списка доступных драйверов для платформы Windows самыми “свежими” является драйвер версии 5.0.314.0 (30.06.2003) для Windows Server 2003… Ни на на что особо не рассчитывая, я всё таки решил попробовать “подружить” эту железку с Windows Server 2008 R2… День мытарств, как я и предполагал, ни к чему не привёл. ОС наотрез отказалась глотать недружественный драйвер, который мало того что не имел цифровой подписи, был рассчитан на более старую систему и к тому же вообще был 32-битным. В статье Windows Hardware Developer Center - INF Requirements for 64-bit Systems нашёл описание того как же всё-таки можно попытаться насильственным способом навязать системе имеющийся в нашем распоряжении драйвер. Для этого достаточно добавить ключ реестра REG_DWORD с именем DisableDecoratedModelsRequirement в ветке HKLMSoftwareMicrosoftWindowsCurrentVersionSetup и присвоить ему значение отличное от нуля, например 1. Для вступления в силу изменений потребуется перезагрузка. После этого драйвер был таки съеден системой, однако работать так и не захотел. После изучения лог-файла установки в C:Windowsinfsetupapi.dev.log стало понятно что ОС органически не переваривает драйвер dgardxb.sys…
    Официальный форум тех.поддержки Digi оказался довольно скудным и поэтому последней надеждой стало обращение в техподдержку Digi. Разместив обращение на сайте тех.поддержки Digi я получил ответ, от которого мне совсем стало грустно.. 

    image

    На сегодняшний день, когда использование 64-битных серверных систем уже вошло в стандарт де факто, очень удивительно наблюдать подобного рода явления, когда такой серьёзный вендор (как я полагал) как Digi не имеет и даже не планирует поддержку своих устройств в 64-битных системах.

  • SCCM & Double UUID

    imageРабота с SCCM продолжает приносить нам сюрпризы. В ходе того как мы начали использовать функционал OS Deployment вскрылись новые подробности.

    При очередном развертывании целевой компьютер (HP DX7400) упорно отказывался начинать процесс установки ОС.

    Для изучения проблемы пришлось в загружаемом образе WinPE включить возможность отладки, после чего мы получили доступ к логам WinPE клиента и обнаружили что на этапе когда загруженный WinPE клиент обращается на SCCM сервер для получения задания развертывания ОС – происходит коллизия. А именно, SCCM сервер почему то определяет этого клиента как уже существующий в БД SCCM компьютер (совершенно другой но такой же модели - HP DX7400)…Далее  путём долгих мытарств выяснилось что эти два компьютера имеют одинаковый аппаратный UUID, который прошит в DMI области BIOS материнской платы на заводе производителе.
    Выяснилось что если SCCM находит в своей базе данных совпадающий UUID то он как принимает два разных компьютера за один и тот же…что и является причиной отказа в развертывании… По доступной в интернете информации - дублирующимися UUID отличаются некоторые производители оборудования, дочерние предприятия DELL и HP. Сначала мы попробовали решить эту проблему «софтверно», то есть я открывал кейс в тех.поддержке MS…но как и следовало ожидать их ответ был неутешительным- «Обращайтесь к разработчику оборудования». Пока изучал проблему узнал интересную вещь -  в свое время компания Microsoft для получения производителями статуса «Сертифицировано для Microsoft Windows» одним из условий выдвигала наличие у производителя поддержки RFC определяющего наличие и уникальность аппаратного UUID…но как оказалось наши «славянские братья» (если не путаю страна-производитель этих рабочих станций HP была Румыния) забили на все эти глупости )))
    Потом была долгая переписка с тех.поддержкой HP…и пока она длилась было найдено обходное решение по сносу с таких компьютеров всех данных BIOS из области DMI. Но при этом из BIOS, как следствие, вытирался не только UUID но и S/N и P/N девайса, что уже само по себе не очень красиво получалось…хотя при желании эти данные можно было вернуть назад с помощью ещё одной немецкой хакерской тулзы … но все эти операции выглядели очень муторно и неудобно...
    Совсем недавно наша переписка с инженером HP из !!!Индии!!! закончилась. Мы получили и успешно провели испытания утилиты SMBCFG от Phoenix Technologies. Данная тулза позволяет в режиме MS-DOS выполнить команду по регенерации аппаратного UUID не теряя при этом прочих данных их DMI области BIOS.

    Делается это одной командой:

    SMBCFG.EXE /UUID

    Столкнувшиеся с подобной проблемой могу стянуть утилиту отсюда

    PS: Обращаю ваше внимание на то что корректность работы утилиты проверена только на рабочих станциях HP DX7400 (Bios AWARD-Phoenix)