Пару недель назад столкнулся с одной интересной проблемой, о которой наконец-то собрался написать, хотя некоторые технические детали уже забылись. В общем, обратился ко мне клиент с очень простой просьбой: установить пакет Microsoft Office на его не так давно приобретенный ноутбук. На ноутбуке оказалась установленная производителем лицензионная Windows 10 Home, а также когда-то стояла ознакомительная версия MS Office 2016, которую клиент не совсем корректно удалил после окончания пробного периода.
Поскольку мне больше всего нравится версия офиса 2010 года, то именно эту версию я и решил установить (на самом деле моя любимая версия — Office 2003, но увы, рано или поздно приходится использовать то, что навязывает конъюнктура софтового рынка). Попытка установки окончилась выдачей сообщения об ошибке (к сожалению, код и описание ошибки уже не вспомню) и откатом установки. Причем скачивание другого дистрибутива и попытка его использования привели к тому же результату.
Решив, что причиной может быть некорректное удаление ранее установленного Office 2016, воспользовался официальным средством для полного удаления офисных продуктов от Microsoft, которое можно взять здесь. В моем случае это тоже не помогло, но кому-то может пригодиться.
После этого оставил попытки установить 2010 версию и заново поставил Office 2016. Проблемы начались при попытке активировать установленный пакет. К сожалению, не могу вспомнить текст получаемых сообщений и тем более коды ошибок, но факт в том, что все попытки активации заканчивались сообщением об ошибке. Для нахождения путей обхода проблемы были даже испробованы широко известные активаторы типа KMSAuto, KMSAutoNet, AAct разных версий, но и они не принесли желаемого результата. Абсолютно все активаторы выдавали сообщение об ошибке не только при попытке активации, но даже при считывании информации о текущем состоянии лицензирования установленного пакета. Номера ошибок, как вы уже поняли, я не запомнил (хотя если не поленюсь и посмотрю историю браузера на домашнем компьютере, то, возможно, внесу уточнения в статью).
В конце концов я добрался до командной строки и скрипта активации офиса, чтобы хоть как-то понять причину непонятного поведения компьютера. Кто еще не знает, активация пакета, получение информации об активации и другие действия возможны с помощью скрипта ospp.vbs, который обычно расположен в папке C:\Program Files\Microsoft Office\Office# или C:\Program Files (x86)\Microsoft Office\Office#. Вместо знака # в реальном пути будут стоять цифры, указывающие на установленную версию офиса (для офиса 2010 — 14, для 2013 — 15, для 2016 — 16).
Синтаксис команды запуска скрипта следующий:
cscript ospp.vbs [Option:Value] [ComputerName] [User] [Password]
Три последних параметра нас не интересуют, а список опций можно получить командой
cscript ospp.vbs /?
Так вот, запуск этого скрипта с подавляющим большинством параметров также заканчивался ошибкой. Конечно же, код ее за прошедшие недели уже стерся из моей памяти (но мог остаться в памяти браузера, так что позже попробую “вспомнить”).
Поиск по номеру ошибки в интернете навел на мысль, что причиной может служить некая проблема с WMI. Технология WMI (Windows Management Instrumentation) создавалась для контроля различных частей компьютерной инфраструктуры под управлением Windows. Проблемы в работе этой службы и ее компонентах могут быть причиной самых неожиданных ошибок. К счастью, “все уже украдено до нас”: интернет дает готовые рецепты для устранения неполадок WMI.
Во-первых, стоит проверить наличие и работу службы Winmgmt (название службы — Windows Management Instrumentation или Инструментарий управления Windows). В моем случае служба присутствовала и была запущена. Далее для проверки работы службы можно использовать оболочку Powershell и попробовать в ней обратиться с любым запросом к WMI, например, командой
get-wmiobject Win32_OperatingSystem
Данная команда должна вывести информацию об установленной операционной системе. В моем случае результатом было очередное сообщение об ошибке, что указывало на проблему с WMI.
Подробная диагностика службы WMI может быть выполнена официальной утилитой WMIDiag от Microsoft. Это скрипт, который проверяет различные подсистемы WMI и записывает собранную информацию в лог-файл. В 64-битных версиях Windows скрипт нужно запускать командой
c:\windows\System32\cscript.exe wmidiag.vbs
иначе вы получите ошибку WMIDiag must be run from native 64-bit environment.
Впрочем, диагностика с помощью WMIDiag довольно сложна, поскольку требует анализа большого количества собранных данных. Гораздо проще выполнить несколько действий, позволяющих “сбросить и обновить” систему WMI. Начать стоит с более простого и безопасного варианта — перерегистрации нужных служб и dll, а также перекомпиляции файлов mof. Это можно сделать с помощью командного файла следующего содержания:
sc config winmgmt start=disabled
net stop winmgmt
cd %windir%\system32\wbem
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
wmiprvse /regserver
winmgmt /regserver
sc config winmgmt start=auto
net start winmgmt
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
Запускать командный файл следует с правами администратора. После завершения работы скрипта надо перезагрузить компьютер.
Если данный вариант не помог (мне он не помог), можно перейти к более сложному шагу — пересозданию репозитория WMI. Репозиторий (то есть хранилище) находится в каталоге %windir%\System32\Wbem\Repository и представляет собой базу данных, в которой содержится информация о метаданных и определениях WMI классов. Само собой разумеется, что при повреждении этой базы данных WMI может работать со сбоями. Однако пересоздание репозитория WMI может нарушить работу некоторых установленных программ, потому что все записи в базе WMI сбросятся до состояния чистой системы. В таком случае неработающие программы придется переустанавливать.
Начиная с Windows Vista, можно проверить целостность репозитория WMI с помощью команды
winmgmt /verifyrepository
Если команда возвращает состояние INCONSISTENT, стоит попробовать команду “лечения” репозитория, после которой следует перезапустить службу Winmgmt:
Winmgmt /salvagerepository net stop Winmgmt net start Winmgmt
Если “лечение” не помогло, можно обнулить репозиторий:
Winmgmt /resetrepository
Данными рекомендациями мне воспользоваться не удалось, так как выполнение команды проверки состояния репозитория тоже заканчивалось ошибкой. В таком случае остается только ручное обнуление репозитория. Для этого следует создать командный файл следующего содержания и выполнить его от имени администратора:
sc config winmgmt start=disabled
net stop winmgmt
cd %windir%\system32\wbem
winmgmt /kill
winmgmt /unregserver
winmgmt /regserver
winmgmt /resyncperf
if exist RepBackup rd RepBackup /s /q
rename Repository RepBackup
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
sc config winmgmt start=auto
net start winmgmt
wmiprvse /regserver
Данный набор команд полностью пересоздаст хранилище WMI, сохранив старую копию в папке RepBackup. После окончания работы скрипта компьютер нужно перезагрузить.
После полного пересоздания репозитория WMI мне наконец-то удалось запустить и успешно провести активацию установленного офисного пакета. Хочу заметить, что при просмотре содержимого папки C:\Windows\System32\Wbem\Repository в программе Total Commander я видел лишь пустую папку даже при включенном в программе отображении всех скрытых и системных файлов. Из-за этого я поначалу решил, что попытки пересоздать репозиторий ни к чему не привели. Однако оказалось, что папка на самом деле не пуста, а “Проводник” содержимое папки прекрасно отображает.
