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

    Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP.

    Читать далее...

  • ИТ Вестник №01.2017

    imageПредставляем вашему вниманию очередной обзорный материал об интересных, на наш взгляд, информационных обновлениях в ИТ-сфере за прошедший месяц. За помощь в подготовке выпуска благодарю Евгения Лейтана.

    Читать далее...

  • Remote Server Administration Tools for Windows 10

    imageСтала доступна для загрузки англоязычная версия Remote Server Administration Tools for Windows 10 (только для редакций Windows 10 Professional и Enterprise). После установки пакета все инструменты RSAT активны по умолчанию (не требуют активации через механизм включения компонент Windows). Однако если установка выполняется на локализованную (напр. русифицированную) клиентскую систему Windows 10, то для появления соответствующих оснасток в системе необходимо предварительно установить английский языковой пакет. Сделать это можно разными способами, например через утилиту lpksetup.exe

    Читать далее...

  • Миграция сервера DHCP c Windows Server 2008 R2 на отказоустойчивую конфигурацию DHCP Failover из двух серверов на базе Windows Server 2012 R2

    imageВ процессе миграции серверных систем на 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 R2
    3. Импортируем все конфигурационные данные DHCP на первый сервер с Windows Server 2012 R2
    4. Импортируем только серверную конфигурацию DHCP на второй сервер с Windows Server 2012 R2
    5. Настраиваем DHCP Failover.
    6. Заключительные процедуры

     

    Читать далее...

  • Антивирус для Windows Server - настраиваем список исключений. Обновлено 11.08.2016

    imageВ ходе настройки политик управления клиентами любого антивирусного ПО необходимо определять список каталогов, имён процессов или даже расширений фалов, которые должны исключаться из Real-Time сканирования. Постараюсь собрать в одном месте информацию о рекомендуемых параметрах исключений и по мере необходимости буду его корректировать.  Стоит отметить, что список составлен исходя из приложений, которые эксплуатируются в моём рабочем окружении. Список разделен по основным категориям сервисов и там где возможно есть ссылки на официальные рекомендации производителей ПО. Во всех случаях подразумевается что программное обеспечение установлено в каталоги «по умолчанию».

    Читать далее...

  • Настраиваем Web Proxy Automatic Discovery (WPAD)

    imageЕсли вы настраиваете параметры прокси сервера в веб-браузере Internet Explorer (IE) с помощью групповых политик, и тем более делаете это с запретом изменений настроек для пользователя, то рано или поздно может возникнуть ситуация, когда пользователь выехавший в командировку не сможет воспользоваться на служебном ноутбуке браузером для доступа в интернет где-нибудь в гостинице или аэропорте из-за невозможности отключения этих самых жёстко заданных настроек прокси.

    Чтобы избежать подобной проблемы можно воспользоваться механизмом авто-настройки параметров прокси в браузере - Web Proxy Automatic Discovery (WPAD). С точки зрения клиентского браузера суть механизма WPAD в том, что при попытке доступа в интернет, браузер будет находить (через DNS/DHCP) сервер, на котором размещён настроечный файл http://wpad.holding.com/wpad.dat 

    Файл Wpad.dat это файл Java-script в котором задаются настройки параметров расположения имени и порта прокси сервера, а также список исключений для обхода прокси. В случае недоступности данного файла браузер будет выполнять попытку прямого подключения к Интернет-ресурсам через настроенный в свойствах сетевого адаптера шлюз по умолчанию. При этом в настройках самого браузера в явном виде параметры прокси не указываются, а включается соответствующая опция авто-обнаружения. Механизм WPAD поддерживают браузеры Internet Explorer, Mozilla Firefox, с некоторыми ограничениями Opera и др.

    Для того чтобы клиентский браузер узнал о том, где в локальной сети расположен сервер с опубликованным файлом wpad.dat, может использоваться механизм обращения в DNS или получения настроек с сервера DHCP. Эти оба метода можно применять как раздельно, так и совместно и каждый из этих методов имеет свои достоинства и недостатки.


    WPAD и DHCP

    Метод настройки сервера DHCP для использования WPAD можно найти здесь: TechNet Library - Creating a WPAD entry in DHCP

    Его основа сводится к добавлению на сервер DHCP дополнительной опции 252, в которой указывается URL файла авто-настройки. Эта опция назначается на сервер или отдельную область и передается клиентам DHCP вместе с основными настройками IP.

    Итак, для настройки сервера DHCP на Windows Server 2008 R2 откроем консоль управления этой ролью (Start -> Programs -> Administrator Tools -> DHCP) и в свойствах сервера выберем пункт управления опциями - Set Predefined Options.

    В окне опций, чтобы добавить новую опцию нажмём Add и затем укажем параметры опции:

    Name – WPAD
    Code – 252
    Data Type – String
    Description - 
    Web Proxy Automatic Discovery
    image

    После этого зададим в поле String значение URL по умолчанию и сохраним параметр.

    image

    В документации встречается отдельное замечание о том, что имя файла wpad.dat должно быть написано в данном случае в нижнем регистре.

    После того как опция создана мы можем сконфигурировать её как для отдельной области так и глобально для всего сервера DHCP:

    image Как видно, при задании URL размещения файла авто-настройки можно указывать нестандартный порт вместо 80, что является преимуществом в сравнении с методом настройки через DNS где при публикации файла может использоваться только 80 порт. С другой стороны метод настройки через DHCP не поможет нам на системах где используется статическая IP адресация (DHCP клиент не запущен) и при этом требуется настройка браузера, например на терминальных серверах. Более того, по имеющейся информации обрабатывать опцию с DHCP способен только Internet Explorer, то есть говорить об альтернативных браузерах в данном случае не приходится вообще. 

    WPAD и DNS

    В нашем практическом примере мы будем использовать метод с использованием DNS, так как, на мой взгляд, он является наиболее универсальным, хотя и не лишён некоторых недостатков (некритичных в нашей ситуации).

    Суть метода настройки клиентов WPAD с использованием DNS заключается в том, что в основной зоне DNS (DNS Suffix) создается запись формата wpad.domain.com которая ссылается на сервер где опубликован файл wpad.dat. Тип этой записи может быть как A так и CNAME.

    В нашем примере все клиенты находятся в DNS домене holding.com. В зоне прямого просмотра holding.com мы создаём запись CNAME - tmgcluster.holding.com. Эта запись ссылается на имя массива из двух серверов Forefront TMG находящихся в NLB кластере.

    Прежде чем начать использовать наш DNS сервер для WPAD, мы должны убедиться в том, что он не настроен на блокировку обновления/разрешения имён wpad. Такая блокировка по умолчанию защищает сервер от атак по регистрации фальшивых узлов wpad. Во времена Windows Server 2003 такая защита обеспечивалась тем, что в зонах DNS создавалась специальная запись-заглушка с типом TXT. Подробней об этом можно почитать в статье KB934864 - How to configure Microsoft DNS and WINS to reserve WPAD registration. С приходом Windows Server 2008 в роли DNS Server появился встроенный механизм глобальных листов блокировки. В нашем примере используется сервер DNS на базе Windows Server 2008 R2, и для того, чтобы посмотреть задействован ли в данный момент механизм глобальных блокировок выполним команду:

    dnscmd /info /enableglobalqueryblocklist

    Чтобы получить содержимое блок-листа выполним:

    dnscmd /info /globalqueryblocklist

    В конфигурации по умолчанию в блок-лист как раз таки включены записи wpad и isatap. Чтобы переписать содержимое блок-листа, исключив оттуда интересующий нас wpad, выполним команду:

    dnscmd /config /globalqueryblocklist isatap

    image

    По сути в данном случае утилита dnscmd оперирует с параметрами реестра описанными в статье TechNet Library - Remove ISATAP from the DNS Global Query Block List

    В ветке реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters

    блок-лист хранится в параметре GlobalQueryBlockList

    Если есть желание отключить использование блок-листа совсем, можно выполнить:

    dnscmd /config /enableglobalqueryblocklist 0

    или же в изменить соответствующий параметр реестра EnableGlobalQueryBlockList

    После сделанных изменений нужно перезапустить службу DNS

    net stop dns & net start dns


    WPAD сервер

    Используя TechNet Library - Configuring a WPAD server рассмотрим настройки на стороне сервера Forefront TMG, который будет у нас выполнять роль сервера WPAD с опубликованным файлом авто-конфигурации wpad.dat

    В консоли Forefront TMG Management в дереве навигации перейдём в ветку Networking на закладку Networks и выберем сеть, для которой нам нужно создать прослушиватель WPAD (обычно это внутренняя сеть – Internal). Откроем свойства этой сети

    image

    На закладке Auto Discovery включим опцию публикации файла wpad.dat -  Publish automatic discovery information for this network

    В поле где указан номер порта устанавливаем 80 порт. Как уже отмечалось ранее, в силу того, что мы используем связку WPAD/DNS, мы должны использовать именно этот порт.

    image

    Переключаемся на закладку Web Browser и настраиваем список исключений для узлов и доменов к которым клиенты должны ходить напрямую минуя прокси.

    image

    Сохраняем настройки конфигурации TMG и после этого через веб браузер TMG должен отдавать нам скрипт авто-настройки по адресу http://tmgcluster.holding.com/wpad.dat

    Открыв этот файл, мы сможем проверить попали ли в него данные списка обхода прокси. Изучив содержимое этого файла можно заметить то, что по умолчанию в этот файл адреса прокси-серверов попадают в виде IP адресов

    ...

    DirectNames=new MakeNames();

    cDirectNames = 10;

    HttpPort = "8080";

    cNodes = 2;

    function MakeProxies(){

    this[0] = new Node("192.168.0.11",2531460408,1.000000);

    this[1] = new Node("192.168.0.12",3457248957,1.000000);

    }

    Proxies = new MakeProxies();

    ...

    В некоторых случаях, например если требуется авторизация Kerberos, это может вызвать некоторые сложности. Есть хороший пост на эту тему Forefront TMG (ISA Server) Product Team Blog > Understanding By-Design Behavior of ISA Server 2006: Using Kerberos Authentication for Web Proxy Requests on ISA Server 2006 with NLB.

    Для того чтобы изменить адреса прокси попадающие в wpad с IP на FQDN можно воспользоваться подключением к COM-объекту TMG через Powershell и свойством CarpNameSystem. Чтобы получить текущее значение этого свойства, выполним скрипт:

    $ServerName = "TMGCLUSTER"

    $FPCRoot = New-Object -comObject "FPC.Root"

    $TMGObj = $FPCRoot.Arrays.Connect($ServerName)

    $TMGObj.ArrayPolicy.WebProxy.CarpNameSystem

    Установленное по умолчанию значение "2" нам нужно будет заменить на значение "0" следующим образом:

    $ServerName = "TMGCLUSTER"

    $FPCRoot = New-Object -comObject "FPC.Root"

    $TMGObj = $FPCRoot.Arrays.Connect($ServerName)

    $TMGObj.ArrayPolicy.WebProxy.CarpNameSystem = 0

    $TMGObj.ApplyChanges()

    Для вступления параметров в силу нужно перезапустить сервера TMG.

    После перезагрузки снова проверяем содержимое файла wpad.dat и убеждаемся в том, что адреса прокси указаны в виде FQDN серверов.

    ...

    function MakeProxies(){

    this[0] = new Node("TMG01.holding.com",2531460408,1.000000);

    this[1] = new Node("TMG02.holding.com",3457248957,1.000000);

    }

    ...

    WPAD клиенты

    Дело осталось за малым – включить настройку WPAD в свойствах клиентских веб-браузеров. В Internet Explorer эта опция включена по умолчанию, и если ранее вы использовали групповые политики для явного задания настроек прокси, то возможно имеет смысл их же использовать для стирания старых настроек и включения авто-определения. image

    В браузере Mozilla Firefox активация механизма WPAD делается аналогичным образом и работает без нареканий (проверено на текущей версии 12.0)

    image

    Дополнительная информация:

    TechNet Library - Automatic Discovery for Firewall and Web Proxy Clients

  • Windows Server DHCP – Перенос областей DHCP между серверами

    imageИногда возникает необходимость переноса областей DHCP (Scope) между серверами Windows Server, особенно если область содержит некоторое количество резервирований. Задача с лёгкостью выполняется с помощью встроенной в Windows Server утилиты Netsh.

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

    Netsh dhcp server \Server01 export C:TempDHCPScopes

    Копируем получившийся файл DHCPScopes на другой сервер и выполняем операцию импорта областей:

    Netsh dhcp server \Server02 import C:TempDHCPScopes

    В моём случае копировалась супер-область с двумя входящими в неё областями. Попытки при копировании указать конкретную отдельную область у меня успехом не увенчались, – в любом случае выполнялся перенос всех областей, возможно это связано именно с используемой у меня супер-областью. Это я говорю к тому что прежде чем выполнять экспорт/импорт во избежание недоразумений желательно сделать так чтобы имена и диапазоны копируемых областей не пересекались с уже имеющимися на сервере областями. Вывести список всех областей можно также командой:

    Netsh dhcp server \Server02 show scope

    Источник: KB281626 - How to use the Netsh utility to export and import DHCP scopes