• ИТ Вестник №11/12.2016

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

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

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

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

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

  • ИТ Вестник №06/07.2016

    imageПредставляем вашему вниманию очередной обзорный материал об интересных, на наш взгляд, информационных обновлениях в ИТ-сфере. В связи с отпускной порой "вне зоны доступа" мне не удалось вовремя опубликовать Июньский обзор, поэтому данный обзор содержит в себе обновления сразу за два прошедших месяца – Июнь и Июль.

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

  • Разворачиваем Application Virtualization SSRS Reports для App-V 5.0

    imageНедавно обновилась коллекция отчётов служб SQL Server Reporting Services (SSRS), разработанных для App-V 4.6/5.0. Скачать архив можно по ссылке Application Virtualization SSRS Reports. В данной заметке мы рассмотрим пример того, как развернуть данные отчёты в службе SSRS на базе SQL Server 2012 с подключением к существующей инфраструктуре App-V 5.0.

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

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

    imageРанее была описана процедура развёртывания инфраструктуры повышенной доступности для App-V 5.0 SP1. С выходом App-V 5.0 SP3 возникло желание обновить развернутую инфраструктуру до уровня этой версии. Практика показала, что процедура перехода на новую версию может оказаться настоящей находкой для любителей “хождения по граблям”. Поэтому после ряда безуспешных попыток с последующим возвращением виртуальных серверов App-V в исходное состояние (хорошо, что есть DPM), было принято решение написать эту заметку для тех, кому эта “радость” ещё предстоит. 

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

  • Использование групп соединений App-V 5.0 SP1

    imageВ данной статье попробую рассмотреть три различных варианта публикации виртуальных приложений App-V 5.0 и методы их объединения в группы:

    1. С помощью серверов публикации;
    2. С помощью SC 2012 SP1 CM;
    3. В ручную, используя PowerShell.

    Группы соединений виртуальных приложений необходимы для тех приложений, которые работают в связке (одно зависит от другого), т.е. для корректной работы им нужна единая файловая система и реестр. Если администратор желает максимально использовать App-V, который в свою очередь изолирует приложения от системы и друг друга, можно столкнуться с ситуацией когда эти приложения нужно как-то подружить.

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

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

    imageВ некоторых ситуациях может потребоваться массовая замена свойств ярлыков. Например в каком-то сетевом каталоге расположено множество ярлыков разгруппированных по подкаталогам и какая-то часть этих ярлыков ссылается на некоторое приложение которое было перемещено в новое месторасположение. В нашем случае имеется несколько серверов RDS в ферме RD Connection Broker с перемещаемыми профилями пользователей, и пользователям со всех серверов RDS доступна общая сетевая папка с ярлыками, ссылающимися на кучу разных мелких бизнес-приложений (АРМ). Большая часть ярлыков ссылается на приложения App-V, для которых после перехода с версии App-V 4.6 на версию App-V 5.0 потребовалось изменить свойства этих ярлыков. Такая ситуация потребует от нас, как минимум, замену таких свойств ярлыков, как ссылка на объект запуска, рабочая папка и иконка приложения.

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

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

    imageС выходом новой версии 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 имели бы дополнительную отказоустойчивость. Далее мы рассмотрим пошагово процесс создания такой конфигурации…

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

  • SC 2012 Orchestrator - Режим обслуживания SCOM по расписанию

    imageДля начала хочу рассказать предысторию того как я пришёл к использованию System Center 2012 Orchestrator (SCO), которая по сути прямого отношения к самому этому продукту не имеет, но возможно информация изложенная здесь кому-то покажется интересной и даст ответы на некоторые вопросы.

    Итак, жила-была ферма Remote Desktop (RD) Connection Broker состоящая из трёх виртуальных серверов RD Session Host на базе Hyper-V, которые обслуживали пользователей в рабочее время и без каких-либо проблем подвергались резервному копированию с помощью System Center 2012 DPM в нерабочее время. И всё бы ничего если бы не возникшая необходимость начать использовать на этих виртуальных серверах клиента Application Virtualization Client (App-V) for Remote Desktop Services. Клиент то конечно установился и прекрасно справляется со своей задачей – виртуализацией в многопользовательской среде весьма специфических приложений, требующих от пользователей расширенных привилегий в системе. Но вот незадача…сразу после начала использования клиента App-V я заметил две вещи: во первых - на DPM пропала возможность нативно на горячую с помощью метода Backup Using Child Partition Snapshot бэкапить виртуальные сервера фермы полноценно используя VSS (осталась доступной лишь возможность бэкапа с помощью Backup Using Saved State), а во вторых – при бэкапе в режиме Save State каждую ночь фиерично разваливался кластерный экземпляр службы RD Connection Broker. По сути вторая проблема является прямым следствием первой. Но это стало ясно позже...А пока я взялся за изучение проблемы систематично разваливающегося кластера RDS…

    Резервное копирование виртуальных серверов (нод кластера) выполнялось в 3.00 каждую ночь и как раз в это время происходил развал кластера. При этом в логе серверов фиксировалось довольно занятное событие:

    Event ID:10 - The miniport 'Microsoft Virtual Machine Bus Network Adapter' disconnected.

    …и затем буквально через пару минут…

    Event ID: 9 - The miniport 'Microsoft Virtual Machine Bus Network Adapter' connected.

    image_thumb2

    Стало очевидно что в процессе создания резервной копии виртуального сервера методом Save State происходит фактически его кратковременное “замораживание”, что влечёт за собой кратковременную потерю сетевого соединения, и как следствие, приводит к коллапсу службы кластера…Ох уж мне этот Save State… Но почему же исчезла возможность бэкапа на горячую с помощью снапшотов?… Колупание недр интернета привело к мысли о том, что в такой “неполноценности” с точки зрения DPM, виноват виртуальный диск который создаётся в системе для нужд клиента App-V.

    image_thumb1

    Натолкнувшись на заметки Deutscher App-V Blog - App-V und VSS–Backup oder kein Backup… и Gridmetric Blog - Enabling (service) process access to App-V virtual environment пришёл к выводу о том, что между VSS и виртуальным диском App-V какая то давняя врождённая нелюбовь, вызванная, на мой взгляд, аскетичностью архитектуры последнего. Обнаружил на своих виртуальных серверах то, что vssadmin действительно не может получить полный список томов

    image_thumb

    Воспользовался рецептом описанным в немецком блоге, разрешив провайдеру VSS доступ к виртуальному тому App-V c помощью ключа реестра:

    [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftSoftGrid4.5ClientAppFSServiceInclusions]

    "VSS"="swprv" (STRING)

    swprv в данном случае это имя процесса Microsoft Volume Shadow Copy Service software provider. После изменения реестра и перезагрузки виртуальных серверов стало понятно, что ошибка с vssadmin исчезла, но он всё равно не воспринимает виртуальный том App-V как что-то съедобное, и причиной того вероятно является тип файловой системы этого самого тома…

    Надеясь поставить точку в этом вопросе, создал обращение в тех.поддержку MS, изложив всю фактуру происходящего и расписав все проделанные манипуляции в попытках самостоятельно разобраться с проблемой. Результатом стал удручающий ответ с европейского саппорта, подтверждающий мои предположения и не имеющий решения (инцидент был закрыт без списания). Ну что-ж…будем ждать следующей версии App-V и надеяться на то, что ситуация в дальнейшем измениться к лучшему… А пока как-то надо работать дальше и что-то делать с пачкой алертов приходящих от Operations Manager (SCOM) в почту каждое утро после очередного ночного краха кластера.

    Логичным решением подавления генерации алертов SCOM конечно является перевод ресурсов кластера в режим обслуживания (Maintenance Mode) на время выполнения резервной копии. Но штатными средствами SCOM не позволяет выполнять запланированный перевод в режим обслуживания (в будущем времени). Поиск нештатных способов привёл к инструменту Maintenance Mode Scheduling Tool разработанному под SCOM 2007. Сразу смутили попадающиеся в интернете сообщения о глючности данной тулзы, и такие “особенности” как неперевариваемость non-EN локали. И несмотря на утверждения, встречающиеся на формах TechNet, о том, что утилита работает с SCOM 2012, у меня так и не получилось добиться от неё адекватного поведения.

    Далее виделся один путь – использовать командлеты Powershell от SCOM в связке с планировщиком заданий Windows Scheduler. На глаза попадались решения типа OpsMgr 2012: Group Maintenance Mode via PowerShell (the way it should be) но хотелось сделать что-то своё – более гибкое и универсальное, и тут я вспомнил про то, что недавно читал какой-то обзорный материал про возможность управления объектами SCOM из System Center 2012 Orchestrator (в прошлой жизни Opalis). Стало понятно что пора знакомится с этим продуктом Улыбка

    В общем-то здесь и кончается предыстория и начинается история использования Orchestrator.

    Заострять большого внимания на развертывании сервера Orchestrator со всеми необходимыми компонентами, в том числе SQL Server, наверно особого смысла нет, так как эта процедура не должна вызвать особых сложностей. Собственно системные требования к серверу можно найти здесь TechNet Library - System Center 2012 – Orchestrator. Единственное, что вызвало у меня затруднения - это выбор редакции SQL Server, так как в текущем варианте документации есть информация лишь о требовании к версии (Microsoft SQL Server 2008 R2) и Collation (SQL_Latin1_General_CP1_CI_AS). Требование к редакции удалось найти только в документации к Opalis, где сказано что редакция SQL Express не поддерживается и необходима как минимум редакция SQL Standard. Итак, был развёрнут отдельный виртуальный сервер на котором было выполнено:

    • Установка SQL Server 2008 R2 Standard с набором компонент: 
      - Database Engine
      - Client Tools Connectivity
      - Management Tools - Complete
      Порядок сортировки -
      SQL_Latin1_General_CP1_CI_AS
    • Установка System Center 2012 Orchestrator с настройками по умолчанию с полным набором компонент:
      - Management Server
      - Runbook Designer
      - Runbook Server
      - Web Features

    После установки открываем консоль Orchestrator Deployment Manager и сначала импортируем загруженные пакеты интеграции System Center 2012 – Orchestrator Component Add-ons and Extensions (System_Center_2012_Orchestrator_Integration_Packs.EXE), а затем в этой же консоли выполняем Deploy этих пакетов, чтобы они стали нам доступны в консоли Runbook Designer

    Возможно вам окажется полезной пошаговая инструкция от Кевина Холмана Orchestrator 2012: a quickstart deployment guide

    Для нашей задачи важно чтобы был загружен пакет интеграции SCO для SCOM. После его загрузки в консоли Runbook Designer нам станет доступ набор активностей (Activities) этого пакета. Перед началом использования этих активностей при построении нужных нам цепочек Runbook, необходимо настроить глобальные параметры подключения SCO к экземпляру SCOM. Сделать это можно через меню Options > SC 2012 Operations Manager

    image

    Для того чтобы успешно произвести настройку параметров подключения к SCOM необходимо установить на сервер SCO консоль Operations Manager (не забываем также прикрутить к ней последний CU/RU). Задаём имя сервера SCOM и учётные данные пользователя входящего в роль администраторов Operations Manager (я создал для этих целей специальную сервисную учетную запись). После установки параметров проверяем подключение и если оно прошло успешно, то можно приступать к процессу создания Runbook

    image

    В нашем примере Runbook будет состоять из довольно простой цепочки активностей.

    image

    На первом этапе мы ждём кода наступит определённое время суток. Используем для этого активность Monitor Date/Time из раздела Scheduling. В настройках этой активности задаём только один параметр – время запуска.

    image

    На втором этапе выполняется запрос параметров из базы данных SCOM с помощью активности Query Database из раздела Utilities. В свойствах активности на закладке Details укажем содержимое SQL запроса:

    SELECT TargetObjectFullName

    FROM RelationshipGenericView

    WHERE isDeleted=0

    AND SourceObjectDisplayName like 'RDS Servers (VMs with App-V Client)'

    ORDER BY TargetObjectFullName

    image

    Запрос выполняет выборку объектов включённых в специально созданную группу SCOM по имени этой самой группы. В эту группу по правилу явного членства (Explicit Members) включены три ноды кластера (как объекты класса Microsoft.Windows.Computer) и кластерные группы страдающие при распаде кластера (объекты класса  Microsoft.Windows.Cluster.Group)

    image

    Вернёмся к свойствам активности Query Database. На закладке Connection указываем тип базы данных, тип аутентификации, имя сервера и имя БД SCOM (по умолчанию используется OperationsManager)

    image

    На закладке Security определяемся с тем от имени какой учетной записи  будет происходить подключение к БД SCOM. Можно использовать учетную запись службы SCO или же специально созданную сервисную учетную запись, которая, как вы понимаете, должна входить в группу роли администраторов SCOM

    image

    Связываем между собой первую и втору активность с помощью соединителя (Link) с помощью мыши:

    image

    Далее создаём третью активность Start Maintenance Mode из раздела SC 2012 Operations Manager. И сразу создаём соединитель с предыдущей активностью

    image

    В свойствах последней активности на закладке Details с помощью кнопки обзора выбираем ранее созданное глобальное подключение к серверу SCOM. В поле Reason с помощью кнопки обзора выбираем причину перевода объектов в режим обслуживания. В полях Duration и Comment соответственно указываем продолжительность активации режима обслуживания и произвольный комментарий.image

    Подробней остановимся на поле Monitor в котором собственно и нужно указать тот объект/объекты для которых будет включаться режим обслуживания. Если пользоваться кнопкой обзора для этого поля, то откроется не очень удобное окно выбора среди всех полученных из SCOM объектов. Нас эта кнопка не интересует и мы воспользуемся механизмом передачи параметров между активностями, чтобы вставить в это поле значение SQL запроса полученного в активности Query Database. Для этого, наведя курсор на это окно, откроем контекстное меню и выберем пункт Subscribe > Published Data

    image

    Суть в том, что каждая активность в цепочке имеет свои выходные данные (Published Data) которые можно использовать в последующих активностях цепочки. В нашем случае мы должны выбрать выходные данные SQL запроса и параметр хранящий результат запроса - Full line as string with fields separated by ';'

    image

    После этого можно считать, что наша примитивная логическая цепочка выстроена, и теперь мы можем запустить её на постоянное исполнение, нажав на верхней панели инструментов кнопки Check In а затем Run. После этого мы можем наблюдать за результатом выполнения каждой активности в цепочке с помощью окна Log History

    image

    Удалённо можно управлять Runbook и просматривать результаты выполнения с помощью веб-консоли SCO, опубликованной в конфигурации по умолчанию на порту 82

    image

    Пусть описанный пример использования задач автоматизации с помощью SCO и не блещет сложностью, зато чётко решает поставленную перед нами задачу без написания кода скриптов, и даёт представление о базовых возможностях продукта, которые открываются перед нами.  По мере возможности, в дальнейшем мы рассмотрим другие примеры создания логических цепочек Runbook, решающих повседневные задачи администрирования.

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

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

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