Занимаясь миграцией серверов приложений с операционной системы Windows Server 2008 R2 на Windows Server 2012 было замечено, что при попытке запуска Службы обнаружения интерактивных служб (Interactive Services Detection) на новой ОС возникает ошибка «Error 1: Incorrect function» В разных инфраструктурах могут до сих пор встречаться устаревшие приложения, которые пытаются использовать так называемую «нулевую сессию». Например у нас есть достаточно старое приложение “Эффект Офис” версии 2.8, где разработчики решили вопрос с автозапуском именно таким образом. Конечно, этому приложению не важно, запущена служба обнаружения интерактивных служб или нет и оно вполне сможет работать в новой системе, однако может возникнуть ситуация когда графический интерфейс старого приложения может быть доступен только в «нулевой сессии» и поэтому запуск выше-обозначенной системной службы просто необходим. Для разрешения проблемы необходимо изменить значение параметра NoInteractiveServices c 1 на 0 в ключе реестра HKLM\SYSTEM\CurrentControlSet\Control\Windows После чего нам удастся запустить службу и появиться предложение входа в режим эмуляции нулевой сессии для доступа к графическому интерфейсу нашего устаревшего приложения… Решение найдено здесь - Unable to start Interactive Services Detection service in Windows 2012
↧
Служба обнаружения интерактивных служб в Windows Server 2012
↧
Массовая замена драйвера HP Universal Print Driver на сервере печати с помощью PowerShell
Имея в инфраструктуре сервер печати, рано или поздно встанет вопрос о замене драйверов на более новую версию для всех принтеров. Конечно, если принтеров немного, то автоматизировать процесс замены драйверов может и нет необходимости, а если их к примеру сотня и более? В этой заметке мы рассмотрим замену драйвера печати на сервере печати c Windows Server 2012 на примере универсального драйвера печати – HP Universal Print Driver (UPD). Каждый, кто хотя бы раз устанавливал драйвера для принтеров HP UPD вставал перед выбором: На самом деле, два предложенных драйвера совершенно одинаковы, различие только в имени. Разработчики сделали две версии одного драйвера не просто так. Если выбрать первый вариант «HP Universal Printing PCL 5«, при первой установке драйвер будет добавлен в систему с этим именем, а при обновлениях он попросту будет заменяться более новой версией. Но этот способ имеет один существенный недостаток. Может возникнуть ситуация, когда старые модели принтеров не будут работать с новой версией UPD, например из-за бага или снятия модели с поддержки.Если выбрать второй вариант «HP Universal Printing PCL 5 (<Номер версии>)«, то при последующем обновлении новая версия драйвера будет добавляться в систему, сохраняя при этом и старую версию драйвера, т.е. получится некая база драйверов одного вендора с разбивкой по версиям. При добавлении драйвера новой версии на сервер печати вторым способом может потребоваться замена драйвера на новый в свойствах большого количества принтеров на сервере печати. Чтобы избавиться от рукопашных манипуляций используем PowerShell: gwmi win32_printer -filter 'drivername="HP Universal Printing PCL 5 (v5.5.0)"' | ForEach-Object{ $_.DriverName='HP Universal Printing PCL 5 (v5.6.5)' $_.Put() } Общий смыл скрипта -ищем все принтеры с установленным драйвером «HP Universal Printing PCL 5 (v5.5.0)» и меняем его на «HP Universal Printing PCL 5 (v5.6.5)«. Источник: Powershell script to get list of printer on a Windows 2008 R2 Print Server which are using «Xerox Global Print Driver PCL6″ and change
↧
↧
App-V 5 for RDS —Разворачиваем инфраструктуру повышенной доступности
С выходом новой версии Microsoft Application Virtualization (App-V) 5.0 появился ряд улучшений и нововведений в этой технологии, которые всерьёз заставили задуматься об обновлении, особенно учитывая уже «набившие оскомину» проблемы с используемой нами до этого момента версии 4.6, в частности описанные в заметке SC 2012 Orchestrator — Режим обслуживания SCOM по расписанию. Планируя внедрение новой версии App-V, после ознакомления с материалами TechNet Library — Planning for High Availability with App-V 5.0 и KB2780309 — How to provide fault tolerance and load balancing in Microsoft App-V v5 возникло желание создать такую архитектуру, при которой серверные компоненты App-V имели бы дополнительную отказоустойчивость. Далее мы рассмотрим пошагово процесс создания такой конфигурации… Среда исполнения В рассматриваемом примере мы построим двух-узловой NLB-кластер для серверных ролей App-V 5.0 — Management Server, Publishing Server и Reporting Server. Узлы кластера – виртуальные сервера одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2012 Standard EN. Каждый из виртуальных серверов создается с двумя сетевыми интерфейсами, настройка которых будет рассмотрена далее. Серверам присвоены имена – KOM-AD01-APPV01 и KOM-AD01-APPV02 Создаваемый NLB-кластер будет иметь виртуальное имя KOM-AD01-APPVCL. Это имя будет использоваться в качестве точки входа для всех серверных ролей App-V 5.0 Базы данных серверных ролей App-V 5.0 Management Server и Reporting Server будут расположены на отдельном уже действующем кластере SQL Server 2012 c именем KOM-SQLCL Централизованное хранилище App-V пакетов будет расположено на отдельном уже действующем файловом кластере с именем KOM-FSCL Дополнительно будет развернута виртуальная машина с именем KOM-AD01-APPV03 для виртуализации приложений – создания пакетов App-V с помощью App-V Sequencer. Упрощённая схема разворачиваемой инфраструктуры App-V 5.0 в нашем случае будет выглядеть так: Адреса точек доступа к соответствующим службам App-V будут следующими: Management Service — http://KOM-APPVCL.holding.com:8080/Console.htmlReporting Service — http://KOM-APPVCL.holding.com:8081Publishing Service — http://KOM-APPVCL.holding.com:8082 Основными клиентами серверных служб App-V в нашем случае будут выступать сервера служб удалённых рабочих столов
↧
Remote Desktop Services –Строим отказоустойчивую ферму RD Connection Broker на базе Windows Server 2012
Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом: - Среда исполнения- Подготавливаем виртуальные сервера- Создаём кластер NLB- Подготавливаем SQL Server- Устанавливаем роли Remote Desktop Services- Создаём высоко-доступный RD Connection Broker - Добавляем сервера в высоко-доступный RD Connection Broker- Добавляем на сервера роль RD Web Access- Создаём коллекцию сеансов – Session Collection- Настраиваем цифровые сертификаты- Настраиваем веб-узлы RD Web Access- Настраиваем Roaming User Profiles и Folder Redirection- Публикуем приложения RemoteApp- Устанавливаем языковой пакет- Настраиваем перенаправление печати Среда исполнения В рассматриваемом примере мы будем строить ферму RDCB из 5 виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На всех виртуальных серверах устанавливается Windows Server 2012 Standard EN. Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее. Серверам присвоены имена – KOM-AD01-RDS21 , KOM-AD01-RDS22 , KOM-AD01-RDS23 , KOM-AD01-RDS24 , KOM-AD01-RDS25 Создаваемый в процессе описания высоко-доступный экземпляр RD Connection Broker а также NLB-кластер RD Web Access будут использовать общее виртуальное имя KOM-AD01-RDSNLB. База данных высоко-доступного экземпляра RDCB будет расположена на отдельном кластере SQL Server c именем KOM-SQLCL С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть следующим образом: Подготавливаем виртуальные сервера Итак, у каждого виртуального сервера создадим по 2 сетевых
↧
High Availability RD Connection Broker на базе Windows Server 2012–выявленная закономерность в конфигурации с более чем 3 серверами
В процессе тестирования конфигурации описанной в предыдущей статье выявлена странная закономерность в поведении работы высоко-доступного экземпляра RD Connection Broker (RDCB). Обнаружено, что если роль RDCB (в режиме High Availability) добавлена в развёртывании RDS более чем на три сервера (в нашем случае — на пяти серверах), то адекватно работают с общей базой данных RDCB не более трёх серверов, на которые раньше всего была развёрнута эта роль. Чтобы стало понятней, о чём я говорю, опишу ситуацию, когда завершив все настройки развёртывания RDS мы начали тестировать работу механизма высокой доступности RDCB, эмитируя поочерёдную недоступность серверов. Как известно, в ферме RDCB всегда какой-то один сервер выступает в роли активного сервера управления. После того, как активный сервер управления становится недоступен, служба RDCB назначает эту роль другому доступному серверу RDCB. Было решено протестировать механизм передачи этой роли от одного сервера к другому. Сначала были выключены все сервера, а затем мы стали по одному включать каждый сервер, чтобы убедиться в том, что включённый сервер, находясь в «гордом одиночестве», успешно захватывает роль активного сервера управления, успешно принимает и делает перенаправление клиентских подключений. Начали в том же порядке что и выполняли добавление серверов в High Availability RDCB, то есть первым включили KOM-AD01-RDS21… Первые тесты порадовали и показали, что сервер выполняет все свои функции так, как мы от него этого ожидаем. Затем таким же образом проверили сервера KOM-AD01-RDS22 и KOM-AD01-RDS23…всё удачно. Однако при попытке завести в одиночестве KOM-AD01-RDS24 или KOM-AD01-RDS25 получили полный облом – RDCB не мог выполнить перенаправление клиентов, хотя роль активного сервера управления вроде как захватывалась сервером, по крайней мере об это свидетельствовали данные консоли Server Manager и результат выполнения вышеприведённого PS-командлета. Эти два сервера не перенаправляли клиентов даже если были включены оба… Как только мы включали любой из первых трёх серверов – всё начинало работать как ни в чём не бывало… Дальше было много экспериментов в попытках
↧
↧
Remote Desktop Services —Настраиваем пользовательский интерфейс на серверах RD Session Host
Серверы сеансов Remote Desktop Services (RDS) — это многопользовательские среды, для которых, как правило, требуется максимально жёсткая настройка пользовательского окружения. Говоря простым языком, – чем у пользователей меньше отвлекающих «буцок», не имеющих прямого отношения к выполняемым ими задачам, – тем лучше и для администратора, и для них самих в конечном итоге. Здесь мы рассмотрим пример настройки некоторых элементов пользовательского интерфейса по следующим позициям:- Отключаем отображение Favorites, Libraries и Network- Скрываем излишние папки в профиле пользователя- Отключаем мастер добавления сетевых расположений- Скрываем локальные диски сервера- Сворачиваем ленту при запуске Windows Explorer- Включаем отображение расширений файлов- Ограничиваем набор апплетов в Панели управления- Настраиваем панель задач (TaskBar)- Заменяем картинку пользователя по умолчанию- Настраиваем стартовый экран Windows- Создаём групповую политику переопределений для администраторов Отключаем отображение Favorites, Libraries и Network Для того чтобы скрыть элементы Favorites, Libraries и Network из панели навигации Windows Explorer нужно изменить значения соответствующих трёх параметров системного реестра. Отключить отображение Favorites:HKEY_CLASSES_ROOT\CLSID\{323CA680-C24D-4099-B94D-446DD2D7249E}\ShellFolderПоменять значение параметра Attributes с a0900100 на a9400100 Отключить отображение Libraries:HKEY_CLASSES_ROOT\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}\ShellFolderПоменять значение параметра Attributes с b080010d на b090010d Отключить отображение Network:HKEY_CLASSES_ROOT\CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolderПоменять значение параметра Attributes с b0040064 на b0940064 Выполнить изменения этих параметров можно например с помощью Group Policy Preferences (GPP), создав в групповой политике применяемой к серверам RDS соответствующие настройки GPP в разделе Computer Configuration\Preferences\Windows Settings\Registry При желании можно для применения данного ключа реестра настроить Item-level targeting (ITL) на семейство ОС – Windows Server 2012 Family. Проблема с применением перечисленных параметров реестра заключается в лишь том, что по умолчанию к родительским ключам этих параметров для пользователя SYSTEM предоставлен доступ только на чтение, и без добавления права на редактирование наши параметры GPP применены не будут. Учитывая то, что владельцем этих ключей является SYSTEM, нам потребуется от имени этого пользователя запустить редактор реестра и добавить права на редактирование. Запустить редактор реестра от имени системы (SYSTEM) можно, например, с помощью утилиты PsExec.exe из состава
↧
Публикация приложения RemoteApp на в ферме серверов RDS (Windows Server 2012) на примере КонсультантПлюс
В Windows Server 2012 консоль Server Manager работает таким образом, что при попытке публикации приложения RemoteApp, для которого выбран исполняемый файл расположенный на общем сетевом ресурсе, возникает грозное уведомление о том, что мы можем выбирать исполняемые файлы расположенные только на каком-то конкретном сервере RD Session Host (RDSH)… На самом деле это не так, и мы вполне можем выполнить публикацию исполняемого файла расположенного в сети с помощью командлетов PowerShell из модуля RemoteDesktop… Рассмотрим публикацию приложения RemoteApp с помощью PowerShell на примере КонсультантПлюс. Но сначала сделаем небольшое отступление в сторону описания особенностей использования КонсультантПлюс в распределённой многопользовательской среде. В нашем примере исполняемый файл этого приложения (cons.exe) расположен вместе с файлами правовых баз данных в общем сетевом каталоге. Нам нужно опубликовать это приложение для пользователей фермы RDS состоящей из нескольких серверов. В ферме RDS используется механизм перемещаемых профилей Roaming User Profiles. Наше приложение для сохранения пользовательских настроек использует специальные служебные каталоги \ConsUserData. Поэтому, учитывая нашу специфику перемещаемых профилей, создадим специальный ярлык (*.lnk) для запуска КонсультантПлюс в ферме RDS в режиме RemoteApp. Дадим ярлыку имя, например CONS_RemoteApp.lnk и разместим его в той-же сетевой папке, где расположен сам исполняемый файл приложения. В качестве рабочей папки обязательно укажем значение ссылающееся на переменную %AppData% которая указывает на часть пользовательского профиля, которая обрабатывается механизмом Roaming User Profiles (это позволит нам добиться того, что при входе на любой сервер фермы RDS, пользователь будет иметь одни и те же настройки в КонсультантПлюс) Так как с свойствах ярлыка мы указали каталог (%AppData%\ConsUserData), которого не существует для вновь создаваемых профилей пользователей, нам придётся позаботиться о его создании, например с помощью Group Policy Preferences (GPP). Создадим в групповой политике применяемой к пользователям на серверах RDS соответствующую настройку GPP в разделе User Configuration\Preferences\Windows Settings\Registry Теперь всё что нам остаётся сделать, это опубликовать созданный ярлык с помощью PowerShell: Import-Module RemoteDesktop New-RDRemoteApp -Alias ConsultantPlus ` -DisplayName
↧
Windows Server 2012 R2 —Разворачиваем KMS для Windows и Office
Начиная внедрять в инфраструктуру новые системы Windows 8.1 и Windows Server 2012 R2, одна из первых вещей, о которых стоит задуматься – это активация новых систем, и поэтому первый сервер, который мы разворачиваем на Windows Server 2012 R2, будет у нас выступать в качестве сервера Key Management Service (KMS). В нашем случае, текущим сервером KMS является сервер на базе Windows Server 2012. Этот сервер настроен на активацию систем до уровня Windows 8/Windows Server 2012, а также обеспечивает активацию Office 2010/2013. Перед нами стоит задача перенести функционал KMS на новый сервере на базе Windows Server 2012 R2. Базовые приёмы работы c KMS были описаны ранее в заметке Основные приемы работы с Key Management Service (KMS) на Windows 7 и Windows Server 2008 R2 и для новой версии Windows эти приёмы остаются в силе. В документе TechNet Library — Volume Activation — Appendix A: KMS Client Setup Keys расширена информация о ключах GVLK, которые нужны для преобразования клиентов MAK/Retail в KMS. Выдержка из этого документа относительно новых систем:Windows Server 2012 R2 and Windows 8.1 Client Setup Keys Operating system edition KMS Client Setup Key Windows 8.1 Professional GCRJD-8NW9H-F2CDX-CCM8D-9D6T9 Windows 8.1 Professional N HMCNV-VVBFX-7HMBH-CTY9B-B4FXY Windows 8.1 Enterprise MHF9N-XY6XB-WVXMC-BTDCT-MKKG7 Windows 8.1 Enterprise N TT4HM-HN7YT-62K67-RGRQJ-JFFXW Windows Server 2012 R2 Server Standard D2N9P-3P6X9-2R39C-7RTCD-MDVJX Windows Server 2012 R2 Datacenter W3GGN-FT8W3-Y4M27-J84CP-Q3VJ9 Windows Server 2012 R2 Essentials KNC87-3J2TX-XB4WP-VCPJV-M4FWM Windows Server 2012 and Windows 8 Client Setup Keys Operating system edition KMS Client Setup Key Windows 8 Professional NG4HW-VH26C-733KW-K6F98-J8CK4 Windows 8 Professional N XCVCF-2NXM9-723PB-MHCB7-2RYQQ Windows 8 Enterprise 32JNW-9KQ84-P47T8-D8GGY-CWCK7 Windows 8 Enterprise N JMNMF-RHW7P-DMY6X-RF3DR-X2BQT Windows Server 2012 BN3D2-R7TKB-3YPBD-8DRP2-27GG4 Windows Server 2012 N 8N2M2-HWPGY-7PGT9-HGDD8-GVGGY Windows Server 2012 Single Language 2WN2H-YGCQR-KFX6K-CD6TF-84YXQ Windows Server 2012 Country Specific 4K36P-JN4VD-GDC6V-KDT89-DYFKP Windows Server 2012 Server Standard XC9B7-NBPP2-83J2H-RHMBY-92BT4 Windows Server 2012 MultiPoint Standard HM7DN-YVMH3-46JC3-XYTG7-CYQJJ Windows Server 2012 MultiPoint Premium XNH6W-2V9GX-RGJ4K-Y8X6F-QGJ2G Windows Server 2012 Datacenter 48HP8-DN98B-MYWDG-T2DCC-8W83P При установке нового
↧
Захват и анализ сетевого трафика в Windows Server 2008 R2 /2012
В системах Windows для захвата и последующего анализа сетевого трафика многие из нас пользуются такими известными инструментами как Network Monitor или Wireshark. Захват трафика через эти инструменты в наблюдаемой системе предполагает установку дополнительных компонент, выстраивающихся в функции сетевого обмена. Начиная с Windows 7 / Windows Server 2008 R2 у нас появилась возможность выполнять захват трафика встроенными в систему средствами, то есть мы можем выполнить захват трафика на интересующей нас системе не выполняя непосредственную установку дополнительных программных средств, а полученный в результате захвата файл сетевого дампа в дальнейшем анализировать на той системе где установлены соответствующие средства анализа, например на рабочей станции администратора с установленным Network Monitor. Для того, чтобы активировать захват сетевого трафика проходящего через все сетевые интерфейсы на интересующей нас системе выполним команду с правами Администратора: Netsh trace start scenario=NetConnection capture=yes report=yes persistent=no maxsize=1024 correlation=yes traceFile=C:\Logs\NetTrace.etl При этом каталог, который мы указываем в качестве сохранения файла захвата должен существовать в файловой системе, иначе мы получим ошибку ‘The system cannot find the path specified‘. Если обследуемая система имеет несколько сетевых интерфейсов и нас интересует трафик только на определённом интерфейсе, то синтаксис команды будет выглядеть примерно так: Netsh trace start scenario=NetConnection capture=yes ipv4.address=192.168.0.100 report=yes persistent=no maxsize=1024 correlation=yes traceFile=C:\Logs\NetTrace.etl Захват трафика запущен и после того, как мы выполнили необходимые манипуляции, например воспроизвели изучаемую проблему из-за которой мы и решили анализировать трафик, останавливаем захват трафика командой: Netsh trace stop В результате будет сгенерирован ETL файл а также CAB архив содержащий дополнительные данные, которые могут потребоваться для анализа сетевых проблем. Полученный ETL файл копируем на рабочую станцию Администратора, запускаем Network Monitor и открываем файл из меню File > Open > Capture Загруженные данные будут разложены на фреймы с малопонятной структурой, да ещё и с предупреждением в описании практически каждого фрейма типа ‘Windows stub parser: Requires full Common parsers. See the «How Do I Change Parser
↧
↧
Remote Desktop Services —Отправка сообщения всем пользователям фермы RDS
В Windows Server 2012 в консоли Server Manager в разделе управления настройками ролей Remote Desktop Services при выборе определённой Коллекции нам доступно окно управления клиентскими подключениями к серверам нашей фермы RDS, однако по какой-то странной причине разработчики этой самой консоли посчитали что функцию выбора более одного пользователя для отправки сообщения реализовывать не нужно, …наверно чтобы администраторам жизнь мёдом не казалась.. Поэтому в момент возникновения такой необходимости пришлось на скорую руку слепить небольшой PowerShell скрипт (должен выполняться на любом из серверов фермы), который позволит выполнить массовую рассылку сообщения всем подключенным пользователям фермы. # $ConnectionBroker - Активный сервер RDCB. Если не указан, будет произведена попытка выявить его автоматически (для этого обязательно чтобы скрипт выполнялся на одном из серверов фермы RDS) # $SessionHostCollection – Имя RD-коллекции в которой нужно вывести сообщение. # $ConnectionBroker = "" $SessionHostCollection = "KOM-AD01-RDCOLL" $MessageTitle = "Сообщение от тех.поддержки SAP" $MessageText = "Уважаемые коллеги! В связи с проведением работ по расчету зарплаты - просьба в программе SAP Персонал с 11:00 до конца дня с табельными номерами не работать!" If ($ConnectionBroker -eq "") { $HAFarm = Get-RDConnectionBrokerHighAvailability $ConnectionBroker = $HAFarm.ActiveManagementServer } $Sessions = Get-RDUserSession -ConnectionBroker $ConnectionBroker -CollectionName $SessionHostCollection ForEach ($Session in $Sessions) { Send-RDUserMessage -HostServer $Session.ServerName -UnifiedSessionID $Session.UnifiedSessionID -MessageTitle $MessageTitle -MessageBody $MessageText } В результате все активные пользователи на всех серверах фермы RDS получат всплывающее сообщение которое трудно не заметить…
↧
Миграция сервера печати на Windows Server 2012 R2
В процессе перехода на новую серверную ОС Windows Server 2012 R2 добрались до серверов печати. Рассмотрим маленький пример миграции действующего сервера печати на базе Windows Server 2012 на новую версию ОС. Для миграции служб печати подразумевается 2 основных сценария: 1. Переустановка сервера с тем же имением;2. Переустановка сервера с другим имением и переподключение клиентов. Самый простой и на мой взгляд более правильный является первый вариант, который и будет рассмотрен в этой заметке. Второй вариант больше подходит для случаев когда необходимо объединить несколько серверов печати в один. Первым делом, необходимо экспортировать текущую конфигурацию сервера печати в файл для последующего развёртывания. Для этого откроем оснастку “Управление печатью” (printmanagement.msc), вызовем контекстное меню на узле сервера и выберем пункт экспорта принтеров в файл: Откроется диалоговое окно, которое после инициализации отобразит все возможные объекты для миграции, а именно: очереди печати, драйверы, обработчики и порты: Следующим шагом укажем каталог для сохранения файла. Расширение файла “.PrinterExport” подставляется автоматически. Мастер так же позволяет использовать UNC пути для указания каталога с файлом. В нашем нехитром примере миграция затронула 34 принтера и 32 драйвера, процесс занял примерно 10 минут. На выходе был получен файл “Print.PrinterExpotr”, 792 Мб в объёме. Любители консоли могут выполнить экспортирование с помощью командной строки, используя встроенную в систему утилиту PrintBrm.exe CD /d %WINDIR%\System32\spool\tools PrintBrm.exe -b -f C:\Temp\Print.PrinterExport Консольный процесс экспорта выглядит примерно следующим образом: Сохраняем файл экспорта на любое доступное сетевое расположение и переустанавливаем операционную систему. Важным критерием является то, что имя сервера после установки должно остаться прежним, в противном случае придётся переподключать клиентов. Для проверки работоспособности печати после миграции нужно подключить к своей рабочей станции принтер с сервера печати. После того, как новый сервер установлен и базово сконфигурирован, привычным для нас образом устанавливаем роль сервера печати через диспетчер серверов: И выберем необходимую службу развёртываемой роли, в нашем случае Print Server Альтернативно роль сервера печати можно
↧
Hyper-V-VMMS Event ID 14050 — Failed to register the service principal name ‘Hyper-V Replica Service’. Возвращаясь в к проблеме регистрации SPN в Windows Server 2012 R2
Ранее как-то я уже писал пост о проблеме c миграцией VM, с которой довелось столкнуться на свеже-установленном хосте Hyper-V на Windows Server 2012. Как я тогда предположил, корнем проблемы было поднятие роли Hyper-V до ввода в домен. Однако комментаторы меня заставили усомниться в этом предположении, более того, спустя некоторое время я заметил, что проблема регистрации SPN «всплыла» снова. То есть, даже не смотря на то, что нужные службе VMMS недостающие SPN для учетных записей проблемных хостов были прописаны в домене вручную, журнал Microsoft/Windows/Hyper-V-VMMS/Admin был переполнен регистрируемыми каждые 2 минуты десятками сотен однотипных ошибок: Log Name: Microsoft-Windows-Hyper-V-VMMS-AdminSource: Microsoft-Windows-Hyper-V-VMMSDate: 10.01.2014 11:50:42Event ID: 14050Task Category: NoneLevel: Error User: SYSTEMComputer: KOM-AD01-VM08.holding.comDescription:Failed to register the service principal name ‘Hyper-V Replica Service’. Log Name: Microsoft-Windows-Hyper-V-VMMS-AdminSource: Microsoft-Windows-Hyper-V-VMMSDate: 10.01.2014 11:50:42Event ID: 14050Task Category: NoneLevel: Error User: SYSTEMComputer: KOM-AD01-VM08.holding.comDescription:Failed to register the service principal name ‘Microsoft Virtual System Migration Service’. Log Name: Microsoft-Windows-Hyper-V-VMMS-AdminSource: Microsoft-Windows-Hyper-V-VMMSDate: 10.01.2014 11:50:42Event ID: 14050Task Category: NoneLevel: Error User: SYSTEMComputer: KOM-AD01-VM08.holding.comDescription:Failed to register the service principal name ‘Microsoft Virtual Console Service’. Поиски решения привели к статье KB2761899 — Hyper-V VMM service fails and Event ID 14050 is logged when dynamicportrange is changed in Windows Server 2012. Применительно к моей ситуации любопытной оказалась информация об одной из возможных причин: This problem may also occur if the NTDS port has been restricted to a specific port on your domain controllers. If this selected NTDS port is not within the default ranges, you must add this port by running the script in the «Resolution» section on every Hyper-V host. Тут же вспомнился тот факт, что ранее один из доменных администраторов, видимо руководствуясь статьёй KB224196 — Restricting Active Directory replication traffic and client RPC traffic to a specific port, применил ко всем контроллерам домена групповую политику в которой присутствовал скрипт изменения порта службы NTDS, в частности в параметрах реестра был
↧
Миграция сервера DHCP c Windows Server 2008 R2 на отказоустойчивую конфигурацию DHCP Failover из двух серверов на базе Windows Server 2012 R2
В процессе миграции серверных систем на Windows Server 2012 R2 дошли до служб DHCP и решили попробовать в действии новый механизм повышения доступности DHCP Failover появившийся еще в Windows Server 2012. Перед началом процедуры возьмём на заметку пару тезисов из документации по DHCP Failover: Для отработки отказа DHCP можно использовать не более двух DHCP-серверов Для правильной работы отработки отказа DHCP необходимо синхронизировать время на двух серверах в отношениях отработки отказа. Для синхронизации времени можно использовать протокол NTP или любой альтернативный механизм. Мастер настройки отработки отказа сравнивает текущее время на серверах, настроенных для отработки отказа. Если время на серверах отличается более чем на одну минуту, установка отработки отказа завершится с критической ошибкой, указывающей администратору на необходимость синхронизации времени на серверах. Последовательность выполняемых действий: 1. Устанавливаем роль DHCP Server на два сервера с Windows Server 2012 R2.2. Экспортируем данные действующего сервера DHCP с Windows Server 2008 R23. Импортируем все конфигурационные данные DHCP на первый сервер с Windows Server 2012 R24. Импортируем только серверную конфигурацию DHCP на второй сервер с Windows Server 2012 R2 5. Настраиваем DHCP Failover.6. Заключительные процедуры 1. Устанавливаем роль DHCP Server на два сервера с Windows Server 2012 R2 1.1. Устанавливаем роль DHCP Server на первый сервер (KOM-AD01-NS01) Выполним установку роли DHCP Server на первый сервер с помощью консоли Server Manager, где вызовем мастер добавления ролей в меню Manage > Add Roles and Features и на этапе выбора ролей отметим DHCP Server тут же нам будет предложено установить компоненты управления ролью из состава RSAT (консоль DHCP и PS-модуль для работы с DHCP) – соглашаемся с их добавлением. В конце процесса установки нам станет доступна ссылка пост-инсталляционной настройки роли – Complete DHCP configuration Мастер настройки выполняет две основные вещи – добавляет на сервер две локальные группы безопасности для управления ролью и выполняет авторизацию службы DHCP в домене Active Directory.
↧
↧
HP Smart Array P400i — Boot Logical Drive is configured but is Missing or Offline
После полной замены дисков на одном из серверов HP ProLiant DL360 G5 с RAID-контроллером HP Smart Array P400i нарвался на ситуацию, при которой пропала возможность установки ОС на вновь установленные диски. Программа установки Windows Server 2012 R2 при выборе зеркала из двух вновь установленных дисков заявила “Windows can’t be installed on this drive” При этом в процессе последующей перезагрузки в процессе инициализации RAID-контроллера отображалось сообщение, которое я изначально “проморгал”: “Boot Logical Drive is configured but is Missing or Offline” Вспомнилось, что на серверах этого типа есть несколько встроенных диагностических утилит, которые могут быть вызваны в процессе загрузки сервера через пункт “Press F10 key for System Maintenance Menu” Когда загрузится интерфейс System Maintenance Menu для дополнительной диагностики сервера можно выбрать пункт Diagnostic Utility… Затем выбрать тестирование загрузочного диска – Boot Disk Test… В моём случае результат был неутешительный… На форуме тех.поддержки HP можно найти совет, – войти в процессе загрузки сервера на этапе инициализации контроллера Smart Array по приглашению Press F8 to run option ROM Configuration for Arrays Utility и в главном меню утилиты выбрать загрузочный диск через пункт Select Boot Volume. Однако в моём случае такого пункта меню в этой утилите не оказалось На выручку в качестве решения проблемы пришла утилита HP Smart Storage Administrator (SSA), которая может быть загружена на сервере вне зависимости от наличия установленной ОС. На данный момент офлайн загрузчик этой утилиты можно скачать в виде образа ISO с сайта HP по ссылке HP Smart Storage Administrator. В моём случае используется последняя доступная на данный момент версия 1.60.17.0 (18 Feb 2014). Записываем полученный образ на DVD-диск (размер образа 961MB) и загружаем сервер с него. В основном меню программы выбираем интересующий нас контроллер, затем Configure Среди доступных конфигурационных действий должен быть пункт Set Bottable Logical Drive/Volume В моём случае, в открывшемся окне опции загрузки и для Primary и
↧
System Center 2012 R2 DPM & Windows Server Backup —Ошибка архивирования образа операционной системы Windows Server 2012 R2
Одной из главных повседневных задач инженера ИТ является архивирование и проверка целостности архивных данных. При использовании программного обеспечения (ПО) System Center 2012 R2 Operations Manager (SCOM) и Data Protection Manager (DPM) от Microsoft данный процесс упрощается. Для SCOM имеется DPM Management Pack (MP), который расположен на диске (образе) дистрибутива DPM в подкаталоге \SCDPM\ManagementPacks\. Также есть отдельный полезный MP Windows Server Backup (WSB), который можно скачать по ссылке с сайта Microsoft. При архивировании операционной системы (ОС) Windows Server 2012 R2 для целей Bare Metal Recovery на аппаратном обеспечении от HP (в моём случае это ProLiant BL460C Gen8) средствами DPM заметил интересную особенность. В консоли DPM и, соответственно, консоли SCOM от MP DPM ошибок или предупреждений не было, НО посмотрев в MP WSB увидел предупреждение. Т.к. архивация ОС происходит через встроенное ПО Windows WSB (которое необходимо предварительно установить), то сразу же решил посмотреть более подробную информацию локально на защищаемом сервере в WSB. К моему удивлению предупреждение говорило, о том, что архивирование завершено не полностью. На 98-99 % появлялась ошибка “The drive cannot find the sector requested”. Проверив необходимые требования к архивированию ОС (BMR) для DPM, решил попробовать найти подобную ошибку и решение на просторах интернета. Нашел очень похожую ошибку в форуме с темой “Server 2012 Server backups — «The drive cannot find the sector requested»”. Предлагаемое решение – уменьшение (сжатие) размера загрузочного диска и логического диска с ОС. После проверки стало понятно, что для решения проблемы достаточно выполнить сжатие (shrink) логического диска с ОС. В результате операция резервного копирования была выполнена успешно. Возможная причина – это установка ОС при помощи ПО HP Intelligent Provisioning версии 1.5. Есть вероятность того, что данный баг устранят в следующей версии. Проверяйте состояние архивов и всех с наступающей весной!
↧
System Center 2012 R2 Configuration Manager — Import failed as \\FS\Share\DriverSources\* is a Reparse Point that SMS does not support via downloads — 0×80004005
В очередном развёртывании System Center 2012 R2 Configuration Manager (SCCM) при попытке добавления драйвера, исходные файлы которого размещены на файловом кластере на Windows Server 2012 R2 (на томе с включенной дедупликацией файлов) в пакет драйверов получили ошибку… При этом на SCCM сервере в логе \\SCCMServer\SMS_<site code>\Logs\DriverCatalog.log были зафиксированы ошибки обработки исходных файлов добавляемого драйвера, говорящие о невозможности обработать эти файлы CreateFromINF("\\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662", "HDXSRSL.INF") DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC) HashFile failed as \\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662\alcmtr.exe is a Reparse Point that SMS does not support via downloads, -1 DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC…) … Import failed as \\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662\* is a Reparse Point that SMS does not support via downloads. DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC) Failed to build driver content information for "\\holding.com\DriverSources\Audio\Realtek High Definition Audio Driver\6.0.1.6662". Code 0x80004005 DriverCatalog 18.03.2014 10:29:03 5052 (0x13BC) Судя по содержимому ошибок в данной ситуации SCCM не в состоянии обработать файлы расположенные на дисковом томе подверженном дедупликации. О том, что эта проблема имеет давние корни, свидетельствуют также записи типа Importing Drivers Fails in ConfigMgr 2007 Если мы посмотрим в свойства файлов и каталогов использующихся в данном случае в качестве исходных, то действительно можем увидеть то, что они обработаны механизмами дедупликации, так как их номинальный размер отличается в большую сторону от фактически занимаемого места на диске. Чтобы обойти вышеописанную проблему с SCCM не отключая при этом дедупликацию на весь том файлового сервера, настроим каталоги исходных файлов драйверов SCCM как исключаемые из механизмов дедупликации. Через графический интерфейс сделать это можно выбрав в Server Manager\File and Storage Services\Volumes для дискового тома в контекстном меню пункт Configure Data Deduplication и в открывшемся окне настроек дедупликации тома добавить исключаемый каталог… Изменить список исключаемых каталогов можно также через командлеты PowerShell: Import-Module ServerManager Set-DedupVolume -Volume S: -ExcludeFolder 'S:\system-center-cm\driversources' Мы создали исключение и теперь все
↧
System Center 2012 R2 Operations Manager —Отключаем монитор Logical Disk Fragmentation Level Monitor для разделов DPM Replica и DiffArea Volumes
Пакет управления/базового мониторинга (Management Pack) ОС Windows Server для System Center 2012 R2 Operations Manager (SCOM) в конфигурации по умолчанию выполняет обнаружение и мониторинг состояния фрагментации всех логических дисков системы. Функциональность это безусловно полезная, но есть ситуации, когда нужно отключить такого рода мониторинг (и соответственно его оповещения) для определённых систем, как например серверы System Center Data Protection Manager (DPM), у которых может быть множество логических разделов диска, создаваемых механизмами DPM и “живущих по своим законам”. Для изменения параметров мониторинга уровня фрагментации дисков можно создать переопределения (Override) для соответствующих мониторов и правил SCOM. Пример, того как можно изменить граничное значение процента фрагментации, превышение которого считается отклонением от нормы, описан “с картинками” в заметке Kevin Holman’s System Center Blog — New Base OS MP 6.0.6667.0 adds file fragmentation monitor to all Logical Disks. Чтобы увеличить допустимый процент фрагментации с значения по умолчанию (10%), например на 20%, нужно создать Override для монитора Logical Disk Fragmentation Level. При этом помимо изменения параметра File Percent Fragmentation Threshold нужно выключить параметр Use OS Recommendation В данном примере Override нацелен на весь класс Windows Server 2012 Logical Disk. В нашей ситуации для того, чтобы совсем отключить мониторинг фрагментации логических дисков используемых для хранения точек восстановления на серверах DPM мы создадим в SCOM динамически наполняемую группу объединяющую такого рода логические диски. Если это ещё не было сделано ранее, создадим новый пакет управления в консоли SCOM на вкладке Administrtion (Management Packs > пункт меню Create Management Pack) Присвоим пакету версию и имя, например Customizations MP for Windows Server Operating System MP MP будет использован для хранения правил формирования динамической группы, а также переопределения, которое будет нацелено на эту группу. Перейдём на вкладку Authoring и вызовем мастер создания новой группы (Groups > Create a new Group) На первой вкладке заполним имя группы, понятное для нас описание и выберем созданный ранее
↧
↧
Windows Server 2012 R2 Remote Desktop Web Access —Исчез ярлык на RDP файл для подключения к коллекции сеансов после публикации RemoteApp приложения
Как можно заметить, в коллекции сеансов RDS на Windows Server 2012 R2 при публикации первого RemoteApp приложения изменяется тип коллекции с Session Remote Desktop на Session RemoteApp Programs и при этом с веб-страницы опубликованных приложений RD Web Access исчезает rdp-ярлык для подключения к коллекции сеансов. В контексте прошлой заметки можно столкнуться с ситуацией, когда нужно получить доступ к указанному ярлыку, но при этом убирать с публикации все RemoteApp приложения (чтобы изменился тип коллекции и ярлык снова стал отображаться на веб-странице RD Web Access) нет особого желания. Ryan Mangan в своём блоге подсказал, как можно выйти из подобной ситуации. На сервере публикации RD Web Access находим ключ реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<Коллекция>\RemoteDesktops\<Коллекция> Здесь в параметре реестра RDPFileContents и можно найти содержимое публикуемого rdp-файла. Достаточно скопировать это содержимое в пустой текстовый файл и присвоить ему расширение *.rdp. Здесь же с помощью параметра ShowInPortal регулируется видимость значка подключения к коллекции сеансов (1 – отображается , 0 – не отображается) на веб-странице Web Access, то есть можно включить его отображение даже в том случае, если тип коллекции — Session RemoteApp Programs. А в параметре Name хранится имя отображаемое под значком, и его также можно при желании изменить. Обратите внимание на то, что если в ферме несколько серверов RD Web Access, то вносить идентичные изменения нужно на всех таких серверах, в противном случае результата не будет. Также стоит отметить, что отредактированные вручную через эти параметры реестра, могут быть переписаны в случае изменения настроек коллекции RDS через Server Manager, например при публикации нового RemoteApp приложения. Поэтому если вы всё-таки хотите иметь в этих параметрах изменённые значения, то возможно стоит задуматься о их форсированном назначении, например с помощью Group Policy preferences. При всём вышесказанном стоит понимать, что данный метод является по сути хаком и нет никакой гарантии, что он не перестанет быть полезен после какого-нибудь очередного хитрого обновления
↧
Windows Server 2012 R2 Remote Desktop Connection Broker —Предупреждение безопасности RDP-клиента при использовании доверенного сертификата.
Выполнено развёртывание Remote Desktop Service на базе Windows Server 2012 R2 в конфигурации с высоко-доступным RD Connection Broker. В свойствах развёртывания для нужд RD Connection Broker SSO назначен сертификат, выпущенный внутренним Центром сертификации, корневому сертификату которого доверяют все клиентские компьютеры локальной сети. Казалось бы, все минимальные условия для беспроблемного подключения клиентов к ферме RDS соблюдены, однако в процессе подключения у RDP-клиента возникает дополнительный вопрос о том, действительно ли мы доверяем “Издателю”. Чтобы отключить появление подобного сообщения достаточно сконфигурировать один параметр групповых политик применяемых к клиентским компьютерам. Для этого нам понадобится так называемый Отпечаток сертификата (Thumbprint), который используется при подключении к ферме RDS. Открываем свойства этого сертификата (можно прямо из ссылки в появляющемся сообщении, как на скриншоте) и на закладке Состав выделяем и копируем значение атрибута Отпечаток. Скопированный отпечаток лучше вставить в текстовый редактор и убедиться в том, что ни в начале ни в конце строки нет лишних пробелов. Находим параметр GPO: Specify SHA1 thumbprints of certificates representing trusted .rdp publishersв разделе Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client Включаем данный параметр и копируем ранее сохранённый отпечаток сертификата… Указанный параметр может быть настроен как в разделе GPO Computer Configuration, так и в разделе Users Configuration. Результат применения указанного параметра групповых политик можно проверить на клиентском компьютере в параметре реестра TrustedCertThumbprints в ключах (в зависимости от выбранной области применения): HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal ServicesHKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services В конечном результате подключение к ферме RDS будет выполняться сразу, без ранее описанного предупреждения…
↧
Обновление HP Insight Management Agents for Windows Server до версии 10.0.0.0
Сегодня получил от HP очередной бюллетень об обновлениях ПО, драйверов и микропрограммного обеспечения, из которого узнал о том, что подтверждённая ранее проблема с HP Insight NIC Agents версии 9.40 относится также и к версиям 9.50 и 9.60… Ссылка на документ: HP ProLiant Servers — Systems Running Microsoft Windows Server 2012 or 2012 R2 May Experience a Memory Leak Up To 5 Mb/ Hour for Some NIC Teaming Configurations (c04209163) Исходя из этого документа, описанная проблема с утечкой памяти решается путём установки самой последней версии пакета HP Insight Management Agents for Windows Server x64 Editions 10.0.0.0 Скачать пакет можно по прямой ссылке cp022559.exe Как ни странно, мне не удалось обнаружить указанный файл в репозитории HP Version Control Repository Manager (VCRM), хотя последний постоянно обновляется с сайта HP. Однако можно добавить загруженный файл в VCRM и вручную. Буквально через несколько минут после копирования файла в каталог VCRM, в логе должно появиться сообщение об успешном добавлении нового компонента. Не помешает после добавления нового компонента дополнительно вызвать процедуру валидации каталога VCRM, выбрав действие rescan repository & rebuild catalog на закладке catalog После этого нужно дождаться окончания процесса, которое можно определить по записям лога: После этого, обновление HP Insight Management Agents до последней версии можно будет выполнять непосредственно через агентов Version Control Agent (VCA) В типичной ситуации установка указанного обновления не требует перезагрузки сервера.
↧