wiki.autosys.tk

лицензирование-сервера-терминалов-windows-2008

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:27 +0000

Все ниже написанное дается в ознакомительных целях. Нелегальное использование ПО неправомерно и может закончиться плачевно.
Статья актуальна до всех версий Windows Server, в том числе и для Windows Server 2016

1. Добавляем роль Службы удаленных рабочих столов (RemoteDesktopServices)
2. Выбираем в диспетчере сервера роль Служба лицензирования удаленных рабочих столов (Remote Desktop Licensing)
3. После установки роли запускаем оснастку управления лицензированием - кнопка “Пуск” → “Все программы” → “Администрирование” → “Службы удаленных рабочих столов” → “Диспетчер лицензирования служб терминалов” или Windows Administrative Tools → Remote Desktop Licensing Manager
4. Щелкаем правой кнопкой на нашем сервере, выбираем пункт “Активировать сервер“
5. Выбираем тип подключения Автоподключение (быстрее и проще) или Web ( в браузере). Не забываем открыть доступ к интернету.
6. Вводим свои личные данные (имя, фамилию,организацию, страну). Следующую страничку (E-Mail, адрес) - оставляем пустой.
7. Hажимаем «Далее», происходит активация.

После успешной активации вам будет предложено добавить лицензии.

Запустится Client Access License (CAL) Activation Wizard, который первым делом снова полезет в Microsoft. После чего спросит тип лицензии, которую желаете установить. Выбираем Enterprise Agreement, и следующим этапом вводим Enterprise Agreement Number.

Как оказалось, это число прекрасно ищется в любом поисковике по запросу Enrollment Number. Варианты Enrollment Number: 4965437 (3325596;6565792;4526017;5296992).

Теперь нужно указать продукт - Windows Server 2008 (или R2). Тип лицензии - per Device (на устройство). Количество требуемых лицензий - n. На этом всё. Закрываем окно Terminal Server Licensing.

Область применения и количество можно менять и переустанавливать.

Лицензирование VDI

Вышеприведенные номера Enterprise Agreement подходят только для лицензий терминального сервера. Но как же быть с VDI, который понадобится при работе с XenDesktop. Тут нам на помощь приходит Google. В нем удалось найти Enterprise Agreement университета штата Флориды, которому доступны VDI: 7133077.

http://www.purchasing.ufl.edu/contracts/microsoft.asp

отключился_rdp

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:27 +0000

2008R2 Отключился RDP Что попробывал:

1. if the patches show installed Windows Server 2008 R2 for x64-based Systems and Windows Server 2008 R2 for x64-based Systems Service Pack 1* OR Windows 7 for x86 or x64 based Systems Service Pack 1* (KB2621440) Windows Server 2008 R2 for x64-based Systems and Windows Server 2008 R2 for x64-based Systems Service Pack 1* OR Windows 7 for x86 or x64 based Systems Service Pack 1* (KB2667402) please uninstall these patches and reboot your box. run sfc /scannow to confirm that theres no file level corruption ensure that rdpcorekmts.dll file exists and is SP1 version that is it 6.1.7601.xxxx 2. Export following registry entry from working RDP machine and Import to machine having RDP issue. HKEY_CLASSES_ROOT\CLSID\{18b726bb-6fe6-4fb9-9276-ed57ce7c7cb2} reboot the box. Post reboot ensure that 3389 is listening using command netstat -a 3. Import the following registry entries and try to RDP HKLM\SYSTEM\CurrentControlSet\Control\Video\{DEB039CC-B704-4F53-B43E-9DD4432FA2E9} HKLM\SYSTEM\CurrentControlSet\services\RDPDD Able to RDP fine. 4. reinstall Windows Server 2008 R2 for x64-based Systems and Windows Server 2008 R2 for x64-based Systems Service Pack 1* OR Windows 7 for x86 or x64 based Systems Service Pack 1* (KB2621440) Windows Server 2008 R2 for x64-based Systems and Windows Server 2008 R2 for x64-based Systems Service Pack 1* OR Windows 7 for x86 or x64 based Systems Service Pack 1* (KB2667402) - reboot and verify that RDP is still working I hope this will help many people with same RDP problem. If this works for you as well then put comment to help others.

1) Go to a working system, run Regedit and “Export”

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

to a .REG file;

2) Go to the NOT working system, stops the services “Remote Desktop Services”, “Remote Desktop Configuration” and “Remote Desktop Services UserMode Port Redirector”;

3) Import de .REG file created in the step 1 and Reboot the system;

Uninstall

KB2830477 KB2592687

Не помогло

А помогло удаление ветки реестра [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp] и импорт с начисто установленной системы.

включаем-удаленныи-рабочии-стол-на-удаленном-сервере

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:27 +0000

Ситуация

У нас есть в сети сервер (Windows 2003). На нем отключен удаленный доступ к рабочесму столу (RDP). У нас есть учетные данные администратора сервера (имя и пароль).

Задача

Включить удаленный доступ к рабочему столу (terminal services).

Решение

Скачиваем pstools - http://technet.microsoft.com/en-US/sysinternals/bb897553 или тут - PSTools.zip - 1.6Mb

Применяем psexec:

PsExec.exe \\server -u Administrator -p password -h cmd

В результате получаем командную строку сервера.

Включаем службу и редактируем правила файервола. Для этого в командной строке выполняем команды:

Включаем службу:

REG ADD "HKLM\System\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Разрешаем доступ конкретному пользователю:

NET LOCALGROUP "Пользователи удаленного рабочего стола" Domain\User /ADD

Добавляем разрешения в файервол:

REG ADD HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile\Services\RemoteDesktop /v Enabled /t REG_DWORD /d 1 /f
REG ADD HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile\Services\RemoteDesktop /v Re

intel_hd_audio_1c20_error_code_10

anonymous@undisclosed.example.com (Anonymous) — Tue, 29 Sep 2020 07:34:04 +0000

https://answers.microsoft.com/en-us/windows/forum/all/high-definition-audio-device-device-cannot-start/f6bb86ad-8097-41ec-acb4-c0da0cd217c0

 Fixed.

Found out that it's all about the Intel DisplayAudio driver, which is not installed unless the device is active. So here is what I did:

- I downloaded once more the latest Intel HD graphics driver from the Intel site, but this time the zip file, not the executable: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23323&lang=eng.

- Extracted the file to some location.

- I changed the display config from single output to my pc monitor to 'extended desktop', so the HDMI output to my receiver became active.

- In Device Manager I right clicked the device with the yellow exclamation mark and updated the driver manually by pointing to the DisplayAudio subfolder in the folder into which I extracted the driver files.

- Done, the exclamation mark was gone. To be sure I rebooted the pc and was able to play audio over HDMI.

See, I had the driver package installed for the most part, just the DisplayAudio bit was missing, because the HDMI output was not active during the first install.

Hope you all get it fixed too!

remote_desktop_services_home_folder_not_mapping

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:27 +0000

Проблема

При входе пользователя на терминальный сервер Windows Server 2016 не мапится пользовательский диск, прописанный в свойствах учетки на вкладке Remote Desktop Services Profile. В логах ошибок нет.

Решение

Оказывается по дефолту не включен соответствующий параметр в реестре, который позовляет брать параметры из свойств учетки в AD.
На терминальном сервере в ветку реестра HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\ нужно добавить параметр fQueryUserConfigFromDC типа REG_DWORD со значением 1.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"fQueryUserConfigFromDC"=dword:00000001

windows_server_core_winrm_negotiate_authentication_error

anonymous@undisclosed.example.com (Anonymous) — Tue, 18 May 2021 10:41:02 +0000

При попытке проадминить работающий вне домена Windows Server Core 20H2 в Server Manager вылезла ошибка:

Winrm negotiate authentication error

Это означает, что клиентский сервер (с которого выполняем управление) не смог согласовать параметры сессии WinRM с управляемым сервером. Причин может быть несколько:

На управляемом сервере отключена аутентификация Negotiate
Клиент (сервер с которого админим) не доверяет администрируемому серверу.
Учетные данные, с которыми осуществляется подключение, не валидны.

Диагностика управляемого сервера

Посмотрим параметры WinRM. По дефолту всё должно быть корректно и сервер не включенный в домен должен дать себя проадминить с учеткой локального админа:

winrm get winrm/config/service
winrm enumerate winrm/config/listener

В выводе этих двух команд должно быть:

Service
  ...
  Auth
    ...
    Negotiate = true
 ...
 AllowRemoteAccess = true

ну и Listener должен слушать на адресе, котоый доступен клиенту.

Диагностика управляющего сервера

На управляющем сервере важно убедиться, что не введенный в домен сервер прописан в Trusted Hosts:

Get-Item WSMan:\localhost\Client\TrustedHosts | select name,value | format-list

Очень важно, что в списке Trusted Hosts сервер должен быть прописан с DNS-суффиксом. В моем случае DHCP сервер выдавал управляемому серверу суффикс .lan и до тех пор, пока я не прописал сервер в Trusted Hosts с этим суффиксом подключиться не удавалось.

Добавление управляемомго сервера в Trusted Hosts

Это актуально, если серверы не входят в один домен. В пределах домена, как правило, серверы доверяют друг другу.
На управляющем сервере запускаем powershell с правами администратора и добавляем хост в доверенные:

Set-Item wsman:\localhost\Client\TrustedHosts "computer_name" -Concatenate -Force

И теперь прописываем учетные данные для доступа к этому хосту:

cmdkey /add:computer_name /user:Administrator /pass:SUPERPASSWORD

не работает Computer Management

Если в консоли Server Manager хост Online, но Computer Management не работает, то скорее всего виноват Firewall.
Из консоли Server Manager запускаем на удаленном хосте сессию powershell и отключаем Firewall:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

Удаленный доступ

Разрешим подключение по RDP (хотя там будет доступен только cmd и powershell):

Set-ItemProperty -Path 'HKLM:System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0

Ну и дадим разрешение на firewall (если он еще не отклбчен):

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"