Архивы RDS - Блог IT-KB

С выходом новой версии 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 в нашем случае будут выступать сервера служб удалённых рабочих столов

В некоторых ситуациях может потребоваться массовая замена свойств ярлыков. Например в каком-то сетевом каталоге расположено множество ярлыков разгруппированных по подкаталогам и какая-то часть этих ярлыков ссылается на некоторое приложение которое было перемещено в новое месторасположение. В нашем случае имеется несколько серверов RDS в ферме RD Connection Broker с перемещаемыми профилями пользователей, и пользователям со всех серверов RDS доступна общая сетевая папка с ярлыками, ссылающимися на кучу разных мелких бизнес-приложений (АРМ). Большая часть ярлыков ссылается на приложения App-V, для которых после перехода с версии App-V 4.6 на версию App-V 5.0 потребовалось изменить свойства этих ярлыков. Такая ситуация потребует от нас, как минимум, замену таких свойств ярлыков, как ссылка на объект запуска, рабочая папка и иконка приложения. Ниже простой пример того, как можно с помощью PowerShell рекурсивно найти все *.lnk файлы в определённом каталоге и выполнить замену их старых свойств на новые: # Пример работы с атрибутами ярлыка здесь: http://msdn.microsoft.com/en-us/library/xsy6k3ys(v=vs.84).aspx # # $ShortcutsDir - Корневой каталог поиска и замены # $OldTargetPath - Старый путь запуска приложения из свойств ярлыков (с аргументами, если они есть) # $NewWorkingDir - Новый каталог запуска приложения (он же определён как рабочая папка) # $NewTargetPath - Новое имя исполняемого файла (с учетом новой рабочей папки) # $NewDescription - Описание ярлыка (всплывающая подсказка) # $NewIconLocation - Иконка ярлыка (по умолчанию используется иконка из исполняемого файла с индексом 0) # $ShortcutsDir = "\\holding.com\Services\RDSNLB_SharedLNK\ARM" $OldTargetPath = '"C:\Program Files (x86)\Microsoft Application Virtualization Client\sfttray.exe" /launch "IS_Client 4.11.11"' $NewWorkingDir = "%ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\5F02F554-B167-41C6-98DB-D35F494AA506\Root\" $NewTargetPath = $NewWorkingDir + "isc_net.exe" $NewDescription = "Запустить Инфострим Клиент" $NewIconLocation = $NewTargetPath + ", 0" $Shortcuts = Get-ChildItem -Recurse $ShortcutsDir -Include *.lnk Write-Host "Всего найдено ярлыков:" $Shortcuts.Count -ForegroundColor Green $Changed = 0 ForEach ($Shortcut in $Shortcuts) { $ShortcutObj =$null $Destination = $Shortcut.FullName $Shell = New-Object -COM WScript.Shell $ShortcutObj = $Shell.CreateShortcut($Destination) $OldTardet = $ShortcutObj.TargetPath $OldArgums = $ShortcutObj.Arguments $OldFPath = '"'+$OldTardet + '" '

Ранее мы рассматривали пример построения фермы 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 сетевых

Серверы сеансов 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 из состава

В 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

После того как новая ферма RDS развернута и протестирована, и мы готовы к тому, чтобы перенаправить всех пользователей на эту ферму, — может возникнуть необходимость автоматизации процесса замены адреса подключения в RDP-файлах, сохранённых на рабочих столах пользователей. Задача может усложниться тем, что у разных пользователей прежние адреса подключений могут быть указаны по разному, например у кого-то указано FQDN имя, у кого-то — NetBIOS имя, а где-то вообще — IP-адрес. Вот пример PowerShell скрипта, в котором в качестве переменных укажем новый адрес подключения и все возможные старые адреса и выполним соответствующую замену во всех найденных RDP-файлах на рабочем столе пользователя. # $NewString - Строка адреса подключения которую хотим установить # $OldString - Массив вариантов старых значений строк адреса подключения, которые хотим заменить на $NewString # $NewString = "full address:s:KOM-AD01-RDSNLB.HOLDING.COM" $OldStrings = @( ` "full address:s:KOM-AD01-TS02.HOLDING.COM", ` "full address:s:KOM-AD01-SRV-RDSH.HOLDING.COM", ` "full address:s:KOM-AD01-TS02", ` "full address:s:KOM-AD01-SRV-RDSH", ` "full address:s:10.160.0.140" ) # $DesktopPath = [Environment]::GetFolderPath("Desktop") $RDPFiles = Get-ChildItem -Path $DesktopPath -Recurse -Include *.RDP Write-Host "Всего найдено RDP-файлов:" $RDPFiles.Count -ForegroundColor Green $Changed = 0 ForEach ($RDPFile in $RDPFiles) { $FileChanged = 0 $LinesArray = Get-Content $RDPFile $LinesCount = $LinesArray.Count For($i=0; $i -lt $LinesCount; $i++){ ForEach ($OldString in $OldStrings) { If ($LinesArray[$i] -like $OldString) { $LinesArray[$i] = $LinesArray[$i] -replace $OldString, $NewString Write-Host "Изменяем файл:" $RDPFile.FullName "`nстрока" $i "принимает значение:" $LinesArray[$i] "`n" -ForegroundColor Gray $FileChanged = 1 } } } If ($FileChanged -eq 1) { $LinesArray > $RDPFile $Changed = $Changed + 1 } } Write-Host "Изменено RDP-файлов:" $Changed -ForegroundColor Green Скрипт распространяем на компьютеры пользователей либо как logon-скрипт через раздел групповых политик User Configuration, либо «заворачиваем» как программу для SCCM также соответственно с выполнением в контексте вошедшего в систему пользователя.

После создания скрипта для изменения строки подключения к RDS-ферме в RDP файлах пользователей нам нужно этот скрипт как-то доставить и выполнить на нескольких сотнях компьютеров. В этом непростом деле нам вновь поможет System Center 2012 Configuration Manager (SCCM). Первым делом сохраним сценарий PowerShell в доступном сетевом расположении. Перейдём к консоль SCCM и вызовем мастер создания пакета (Package). Присвоим имя создаваемому пакету, например “KOM Package Change Server name On RDP”. Укажем, что пакет имеет исходные файлы и укажем путь к каталогу с скриптом. Следующий шаг оставим по умолчанию. Потому как нам необходима стандартная программа для выполнения на компьютерах. Далее мастер переходит в меню создания программы, которая и будет разворачиваться на компьютерах. Присвоим программе имя, например “KOM Program Change Server name On RDP” Так как выполнение программы подразумевает выполнение чего-либо в командной строке (CMD), нам необходимо указать вызов PowerShell с политикой выполнения скриптов RemoteSigned. PowerShell -ExecutionPolicy RemoteSigned .\ChangeServerNameOnRDPFiles.ps1 Указать политику выполнения весьма желательно, иначе скрипт может быть не выполнен на клиентских компьютерах. Проверить отработку скрипта всегда можно с командной строки на компьютере: Так как в данной задаче нам необходимо изменить сервер подключения в RDP файлах на рабочем столе пользователей, указываем требование для запуска “Только после входа пользователя” и режим выполнения “Запустить с правами пользователя”. Завершающим этапом создания программы укажем операционные системы, на которых должна работать программа. Понятно, что в данной задаче выбираем только клиентские операционные системы. На этом создание программы закончено. Распространим пакет по точкам распространения и развернём на необходимую коллекцию компьютеров. Развёртывание выполняем с обязательным намерением. В расписании создадим тип “Как можно скорее”. Повторный запуск оставляем по умолчанию, в данной задаче нам это подходит. Оставшиеся шаги мастера можно оставить по умолчанию. Через некоторое время можно посмотреть мониторинг по развёртыванию, чтобы убедиться об успешном выполнении программы. Если в развёртывании пакетов что-то пойдёт не так, более детальную информацию можно всегда получить с клиентского

В обычной ситуации, для того чтобы централизованно нацелить все сервера с ролью Remote Desktop Session Host (RDSH) на использование какого-то конкретного сервера лицензирования RD Licensing, используются стандартные параметры объектов групповых политик (GPO) из состава Административных шаблонов, конкретнее за это отвечают параметры: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing - Use the specified Remote Desktop license servers- Set the Remote Desktop licensing mode В нашем рассматриваемом примере эти параметры выглядят следующим образом: Фактически эти параметры GPO на серверах RDSH добавляют два параметра реестра в ключе:HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services Параметр GPO: Use the specified Remote Desktop license serversПараметр реестра: LicenseServers REG_SZ = KOM-AD01-LIC03.holding.com Параметр GPO: Set the Remote Desktop licensing mode (Включен режим Per Device)Параметр реестра: LicensingMode REG_DWORD = 2 Однако в больших холдинговых инфраструктурах с разнообразием юридических лиц, может возникнуть потребность указания разных серверов RD Licensing для разных групп серверов RDSH. В такой ситуации, чтобы не плодить отдельные объекты GPO, можно разделить эти настройки на уровне одной общей GPO с применением Group Policy Preferences (GPP), создав дифференциацию настроек для соответствующих параметров реестра. Для этих параметров реестра можно настроить нацеливание применения GPP (Item-level targeting) для разных групп компьютеров, отталкиваясь от таких условий которые нас интересуют, например в зависимости от имени компьютера или подсети в которой он находится… После применения такой единой групповой политики с дифференцированными настройками GPP на все сервера RDSH, каждый из этих серверов получит те настройки, которые ему положены по юридическому статусу. Стоит помнить о том, что вышеуказанные параметры Административных шаблонов GPO при этом не должны использоваться, так как фактически это будет приводить к конфликту с теми настройками, которые выполняет GPP. Если по какой-то причине потребуется отменить применённые таким образом параметры GPP, то нужно не забыть поменять тип действия Action на удаление соответствующих ключей реестра =

Как известно, программа запуска баз 1С версии 7.7 (1cv7.exe) информацию о перечне зарегистрированных БД хранит в пользовательском ключе реестра HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\Titles. При использовании 1С v7.7 в многопользовательской среде на серверах RDS в своё время у нас возник вопрос единообразной централизованной настройки указанного ключа реестра для всех пользователей, который мы успешно решили с помощью использования метода описанного в заметке Windows Server 2008 R2 – Добавление скриптов входа на сервере RDS через ключ реестра AppSetup. То есть фактически на серверы RDS был добавлен дополнительный winlogon-скрипт, выполняющий ряд необходимых настроек пользовательского окружения, в том числе и заполнение списка зарегистрированных БД 1С в указанном ключе реестра. В нашем файле USRLOGON_2.CMD была добавлена строчка импорта reg-файла @echo off reg import USRLOGON_2_Set1CBasesPaths.reg Содержимое файла USRLOGON_2_Set1CBasesPaths.reg имело примерно следующий вид: Windows Registry Editor Version 5.00 [-HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\Titles] [HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\Titles] "\\\\holding.com\\ApppData\\1Cv77\\ACC_DB1\\"="Бухгалтерия. База 1" "\\\\holding.com\\ApppData\\1Cv77\\ACC_DB2\\"="Бухгалтерия. База 2" "\\\\holding.com\\ApppData\\1Cv77\\ACC_DB3\\"="Бухгалтерия. База 3" То есть фактически при каждом входе пользователя в систему мы сначала полностью очищали соответствующий ключ реестра, а затем заполняли общими для всех значениями. Это было полезно на тот случай, если пользователь нечаянно что-то наколбасит руками в списке баз, то этот список будет восстановлен при следующем его входе в систему Одним недостатком использования метода с дополнительным winlogon-скриптом было то обстоятельство, что подобную настройку приходилось делать вручную на нескольких серверах RDS, и чтобы сделать процесс этой настройки более централизованным было решено попробовать вместо скрипта использовать Group Policy preferences (GPP). С помощью мастера GPP Registry Wizard в групповую политику настраивающую пользовательское окружение на серверах RDS был импортирован ключ реестра HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\Titles с уже настроенного сервера. Использование winlogon-скрипта было отключено и применение групповой политики показало что всё вроде бы хорошо. Однако через некоторое время пользователи стали жаловаться на то, что в окне запуска 1С исчезает список баз.. Причём жалобы поступали от пользователей которые на следующий день к удивлению не подтвердить наличие проблемы…Загадка становилась всё интересней. После ряда

В 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 получат всплывающее сообщение которое трудно не заметить…

Наконец-то добрались руки до того, чтобы развернуть новую ферму высоко-доступного RD Connection Broker на базе Windows Server 2012 R2. В отличие от конфигурации, которая описывалась ранее, было решено выполнить разделение ролей RDS и отказаться от использования NLB в пользу DNS Round Robin. При планировании развёртывания акцент был сделан на то, чтобы в итоге получить конфигурацию, которую можно будет считать более или менее поддерживаемой Microsoft. В результате получилась конфигурация из двух виртуальных серверов с совмещенными ролями RD Connection Broker/RD Web Access и пяти виртуальных серверов с выделенной ролью RD Session Host. А в силу того, что роли RD Connection Broker и RD Web Access не сильно требовательны к ресурсам, мы не стали создавать для них выделенные сервера, а установили эти роли на уже работающих серверах App-V 5.0 (с ролями Management Server, Publishing Server и Reporting Server, по аналогии с теми, которые были описаны в заметке App-V 5 for RDS — Разворачиваем инфраструктуру повышенной доступности, только уже на базе Windows Server 2012 R2). Сам процесс развёртывания ролей RDS прошёл достаточно гладко, однако в ходе тестирования работы новой фермы возник ряд вопросов, решение которых хоть и оказалось “на поверхности”. но всё-таки отняло некоторое время. И первый вопрос, который возник – на какие сервера должны указывать A-записи в DNS для Round Robin? Некоторые товарищи предлагают при создании RR DNS записей использовать IP адреса серверов с выделенной ролью RD Session Host, как например здесь Step-by-Step Remote Desktop Connection Broker installation in Windows 2012 – Page 1 или здесь Creating RDS Load Balancing Farm, RD Session Host & Broker Services on WIn Server 2012 R2. При этом специалисты, как я понимаю, из команды разработчиков Remote Desktop Services Blog — RD Connection Broker High Availability in Windows Server 2012 для RR DNS записей предлагают использовать IP адреса серверов RD Connection Broker: 6. Assign static IP addresses to

Как можно заметить, в коллекции сеансов 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. При всём вышесказанном стоит понимать, что данный метод является по сути хаком и нет никакой гарантии, что он не перестанет быть полезен после какого-нибудь очередного хитрого обновления

Выполнено развёртывание 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 будет выполняться сразу, без ранее описанного предупреждения…

После развёртывания новой фермы RD Connection Broker на базе Windows Server 2012 R2 встаёт вопрос настройки пользовательского окружения на серверах RD Session Host. В целом общий процесс настройки почти полностью совпадает с тем, что уже описывалось ранее в заметке Remote Desktop Services — Настраиваем пользовательский интерфейс на серверах RD Session Host. Исключением является лишь пара пунктов, которые будут здесь описаны. *** Метод описанный в пункте Скрываем излишние папки в профиле пользователя применительно к Windows Server 2012 R2 работать не будет. Вместо него воспользуемся вариантом, описанным здесь Windows 8 Forums — This PC — Add or Remove «Folders» in Windows 8.1 Видимостью рабочих папок пользователя можно управлять с помощью наличия под-ключей в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace , где каждый отдельный ключ отвечает за какую-то папку, в частности: {1CF1260C-4DD0-4ebb-811F-33C572699FDE} — Музыка{374DE290-123F-4565-9164-39C4925E467B} — Загрузки{3ADD1653-EB32-4cb0-BBD7-DFA0ABB5ACCA} — Изображения{A0953C92-50DC-43bf-BE83-3742FED03C9C} — Видео{A8CDFF1C-4878-43be-B5FD-F8091C1C60D0} — Документы{B4BFCC3A-DB2C-424C-B029-7FE99A87C641} — Рабочий стол Предположим мы хотим удалить папки “Музыка”, “Загрузки” и “Видео”. Для этого нам можно либо вручную удалить соответствующие ключи реестра, либо создать GPP, удаляющие эти ключи (если нужно одинаково конфигурировать несколько серверов). Например, создадим для этой цели параметры GPP в разделе Computer Configuration\Preferences\Windows Settings\Registry Соответствующие параметры для удобства объединены в группу, которая в нашем примере называется WS-2012R2. В свойствах этой группы параметров сделано нацеливание на семейство ОС – Windows Server 2012 R2 Family. Результат виден сразу после применения GPO (перезагрузка ОС при этом не требуется): *** Метод описанный ранее в пункте Настраиваем стартовый экран Windows применительно к Windows Server 2012 R2 работать вполне возможно и будет, но более правильно использовать другой метод, доступный в новой ОС для управления стартовым экраном (Start Screen) Windows и описанный в документе Customize Windows 8.1 Start Screens by Using Group Policy: 1) После того, как на все сервера RD Session Host установлено и настроено однотипное программное обеспечение, входим на любой из этих серверов и настраиваем стартовый

Ранее была описана процедура развёртывания инфраструктуры повышенной доступности для App-V 5.0 SP1. С выходом App-V 5.0 SP3 возникло желание обновить развернутую инфраструктуру до уровня этой версии. Практика показала, что процедура перехода на новую версию может оказаться настоящей находкой для любителей “хождения по граблям”. Поэтому после ряда безуспешных попыток с последующим возвращением виртуальных серверов App-V в исходное состояние (хорошо, что есть DPM), было принято решение написать эту заметку для тех, кому эта “радость” ещё предстоит. Общую информацию о новой версии можно получить из документа About App-V 5.0 SP3 Согласно статьи KB2940578 — Current list of App-V 5.0 file versions, версия серверных компонент после обновления должна подняться до 5.0.10107.0 Предварительные требования для установки новой версии — в документе App-V 5.0 SP3 Prerequisites, при прочтении которого, особое внимание стоит обратить в раздел Unsupported deployment scenarios и фразу: Installing the App-V Server on a computer that runs any previous version or component of App-V Согласно данной фразы, установка серверных компонент App-V 5.0 SP3 поверх имеющейся у меня версии App-V 5.0 SP1 (методом in-place upgrade) не допускается. Однако не смотря на это, в статье The Official Microsoft App-V Team Blog — Step-by-step guide for upgrading your App-V 5.0 infrastructure to Service Pack 3 явно рассматривается пример с обновлением серверных компонент методом in-place upgrade. Получается, что эти два источника противоречат друг-другу. Я посчитал, что в блоге команды разработчиков App-V “плохому не научат” и начал процедуру обновления без предварительного удаления компонент старой версии, о чём в дальнейшем пожалел. В результате такого обновления я получил неработоспособную службу публикации App-V да ещё и проблемы с последующими попытками полного удаления и повторной установки серверных компонент App-V. В итоге, после ряда экспериментов и нескольких откатов виртуальных серверов App-V из бэкапа, всё-таки удалось найти работающий рецепт обновления ранее описанной инфраструктуры. Излагаю… Обновляем базу данных App-V SP3 для App-V 5.0 не поставляется

При использовании дисков профилей User Profile Disk в ферме RD Connection Broker на базе Windows Server 2012 R2 рано или поздно может появиться задача расширения того или иного диска профилей. Выполнить эту задачу можно как с помощью графических средству управления, таких как, консоль Управление дисками (diskmgmt.msc) и Диспетчер Hyper-V (virtmgmt.msc), так и с помощью PowerShell для того, чтобы свести к минимуму пробег мыши. Для непосредственной процедуры расширения VHDX-диска воспользуемся командлетом Resize-VHD из PS-модуля Hyper-V. Для того, чтобы этот командлет отрабатывал без ошибок на рабочей станции с Windows 10, помимо Средств управления Hyper-V мне пришлось доустановить в систему Службы Hyper-V через оснастку Программы и компоненты (appwiz.cpl) Чтобы сориентироваться в том, какой именно VHDX-файл нам нужно модифицировать в сетевой папке где расположены файлы дисков профилей, узнаем SID доменного пользователя запросившего расширение диска профиля: Import-Module ActiveDirectory Get-ADUser petya | Select -Property SID Зная SID, сформируем полный путь к VHDX-файлу (имя файла формируется как UVHD-<SID>.vhdx) и запишем его в переменную $VDiskPath В переменную $VDiskNewSize запишем новый размер (увеличенный) виртуального диска в байтах. Перед запуском скрипта на всякий случай сделаем резервную копию модифицируемого VHDX-файла. В процессе расширения диска нам потребуется эксклюзивный доступ к VHDX-файлу, поэтому на время расширения лучше попросить пользователя закрыть сессию в ферме RDS, чтобы диск его профиля не был занят. Выполним скрипт расширения: Import-Module Hyper-V # $VDiskPath = "\\MYDOM\DFSRoot\RDS-Profiles\UVHD-S-1-5-21-2988499774-3619934774-1776546648-108997.vhdx" $VDiskNewSize = 1347420160 [int]$VDiskBusy = 0 # Try { # # Check if vdisk busy # Mount-DiskImage -ImagePath $VDiskPath -ErrorAction Stop } Catch{ Write-Warning "Mount-DiskImage error:`n$_" $VDiskBusy = 1 BREAK } # If ($VDiskBusy -eq 0) { # Dismount-DiskImage -ImagePath $VDiskPath # # Resize vdisk # Resize-VHD -Path $VDiskPath -SizeBytes $VDiskNewSize # # Mount, extend partition and dismount vdisk # Mount-DiskImage -ImagePath $VDiskPath $VDiskVol = Get-DiskImage –ImagePath $VDiskPath | Get-Disk | Get-Partition | Get-Volume $PartSize = Get-PartitionSupportedSize -DriveLetter $VDiskVol.DriveLetter Resize-Partition -DriveLetter $VDiskVol.DriveLetter -size

Если вы используете авто-развёртывание обновлений Windows с WSUS/SCCM SUP, и при этом нет практики предварительного тестирования развёртываемых обновлений на группе непродуктивных/некритичных/тестовых систем, то можно столкнуться с проблемами после установки обновления KB3102467 на системах Windows Server 2012 R2, которое, как я понял, обновляет .NET Framework 4, 4.5, 4.5.1, 4.5.2 до версии 4.6.1. Аналогичное обновление (KB3102433) есть и для систем Windows 7 SP1. Объявление о доступности данного обновления на WSUS было опубликовано в статье .NET Blog — Microsoft .NET Framework 4.6.1 is available on Windows Update and WSUS. Однако ряд серверных продуктов Microsoft не имеют на сегодняшний день поддержки .NET Framework 4.6.1 и установка этого обновления может вызвать проблемы в их функционировании. Рекомендация воздержаться от установки на серверы Exchange Server в блоге продуктивной группы The Exchange Team Blog — On .NET Framework 4.6.1 and Exchange compatibility. Там же можно найти порядок действий по откату уже установленного обновления KB3102467 на серверах Exchange. Описание ещё одной проблемы с Exchange можно найти в статье KB3095369 — Mailboxes are quarantined and databases fail over unexpectedly in Exchange Server 2013 Рекомендацию отказаться от установки .NET Framework 4.6.1 на серверы Lync/Skype for Business можно найти в заметке NextHop Team — On .NET Framework 4.6.1 and Skype for Business/Lync Server Compatibility Свидетельства проблем совместимости SharePoint Server с .NET Framework 4.6 можно найти ещё в прошлогодних записях, например — The Frog Pond of Technology — Be Careful Installing .Net 4.6 / Visual Studio 2015 with SharePoint 2013 (July 2015). Подтверждение проблемы есть в статье KB3087184 — SharePoint 2013 Setup error if the .NET Framework 4.6 is installed Свидетельство проблемы с консолью RD Gateway можно найти в статье Working Hard In IT — RD Gateway Management Console crashes with .NET framework 4.6.1 update (KB3102467) Это лишь часть информации, лежащей, что называется, на поверхности. Вполне возможно, что и программное обеспечение других вендоров,

В блоге Remote Desktop Services Blog опубликована заметка Staying current with Windows Server updates for Remote Desktop Services (RDS), в которой старший эскалационный инженер David Rankin (тех.поддержка Microsoft по направлению Remote Desktop) даёт полезную рекомендацию по использованию нескольких статей базы знаний Microsoft описывающих перечень исправлений/обновлений компонент служб RDS, применение которых может рассматриваться в качестве первоначальной меры по разрешению разнообразных проблем связанных с RDS. KB2601888 — Available Updates for Remote Desktop Services in Windows Server 2008 R2 SP1 KB2821526 — Available updates for Remote Desktop Services in Windows Server 2012 KB2933664 — Available Updates for Remote Desktop Services in Windows Server 2012 R2 В соответствующих статьях перечисляются не только обновления доступные для загрузки и установки через службы Windows Update/WSUS (в основном из категории рекомендуемых обновлений), но и отдельные хот-фиксы, которых нет на Windows Update/WSUS (такие хот-фиксы должны применяться исключительно в ситуациях, описываемых в симптоматике соответствующих им статей KB). Заносим указанные статьи в Избранные ссылки, как отправные точки при решении проблем со службами RDS.

В продолжение темы, ранее описанной в заметке Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено… один из комментаторов к этой заметке навёл на идею использовать для подключения к высоко-доступному экземпляру RDCB вместо специально настроенного RDP-файла на стороне клиентов, настройку параметра реестра DefaultTsvUrl на серверах RDCB. В общем случае, как я понял из статьи Ask the Performance Team Blog — Walkthrough on Session hint / TSVUrl on Windows Server 2012, этот параметр реестра используется для совместимости RDCB в Windows Server 2012/R2 с RDP клиентами, которые не умеют принимать дополнительные параметры через RDP-файлы. Этот параметр способен принимать имя основной коллекции сеансов, к которой должны перенаправляться все пользователи, подключающиеся к серверам RDCB без явной передачи параметров нужной коллекции. В случае если у вас используется всего одна коллекция, то настройка параметра реестра DefaultTsvUrl на серверах RDCB снимет необходимость в формировании и распространении по клиентам специально сформированного RDP-файла. В первую очередь, нам потребуется определить имя коллекции, к которой должны подключаться все клиенты, не имеющий явной направленности в ту или иную коллекцию. Это имя имеет специальный формат вида tsv://<TSVURL> На сервере с ролью RDCB найдём значение параметра RDPFileContents в ключах реестра вида: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<Collection>\RemoteDesktops\<Collection> или HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<Collection>\Applications\<RAApplication>\ Скопируем значение из параметра реестра RDPFileContents в текстовый редактор и убедимся в том, что фактически это содержимое RDP-ярлыка которое доступно нам как RemoteApp приложение с веб-странички RD Web Access и совпадает со значением, о котором мы говорили ранее. Копируем это значение в новый параметр реестра DefaultTsvUrl (тип REG_SZ) в ключе: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings Так как серверов с ролью RDCB в нашем случае два, то и соответствующую правку реестра выполняем на обоих. После этого проверяем подключение обычным RDP-клиентом на FQDN адрес DNS RR имени нашего высоко-доступного экземпляра RDCB и убеждаемся в том, что клиент успешно перенаправлен в заданную

Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP. В качестве аппаратной платформы для тонкого клиента мы будем использовать устройства HP t610, хотя в рамках нашей задачи эти устройства имеют более чем избыточную конфигурацию. По сути минимальные системные требования для тонкого клиента с Thinstation – любой «аппаратный хлам» начиная с уровня Pentium-II с 128MB RAM и выше. Мы будем использовать бездисковую конфигурацию тонких клиентов, то есть загрузка системы будет выполняться по сети с использованием PXE (приоритетно) или с локальных загрузочных USB-накопителей (для клиентов без поддержки PXE и в отдалённых участках со слабым каналом передачи данных). Когда я изучал доступные в открытых источниках статьи на тему подобного развёртывания, то среди множества материалов выделил для себя статью Пети Хинчли «Use Thinstation to build a network-bootable RDP-enabled thin client image», от наработок которой я и буду отталкиваться. Также в качестве полезного источника информации стоит отметить такие русскоязычные ресурсы, как Thinstation по русски и Thinstation Доработка тонкого клиента. В рассматриваемом примере имеется несколько исходных условий, от которых нам придётся отталкиваться: Все тонкие клиенты должны быть изолированы в рамках одной сети и должны маршрутизироваться только до своего RDS-сервера. RDS-сервер, помимо предоставления сессий удалённых рабочих столов, по совместительству должен выполнять все функции управления тонкими клиентами (раздача IP адресов, раздача загрузочных образов ОС, раздача настроек каждого конечного клиента и т.д.). Загрузка конечной рабочей среды тонкого клиента должна происходить автоматически без участия пользователя/оператора (авто-логон RDP-сессии и запуск необходимой оболочки – конечного бизнес-приложения) Цикличная работа тонких клиентов должна быть автоматизирована, то есть клиенты должны автоматически включаться по расписанию утром каждого рабочего дня и выключаться в конце рабочего дня. Начнём

App-V 5 for RDS —Разворачиваем инфраструктуру повышенной доступности

PowerShell —Массовая замена свойств ярлыков

Remote Desktop Services –Строим отказоустойчивую ферму RD Connection Broker на базе Windows Server 2012

Remote Desktop Services —Настраиваем пользовательский интерфейс на серверах RD Session Host

Публикация приложения RemoteApp на в ферме серверов RDS (Windows Server 2012) на примере КонсультантПлюс

PowerShell —Меняем адрес подключения в RDP файлах пользователя

Распространение и выполнение сценариев PowerShell с помощью System Center 2012 Configuration Manager

Нацеливаем сервера RDSH на RD Licensing с помощью Group Policy Preferences

Загадочное поведение окна запуска баз 1С 7.7 настроенного через GPP Registry Wizard

Remote Desktop Services —Отправка сообщения всем пользователям фермы RDS

Windows Server 2012 R2 Remote Desktop Connection Broker —Невозможно подключиться к высоко-доступной ферме RDS —Подключение было запрещено…

Windows Server 2012 R2 Remote Desktop Web Access —Исчез ярлык на RDP файл для подключения к коллекции сеансов после публикации RemoteApp приложения

Windows Server 2012 R2 Remote Desktop Connection Broker —Предупреждение безопасности RDP-клиента при использовании доверенного сертификата.

Windows Server 2012 R2 Remote Desktop Services —Настраиваем пользовательский интерфейс на серверах RD Session Host

Обновляем инфраструктуру App-V 5.0 Service Pack 1 до уровня Service Pack 3

Расширяем User Profile Disk с помощью PowerShell

Внимание, грабли. Обновление KB3102467 — .NET Framework 4.6.1

Обновления для Windows Server Remote Desktop Services

Windows Server 2012 R2 Remote Desktop Connection Broker —Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.

Разворачиваем сеть тонких клиентов Thinstation с подключением к серверу Windows Server 2012 R2 Remote Desktop Services

Latest Images

Дорама «Наш фильм» завершилась на подъёме, рейтинг дорамы «Закон и город»...

Дорама «Наш фильм» завершилась на подъёме, рейтинг дорамы «Закон и город»...

Дорама «Наш фильм» завершилась на подъёме, рейтинг дорамы «Закон и город»...

Дорама «Наш фильм» завершилась на подъёме, рейтинг дорамы «Закон и город»...

Игры в разработке и демо-версии :: [В разработке] DREADZONE (RUS|ENG|MULTI8) [Р]

Kaspersky Standard | Plus | Premium (Часть 1) (3934) / Новые...

-=Железный флейм=- часть IX (20173) /

John Robinson - Pity For The Victim 1974 (Remastered 2006)

Я 6Р(О)ДЯГА С Д(Ы)61Р(О)Й В КА(Р)МАНЕ

Я 6Р(О)ДЯГА С Д(Ы)61Р(О)Й В КА(Р)МАНЕ