Ошибка при in-place upgrade Windows Server

Привет!
Если в процессе обновления до новой редакции Windows Server вы столкнетесь с ошибкой «Windows could not configure one or more system  components»in-place upgrade error

а после отката система покажет ошибку 0xC1900101 — 0x30018error in-place upgrade

то знайте, что проблема скорее всего в одной из установленных программ. В моем случае это был Crypto Pro CSP. После ее удаления и перезагрузки запускаем обновление заново и ошибки уже не будет. Проверено.

Windows cannot find Microsoft Software License Terms

Если при in-place upgrade операционной системы Windows у вас возникла ошибка «Windows cannot find Microsoft Software License Terms» сразу после этапа выбора операционной системы. Проверьте файл C:\$Windows.~BT\Sources\Panther\setuperr.log (путь может отличаться) на наличие номера ошибки. В моем случае ошибка была с номером 0x060613. Мне помогло, то что нашел решение на сайте technet.microsoft.com, где посоветовали проверить политики безопасности а точнее политику «Manage auditing and security log» узкому кругу лиц, в группу которых не входила учетная запись, которая запускала установщик системы. Я поменял учетку на ту, что имеет более расширенные привилегии и установка прошла успешно.

Ошибка c event id 8194 в VSS

Если у вас после создания теневой копии в Windows Server 2016 возникла ошибка в логе Application «hr = 0x80070005 Access is denied» от источника VSS с Event ID 8194, то знайте, что это стандартная ошибка на свежеустановленной системе и чтобы ее решить надо зайти в настройки DCOM, набрав dcomcnfg и учетной записи Network Service предоставить право локального доступа. Как это сделать смотрите на скриншоте ниже.

После этого нужно перезапустить службу «Система событий COM+» или в английской редакции «COM+ Event System» и затем службу «Теневое копирование тома» или «Volume Shadow Copy» в английской редакции и после этого ошибка из логов пропадет при создании снапшота диска.

VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f]

При бекапе Veeam агентом физического сервера возникла ошибка:
Error: Failed to create snapshot: Backup job failed.
Cannot create a shadow copy of the volumes containing writer’s data.
VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].
Ошибка стала возникать после увеличение диска и перезагрузки сервера.
Команда vssadmin list writers выдавала ошибки подобные этим

Writer name: ‘WMI Writer’
Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
Writer Instance Id: {7ce8d4ce-3313-4b76-a3c8-254d83320432}
State: [7] Failed
Last error: Timed out

Writer name: ‘MSMQ Writer (MSMQ)’
Writer Id: {7e47b561-971a-46e6-96b9-696eeaa53b2a}
Writer Instance Id: {37a842aa-7da6-4564-af96-e82380de7be4}
State: [7] Failed
Last error: Timed out

Writer name: ‘IIS Config Writer’
Writer Id: {2a40fd15-dfca-4aa8-a654-1f8c654603f6}
Writer Instance Id: {09cbce07-9f96-41fb-9b85-0eed6a1f4432}
State: [7] Failed
Last error: Timed out

Writer name: ‘IIS Metabase Writer’
Writer Id: {59b1f0cf-90ef-465f-9609-6ca8b2938366}
Writer Instance Id: {31eaa04e-0da2-4cde-8dd4-28325a4039d2}
State: [7] Failed
Last error: Timed out

Как вариант, в интернете предлагается перезапустить соответствующие службы, в моем случае это Windows Management Instrumentation, Application Host Helper Service, IIS Admin Service, Message Queuing, но мне это не помогло. Тогда я сделал тестовый снапшот командой vssadmin Create Shadow /FOR=C: иvssadmin Create Shadow /FOR=D:  — они прошли успешно. 
После этого я перезапустил службу Volume Shadow Copy и ошибка при бекапе пропала!
Надеюсь эта статья вам поможет.

Конвертация диска из MBR в GPT (online, Windows)

Понадобилось сконвертировать диск более 2 Tb из MBR в GPT, на котором располагаются файловые шары.
Windows не хочет конвертировать такой диск на лету стандартными средствами оснастки управлениями дисками и утилитой diskpart, поэтому пришлось искать утилиту на стороне. Ею оказалась gptgen, которую можно скачать с SourceForge
Переносом данных при конвертировании онлайн заниматься не надо, что меня вполне устроило. И так план действий:
0. Делаем бекап диска, с которым будем проводить манипуляции (на всякий случай)
1. Запускаем в командной строке утилиту diskpart. Пишем команду list disk и смотрим какой номер диска, который нам нужен. Выходим из diskpart
2. Запускаем утилиту gptgen в командой строке. Она выдает список доступных ключей для запуска.
3. Запускаем команду gptgen -w \\.\physicaldriveX, где X-номер диска из пункта 1. Через несколько секунд появится сообщение, что все прошло успешно.
4. Перезагружаем сервер.
5. Проверяем, на месте ли все корневые папки на диске. В моем случае после конвертации все папки, которые были открыты на общий доступ, были отключены (зашарены). Пришлось их заново расшаривать. NTFS права на папки при этом не были затронуты.
6. Только после всех манипуляций я расширил диск в диспетчере дисков до размера превышающего 2 Tb. Все прошло успешно.

Недоступно RDP-подключение на Windows Server 2003

После установки родного от Microsoft iSCSI-инициатора на английский windows-сервер 2003R2 SE SP2 x64 возникла проблема — неожиданно пропал доступ к серверу по RDP. Перезагрузка сервера не помогала. Включение/выключение удаленного доступа также ничего не давало. В реестре все настройки были выставлены верно, но при этом netstat -ant | findstr 3389 ничего не выдавал. Выяснилось, что не установлено обновление KB948496, которое в том числе решает проблему с удаленным рабочим столом. После установки патча и перезагрузки сервера проблема была решена.

Системная служба заняла всю свободную оперативную память

Возникла проблема: на двух серверах Windows Server 2008R2 SP1, на которых давно не ставили обновления и которые не перезагружались больше года, кончилась свободная оперативная память на сервере. При беглом взгляде было обнаружено, что проблема вроде бы как в системных службах, в частности в службе «Установщик модулей Windows» (aka TrustedInstaller). После ее перезапуска проблема не устранилась, тут же другая системная служба заняла всю доступную оперативную память. И тут пришла идея проверить количество дескрипторов, занятых процессами..

Сразу стало понятно в чем источник проблемы. Перезапуск службы «Digi Anywhere» инициировал активную работу служб, которые заняли оперативную память и через 20-30 секунд вместо 4 ГБ занятой памяти осталось только 1 ГБ. Проблема бесследно исчезла. Так что почаще проверяйте количество дескрипторов, использующимися вашими процессами, возможно проблема в них.

Сбор статистики с принт-сервера на Windows.


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

$date = get-date -format dd-MM-yyyy
$number = get-counter "\Очередь печати(_total)\Всего напечатано страниц" | Foreach-Object {$_.CounterSamples[0].CookedValue}
Convertto-html -title "Статистика печати" -PreContent "Количество распечатанных листов за $date : <b>$number</b>" >> C:\counter_print_pages.html

Всё, что он делает — это создает html файл в корне диска C:, в котором записывается информация из счетчика очереди печати со всех принтеров.

Чтобы этот скрипт выполнялся каждый день и заносил каждый раз новую информацию, нужно в «Планировщике задач» создать расписание, где в 23:59 будет выполняться данный выше кусок кода. Далее, чтобы статистика за день обнулилась, а также для того, чтобы на сервере печати очищались от заданий очереди на печать, в «Планировщик задач» добавить на выполнение в 0:00 еще один скрипт:

net stop "spooler"
del /S /Q c:\windows\system32\Spool\Printers\*
net start "spooler"

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

Настройка аудита запуска/остановки службы в Windows

Столкнулся с такой задачей: требовалось знать кто остановил критически важную службу на Windows-сервере. Как оказалось аудит этого события настраивается немного по-другому, в отличии, например, от файлового сервера. Что для этого требуется:

1) для начала скажу, что нельзя настроить аудит сразу всех служб — нужно выбрать конкретные службы для их аудита. Узнаем короткое имя службы, например, через команду PS get-service и в столбце «Name» оно будет отображено

2) в cmd выполняем команду sc sdshow [короткое имя службы]. Выведется строка примерно такого вида D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU). Скопируйте ее в блокнот и в конце добавьте строку S:(AU;SAFA;RPWPDT;;;WD). Буква «D» в начале строки означает начало списка доступа DACL, а буква «S» — список доступа SACL, который используется при логировании. Если выводимая строка в команде «sc sdshow» уже будет содержать SACL, то удаляем ее и добавляем ту, которая указана выше.

3) выполняем в cmd команду sc sdset [короткое имя службы][получившаяся новая строка]. После этого должна появиться строка [SC] SetServiceObjectSecurity: успех


4) командой auditpol /get /category:* проверяем какой аудит включен в системе. Нам необходимо, чтобы был включен аудит для подкатегорий «Другие события доступа к объекту» и «Работа с дескриптором». В английской Windows они соответственно называются «Other Object Access Events» и  «Handle Manipulation». Если аудит не настроен, то делаем это через групповые политики, если компьютер в домене или через команды auditpol /set /subcategory:"Другие события доступа к объекту" /success:enable /failure:disable и  auditpol /set /subcategory:"Работа с дескриптором" /success:enable /failure:disable, если компьютер не в домене.

5) фильтруем журнал безопасности Windows по коду события «4656» и можем видеть событие в журнале


Аудит настроен.