+7 (812) 325 84 00

+7 (499) 322 07 96

Блог системного интегратора

  • Архив

    «   Июнь 2018   »
    Пн Вт Ср Чт Пт Сб Вс
            1 2 3
    4 5 6 7 8 9 10
    11 12 13 14 15 16 17
    18 19 20 21 22 23 24
    25 26 27 28 29 30  

Программное управление уровнями целостности (Integrity Levels) объектов файловой системы

Короткий пост.

Для одной факультативной задачи, потребовалось сделать средство программного управления уровнями целостности (Integrity Level) файловых объектов в операционной системе.

Уровни целостности - технология довольно экзотическая и малоизученная, появились в Windows Vista/2008, используются в них и во всех более поздних версиях клиентских и серверных ОС как один из встроенных механизмов защиты. Пример описания на MSDN – “Windows Integrity Mechanism Design”, https://msdn.microsoft.com/en-us/library/bb625963.aspx.

В итоге не придумал ничего лучше, чем тряхнуть стариной, и написать мини-утилиту командной строки на старом добром Си. Выкладываю как есть, исходный текст совсем не велик, и интуитивно понятен. Библиотеки классов не используются вовсе, стандартные функции тоже по минимуму, хватает Windows API. MIL – это “Manage integrity levels”.

Компилируется в любой современной версии Visual Studio (я использовал Visual Studio Community 2017) как консольное приложение.

Файлы:
MIL.7z (2.01 КБ)

Детальный контроль прав доступа к функции Remote Control на клиенте SCCM

Я всегда много рассказывал на семинарах про "тонкую доработку SCCM по потребностям", и призывал к этому слушателей. Приведу хороший пример.

1. Общая постановка задачи
Пару месяцев назад клиент, эксплуатирующий инсталляцию SCCM 2012 R2, обратился с весьма специфическим вопросом.
 
Для нужд удаленной поддержки рабочих мест клиентская служба ТП активно использовала механизм Remote Control (RC) в составе клиента Configuration Manager. Однако, поддержкой разного ПО занимались совершенно разные группы Help Desk; при этом, на рабочем месте могло быть установлено более одного целевого приложения. Стандартный механизм создания коллекций компьютеров с применением соответствующих политик клиента SCCM как ACL для Remote Control не годился, так как настройки прав доступа в политике не кумулятивные; политика, применяемая с наибольшим приоритетом, или последней, “затирает” все остальные. Таким образом, эффективной в каждом конкретном случае становится только одна политика (в нашем случае, для одного из приложений).
 
В сообществе пользователей SCCM этот вопрос к Microsoft (сделать настройки прав доступа к RC объединяемыми для набора нескольких политик) уже поднимался, см. https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/13748199-ability-to-set-multiple-remote-control-privileges. В SCCM Client Settings часть параметров действительно может объединяться из разных политик (некоторые разделы Inventory, например), но к правам доступа RC это, увы, не относится. После детального анализа задачи стало ясно, что штатными средствами ее не решить.
 
Клиент был весьма озабочен вопросами безопасности, и ситуация, когда кто-то получал удаленный доступ к чужому рабочему столу за пределами своей зоны ответственности, была неприемлема. Правильно разграничить доступ подразделений поддержки только к “своему” приложению не получалось, из-за возможности иметь более одного приложения на контролируемой системе. Дело осложнялось еще и тем, что число пользователей одного приложения могло быть большим (до 500 человек и больше); при этом, очень хотелось автоматизировать логику добавления системы с приложением в соответствующую коллекцию компьютеров (с последующим автоматическим назначением на нее ACL для Remote Control). Ручное добавление каждого объекта-компьютера в нужную коллекцию никого не устраивало; приложения тоже были самые разные, от “толстого” клиента 1C до веб-сервиса, не оставляющего никаких следов в системе нигде, кроме кэша браузера в профиле пользователя. Поэтому от идеи инвентаризации каких-либо объектов, уникально идентифицирующих приложение (вроде файла по фиксированному пути или ключа реестра), пришлось отказаться сразу.
Однако, имелись глобальные группы домена AD, каждая из которых содержала всех пользователей, использующих каждое приложение - это и были группы доступа. Сразу же возникла мысль попробовать использовать эти группы и механизм SCCM UDA (User Device Affinity) для построения коллекций компьютеров, к компоненту Remote Control на которых бы предоставлялся доступ соответствующих групп Help Desk.

2.   Условия

Для примера рассмотрим следующий сценарий, близкий к реальным условиям клиента. Имеется четыре приложения – 1C, Directum, CRM, Invest, для поддержки которых необходимо организовать доступ разных групп службы ТП.

Глобальные группы доступа пользователей к приложениям: DOMAIN\Access_1C, DOMAIN\Access_Directum, DOMAIN\CRM_Access, DOMAIN\Access_Invest;  

Соответствующие (создаваемые в рамках решения) коллекции компьютеров в SCCM: 1C, Directum_5_3, PC_Remote_control_CRM, PC_Remote_control_Invest;
Соответствующие глобальные группы учетных записей пользователей ТП, которым предоставляется доступ к Remote Control для
компьютеров в целевых коллекциях: DOMAIN\SCCM-RC_Access_1C, DOMAIN\SCCM-RC_Access_Directum, DOMAIN\SCCM-RC_Access_CRM, DOMAIN\SCCM-RC_Access_Invest.
Решение строим для этих условий.

3.    Формирование коллекций компьютеров
Механизм сопоставления User Device Affinity требует требует включения в политиках домена параметров аудита Audit account logon events и Audit logon events, как описано в статье “How Automatic User Device Affinity Works in SCCM 2012”, https://blogs.technet.microsoft.com/sudheesn/2015/03/05/how-automatic-user-device-affinity-works-in-sccm-2012. Сбор данных из журналов безопасности осуществляется SCCM автоматически. Порог срабатывания (время работы пользователя в системе, по прошествии которого он становится “Primary User”), контролируется через политику клиента SCCM, раздел “Сопоставление пользователей и устройств”, например, так:


Приступаем к созданию коллекций. Пример для коллекции для компьютеров с CRM:

Коллекция формируется на основе запроса WQL:

Сам запрос WQL:

Идея запроса взята отсюда: “ConfigMgr User Device Affinity (UDA) Collection Query”, https://deploymentramblings.wordpress.com/2017/05/22/configmgr-user-device-affinity-uda-collection-query/. При выполнении этого запроса формируется коллекция компьютеров, основные пользователи (Primary Users в терминологии SCCM) входят в доменную группу DOMAIN\CRM_Access.

Итак, по результатам настройки UDA у нас есть четыре коллекции, которые динамически и в реальном времени формируют списки компьютеров, за которыми работают пользователи соответствующих приложений. Первая часть автоматизированного решения получена.
4. Контроль доступа к Remote Control

Доступ к функции SCCM Remote Control на управляемой системе, в общем случае, контролируется членством в локальной группе "Пользователи удаленного управления Configuration Manager" (в русской версии SCCM). В нее попадают объекты безопасности, прописанные в политике клиента SCCM в разделе “Средства удаленного управления”, параметр “Пользователи средств удаленного управления и удаленного помощника”. При установке значения этого параметра, перечисленные в нем пользователи и группы попадают в локальную группу "Пользователи удаленного управления Configuration Manager" на компьютере, к которому применяется политика. Но, как уже говорилось, эффективная политика – только одна, поэтому нам стандартный механизм помочь не может.

Однако, опытным путем установлено, что если параметр “Пользователи средств удаленного управления и удаленного помощника” в политике клиента SCCM оставить пустым, вот так:

, то клиент SCCM на управляемой системе перестает контролировать требуемую локальную группу вовсе. Это приводит нас к идее реализовать контроль над группой по-другому - например, универсальным централизованным скриптом, запускаемым на клиентской стороне, скажем, периодически по планировщику.

Именно такое решение и было применено – скрипт на WSH с помощью подсистемы WMI подключается к локальным экземплярам классов клиента SCCM, и динамически проверяет принадлежность системы к каждой из анализируемых коллекций, при необходимости добавляя в локальную группу "Пользователи удаленного управления Configuration Manager" операционной системы десктопа требуемую глобальную группу доступа для Help Desk.

“Подводный камень” заключается в том, что простого способа проверить список коллекций, к которым принадлежит компьютер, с помощью локальной подсистемы WMI - нет (по крайней мере, я пока не придумал). Такая проверка возможна только, если подсоединиться по сети к подсистеме WMI самого сервера SCCM. Но очень хочется исполнять скрипт с правами локальной системы, а не сетевой учетной записи - ведь если подсоединяться к SCCM с локальной системы с помощью сетевой УЗ с паролем, это почти наверняка так или иначе приведет к ослаблению системы безопасности. Учетная же запись системы по сети подсоединиться к SCCM для проверки списка коллекций не может - для такого запроса у нее не хватает прав на уровне DCOM, а ослаблять защиту DCOM без крайней необходимости не стоит, по той же причине.

Эта задача решается с помощью переменных коллекции. Пример того, как это реализовано, для уже упомянутой коллекции PC_Remote_control_CRM:


То есть, для каждой проверяемой коллекции (и только для нее одной в рамках инсталляции SCCM), мы дополнительно определяем специальную переменную с префиксом Collection_RC_, с именем и значением, соответствующим имени самой коллекции. Переменные коллекции, в отличие от самого списка коллекций, “спускаются” в локальный WMI клиента при каждом обновлении политики; наличие их в репозитарии WMI мы проверяем программным способом.

Скрипт ManageSCCMRCAccess.vbs приведен в приложении к статье, предоставляется AS IS. Работоспособность проверена на всех версиях Windows, содержащих подсистему WMI, то есть, он гарантированно работает на Windows XP и выше - иначе говоря, на всех системах Windows, для которых существует клиент SCCM. Логика скрипта отражает условия нашей задачи (имена коллекций и групп), но он может быть адаптирован по потребностям для любого количества комбинаций “коллекция-группа доступа”. Для запроса данных SCCM используются классы и методы WMI, для управления локальной группой – интерфейс ADSI. Перед каждой проверкой коллекций производится предварительная чистка группы "Пользователи удаленного управления Configuration Manager". Это сделано для отработки ситуации, когда приложение более не используется (компьютер пропадает из коллекции), это приводит к отзыву права подключения у соответствующей группы ТП. Установка константы DEBUGLOG=True задает протоколирование работы скрипта в простой текстовый лог C:\SCCM_RC_Config.log – включить отладку полезно на случай, если что-то пошло не так.

5. Запуск скрипта

Скрипт размещается в сетевой папке с правами только для чтения для группы Domain Computers, запускается планировщиком Task Scheduler операционной системы раз в час, обнаруженные изменения вступают в силу немедленно. Этого оказалось достаточно, чтобы построить систему управления правами доступа к Remote Control, практически не требующую вмешательства администратора. Единственное, что нужно – добавлять пользователей в глобальные группы доступа к приложениям DOMAIN\Access*, но это как раз та операция, которая контролируется персоналом ИТ.

Никто, кстати, не мешает использовать любые другие способы периодического запуска скрипта, например, с помощью самого SCCM.

Скриншоты задания планировщика приведены ниже, они тривиальны. Задача назначается на целевые рабочие станции с помощью доменного GPO, раздел “Preferences”:






Отдельное замечание касается использования объектов планировщика в Group Policy Preferences. В механизме GPP уже давно обнаружена уязвимость, делающая хранение паролей в них небезопасным – см. бюллетень Microsoft Technet MS14-025 https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2014/ms14-025. В поддерживаемых версиях ОС Windows возможность хранения пользовательских паролей в GPP принудительно отключена модулями коррекции, распространяемыми через Windows Update или WSUS, и это правильно. Однако, поскольку мы запускаем задачу от системы, к нам проблема отношения не имеет.
6. Замечания

  • Все ссылки на реальную инфраструктуру клиента в скрипте и скриншотах изменены;
  • Решение тестировалось в среде SCCM 2012 R2, но оно полностью применимо и к SCCM 2016 – основные подсистемы в новой версии почти не поменялись;
  • Для анализа объектов WMI в системе Windows, из известных мне средств, удобнее всего использовать утилиту WMI Explorer от CodePlex, см. https://archive.codeplex.com/?p=wmie.
Файлы:
ManageSCCMRCAccess.7z (2.06 КБ)

Гостевой роутер для виртуальных стендов

По работе мне постоянно приходится иметь дело с виртуальными стендами. Бывает и так, что приходится моделировать среды из нескольких IP-подсетей, между которыми необходимо обеспечить маршрутизацию пакетов. В статье описывается часть моих решений применительно к хост-системе Windows, однако, с незначительными изменениями, они могут применяться и в других средах (VMware vSphere/ESXi, например).

1. Хост-система.
Традиционно я использую в качестве хост-системы Windows Server, на которой поднимается либо Hyper-V, либо VMware Workstation/Player, с необходимым числом виртуальных сетей. Долгое время я пытался организовывать маршрутизацию между гостевыми сетями через хост c с поднятой на нем службой RRAS, однако в конце концов от этой идеи пришлось отказаться. Взаимодействие гипервизора даже с RRAS на одной системе порождает трудноуловимые сетевые проблемы; если же пытаться использовать  решения типа TMG либо Kerio (имеющие, в числе прочего, функционал программной маршрутизации), добавляются еще и трудности сосуществования гипервизора и достаточно глубокого брандмауэра. И, в любом случае, такая маршрутизация нормально не заработает без NAT (т.е. объявления одного из интерфейсов хост-системы “внешним”), что на хосте не всегда приемлемо. Проблем может добавить еще и нагромождающийся на все это хостовой антивирусный модуль, неважно даже, какой именно - такие антивирусы обычно имеют собственный сетевой компонент.
Решение, к которому я пришел за долгие годы экспериментов – организовывать роутер в гостевой VM. Гостевая VM создается с необходимым количеством сетевых интерфейсов (multihomed), и в ней уже поднимается маршрутизатор. Мы рассмотрим как вариант с гостевой ОС Windows Server 2016 с RRAS, так и с гостевым маршрутизатором на CentOS (любой UNIX можно так приспособить; у меня CentOS только потому, что он гарантированно работает в Hyper-V).
Отдельное замечание касается файрволльного модуля в антивирусе хост-системы. Трафик даже между гостевыми виртуальными сетями, так или иначе, через него проходит. Поэтому, может понадобиться некая настройка брандмауэра антивируса для корректной обработки трафика, не подпадающего под правила - “Unmatched IP Traffic” (правила относятся к хост-системе). В Symantec Endpoint Protection клиенте, например, эта настройка выглядит так:

Fig 1. SEP FW Settings.jpg
Переходим к конфигурациям VM.
2. Виртуальный маршрутизатор на Windows Server 2016 RRAS, гипервизор VMware Workstation 12.
Имеем хост-систему Windows Server с установленной VMware Workstation 12 и неким набором виртуальных машин в разных подсетях. Конфигурация виртуальных сетей VMware, к примеру, такая:

Fig 2. VMware virtual networks.jpg

Для стендовых виртуальных машин мы используем сети VMNet1 (192.168.121.0/24), VMNet2 (192.168.122.0/24), VMNet3 (192.168.44.0/24). VMNet0 – это мост в физическую сеть (используются адреса в подсети 192.168.250.0/24). Роутер VM будет осуществлять маршрутизацию между ними всеми, поэтому у созданной VM программного RRAS-маршрутизатора (ROUTER1) четыре интерфейса:

Fig 3. Router VM network settings.jpg

В VM ROUTER1 устанавливаем операционную систему Windows Server 2016. На ней поднимаем роль Remote Access, служба Web Application Proxy, как и компонент DirectAccess, нам не понадобятся:
Fig 4. OS Roles.jpg

После установки конфигурируем службу RRAS и запускаем ее. В задачу узла входит только маршрутизация пакетов, поэтому RRAS у нас работает в режиме LAN Routing Only:

Fig 5. RRAS Settings.jpg

Ни маршрутизация по требованию, ни удаленный доступ VPN нам не нужны. Сетевые интерфейсы в оснастке RRAS выглядят так:

Fig 6. Interfaces.jpg

(видно, что Ethernet0 – это мост в физическую сеть, то есть, если можно так выразиться, “uplink”).

Конфигурация интерфейсов по Ipconfig / all:
Windows IP Configuration
Ethernet adapter Ethernet0:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::f9c2:c00d:b442:efc0%18
  IPv4 Address. . . . . . . . . . . : 192.168.250.10
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . : 192.168.250.1
Ethernet adapter Ethernet1:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::f875:715a:74c2:8463%10
  IPv4 Address. . . . . . . . . . . : 192.168.44.2
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :
Ethernet adapter Ethernet2:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::bdd5:7d16:7b99:b456%14
  IPv4 Address. . . . . . . . . . . : 192.168.122.2
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :
Ethernet adapter Ethernet3:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::58b8:5340:3b0b:9593%2
  IPv4 Address. . . . . . . . . . . : 192.168.121.2
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :

Только Ethernet0 имеет шлюз по умолчанию. Казалось бы, все должно работать, однако, у Windows Server RRAS есть одна особенность – не удается заставить работать маршрутизацию без NAT (в Linux это возможно). Нам нужен интерфейс, объявленный внешним с точки зрения трансляции адресов. Идеальный кандидат на эту роль – Ethernet0. Поэтому, его мы объявляем как Public, а остальные – как Private:

Fig 7. NAT Settings.jpg

Таблица маршрутизации, выдаваемая через команду route print, получается такая (строки протокола IPv6 для краткости не приводим):
===========================================================================
Interface List
18...00 0c 29 01 88 59 ......Intel® 82574L Gigabit Network Connection
10...00 0c 29 01 88 63 ......Intel® 82574L Gigabit Network Connection #2
14...00 0c 29 01 88 6d ......Intel® 82574L Gigabit Network Connection #3
 2...00 0c 29 01 88 77 ......Intel® 82574L Gigabit Network Connection #4
 1...........................Software Loopback Interface 1
16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 5...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
17...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination  Netmask    Gateway Interface  Metric
   0.0.0.0    0.0.0.0    192.168.250.1   192.168.250.10    257
 127.0.0.0  255.0.0.0   On-link   127.0.0.1    331
 127.0.0.1  255.255.255.255   On-link   127.0.0.1    331
 127.255.255.255  255.255.255.255   On-link   127.0.0.1    331
    192.168.44.0    255.255.255.0   On-link 192.168.44.2    281
    192.168.44.2  255.255.255.255   On-link 192.168.44.2    281
  192.168.44.255  255.255.255.255   On-link 192.168.44.2    281
   192.168.121.0    255.255.255.0   On-link     192.168.121.2    281
   192.168.121.2  255.255.255.255   On-link     192.168.121.2    281
 192.168.121.255  255.255.255.255   On-link     192.168.121.2    281
   192.168.122.0    255.255.255.0   On-link     192.168.122.2    281
   192.168.122.2  255.255.255.255   On-link     192.168.122.2    281
 192.168.122.255  255.255.255.255   On-link     192.168.122.2    281
   192.168.250.0    255.255.255.0   On-link    192.168.250.10    257
  192.168.250.10  255.255.255.255   On-link    192.168.250.10    257
 192.168.250.255  255.255.255.255   On-link    192.168.250.10    257
 224.0.0.0  240.0.0.0   On-link   127.0.0.1    331
 224.0.0.0  240.0.0.0   On-link     192.168.122.2    281
 224.0.0.0  240.0.0.0   On-link    192.168.250.10    257
 224.0.0.0  240.0.0.0   On-link     192.168.121.2    281
 224.0.0.0  240.0.0.0   On-link 192.168.44.2    281
 255.255.255.255  255.255.255.255   On-link   127.0.0.1    331
 255.255.255.255  255.255.255.255   On-link     192.168.122.2    281
 255.255.255.255  255.255.255.255   On-link    192.168.250.10    257
 255.255.255.255  255.255.255.255   On-link     192.168.121.2    281
 255.255.255.255  255.255.255.255   On-link 192.168.44.2    281
===========================================================================
Persistent Routes:
 Network Address    Netmask  Gateway Address  Metric
         0.0.0.0    0.0.0.0    192.168.250.1  Default

Полученная конфигурация полностью рабочая, и позволяет VM ROUTER1 маршрутизировать пакеты между подсетями 192.168.121.0/24, 192.168.122.0/24, 192.168.44.0/24, 192.168.250.0/24, а также из первых трех подсетей в физическую сеть и, при необходимости, в Интернет. Естественно, для виртуальных машин в этих подсетях, именно интерфейсы VM ROUTER1 (то есть 192.168.121.2, 192.168.122.2 и 192.168.44.2) нужно указывать в качестве шлюзов по умолчанию.
К слову сказать, в Windows Server 2012/R2 настройки точно такие же. Компонент RRAS в Windows Server 2016 по сравнению с предыдущими версиями не изменился.

3. Виртуальный маршрутизатор на CentOS 6.4, гипервизор Windows Server 2016 Hyper- V.
Сценарий очень похожий. Хост-система Windows Server 2016 с установленной ролью Hyper-V и набором виртуальных машин в разных подсетях. В числе прочих, есть три виртуальных коммутатора типа InternalPapapach, Bugravsk и Puksyalovo, и коммутатор BRIDGED типа External (мост в физическую сеть - “uplink”):

Fig 1. HyperV virtual networks.jpg

Виртуальные сети типа Internal имеют такую адресацию: Papapach - 192.168.44.0/24, Bugravsk - 192.168.41.0/24, и Puksyalovo - 192.168.40.0/24. VM роутера UNIX (CNTR-1- ROUTER) будет осуществлять маршрутизацию между всеми ними, поэтому у нее четыре интерфейса:

Fig 2. Router VM network settings.jpg

Устанавливается ОС CentOS 6.4 с инсталл-профилем Minimal. Далее нам понадобятся следующие пошаговые руководства по конфигурированию сети, маршрутизации и NAT:
·  "Home Lab: CentOS 6.3 as a firewall and Router", http://www.itadmintools.com/2012/10/home-lab-centos-63-as-firewall-and.html;
·  "Moo Trader – IT Infrastructure", http://www.keymoo.info/trading/wp-content/uploads/2012/08/Steps-to-configure-a-CentOS-router.pdf;
·  "Linux Static IP Address Configuration", https://www.cyberciti.biz/faq/linux-configure-a-static-ip-address-tutorial.
Дополнительно про NAT:
·  "Quick-Tip: Linux NAT in Four Steps using iptables. By Frank Wiles", http://www.revsys.com/writings/quicktips/nat.html;
·  "Red Hat Enterprise Linux  4 : Security   Guide  . Chapter 7. Firewalls. 7.4. FORWARD and NAT Rules", https://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-fwd.html;

Конфигурация сети (вывод команды ifconfig) такая:
eth0 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:07  
   inet addr:192.168.250.10  Bcast:192.168.250.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:507/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:648 errors:0 dropped:0 overruns:0 frame:0
   TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:54842 (53.5 KiB)  TX bytes:2260 (2.2 KiB)

eth1 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:08  
   inet addr:192.168.44.2  Bcast:192.168.44.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:508/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:264 errors:0 dropped:0 overruns:0 frame:0
   TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:28478 (27.8 KiB)  TX bytes:15707 (15.3 KiB)

eth2 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:09  
   inet addr:192.168.40.2  Bcast:192.168.40.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:509/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:144 errors:0 dropped:0 overruns:0 frame:0
   TX packets:86 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:12794 (12.4 KiB)  TX bytes:3828 (3.7 KiB)

eth3 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:0A  
   inet addr:192.168.41.2  Bcast:192.168.41.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:50a/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:225 errors:0 dropped:0 overruns:0 frame:0
   TX packets:65 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:25729 (25.1 KiB)  TX bytes:9569 (9.3 KiB)

lo  Link encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

“Рабочими” являются интерфейсы eth0-eth3. Eth0 смотрит в физическую сеть (то есть, подключен к виртуальному коммутатору BRIDGED типа External). Остальные интерфейсы подключены к коммутаторам типа Internal, и каждый из них относится к соответствующей подсети виртуального стенда. IP-адреса этих интерфейсах указываются в других VM в качестве шлюзов по умолчанию.

Включаем NAT для интерфейса eth0. Таблица iptables (файл / etc/ sysconfig/ iptables) получается такой:

# Generated by iptables-save v1.4.7 on Mon Jan 30 23:45:45 2017
*filter
:INPUT ACCEPT [1438:192141]
:FORWARD ACCEPT [8777:3124578]
:oUTPUT ACCEPT [1745:143062]
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
COMMIT
# Completed on Mon Jan 30 23:45:45 2017
# Generated by iptables-save v1.4.7 on Mon Jan 30 23:45:45 2017
*nat
:PREROUTING ACCEPT [5401:731115]
:POSTROUTING ACCEPT [2490:181208]
:oUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Jan 30 23:45:45 2017
В CentOS маршрутизация будет работать и без NAT. Однако, наличие  NAT позволяет, в случае необходимости, публиковать порты.

Вывод команды route:

Kernel IP routing table
Destination     Gateway   Genmask   Flags Metric Ref    Use Iface
192.168.44.0    *   255.255.255.0   U     0 0  0 eth1
192.168.250.0   *   255.255.255.0   U     0 0  0 eth0
192.168.40.0    *   255.255.255.0   U     0 0  0 eth2
192.168.41.0    *   255.255.255.0   U     0 0  0 eth3
link-local *   255.255.0.0     U     1002   0  0 eth0
link-local *   255.255.0.0     U     1003   0  0 eth1
link-local *   255.255.0.0     U     1004   0  0 eth2
link-local *   255.255.0.0     U     1005   0  0 eth3
default   192.168.250.1   0.0.0.0   UG    0 0  0 eth0

Шлюз по умолчанию в системе указывается только для eth0, это позволяет маршрутизировать трафик VM в Интернет.
Полученная конфигурация полностью рабочая, и по функциональности аналогична приведенной в разделе 2.

4. Заключение
Вместо программного маршрутизатора RRAS или CentOS можно было бы использовать “псевдо-аппаратный” на эмуляторе GNS3 (https://www.gns3.com). GNS3 – это полнофункциональный эмулятор Cisco, который, в отличие от Packet Tracer, можно использовать в кастомизированной виртуальной среде. Изначально он доступен в качестве VMware VM, но существуют и способы его адаптации под Hyper-V (Google в помощь). Использование GNS3 позволяет привнести в стенд еще и логику Cisco устройств - возможности для экспериментирования здесь безграничные.

Особенности диагностики процесса SCCM 2012 R2 Client Push Install

Недавно я разворачивал систему SCCM 2012 R2 в достаточно крупной организации. В числе прочего, столкнулся с довольно неочевидной проблемой при распространении клиентов Configuration Manager методом Push Install.

Операция Client Push Install, в общем случае, работает одновременно для всех клиентов в области обнаружения в сайте; есть возможность только отдельно выбрать, ставить ли клиента на машины с ОС рабочих станций, серверов, и с установленными ролями системы сайта SCCM (а также указать, выполнять ли установку на DC). Для детального контроля списка целевых машин предпочтительнее использовать другие варианты установки клиента (через групповые политики, например).

В данном случае SCCM клиентов нужно было ставить везде и сразу, поэтому вариант Push Install подходил. Однако, из-за особенностей работы в конкретном окружении, часть пользовательских машин была недоступна достаточно продолжительное время. По умолчанию, SCCM повторяет попытку автоматической push-инсталляции раз в час в течении недели – см. пост на форуме  https://social.technet.microsoft.com/Forums/en-US/cf3a6a7a-01a2-4425-8032-2639e25c0e81/manually-force-a-client-installation-retry?forum=configmanagerdeployment. В логе сервера сайта ccm.log попытки push-установки для недоступных машин протоколируются вот так (это пример):

---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:30.403-180><thread=4288 (0x10C0)>
---> Attempting to connect to administrative share '\\SPBM115-WSKHALE\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:30.403-180><thread=4288 (0x10C0)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.520-180><thread=4912 (0x1330)>
---> The device MSKTSV-WS11014N does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.521-180><thread=4912 (0x1330)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.522-180><thread=4912 (0x1330)>
---> Attempting to connect to administrative share '\\MSKTSV-WS11014N.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.522-180><thread=4912 (0x1330)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.653-180><thread=5152 (0x1420)>
---> The device T430SI-ALEXANDR does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.654-180><thread=5152 (0x1420)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.655-180><thread=5152 (0x1420)>
---> Attempting to connect to administrative share '\\T430si-Alexandr.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.655-180><thread=5152 (0x1420)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.989-180><thread=6500 (0x1964)>
---> The device SPBO123-WS21502 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.991-180><thread=6500 (0x1964)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.991-180><thread=6500 (0x1964)>
---> Attempting to connect to administrative share '\\SPBO123-WS21502.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.991-180><thread=6500 (0x1964)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.340-180><thread=12752 (0x31D0)>
---> The device SPBM115-WS40101 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.341-180><thread=12752 (0x31D0)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.342-180><thread=12752 (0x31D0)>
---> Attempting to connect to administrative share '\\spbm115-ws40101.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.342-180><thread=12752 (0x31D0)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.219-180><thread=8644 (0x21C4)>
---> The device SPBHDQ-WS31504 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.220-180><thread=8644 (0x21C4)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.221-180><thread=8644 (0x21C4)>
---> Attempting to connect to administrative share '\\spbhdq-ws31504.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.221-180><thread=8644 (0x21C4)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.330-180><thread=2804 (0xAF4)>
---> The device SPBN85-WS1006 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.331-180><thread=2804 (0xAF4)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.332-180><thread=2804 (0xAF4)>
---> Attempting to connect to administrative share '\\spbn85-ws1006.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.332-180><thread=2804 (0xAF4)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:14:00.767-180><thread=13204 (0x3394)>
---> The device SPBM115-WSSAV does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:14:00.768-180><thread=13204 (0x3394)>

Операцию Client Push Install можно форсировать вручную с сервера SCCM, выполняющего установку, путем генерации запроса CCR с помощью утилиты ClientPushGenerator.exe (лежит в папке установки SCCM по пути \AdminConsole\bin\ClientpushGenerator.exe). Соответствующая процедура описана здесь:
Запрос к БД SCCM из первого поста отображает время и код завершения последней операции установки:

Fig1.jpg

Последняя попытка инсталляции на 10-THINK (пример недоступной в сети машины) завершилась с ошибкой 53, это стандартный код для “Network path not found”. CCR-запрос пролежал в очереди положенное время (неделю), и истек по таймауту.

Итак, генерируем новую CCR-запись для машины 10-THINK, как описано в статье. В логе ccm.log видим следующее:

Successfully retrieved information for machine 10-THINK fr om DB $$
Execute query exec [sp_CP_GetPushRequestMachineIP] 2097152894~ $$
Execute query exec [sp_CP_GetPushRequestMachineResource] 2097152894~ $$
Execute query exec [sp_CP_GetPushMachineName] 2097152894~ $$
Received request: "2097152894" for machine name: "10-THINK" on queue: "Incoming". $$
Request "2097152894" for machine "10-THINK" doesn't exist in DB or has expired and will not be stored in queue "Processing" . $$
STATMSG: ID=3011 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_CLIENT_CONFIG_MANAGER" SYS=SPbv-srvSCCM.etalon.local SITE=S01 PID=17128 TID=7108 GMTDATE=Ср окт 21 09:31:07.672 2015 ISTR0="10-THINK" ISTR1="162" ISTR2="168" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 $$
Deleted request "2097152894", machine name "10-THINK" $$
То есть, сходу оно не заработало. Выяснилось, что CCR-запросы, генерируемые утилитой ClientPushInstall. exe, игнорируются при наличии для клиента истекшей записи в таблице ClientPushMachine _ G. Поэтому, перед выдачей CCR-запроса, таблицу надо подчистить – или дождаться стандартной операции очистки при обслуживании БД SCCM, но таймаут ротации таких записей достаточно долгий.
Поэтому, делаем такой запрос к SCCM базе (в моем случае, для клиента 10-THINK):

DELETE FR OM ClientPushMachine_G WH ERE Name like '10-THINK'

См. статью “Remove Client Push records in Configuration Manager 2012”, http://systemcenterme.com/remove-client-push-records-in-sccm-2012/.
И уже после этого повторно генерируем CCR-запись с помощью Client Push Generator. Теперь в логе ccm. log видим следующее:

Received request: "2097152894" for machine name: "10-think" on queue: "Incoming".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:41.830-180><thread=7108 (0x1BC4)>
Stored request "2097152894", machine name "10-think", in queue "Processing".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:41.831-180><thread=7108 (0x1BC4)>
Execute query exec [sp_CP_SetPushRequestMachineStatus] 2097152894, 1~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:41.845-180><thread=7108 (0x1BC4)>
----- Started a new CCR processing thread. Thread ID is 0x2100. There are now 1 processing threads  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.849-180><thread=7108 (0x1BC4)>
Submitted request successfully  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.850-180><thread=7108 (0x1BC4)>
Getting a new request from queue "Incoming" after 100 millisecond delay.  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.850-180><thread=7108 (0x1BC4)>
Waiting for change in directory "C:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box" for queue "Incoming", (30 minute backup timeout).  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.851-180><thread=7108 (0x1BC4)>
======>Begin Processing request: "2097152894", machine name: "10-think"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.850-180><thread=8448 (0x2100)>
Execute query exec [sp_IsMPAvailable] N'S01'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.873-180><thread=8448 (0x2100)>
---> Trying each entry in the SMS Client Remote Installation account list~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.874-180><thread=8448 (0x2100)>
---> Attempting to connect to administrative share '\\10-THINK\admin$' using account 'ETALON\admin'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.875-180><thread=8448 (0x2100)>
---> Connected to administrative share on machine 10-THINK using account 'ETALON\admin'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.953-180><thread=8448 (0x2100)>
---> Attempting to make IPC connection to share < \\10-THINK\IPC$ > ~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.953-180><thread=8448 (0x2100)>
---> Searching for SMSClientInstall.* under '\\10-THINK\admin$\'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.957-180><thread=8448 (0x2100)>
---> System OS version string "6.1.7601" converted to 6,10  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.464-180><thread=8448 (0x2100)>
---> Unable to connect to WMI (root\ccm) on remote machine "10-THINK", error = 0x8004100e.  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.490-180><thread=8448 (0x2100)>
~'PushClientEvenIfDC' flag is set. Skipping DC checks.  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.490-180><thread=8448 (0x2100)>
---> Creating \ VerifyingCopying existence of destination directory  \\10-THINK\admin$\ccmsetup.~   $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.492-180><thread=8448 (0x2100)>
---> Copying client files to  \\10-THINK\admin$\ccmsetup.~   $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.495-180><thread=8448 (0x2100)>
---> Copying file "C:\Program Files\Microsoft Configuration Manager\bin\I386\MobileClient.tcf" to "MobileClient.tcf"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.499-180><thread=8448 (0x2100)>
---> Copying file "C:\Program Files\Microsoft Configuration Manager\bin\I386\ccmsetup.exe" to "ccmsetup.exe"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.520-180><thread=8448 (0x2100)>
---> ForceReinstall flag is set to true  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.680-180><thread=8448 (0x2100)>
---> Created service "ccmsetup" on machine "10-THINK".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.694-180><thread=8448 (0x2100)>
---> Started service "ccmsetup" on machine "10-THINK".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.187-180><thread=8448 (0x2100)>
---> Deleting SMS Client Install Lock File '\\10-THINK\admin$\SMSClientInstall.S01'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.189-180><thread=8448 (0x2100)>
Execute query exec [sp_CP_SetLastErrorCode] 2097152894, 0~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.236-180><thread=8448 (0x2100)>
---> Completed request "2097152894", machine name "10-think".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.239-180><thread=8448 (0x2100)>
Deleted request "2097152894", machine name "10-think"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.239-180><thread=8448 (0x2100)>
Execute query exec [sp_CP_SetPushRequestMachineStatus] 2097152894, 4~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.241-180><thread=8448 (0x2100)>
Execute query exec [sp_CP_SetLatest] 2097152894, N'10/21/2015 10:21:45', 1~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.244-180><thread=8448 (0x2100)>
<======End request: "2097152894", machine name: "10-think".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.246-180><thread=8448 (0x2100)>

Begin Processing request – это именно то, что нам надо, при доступности сетевого ресурса \\10-THINK\Admin$ для учетной записи инсталляции процесс запускается сразу. Клиент через положенное время встал:

Fig2.jpg

Проблема здесь в том, что для каждого такого клиента просроченные записи нужно удалять вручную. Можно, в принципе, попытаться придумать какой-нибудь хитрый запрос к базе данных для удаления только нужных клиентов по коду завершения предыдущей операции CCR. И, конечно, надо соблюдать осторожность при прямой работе с БД Configuration Manager!

А в остальном - методика рабочая.

Автоматизированное распространение клиента Lotus Notes с настроенной конфигурацией

1. Постановка задачи
Некоторое время назад пришлось выступить консультантом по решению достаточно специфической задачи.
Предприятие разворачивало корпоративную почтовую систему на базе IBM Domino 8. Рабочих мест – до 800, впоследствии Lotus предполагалось использовать также для организации документооборота. Парк рабочих станций был разношерстным, в большом количестве присутствовали системы еще Windows 2000 Professional, были также XP/Vista/7, как 32-, так и 64-разрядные.
В процессе установки Notes очень хотелось передать клиенту некоторые настройки – как минимум, параметры подключения к серверу Domino, чтобы не тратить время на указание параметров связи на каждом клиенте вручную. Помимо этого, нужно было разворачивать дистрибутив клиентской части только с определенным набором компонент, и обеспечивать SSO - синхронизацию пароля Notes ID с паролем работающего пользователя Windows, избавив его от необходимости помнить отдельный пароль в почтовый клиент, и вводить его каждый раз.
Служба каталогов AD была, системы управления конфигурациями и распространения ПО – как обычно, нет. Требовалось организовать автоматизированное развертывание клиента имеющимися средствами.
Определенная проблема возникала также из-за разнородности клиентских ОС (особенно порадовало наличие Windows 2000; предприятие, кстати, было режимным). Вендорская матрица совместимости клиентов Notes (http://www-01.ibm.com/support/docview.wss?rs=475&uid=swg27007909) гласит, что последняя совместимая с Windows 2000 версия клиента Notes – не старше 7.0.4, а актуальной для заказчика на момент установки была 8.5.2 (встает на Windows XP SP2 и старше). Поэтому, было принято решение создать набор настроенных пакетов для установки:
· Lotus Notes 7.0.4, русская версия (для Windows 2000);
· Lotus Notes 8.5.2 x86, русская версия (для 32 и 64-разрядных Windows XP/Vista/7);
Логика выбора конкретной версии пакета для установки на каждом клиенте я решил реализовывать универсальным скриптом.
Кроме того, на клиенты Lotus Notes 8.5.2 в процессе инсталляции хотелось сразу же ставить еще и пакет обновлений FixPack 2 (http://www-01.ibm.com/support/docview.wss?uid=swg24028680; кстати, механизм SSO на клиенте 8.5.2 без установленного FP на 64-битной системе не работает).  Для клиента Notes 7.0.4 FixPack’ов не имелось.

2. Настройка пакетов
Для настройки пакетов unattended-установки клиента Notes служит утилита InstallShield Tuner. Сам процесс настройки очень подробно описан в пошаговом руководстве “The great Lotus Notes installation guide” (http://www.lotus-expert.com/en/articles/sntt-customize-client-installation.html), переписывать его не буду. Скажу только, что, для моей задачи, мне хватило следующих разделов:

· Preparations (страница A) – для подготовки дистрибутива. В качестве настроечной станции для запуска InstallShield Tuner я использовал виртуальную машину с русской версией Windows 7 Enterprise SP1 x86, никаких проблем не возникло. Замечание из предыдущего опыта – для настройки пакетов установки локализованных версий клиента Notes, всегда лучше использовать установку ОС соответствующей локали, иначе впоследствии, при развертывании пакета на целевых системах, возможны проблемы с кодировкой. В частности, я сталкивался с тем, что названия служб Notes в операционной системе в этом случае регистрировались “крякозябрами”.
JDK мне не понадобился;

· Changing the Installation Features (страница 5) – здесь необходимо выбрать компоненты для установки в составе клиента. В моем случае достаточно было стандартного набора без офисной части, клиент Sametime также не был нужен;

· Adding Notes. ini Options (страница 6) – здесь задается возможность передачи собственных параметров в файл notes. ini настройки клиента (см. ниже страницу 8, Scriptable setup). Поэтому, важный момент - необходимо установить параметр VDIR_INI, как описано в руководстве;

· Multi- user vs. single- user installation (страница 7) – в корпоративном окружении, в доменной среде используем вариант multi-user. В этом случае все настройки клиента хранятся в профиле пользователя Windows;

· Scriptable setup, страница 8. Здесь создается INI-файл с теми настройками, которые при установке отображаются в конфигурационный файл notes. ini. В частности, таким образом можно передать клиенту параметры подключения к серверу Domino, так, чтобы при первом запуске клиента никакие данные, кроме ID-файла не запрашивались. Это сильно минимизирует риск ошибок при начальной настройке.
Для автоматизации подключения к серверу почты (без IM), опций Domino. Port, Domino. Name, Domino. Server, AdditionalServices и AdditionalServices. NetworkDial минимально достаточно. Поэтому у меня получился такой файл company_notes.cfg, размещаемый в подкаталоге plugins кастомизированного пакета:

Domino.Port=TCPIP
Domino.Name=CM01/FGUP
Domino.Server=1
AdditionalServices=-1
AdditionalServices.NetworkDial=0
Нужно понимать, что для того, чтобы это заработало правильно, необходимо обеспечить корректную работу механизмов разрешения имен Notes поверх TCP/IP. Иначе может получиться так, что при первом запуске клиента документ соединения (connection document) будет создан неверно, и это потом придется исправлять на каждом клиенте вручную. О разрешении имен необходимо позаботиться заранее;

· Use the .mst (страница 13). Здесь приводится командная строка, которая применяет созданный файл преобразований (transform) к установочному пакету. Она нам понадобится при создании скрипта установки (см. ниже). То есть, мне нужен вариант 13. I. A ( Batch files).
Больше никакие разделы из данного руководства мне не понадобились. Installshield Tuner необходимо использовать для обоих пакетов (7.0.4 и 8.5.2). На выходе получаем по одному MST (transform) для каждого пакета, вся логика настройки стандартного дистрибутива содержится в них.

Для справки несколько дополнительных ссылок:

В результате сборки, у меня получилась следующая структура пакетов, размещаемая на сетевом дистрибутивном ресурсе в домене AD (под корнем \\SERVERNAME\Distr):

· Distr\Notes\7.0.4 – дистрибутив клиента Notes 7.0.4 (включая MST-файл);
· Distr\Notes\8.5.2 – дистрибутив клиента Notes 8.5.2 (включая MST-файл);
· Distr\Notes\8.5.2.FP2 – дистрибутив Notes 8.5.2 FixPack 2;
· Distr\Notes\Shortcuts\7.0.4 – ярлыки клиента Notes 7.0.4;
· Distr\Notes\Shortcuts\8.5.2\x86 – ярлыки клиента Notes 8.5.2 для 32-разрядной ОС;
· Distr\Notes\Shortcuts\8.5.2\x64 – ярлыки клиента Notes 8.5.2 для 64-разрядной ОС.

3. Универсальный VBS -скрипт установки
Скрипт можно загрузить из приложения (файл Install.7z), и при необходимости адаптировать. Хотелось бы сделать несколько замечаний:
· Разрядность ОС (логика введена для копирования ярлыков) определяется по системной переменной PROCESSOR_ARCHITECTURE, а версия ОС – по выводу встроенной команды ver командного интерпретатора cmd. exe;
· Скрипт определяет наличие клиента Notes на целевой системе по присутствию файла notes. exe в соответствующем каталоге. Если файл обнаружен, ничего не делается;
· Опытным путем установлено, что при подобной инсталляции (скриптом, запускаемым с правами системы из объекта групповой политики AD, в сочетании с пакетом клиента Notes для автоматизированной установки), операция установки проходит отлично, но, почему-то, в профилях пользователей не создаются ярлыки для программ. Поэтому я просто подготовил отдельные наборы эталонных ярлыков (файл Shortcuts.7z) для клиентов Notes 7 и 8, для x86 и x64-систем, для “Главного меню” и “Рабочего стола”, и по завершении операции установки копировал их явно командой xcopy в необходимые каталоги. Метод оказался вполне рабочим, никаких проблем не возникло;
· В процессе установки (асинхронной), хотелось оповестить работающего пользователя о выполняемой процедуре и предстоящей перезагрузке. Еще в Windows 2000 для этого существовала утилита msg. exe (выдает всплывающее сообщение на консоль), однако, здесь применен другой подход – для Windows 2000, из системы Windows XP SP3 взята утилита shutdown. exe, которая, по завершении установки, в случае, если нужна перезагрузка, выдает на пользовательский экран модальное окно о завершении работы системы, и инициирует перезапуск через 2 минуты. Перезагрузка же необходима для того, чтобы заработала служба единого входа в Lotus Notes клиент (SSO).
В Windows XP и позже утилита shutdown. exe есть штатно.
Соответствующие команды в скрипте такие:

RestartCmd = "shutdown.exe -r -f -t 120 -c " & Chr(34) & "Система будет перезагружена, приготовьтесь к завершению работы!" & Chr(34)
objShell.Run RestartCmd,0,FALSE

· Операция установки 8.5.2 FixPack 2 для Windows 2000 не нужна, так как для этой ОС устанавливается более старый клиент;
· Чтобы скрипт не был “черным ящиком”, введено простое протоколирование операций установки в текстовый файл на каждой системе во временный каталог (в файл %TEMP%\runresult.tmp). Это позволяет отследить, что именно происходило, если что-то пошло не так. Выглядит лог примерно так (вариант успешной установки клиента 8.5.2):

ЛОГ СКРИПТОВОЙ УСТАНОВКИ NOTES
13.12.2012 17:52:52
Инициализация скрипта установки...
Обнаружена операционная система Windows Vista и выше
Система имеет 64-разрядную архитектуру, путь установки Notes C:\Program Files (x86)\IBM\Lotus\Notes\notes.exe
Попытка установки клиента версии 8.5.2.
13.12.2012 18:03:05
Установщик вернул код 0
Попытка установки 8.5.2 Fixpack 2.
13.12.2012 18:06:23
Установщик вернул код 0
Путь общего пользовательского профиля C:\ProgramData
Копируем ярлыки главного меню в C:\ProgramData\Microsoft\Windows\Start Menu\Programs
xcopy "\\DM1-DC01\Distr\Notes\Shortcuts\8.5.2\x64\Lotus Applications" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Lotus Applications" /E /I /R /Y
Копирование вернуло код 0
Копируем ярлыки рабочего стола в C:\ProgramData\Desktop
xcopy "\\DM1-DC01\Distr\Notes\Shortcuts\8.5.2\x64\Lotus Notes 8.5.lnk" "C:\ProgramData\Desktop" /R /Y
Копирование вернуло код 0
Инициирована перезагрузка системы.
Скрипт завершен.
13.12.2012 18:06:28

Все имена серверов и организации в скрипте и примере конфигурации, конечно, изменены.

4. Замечания по установке клиента Notes
По завершении установки, однократный визит на каждую рабочую станцию все-таки нужен – для того, чтобы выдать пользователю его ID-файл с начальным паролем (который потом синхронизируется с паролем Windows). ID-файлы для каждого пользователя нужно предварительно подготовить, это стандартная задача администратора Domino. Но, в любом случае, предоставление Notes клиенту ID-файла – простая операция, занимающая минимум времени, а все остальное автоматизировано.
Дальнейшие настройки Notes клиента (после подключения к предварительно сконфигурированному серверу) можно выполнять уже с помощью политик Domino. В частности, можно задать список доступных баз данных на рабочей области Notes клиента.
Клиенты Lotus Notes от версии к версии, в сущности, меняются мало, поэтому, уверен, эта методика установки будет актуальной еще долгое время.

5. Групповая политика AD
Здесь реализация стандартная. Скрипт назначается как стартовый на контейнер Computer Configuration объекта групповой политики. Дополнительно, так как установка занимает достаточно длительное время, в ветви административных шаблонов (Computer Configuration\ Policies\Administrative Templates\System\Scripts) устанавливается два параметра:
· Maximum wait time for Group Policy ScriptsEnabled, 0 (значение 0 означает, что скрипт не будет прерван принудительно, и расширение Script CSE на клиентской стороне в любом случае дождется его завершения);
· Run startup scripts asynchronously  – Enabled , задает выполнение скрипта в фоновом режиме (асинхронно по отношению к процедуре входа в систему):


GPO Script Settings.jpg

Ну и традиционное замечание: групповая политика установки применяется при следующей перезагрузке целевой рабочей станции; дабы избежать падения производительности сети и сервера с дистрибутивом, крайне рекомендуется создать специальную группу безопасности в AD, и включать в нее целевые учетные записи компьютеров поэтапно, используя для созданных групповых политик фильтрацию по ACE “Apply Group Policy” (опция Security Filtering консоли GPMC) для этой группы.

Файлы:
Shortcuts.7z (4.15 КБ)
Install.7z (2.67 КБ)

Опыт траблшутинга SEP 12.1 Client AutoUpgrade

Опять о том же.

Получил достаточно интересный опыт применения технологии AutoUpgrade для развернутого решения SEP 12.1 для обновления клиентов. Требовалось обновить инсталляцию c RU3 до RU5.

Технология AutoUpgrade  вскользь упоминалась в предыдущем посте (“Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик AD”, http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php).

Полностью процесс обновления SEP описан здесь – “Upgrade or migrate to Symantec Endpoint Protection 12.1.5” https://support.symantec.com/en_US/article.TECH224034.html. Начинать надо с обновления серверной части.

Здесь речь пойдет о двух специфических моментах, связанных с обновлением клиентов (собственно технологией AutoUpgrade). Сама процедура обновления описана в статье “Upgrade Symantec Endpoint Protection 12.1 clients using AutoUpgrade”, https://support.symantec.com/en_US/article.TECH96789.html.

1.
Для того, чтобы обновление успешно запустилось на группе, по факту нужно установить несколько параметров распространения пакета в следующие значения (на скрине пример нужных настроек):



· Сохранить существующие функции клиента при обновлениифлаг снят;
· Расписание обновленияфлаг снят;
· Время рассылки обновлений0 дней.

Последние два параметра инициируют немедленную рассылку пакета (при следующей пульсовой передаче). А если не снять первый флаг, пакет обновления может быть отклонен клиентом.

Соответствующие вопросы обсуждаются на форумах Symantec Connect, например, здесь: http://www.symantec.com/connect/articles/upgrade-clients-sep-121-auto-upgrade-feature

2.
В процессе развертывания, некоторые разрозненные клиенты RU3 (порядка 4%), все равно явно отклонили пакет обновления RU5, записав об этом в лог. Выглядело это вот так (в свойствах клиента):



Чтобы найти причину, в конце концов понадобилось включить SMC/Sylink Debugging на тестовом клиенте (“Enable sylink debugging for Endpoint Protection clients”, https://support.symantec.com/en_US/article.TECH104758.html). Выяснилось, что в дебаг логе клиента SMC c:\ programdata\symantec\symantec endpoint protection\12.1.3001.165\Data\Logs\debug.log в момент загрузки пакета обновления фиксируются следующие строки:

2015/04/23 23:46:12.822 [4068:4180] unmatched language type.  the requested auto-upgrade cancelled.
2015/04/23 23:46:12.822 [4068:4180] Upgrade package not needed by SMC. .checking if opstate to be sent or not.

Анализ показал, что на проблемных системах ошибочно определялась ситуация, описанная в статье “AutoUpgrade fails if the language of the assigned package does not match the language of the currently installed client”, https://support.symantec.com/en_US/article.TECH153398.html - несовпадение языков установленного клиента и назначенного пакета обновления. Причем, в реальности, никакого несовпадения не было.

SEP клиент 12.1 RU3 отслеживает свою локализацию по двум параметрам реестра в ключе  HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC : HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\ProductLocale (тип REG_DWORD) и HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\Language (тип REG_SZ).

На русских версиях клиента параметры должны быть такие: ProductLocale =0x00000419 (1049), и Language =”Russian”.

Оказалось, что на проблемных системах RU3, отклонивших обновление до RU5, параметр Language почему-то установился в “ English”, хотя и локаль клиента, и операционная система были русские. Видимо, SEP клиент RU3 так определил язык при изначальной инсталляции. Почему – неизвестно; возможно, причиной было наличие какого-то специфического стороннего программного компонента либо настройки, или еще что-то в этом роде.

Workaround заключается в том, чтобы вручную через реестр сменить параметр HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\Language на "Russian”, затем перезапустить клиент командами smc –stop и smc –start (делать это нужно с правами  администратора; при остановке клиента спрашивается пароль на выгрузку SEP, если он установлен), и затем переобъявить пакет обновления до RU5 на группу средствами SEP Manager. Решение помогает сразу.

ПРИМЕЧАНИЕ.
Для очень больших групп, немедленное развертывание клиента теоретически может вызвать лаг сети и сервера, о чем SEPM честно предупреждает при публикации пакета. Однако я с какими-либо проблемами производительности на инсталляции порядка 650 клиентов, распределенных по примерно 7 группам, не столкнулся.

Распространение SEP 12.1 с помощью групповых политик. Вариант для беспроводных соединений с авторизацией по входу пользователя в домен

Cтатья описывает несколько видоизменное решение из предыдущего поста (“Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик AD”, http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php).

В процессе того же внедрения, обнаружилась специфическая именно для данной инфраструктуры проблема. Заказчик в офисе активно использовал Wi-Fi, и более половины парка рабочих станций составляли ноутбуки, работавшие только по беспроводному соединению; причем, авторизация системы на точках доступа внутренней сети происходила только после входа пользователя в домен (для выдачи сертификатов авторизации использовалась служба AD CS).

В ОС Windows политики, назначенные на контейнер Computer Configuration, запускаются в обработку, в общем случае, еще до момента входа пользователя в систему (и до появления стандартного приглашения на вход по Ctrl-Alt-Del). Поэтому предложенный ранее метод для беспроводных клиентов не работал - так как, на момент инициализации и применения политик, системы еще не были авторизованы в сети, и не имели доступа к файловым ресурсам с дистрибутивами. В то же время, для проводной сети все работало отлично.

Поэтому решили инициировать запуск скрипта установки альтернативным методом – путем добавления задачи в планировщик Task Scheduler операционной системы через механизм Group Policy Preferences (GPP). Поскольку все клиенты работали под управлением Windows 7/8, проблем с совместимостью параметров GPP со старыми версиями ОС не возникло.

Процесс по шагам:

1.
Для того, чтобы создать нужное задание в планировщике, в GPO в контейнере Computer Configuration\Preferences\Control Panel Settings\Scheduled Tasks создаем новое задание командой New\Scheduled Task (At least Windows 7), и устанавливаем такие параметры задания (вкладка General):


Доменная учетная запись SEPInstall должна иметь административные права на целевой рабочей станции, доступ на чтение к файловому ресурсу с дистрибутивом и постоянный пароль на время развертывания (пароль сохраняется в свойствах назначенного задания);

2.
Триггер старта задания устанавливаем, например, так:


Так как задача запускается периодически, в скрипт должна быть добавлена какая-то логика определения уже успешной установки, дабы процедура не запускалась снова и снова (см. мой комментарий к предыдущему посту);

3.
На вкладке Actions устанавливаем запуск скрипта:


Обращаю внимание, что, пакетов будет два - для x86 и x64 версий клиента (см. предыдущий пост http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php), поэтому политик GPO и скриптов установки опять таки должно быть по паре, для систем разной разрядности. То есть, все, что говорилось в ранее о таргетировании с помощью WMI-фильтров на 32- и 64-разрядные системы, в силе - повторяться не буду;

4.
Ниже рабочие примеры вкладок Conditions и Settings, оттестированные в реальном окружении:



5.
И, наконец, сами скрипты для установки клиента – те же, что уже публиковались (http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php?commentId=1590). По сути, методика может использоваться и для систем с обычным (проводным) подключением. Теперь можно отказаться и от перезагрузки системы для запуска процедуры инсталляции (задача добавляется в планировщик сразу же при очередном цикле применения GPO).

ЗАМЕЧАНИЯ.

· Идея взята отсюда - http://www.grouppolicy.biz/2010/01/how-to-schedule-a-delayed-start-logon-script-with-group-policy.
Но - есть определенные нюансы безопасности при хранении учетных данных назначенных заданий в объектах GPO, и в самом планирощике Task Scheduler. В принципе, это может быть проблемой, так что решение предоставляется AS IS.
В любом случае, по завершении развертывания, соответствующие объекты групповых политик и планировщика желательно удалить, а пароль служебной учетной записи инсталляции – поменять;

· Для синхронизации применения групповых политик с моментом входа пользователя в систему существуют альтернативные решения, см. многочисленные посты по теме на http://social.technet.microsoft.com/Forums/windowsserver/en-US/home. Но, по ряду причин, в данном конкретном случае применять их было нежелательно. Поэтому и придуман вариант с GPP;

· Опять-таки - решение не заменит полноценную систему управления конфигурациями, даже для установки ПО. Для серьезных ИТ-инфраструктур она обязательна!
Страницы: 1 | 2 | След.