Хотя в интернете есть статьи, детально и со скриншотами описывающие действия по включению RDP Remote Recording, для вновь установленных ОС в общем случае данных действий не достаточно. В этой заметке я приведу проверенный лично алгоритм включения Remote audio recording на WS2008R2 и Win7.

1. Включить Windows Audio Service. Актуально для WS2008R2, так как по умолчанию данная служба отключена. Для включения достаточно кликнуть правой кнопкой по громкоговорителю в углу экрана и вызвать свойства, далее система сама предложит запустить сервис.

2. Разрешить перенаправление аудио/видео и записи звука в свойствах RDP-сервера.

Сия настраивается доступна в следующих местах:

• MMC-оснастке Remote Desktop Session Host Configuration (не доступна в стандартной поставке Windows 7)
• Групповых политиках (доменных, либо локальных — gpedit.msc)

[Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection]

Allow audio and video playback redirection
Allow audio recording redirection


3. Отредактировать реестр. Как выяснилось, даже если в политике нужные функции будут явно разрешены, передача аудио/видео работать начнет, а вот запись звука — нет. Для того, чтобы запись звука по RDP начала работать, нужно задать следующее значение в реестре:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]

"fDisableAudioCapture"=dword:00000000

После этого в записывающих устройствах (Recording Devices) ОС Windows 7 появится Remote Audio.

4. Установить роль Remote Desktop Session Host на WS2008R2. В режиме Remote Desktop fot Administration, который настраивается при установке системы, перенаправление записи звука не работает.

Установщик роли Remote Desktop Session Host будет настоятельно предлагать установить фичу Desktop Experience, если отметить галочки Audio and video playback, Audio recording redirection. Рекомендую снять эти галочки и поставить роль RDSH без фичи Desktop Experience, так как она для работы записи звука по RDP не требуется, но при этом в систему добавляет много ненужного (полупрозрачные окна, нескучные обои и прочий BolgenOS).

5. Включить в RDP-клиенте функциональность Remote audio playback и Remote audio recording.

Ссылки

• Configure Audio Recording Redirection on an RD Session Host Server
• Enable Audio in Windows 2008 guest machines running on HyperV
• What’s New in Remote Audio for Windows 7?

Субъективное мнение о пользе Server Core

Жалобы и предложения

На протяжении всего моего знакомства с режимом Server Core у Windows Server 2008 R2 меня не покидают ощущения искусственности этого продукта. Явно прослеживается желание Server Core быть как Linux, но при этом постоянно натыкаешься на несвойственные для Linux неприятности.

Приведу небольшое сравнение особенностей Server Core и Linux.

Однако, раньше было еще хуже, со времени первой редакции Server Core в Windows Server 2008 есть значительное развитие:

• стала доступна роль веб-сервера IIS
• появился PowerShell
• встроен скрипт начального конфигурирования

Хотелось бы видеть развитие Server Core в следующих направлениях:

• Увеличение числа поддерживаемых стандартных ролей. Любые стандартные серверные роли, даже исходя из названия, не требуют для своей работы графического интерфейса. Видимо, для оставшихся за бортом ролей Microsoft пока не успели сделать адекватное удалённое управление.
• Поддержка дополнительных серверных приложений от Microsoft и сторонних разработчиков (их участие, конечно, тоже потребуется). Таким продуктам, как SQL Server, Exchange, Kerio WinRoute и MailServer (да и любым другим, нормальным серверным) для работы серверной части не нужна графическая оболочка, всё равно управление осуществляется из отдельных консолей.
• Включение в стандартную поставку диалоговых скриптов для автоматизированного конфигурирования основных параметров. В Linux-е же есть такие, здорово облегчают рутину. Чем Microsoft хуже?

Сценарии для адекватного применения Server Core

Реальное применение Server Core я вижу, например, в следующем сценарии. Для исполнения заранее ограниченного числа встроенных в Windows Server ролей, поддерживаемых Server Core, необходим выделенный сервер. Предполагается однократное конфигурирование перед запуском в среду. Дальнейшие административные вмешательства, диагностика, применение дополнительного ПО и возникновение каких-либо проблем — не предполагаются.

Предполагаю следующие варианты адекватного применения Server Core:

• Active Directory DC/RODC + DNS + DHCP в удалённом офисе
• File Server + Print Server + BranchCache Hosted Cache
• IIS + Media Services
• Hyper-V — просто идеально!
• Network Policy and Access Services (RRAS, NAP) + WSUS + Exchange — было бы шикарно, но пока не возможно.

При совместном применении указанных сочетаний ролей, аппаратного шифрования BitLocker, грамотной, нацеленной на безопасность настойки и качественного оборудования может получается довольно надежное и безопасное решение возложенных функций и практически «черный ящик» для нежелательных внешних воздействий.

Hyper-V Server 2008 R2

Hyper-V Server 2008 R2 представляет собой Windows Server 2008 R2 в режиме Server Core с одной единственной предустановленной ролью — Hyper-V. По способу управления они идентичны: командная строка, PowerShell, WinRM, MMC, RDP.

Как я писал выше, именно роль Hyper-V является идеальной для использования Windows Server 2008 R2 в режиме Server Core, и счастье, что Microsoft тоже это понимает. Но особая радость состоит в том, что Hyper-V Server 2008 R2 абсолютно бесплатен и практически не ограничен по функциональности в рамках роли Hyper-V.

Поддерживается 1 терабайт памяти, 64 логических процессора, 386 виртуальных машин, современные серверные хранилища информации, непосредственно подключаемое и сетевые. Сохранена совместимость виртуальных машин с «обычным» Hyper-V, поддерживаются снапшоты, отказоустойчивая кластеризация, Live Migration, управление через System Center Virtual Machine Manager, работает PowerShell.

Это несомненный Epic Win со стороны Microsoft и «Кузькина Мать» для vmWare.

Боевой опыт работы с Server Core

Режим Server Core рассчитан на однократную настройку из консоли, а все дальнейшее управление предполагается удаленно по сети, из различных MMC консолей, WinRM и прочих радостей. Полный набор для удаленного управления Windows Server 2008 R2 (не только Server Core) можно установить на Windows 7. Однако, ограниченно работают и наборы удаленного администрирования серверных ОС и для Windows Vista, и для Windows XP.

Первоначальная настройка

С версии R2 появилась так недостающая ранее утилита автоматизированной первоначальной настройки sconfig. Она позволяет:

• задать имя компьютера, включить его в домен
• добавить локального администратора
• настроить сетевые параметры
• активировать PowerShell
• включить удаленное управление через WinRM, MMC, RDP, Server Manager

Из графических средств остались следующие полезные вещи:

• intl.cpl — элемент панели управления для настройки языковых параметров
• timedate.cpl —элемент панели управления для настройки параметров времени
• taskmgr —диспетчер задач
• notepad никуда не делся
• regedit всё тот же
• msinfo32 — вот уж «необходимая» вещь!
• но самое приятное — работает Total Commander (и, возможно, другой незаменимый софт)!

CoreConfig

Энтузиастами была разработана более продвинутая графическая утилита для конфигурирования Server Core — Core Configurator, настоятельно рекомендую опробовать, так как на позволяет выполнить мышкой почти все действия, описанные ниже. Перед запуском CoreConfig необходимо включить PowerShell в SCONFIG, а саму программу можно закинуть на сервер по сети (\\server\c$) сразу после установки и конфигурации сетевых параметров.

Настройка железа

Несмотря на богатый набор встроенных в стандартную поставку Server Core драйверов для сетевых карт, может понадобиться установить эти драйвера вручную. За работу с драйверами устройств в Server Core отвечает утилита pnputil. Например, для установки драйвера для сетевой карты нужно выполнить следующую команду

pnputil -i -a drivername.inf

Удаленное управление

Как уже упоминалось выше, возможности удаленного управления активируются с помощью программы sconfig, советую включить их все. Затем настроите брандмауэр, используя консоль Windows Firewall with Advanced Security в режиме удаленного управления (mmc → добавить консоль Windows Firewall with Advanced Security → указать адрес управляемого сервера в качестве цели). Возможно, перед этим понадобится разрешить в брандмауэре входящие управляющие соединения, сделать это можно с помощью CoreConfig, либо следующей командой:

Меньше всего проблем с управлением свежеустановленным Server Core возникает, если его ввести в домен. По умолчанию в брандмауэре включится профиль Domain, будет работать прозрачная аутентификация в консолях MMC и WinRM. Ну и, конечно, групповые политики будут применены ко всему, что найдут.

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

Это здорово облегчит подключение по WinRM и сделает возможным в принципе управление по MMC.

Как настроить WinRM на клиенте и подключиться им к вашему серверу, читайте в моей статье «Выполнение консольных команд на удаленных компьютерах по сети».

Для управления Server Core с помощью консоли Server Manager, нужно открыть его на локальной машине, правый клик на корне Server Manager → Connect To… Будут доступны:

• Task Scheduler
• Event Viewer
• Shared Folders
• Services
• Disk Management (если сначала запустить службу Virtual Disk)

Для доступа к следующим управляющим возможностям нужно запустить MMC, выбрать File → Add Snap-in… и указать в качестве цели адрес управляемого компьютера:

• Group Policy Object Editor
• Windows Firewall with Advanced Security

Device Manager

По умолчанию, управление устройствами не доступно, чтобы включить его (да и то только в режим чтения), в консоли Group Policy Object Editor идём в Computer Configuration → Administrative Templates → System → Device Installation и включаем Allow remote access to the PnP interface. Для вступления изменений в силу нужно перезагрузить компьютер. Для этого можно выполнить команду

winrs -r:servername shutdown /r /t 0

…если у вас все в порядке с учетными записями, в противном случае можно воспользоваться ключами -u:user -p:pass.

Конфигурирование сетевых интерфейсов

В стандартной поставке нет графического элемента панели управления ncpl.cpl, который позволяет настраивать параметры сетевых интерфейсов. Имеется текстовое средство netsh, которое помимо всей своей неудобности не позволяет настраивать привязки сетевых протоколов.

Со мной несколько раз происходила неприятная ситуация: при создании внешних виртуальных сетей в менеджере Hyper-V что-то может пойти не так, и ваша сетевая карта оставалась привязана только к протоколу Microsoft Virtual Network Switch Protocol. Но ни основная ОС, ни виртуальные машины к этому сетевому интерфейсу доступа не имели. А при попытке привязать виртуальную сеть к этому сетевому адаптеру выдавалась ошибка:

В графической среде эта проблема решалась отключением привязки протокола Microsoft Virtual Network Switch Protocol от физического сетевого интерфейса, а затем включением на нем традиционных протоколов (IP, IPv6, Клиент для сети Microsoft).

Однако, в Server Core такая задача была не выполнима стандартными средствами, что вводило в бешенство. Даже Microsoft признали эту проблему и, наконец, выпустили утилиту NVSPBind, которая позволяет настраивать привязку протоколов к сетевым интерфейсам в среде Server Core.

Полезные ссылки

• Официальный блог Server Core — самый лучший источник мудрости на начальном этапе
• Server Core Installation Option Getting Started Guide
• Remote Management with Server Manager
• Таблица поддерживаемых ролей Windows Server 2008 R2 в режиме Server Core
• Таблица поддерживаемых ролей Windows Server 2008 R2 в полной версии
• Официальная Страница Hyper-V Server 2008 R2
• FAQ по Hyper-V Server 2008 R2
• Бесплатная загрузка Hyper-V Server 2008 R2
• Средства удаленного администрирования сервера для Windows 7

Я использую 2 средства удаленного выполнения консольных команд: PsExec и WinRM, у каждого из них есть свои преимущества.

PsExec

Одним из отличных решений поставленной в заголовке задачи является использование программы PsExec от великого Марка Руссиновича.

Программа работает по клиент-серверному принципу: на локальной машине выполняется клиент, который посылает команды серверу на удаленном компьютере. Особенностью этой программы является то, что серверная часть устанавливается автоматически непосредственно перед выполнением команды, а затем удаляется. Таким образом для выполнения команд на удаленных машинах достаточно иметь на них административные права.

Если PsExec запускается от имени администратора, который входит в тот же домен, что и удаленны компьютер, то никаких учетных данных даже вводить не нужно. В противном случае, их можно указать в командной строке, либо PsExec сама их запросит. PsExec работает на ОС начиная с Windows 2000 и заканчивая 64-битным Windows Server 2008 R2.

Очень полезными в PsExec являются следующие возможности:

• Выполнение команды на группе компьютеров. Пример: следующая команда позволяет принудительно применить самые свежие групповые политики:
  psexec @group.txt gpupdate /force
• Выполнение команд от имени системной учетной записи. Пример: следующая команда заставит удаленную систему принудительно проверить обновления:
  psexec \\computer -s wuauclt /detectnow
• Копирование выполняемой программы на удаленный компьютер перед выполнением. Пример: следующая команда позволит обновить членство данного компьютера в группе безопасности Active Directory (токен доступа) без перезагрузки:
  psexec \\computer -c -s klist.exe purge

Трудно переоценить пользу этой программы, если использовать скрипты и возможности консольных команд, встроенных в Windows.

Windows Remote Management

Изначально это была серверная технология для удаленного управления оборудованием, которая появилась в Windows Server 2003 R2 как часть компонента Hardware Management, но недавно Microsoft выпустили пакет Windows Management Framework, который включает в себя PowerShell 2.0 и WinRM 2.0 и устанавливается на клиентские ОС как обновление. Подробности можно прочитать в статье KB968929.

Прелесть WinRM заключается в простоте развертывания в доменной среде через WSUS в качестве факультативного обновления ОС и мощи, которую даёт совместное с PowerShell применение.

Использование WinRM происходит через 2 команды.

winrm.cmd служит для конфигурирования настроек и диагностики клиента и сервера WinRM.

Для того, чтобы сервер WinRM начал принимать команды, должна быть запущена служба Windows Remote Management и произведена её начальная конфигурация. Используйте команду

winrm quickconfig на локальной машине, либо финт ушами
psexec -s \\servername winrm quickconfig по сети, используя PsExec от имени системной учетной записи.

Будет предложено автоматически запускать службу WinRM и разрешить уделенные подключения, соглашайтесь ;)

Чтобы успешно подключаться к WinRM серверу (имеется в виду серверная часть, принимающая команды), не входящему в тот же домен, что и ваш клиентский компьютер, необходимо на клиенте этот целевой сервер добавить в «доверенный список» следующей командой:

winrm set winrm/config/client @{TrustedHosts="servername"}, где вместо servername можно указать IP-адрес, либо * (звёздочку).

Для пользователей Windows Vista и Windows 7, работающим не от имени встроенного администратора (обычно так и бывает), нужно выполнить следующую команду

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

По умолчанию, установлено ограничение на 5 одновременных соединений WinRM от клиента, для увеличения этого числа выполните команду

winrm s winrm/config/winrs @{MaxShellsPerUser="X"}

winrs.exe — клиент для отправки запросов к серверной части. Пример: следующая команда принудительно перезагрузит удаленную систему…

winrs -r:servername shutdown /r /t 0

В доменной среде при отправке команд используются учетные данные запустившего пользователя. Для посыла команд от имени другого пользователя используются ключи -u:user -p:pass. Пример: следующая команда очистит локальный кэш DNS-имён на удаленной системе

winrs -r:servername -u:user -p:pass ipconfig /flushdns