Лично я частенько сталкиваюсь с Blue Screen Error на Windows Server 2008 R2 и Windows Server 2012, код которого подобен:

STOP: 0x0000007B (0xFFFFF880009A9928, 0xFFFFFFFFC0000034, 0x0000000000000000, 0x0000000000000000)

Если посмотреть в таблицу стоп-кодов, то можно увидеть более понятное объяснение что же все таки случилось:

INACCESSABLE_BOOT_DEVICE

На моей практике это происходило в основном после выкатки из бэкапов и причиной были:

• Неверно определен активный раздел на запоминающем устройстве (чаще всего возникало после выкатки из Acronis'a, в котором был неверно указан активный раздел)
• Целевой сервер имел различное оборудование с исходным, в частности - контроллер накопителя (тут как раз Acronis Universal Restore мог помочь разрешить подобную проблему и гораздо чаще проблемы были с восстановлением из Bare Metal Recovery от Microsoft Windows Backup Feature)

В первом случае поправить ситуацию было довольно просто - загружаешься с диска восстановления, запускаешь diskpart и указываешь верный раздел активным.

Второй же случай я подробно опишу далее...

Исходные данные

1. Есть физический сервер на Windows Server 2008 R2.
   Он имеет всего один раздел (primary), размером 465.73 Гб, на котором расположена система, который является активным и загрузочным. Этот раздел находится на массиве RAID-1, построенном на аппаратном контроллере. Подключен также к серверу и другой диск, размером 250 Гб, однако на самом деле это iSCSI диск, который используется для хранения резервных копий Server Backup Feature (Рис. 1).
2. Есть скелет виртуальной машины VMWare, с одним подцепленным к ней накопителем VMDK, размером чуть больше чем раздел на физическом сервере - 505 Гб (Рис. 2).

Рисунок 1

Рисунок 2

Что было сделано и к чему эти действия привели

Был восстановлен образ Windows Server Backup Feature: Bare Metal Recovery на виртуальной машине (Рис. 3). [Как сделать образ для восстановления, включающий в себя iSCSI Initiator читайте в моей статье (ссылка)]

В результате, развернутый образ на виртуальной машине вывалился в соответствующий синий экран (Рис. 4).

Рисунок 3

Рисунок 4

Как поправить?

Загружаемся еще раз с диска восстановления WinRE (лично я предпочитаю это делаю по сети через WDS).

Запускаем командную строку и вызываем regedit.exe

В редакторе реестра устанавливаем курсор на раздел HKEY_LOCAL_MACHINE

В меню File выбираем пункт Load Hive...

Выбираем на нашем восстановленном разделе файл (без расширения): c:\Windows\System32\config\SYSTEM

В поле Key Name вписываем: hive_system

В итоге у нас должна быть такая картинка (Рис. 5).

Рисунок 5

Далее переходим в раздел реестра HKEY_LOCAL_MACHINE\hive_system\ControlSet001\services\

Внутри выбираем раздел atapi (HKEY_LOCAL_MACHINE\hive_system\ControlSet001\services\atapi\)

Устанавливаем значение реестра Start [REG_DWORD] = 0x00000000 (0)

Затем выбираем соседний раздел intelide (HKEY_LOCAL_MACHINE\hive_system\ControlSet001\services\intelide\)

Устанавливаем значение реестра Start [REG_DWORD] = 0x00000000 (0)

Повторяем то же самое с разделом LSI_SAS (HKEY_LOCAL_MACHINE\hive_system\ControlSet001\services\LSI_SAS\)

Устанавливаем значение реестра Start [REG_DWORD] = 0x00000000 (0) (Рис. 6)

Рисунок 6

В редакторе реестра устанавливаем курсор на раздел HKEY_LOCAL_MACHINE\hive_system

В меню File выбираем пункт Unload Hive... (Рис. 7)

Перестартовываем новый сервер и загружаемся в обычном режиме с нашего восстановленного раздела

Рисунок 7

Синего экрана больше нет, сервер успешно запустился и операционная система устанавливает драйвера для нового оборудования (Рис. 8). Осталось накатить VMWare Tools и проверить работу наших сервисов.

Рисунок 8

Таблица значений реестра типичного целевого оборудования

В моем примере я привел восстановление на виртуальную машину VMWare. В таблице ниже указаны значения реестра для другого целевого оборудования. Если в таблице Вам ничего не подходит, можете поэксперементировать.

Настройка синхронизации времени на PDC и остальных контроллерах домена AD

Настраивать время в домене нужно как только мы развернули новый лес, или же если мы передали роль PDC другому контроллеру домена в существующем лесу.

Стандартная схема синхронизации времени в домене довольно проста:

1. Есть контроллер домена в Root Domain, который держит роль FSMO - PDC (Primary Domain Controller). Его нужно настроить на синхронизацию времени с каким-либо внешним NTP сервером.
2. Есть другие контроллеры домена, которые в стандартной схеме синхронизируются с вышестоящим контроллером домена в иерархии Active Directory.
3. Контроллеры наивысшего уровня синхронизируются с PDC эмулятором.
4. Рядовые серверы AD и клиентские компьютеры синхронизируют время с соответствующим контроллером домена своего сайта.

Настраиваем контроллер домена с ролью PDC

PS C:\> w32tm /config /manualpeerlist:192.168.5.10 /syncfromflags:manual /reliable:yes /update
The command completed successfully.
PS C:\>
PS C:\> Restart-Service w32time
PS C:\>
PS C:\> w32tm /resync
Sending resync command to local computer
The command completed successfully.

где 192.168.5.10 - внешний или корпоративный NTP сервер. Также здесь можно указать и несколько пиров, разделенных пробелами и заключить все в двойные кавычки. Пиры можно указывать как с помощью IP-адресов, так и с помощью DNS-имён.

Настраиваем члена домена, не держащего роли PDC, на работу в стандартной доменной схеме

Хочу отметить, что данную процедуру нужно проводить в том случае, если настройки времени на текущем компьютере домена перед этим менялись на нестандартные. Таким образом мы вернем все в дефоулт.

PS C:\> w32tm /config /update /syncfromflags:DOMHIER
The command completed successfully.
PS C:\>
PS C:\> w32tm /resync
Sending resync command to local computer
The command completed successfully.