Восстановление потерянных разделов HDD.

 Давно не сталкивался с потерей таблицы разделов, но недавно двое моих знакомых почти одновременно обратились за помощью. При чём, если в первом случае разделы "потерял" переносной диск, после временного знакомства с телевизором (фоточки смотрели на большом экране) - ситуация вполне объяснимая, то второй случай вызвал некоторое недоумение - жёсткий диск в ноутбуке под управлением Windows 7, ни на что не жаловался, но в какой-то из дней ноут отказался загружаться - лет 10 назад, когда я широко практиковал оказание помощи в "починке компьютеров на дому", такие случаи были нередки, но с тех пор не припоминается подобных сбоев.

Итак, уже подзабыв свои навыки "воскрешения" разделов, взялся второй случай "лечить по телефону" (в итоге вполне успешно, хотя и весьма неэффективно), а переносной диск "пригласил к себе в гости".

Итак, через что пришлось пройти:

1. Перед началом любых операций по восстановлению данных, надо убедиться, что диск полностью исправен, иначе очень велики шансы потерять всю информацию безвозвратно. Первый тест - звук включения - если есть скрежет, нетипичное биение головок или иные аномалии - диск сразу отключаем и при необходимости несём в хорошую лабораторию восстановления данных (я знаю как минимум одну в Москве). Если "на слух" диск работает нормально, читаем атрибуты S.M.A.R.T. (в Windows я обычно использую CrystalDiskInfo - сайт автора засыпан рекламой, но сама программа бесплатная и достаточно удобная; можно использовать и другие инструменты - нет им числа) - если все параметры идеальные или близки к идеальным (отсутствуют Pending sectors и Reallocation sectors, нет ошибок чтения и т.д.), можно переходить к поиску данных.
2. Изначально я перебрал с десяток инструментов (RS Partition Recovery, AOMEI Partition Assistant, Piriform Recuva, Wondershare Recoverit, Starus Partition Recovery, RStudio и даже AcronisTrueImage WD Edition), но они либо просили денег за своё использование, либо не находили искомые данные. Даже любимый и уважаемый мной gpart не смог найти "потерянный раздел".
   
3. В итоге я загрузился с древнего, ещё бесплатного Partition Magic, безрезультатно прогнал "поиск разделов" в gparted (средствами уже упомянутого gpart), приготовился уже вываливать в единую кучу файлы, восстановленные с помощью photorec, но увидел в меню инструментов TestDisk... оказалось, это как раз тот инструмент, который был мне нужен! Буквально в два клика был найден требуемый раздел, результат (таблица разделов) был записан на диск и после переподключения, все данные были доступны.

До сих пор не знаю, что именно вызывает потерю таблицы разделов (кроме случаев подключения к бытовым устройствам типа ТВ или MP3-проигрывателей, где вполне можно допустить некорректную работу с файловой системой), но из-за редкости таких сбоев "каждый раз как первый"...

По моим воспоминаниям, такую ошибку автоматически восстанавливал Acronis DiskDirectorSuite, купленный мной за 550 рублей в стародавние времена, но ту версию запустить под Windows 10 не удалось, а покупать новую как-то... ну, не стал.

Проблема при обновлении BIOS платы DH61BE (на версию 0099/0120)

На днях собирал рабочее место "из того, что было", а был системный блок с материнской платой DH61BE, процессором Core i3 и двумя гигабайтами оперативки (диск, видимо, посыпался - его не обнаружилось). Из-за наличия лицензии и по соображениям единообразия, устанавливать решили Windows 10, но BIOS был без поддержки UEFI (самой первой для этой платы версии - 0016). Как истинный джедай, не читая никаких инструкций, я ломанулся обновлять firmware до последней версии - 0120, но обновлятор остудил мой пыл, заявив, что "эту древность я обновлять не буду", и попросил сперва установить версию 0099, обновлятор 0099, в свою очередь, попросил установить версию 0048. Обновлятор версии 0048 успешно установился в штатном режиме (через iFlash), на него успешно установилась версия 0099... и всё - комп "окирпичился" - при включении компьютер позволял зайти в "CMOS Setup" (F2), реагировал на F7 (обновление BIOS), но отказывался устанавливать версию 0120 (ругаясь на что-то про Intel management engine), и категорически отказывался загружаться - висел с логотипом Intel и молчал. Стал изучать информацию "в интернетах" и обнаружил, что обновляться на версию 0048 надо было не "штатным" методом (F7 или windows-утилита), а через "режим восстановления" (снять перемычку CMOS с платы, вставить флэшку с BE0048.BIO и включить комп, дождаться завершения), но мне было уже "поздняк метаться" - BIOS версии 0099, ME Firmware показывает версию 0.0.0.0, в режиме BIOS Recovery с на экран ничего не выводится (хотя флэшка время от времени мигает), вне зависимости от версии записанного файла. Натолкнулся на статью с ixbt, где описана ровно такая же проблема, но как-то не понял, нащупал ли кто правильный алгоритм (описанные манипуляции выглядят малоубедительными, да и не помогли мне). В итоге, на форуме Intel по кусочкам собрал "правильную" последовательность действий (если имеем "окирпиченную" прошивку версии 0099):

1. Вынуть батарейку CR2032 минут на 20 при обесточенном компьютере (вынуть шнур питания)
2. Отформатировать флэшку в FAT32 (у меня была флэшка на 4ГБ, но говорят, что и 8 или 16ГБ пойдёт)
3. Удалить с флэшки "System Volume Information" и скопировать на неё BE0120.BIO (прошивка версии 0120)
4. Вставить полученную флэшку в порт USB2 (чёрный)
5. Вернуть батарейку, снять перемычку BIOS CFG, включить компьютер

В описанном алгоритме важными названы все пункты. После этих манипуляций на мониторе пошёл прогресс обновления прошивки, после чего комп заработал (первое включение шло чтранно - завёлся, пикнул, выключился, опять завёлся, ещё раз пикнул, выключился...), версия ME стала отображаться 8.1.что-то.там. В общем, всё заработало.

Пробуем вылечить ошибку Outlook "Точка входа в процедуру CompareStringOrdinal не найдена в библиотеке dll kernel32.dll"

Ни для кого не секрет, что в корпоративной среде до сих пор нередко можно встретить снятую с поддержки Windows XP, при чём остальной софт может быть весьма современным. Итак, я столкнулся с такой ситуацией - на нескольких машинах стоит WinXP SP3 и Office 10. После недавнего обновления при попытке "запустить почту" пользователи стали получать ошибку "Точка входа в процедуру CompareStringOrdinal не найдена в библиотеке dll kernel32.dll"... краткое расследование показало, что недавно на проблемные машины установились обновления:
Обновление безопасности для Microsoft Excel 2010 (KB4011660) 32-разрядный выпуск;
Обновление безопасности для Microsoft Outlook 2010 (KB4011273) 32-разрядный выпуск;
Обновление безопасности для Microsoft Office 2010 (KB4011611) 32-разрядный выпуск;
Обновление безопасности для Microsoft Office 2010 (KB4011610) 32-разрядный выпуск;
Обновление безопасности для Microsoft Word 2010 (KB4011659) 32-разрядный выпуск;
Собственно, после их установки проблема и стала проявляться.
Если верить описанию метода (функции) CompareStringOrdinal, то он появился в Windows Vista и в XP поддерживаться не будет. Странно, что такое нововведение появилось лишь в недавнем обновлении офиса, но до него всё работало вполне нормально.
Локально решили откатом этих машин до состояния до установки обновлений, а вообще, в такой ситуации остро напрашивается обновление парка или хотя бы операционных систем.

UPD: вот, более дотошные коллеги утверждают, что к данной ошибке приводит конкретно обновление "Обновление безопасности для Microsoft Outlook 2010 (KB4011273) 32-разрядный выпуск", что, вообще-то, логично...

UPD2: поступила информация, что несколько позже вышло ещё одно обновление, вызывающее такую же ошибку: "Такую же ошибку вызывает установка Обновления безопасности для Microsoft Outlook 2010 (KB4011711) 32-разрядный выпуск. После его удаления Outlook 2010 заработал"

Чиним "Диспетчер Hyper-V": "RPC сервер недоступен. Не удается установить соединение..."

После обновления Windows 10 (в моём случае до 10.0.16299.64), при попытке подключиться к серверам виртуализации через Диспетчер Hyper-V я стал получать ошибку "RPC сервер недоступен. Не удается установить соединение...". Решение оказалось каким-то неочевидным и неожиданным - виноват был брандмауэр. Для исправления следует сделать следующее:
Параметры - Сеть и Интернет - Брандмауэр Windows - Дополнительные параметры; в отрывшемся окне "Монитор брандмауэра Защитника Windows" в разделе "Правила для входящих подключений" надо включить правило "Инструментарий управления Windows (асинхронный - входящий трафик)" для соответствующего профиля (в моём случае - "Домен").
После этой манипуляции всё заработало. Что примечательно - после отключения этого правила, работоспособность диспетчера Hyper-V сохранилась. Глубоко копать не хватило времени и мотивации, но подозреваю, что входящее подключение нужно было для обновления каких-то параметров оснастки диспетчера.
UPD 2018-04-10: на самом деле через какое-то время (пара недель) после отключения правила, оснастка опять стала выдавать ту же ошибку - видимо, предполагаемое обновление (и разрешающее правило) нужно достаточно часто.

В системе мониторинга Zabbix элемент данных vfs.file.exists[] отображает статус "не поддерживается"

Забавный сбой обнаружил сегодня при попытке заставить Zabbix отслеживать наличие файла-семафора на одном из серверов - после создания "Элемента данных" с типом "Zabbix agent" и "ключём" вида "vfs.file.exists[C:\Semaphores\Alert.txt]" в графе "Состояние" отображалось "Не поддерживается"... видимо, элементы данных обязаны находиться в какой-либо "Группе элементов данных", так как после выбора группы "Filesystems" всё заработало в лучшем виде.
Вывод: надо либо досконально изучать документацию на применяемые инструменты, либо звать компетентных людей... либо, идти тыком до победного =)

Настройка ККТ Штрих-Онлайн (Штрих-On-Line) для отправки данных в ОФД

Сегодня столкнулся с проблемой - на нескольких торговых точках недавно была произведена плановая замена фискальных регистраторов на Штрих-Он-лайн, но данные в ОФД не передавались. Благо, для передачи данных отведено 30 дней, но и они подходили к концу. В итоге, фискалы были сняты (на точках был санитарный день) и доставлены в офис для выяснения причин такого непотребного поведения и исправления ситуации. Как ни странно, внятной документации по настройке данных фискалов мне найти не удалось - инструкция годилась только для подключения проводов к полностью настроенным кассам, а на форумах мысли начинались с середины, или обрывались так и не дойдя до развязки.

Ошибка 1С УТ 11: Поле "Способ установки курса" не заполнено.

Похоже, в конфигурации 1С "Управление торговлей, редакция 11" (как минимум, это справедливо для 11.3.1.142) допущена фатальная ошибка - если не установлен функциональный параметр "ИспользоватьНесколькоВалют", то в форме элемента для используемой валюты отсутствует реквизит "Способ установки курса" (и по умолчанию он не заполнен, как минимум, для RUR) и как результат, при создании/изменении валюты, да даже просто при попытке её выбора, невозможно записать элемент справочника "Валюты" - при попытке записи выдаётся данная ошибка (Поле "Способ установки курса" не заполнено).
Для исправления ситуации, необходимо зайти в "НСИ и администрирование", в разделе "Настройка НСИ и разделов" выбрать "Предприятие", там развернуть раздел "Валюты" и поставить флажок "Несколько валют". После этих манипуляций форма элемента "Валюта" изменится на полноценную и можно будет вносить изменения (в том числе - поставить злосчастный "Способ установки курса" на "вводится вручную"). Если нет необходимости вести учёт в нескольких валютах, то параметр "Несколько валют" можно после этого выключить.