Начиная с Windows Server 2012 компания Microsoft изменила процедуру сжатия (compact) файлов виртуальных жестких дисков (vhdx) - перед сжатием такого файла нужно вначале присоединить (mount) его к системе в режиме "Только чтение" (Read-only), а потом уже выполнять процедуру сжатия. Затем файл нужно отсоединить (dismount).
Присоединить и отсоединить vhdx-файл можно как с помощью оснастки "Управление дисками" (Disk Management), так и с помощью PowerShell.
Присоединяем vhdx:
Ставим галку "Read-only" (Только чтение):
Сжимаем vhdx используя Edit Disk в консоли Hyper-V:
Отсоединяем vhdx с помощью оснастки "Управление дисками":
Для PowerShell набор команд будет выглядеть следующим образом (запускать PowrerShell нужно с повышением):
В случае, если на сервере не установлены Службы удаленных рабочих столов, сертификат RDP можно изменить следующим образом:
1) Поместить сертификат в хранилище сертификатов локального компьютера в Личное:
2) Открыть сертификат, найти в свойствах его Отпечаток (Thumbprint), скопировать его, например, в Блокнот и удалить пробелы. Должно получиться что-то вроде 579a301318c5664f3b2bff0b88bf73d8bd2464dd.
3) Запустить PowerShell с правами администратора и выполнить следующие команды:
После перенастройки размещения CRL в Центре сертификации и перевыпуска сертификатов сервера перестала запускаться Панель мониторинга (Dashboard) роли Essentials Experience в Windows Server 2012 R2. При этом в Журнале приложений фиксировались следующие ошибки:
Event ID: 1026
Приложение: Dashboard.exe
Версия платформы: v4.0.30319
Описание. Процесс был завершен из-за необработанного исключения.
Сведения об исключении: Microsoft.WindowsServerSolutions.Common.ProviderFramework.ProviderException
Event ID: 1000
Источник: Application Error
Имя сбойного приложения: Dashboard.exe, версия: 6.3.9600.17393, метка времени: 0x54333ee9
Имя сбойного модуля: KERNELBASE.dll, версия: 6.3.9600.18007, метка времени: 0x55c4c341
Код исключения: 0xe0434352
Смещение ошибки: 0x000000000000871c
Идентификатор сбойного процесса: 0x6ec
Время запуска сбойного приложения: 0x01d15b3d5c8cdd17
Путь сбойного приложения: C:\Windows\system32\Essentials\Dashboard.exe
Путь сбойного модуля: C:\Windows\system32\KERNELBASE.dll
А в логе Панели мониторинга (C:\ProgramData\Microsoft\Windows Server\Logs\Dashboard.log) содержалось множество подобных сообщений:
[6636] 160130.223341.2577: PluginManager: Unable to retrieve digital certificate for C:\Windows\System32\Essentials\HEAddin.dll: Cannot find the requested object.
[6636] 160130.223341.2734: PluginManager: Unable to retrieve digital certificate for C:\Windows\System32\Essentials\OIMAddin.dll: Cannot find the requested object.
[6636] 160130.223341.2734: PluginManager: Unable to retrieve digital certificate for C:\Windows\System32\Essentials\GroupUIAddin.dll: Cannot find the requested object.
Для устранения проблемы необходимо запустить PowerShell с правами администратора и выполнить следующую команду:
Add-WssLocalMachineCert
Если выполнение команды завершится с ошибкой, необходимо перезагрузить сервер и снова запустить ее.
Причиной ошибки отправки уведомления по электронной почте по квотам на папки или диски службой File Server Resource Manager может быть то, что у пользователя, который превысил квоту, в учетной записи в AD отсутствует e-mail. При этом в журнале сервера генерируется событие:
SRMSVC Event ID 12306, Error-specific details:
Error: IFsrmEmailExternal::SendMail, 0x8004531c, The parameter 'addresses' cannot be an empty string.
Parameter name: addresses
В частности, при просмотре деталей события можно обнаружить, что квоту превышает учетная запись NT AUTHORITY\SYSTEM или подобная:
У этих учеток нет адреса электронной почты, поэтому отправка не удается и генерируется сообщение ошибке. Если уведомление пользователей не требуется, то для решения проблемы его можно просто отключить, оставив только администраторов.
В Microsoft Windows Server 2012 и Windows 8 отсутствует возможность изменять тип сетевого подключения через Центр управления сетями и общим доступом (Network and Sharing Center). Если вам нужно изменить тип сети, это можно сделать следующими способами:
1. С помощью изменения в реестре:
Запустите regedit, найдите ключ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles. Этот ключ будет содержать профили сетей вида {93BCDFC1-5C66-420A-A786-85AFBCE1D5E8}, в фигурных скобках может быть любой другой номер - найдите среди них вашу сеть по ключу ProfileName (её имя отображается Центре управления сетями) и измените значение ключа Category в соответствии с тем типом сети, который вам нужен:
0 - Общественная сеть (Public Network)
1 - Частная сеть (Private Network)
2 - Доменная сеть (Domain Network)
2. С помощью изменения локальных политик безопасности:
Запустите оснастку Локальная политика безопасности (Local Security Policy). Это можно сделать в Панели управления, далее Система и безопасность -> Администрирование, либо просто выполнив в командной строке secpol.msc. Далее в левой части оснастки выбираете Политики диспетчера списка сетей (Network List Manager Policies), в результате справа отобразится список сетей. Найдите среди них вашу сеть по имени, которое отображается в Центре управления сетями, кликните на ней правой кнопкой мыши и зайдите в Свойства (Properties). Далее в закладке Имя сети (Network name) можно изменить соответственно имя сети, а в закладке Сетевое расположение (Network Location) - тип сети. Также можно изменить иконку сети. Если сервер или компьютер включены в домен, изменить тип сети на другой невозможно.
Иногда требуется изменить ключ продукта в Windows 8 и Windows Server 2012, однако "кнопки" для изменения ключа в этих ОС нет, в отличие от предыдущих версий. Для изменения ключа запустите командную строку от имени администратора и используйте следующую команду:
slmgr -ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
где XXXXX-XXXXX-XXXXX-XXXXX-XXXXX - ключ продукта.
По умолчанию сервер WSUS 3.0, установленный на сервере с операционной системой Windows Server 2008 R2 и ниже, не поддерживает обновление клиентов с Windows 8 и Windows Server 2012. При попытке вручную запустить обновление на этих операционных системах выдается ошибка Центра обновления с кодом 800b0001. Для того, чтобы WSUS мог обслуживать клиентов с Windows 8 и Windows Server 2012, необходимо установить следующее обновление: http://support.microsoft.com/kb/2734608 Однако, установка этого обновления зачастую завершается неудачно и приводит к неработоспособности WSUS, о чем можно найти много обсуждений в Интернете. В моей практике было два случая, в которых обновление не устанавливалось. В первом случае это было по причине того, что учетная запись, из-под которой я устанавливал это обновление, не обладала правами администратора на базу данных WSUS, которая располагалась на отдельном SQL-сервере (об этом несколько туманно, но упоминается в разделе "Известные проблемы..." в ссылке на обновление, на что я не обратил внимания). На время установки обновления я предоставил права sysadmin на сервере SQL для учетки, из-под которой я устанавливал обновление, и оно установилось без проблем, работоспособность WSUS восстановилась после удачной установки обновления. Во втором случае база данных WSUS хранилась в Windows Internal Database и установить обновление помогла игра с ключом