Домой Блог

Удаленное управление Mac OS X — расширение консоли SCCM (powershell)

9

Я уже писал про нативное управление Mac OS X через Configuration Manager без дополнительных плагинов. И появилась идея добавить в консоль пункты для быстрого подключения через SSH и VNC к устройству. На самом деле вы можете использовать это и для Linux, т.к. схема абсолютно такая же, за одним исключением, что необходимо будет дополнительно скопировать RemoteSshVnc.xml в каталоги с консолью SCCM 2012 R2 ed9dee86-eadd-4ac8-82a1-7234a4646e62 и 3fd01cd1-9e01-461e-92cd-94866b8d1f39

Давайте обо всем по порядку.

Скачать расширение Mac OS X Tools из Microsoft Gallery Technet.

В архиве 5 файлов:

Install-SshVncV2.ps1 — скрипт для установки расширения, просто копирует необходимые файлы, запускать с повышенными правами;
putty.exe — клиент SSH версии 0.64.0.0;
RemoteSshVnc.xml — XML, который добавляет необходимые пункты в консоль SCCM 2012 R2;
sshvnc.ps1 — powershell скрипт с формой для подключения и вызова клиентов putty и tightvnc;
tvnviewer.exe — клиент tightvnc версии 2.7.10.

remote_control_mac_os_x_sccm_extension_1

Предварительные требования для Mac OS X

В системе Mac OS X в разделе «Системные настройки — Общий доступ» должны быть включены две настройки: Удаленный вход и Удаленное управление.

Удаленный вход включает доступ по SSH.

remote_control_mac_os_x_sccm_extension_12

Удаленное управление включает доступ к рабочему столу.

remote_control_mac_os_x_sccm_extension_13 remote_control_mac_os_x_sccm_extension_14

Установка

1. Из архива запускаем Install-SshVncV2.ps1 и он копирует необходимые файлы в каталоги с консолью SCCM 2012 R2 %Program Files%\Microsoft Configuration Manager\AdminConsole\XmlStorage\Extensions\Actions\ в 331037bb-97e6-4c9b-9c3c-d11e85b51fef и dbb02e2a-3aa6-4e27-82e9-840924d73527

remote_control_mac_os_x_sccm_extension_11

331037bb-97e6-4c9b-9c3c-d11e85b51fef это GUID раздела Devices в консоли SCCM 2012 R2 для устройств со свойством Client Type — Mobile, а dbb02e2a-3aa6-4e27-82e9-840924d73527 GUID, если вы развернули коллекцию с устройствами.

На выходе должно получиться следующее:

remote_control_mac_os_x_sccm_extension_2 remote_control_mac_os_x_sccm_extension_3

2. Если путь установки вашей консоли SCCM 2012 R2 отличается от C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\, тогда необходимо в файле RemoteSshVnc.xml исправить тэги <Parameters></Parameters>.

remote_control_mac_os_x_sccm_extension_16

3. Запускаем консоль SCCM 2012 R2 и видим новый пункт в меню Mac OS X Tools

remote_control_mac_os_x_sccm_extension_4

Подключение к Mac OS X через SSH

В меню выбираем Connect via SSH, в появившемся окне видим IP адрес устройства и нажимаем Connect

remote_control_mac_os_x_sccm_extension_5

Вводим пароль администратора системы. Профит. Дальше уже творим, что хотим. )

remote_control_mac_os_x_sccm_extension_6

Подключение к удаленному столу Mac OS X через TightVNC

В меню выбираем Connect via VNC и IP адрес устройства

remote_control_mac_os_x_sccm_extension_7

Вводим пароль для доступа к рабочему столу

remote_control_mac_os_x_sccm_extension_8

Подключаемся.

remote_control_mac_os_x_sccm_extension_9 remote_control_mac_os_x_sccm_extension_10

Install-SshVncV2.ps1

sshvnc.ps1

RemoteSshVnc.xml

 

Подкаст Мамкин Айтишник #1 — Microsoft Ignite, Slack против Microsoft Teams, Apple и приложения UWP

0

В этом выпуске подкаста Мамкин Айтишник говорим про новинки с Microsoft Ignite (Azure Arc, Microsoft Endpoint Manager, Azure Stack HCI, Hub и Edge), Slack против Microsoft Teams или Microsoft Teams против Slack, Apple собирается разрабатывать приложения UWP и совсем немного про сертификацию Microsoft.

Еженедельная трансляция — https://www.twitch.tv/mamkinboycast
Сайт подкаста — https://mamkinboycast.ru/
Телеграм — https://t.me/MamkinBoyCast

Где послушать?
iTunes Podcast — https://podcasts.apple.com/ru/podcast/id1489218647
Spotify — https://open.spotify.com/show/52cz97vVjA8IS02exZYPY9
SoundCloud — https://soundcloud.com/mamkinboycast
RSS — https://cdn.mamkinboycast.ru/feed/podcast

1:56 — Microsoft Ignite: Azure Arc
7:05 — Microsoft Ignite: Visual Studio Online
13:28 — Microsoft Ignite: Microsoft Ignite: ConfigMgr + Intune = MEM
17:05 — Microsoft Ignite: Productivity Score & Experience Score
22:00 — Microsoft Intune и macOS, Windows vs. macOS
33:20 — Microsoft Ignite: Azure Stack HCI, Azure Stack Hub и Azure Stack Edge
40:33 — Microsoft Ignite: Connected Cache
43:30 — Microsoft Ignite: Power Platform — Virtual Agent
50:02 — Microsoft Ignite: RPA — Robotics Process Automation
52:11 — Как выглядят сервера в Microsoft Azure
55:03 — Про дацатацентры в России
59:47 — Slack vs. Microsoft Teams — “Ok, Boomer”
1:04:43 — Про роботов из Boston Dynamics
1:06:15 — Приложения Universal Windows Platform (UWP) от Apple
1:08:32 — Huawei и Harmony OS
1:11:26 — Совсем немного про сертификацию Microsoft

Мамкин Айтишник — Выпуск #0: Microsoft, Azure, MVP, RD и о жизни облаков в России

0

Да, мы запустили подкаст про технологии под названием «Мамкин Айтишник«. Видео версия уже доступна на ютубе, сам подкаст записывается в прямом эфире на Твиче — https://www.twitch.tv/mamkinboycast <- Подписывайтесь.

В пилотном выпуске у нас был Александр Ермаков. Темы с тайм-метками под видео. ;)

VK — https://vk.com/mamkinboycast
Soundcloud — https://soundcloud.com/mamkinboycast
Spotify — https://open.spotify.com/show/52cz97vVjA8IS02exZYPY9

  • 1:35 — Про Microsoft Regional Director;
  • 7:20 — Как из бухгалтера стать управляющим партнёром в IT компании;
  • 15:55 — Про импортозамещение;
  • 19:12 — Как внедрять решения Microsoft в России;
  • 26:13 — Облако Microsoft — это недорого;
  • 34:12 — Про программу Microsoft MVP;
  • 47:58 — Microsoft Regional Director — кто эти люди и что за программа?
  • 54:34 — Cortana на русском?
  • 1:01:57 — Microsoft в 1995 году и сейчас;
  • 1:04:06 — Почему умер Windows Mobile;
  • 1:11:50 — Самое интересное с Microsoft Ignite: когнитивные сервисы, голосовые ассистенты, Azure Stack и прочее;
  • 1:20:24 — Про будущее Microsoft Azure в России, конкурентов и РКН;
  • 1:31:39 — Секция “Насколько ты хорошо знаешь продукты Microsoft”;
  • 1:41:02 — Блиц как у Дудя для Александра Ермакова.

Аудио версия уже доступна в Spotify. Надеюсь, что скоро подоспеют iTunes и Yandex Музыка.

SCOM и Grafana: рисуем графики — часть 2: Drill Down, Data Warehouse и docker

8

В прошлом посте мы забирали данные из OperationsManager базы SCOM’a, чтобы что-то нарисовать в Grafana и у нас получился примерно вот такой вот дашборд:

В этом посте разберемся, как сделать Drill Down, чтобы при клике на панель мы могли провалиться в другой дашборд, где бы была уже собрана более детальная информация по конкретному сервису/серверу. В Grafana это называется Data link и появилось с версии 6.3. Grafana может передать в другой дашборд любую переменную с именем вашего сервиса, отметкой времени и т.д., а мы уже эту переменную обработаем в новом дашборде. В нашем случае это будет объект в SCOM’е или проще — FQDN-имя сервера. Про встроенные переменные можно почитать в документации Global Built-in Variables.

Но перед тем как приступить к построению дашбордов, нам необходимо решить, а какие данные и откуда будем тянуть. Здесь есть ряд нюансов. В System Center Operations Manager есть две базы: OperationsManager и OperationsManager Data Warehouse. SCOM пишет данные одновременно и в одну, и в другую, но вот хранятся они там по-разному, а это будет очень сильно влиять на то, как ваши графики будут отображаться. Если мы берём базу OperationsManager, то данные мониторинга, событий, алёрты, метрики и прочее хранятся всего 7 дней. Определяется это в консоли SCOM’a — Administration — Settings — Database Grooming или в powershell: Get-SCOMDatabaseGroomingSetting и Set-SCOMDatabaseGroomingSetting.

Понимаете к чему я веду? Когда вы захотите посмотреть метрики за месяц, то будет примерно такая картина.

Ага, все верно, данные за 7 дней и всё. Но где же остальные данные? Они хранятся в базе Data Warehouse, но с ними другие приколы. Если мы возьмем один и тот же сервер и сравним одну и ту же метрику, например нагрузка на CPU, то увидим примерно следующее.

Вот данные из баз OperationsManager и Data Warehouse. Видно, что в левой части данные хранятся согласно правилам сбора, а в правой части — среднее значение за час.

Пример правила для сбора метрики по CPU в Windows Server 2012 R2

Но почему так? Смысл в том, что данные в Data Warehouse не складываются просто абы как, а агрегируются в уникальные Datasets, которые представляют разные типы данных (события, алёрты, метрики и т.д.), которые еще имеют разный тип агрегации (raw, hourly, daily). Т.к. в данном запросе я «селектнул» из Perf.vPerfHourly, то и данные представлены часовым «шагом». Но вы скажите: «эй, там же есть raw (сырые) данные, а давай мы дёрнем из них и все будут счастливы». Raw данные хранятся 10 дней и менять это значение не имеет смысла, т.к. метрики это одна из самых прожорливых вещей в Data Warehouse.

То, сколько хранить данные в Data Warehouse можно посмотреть и изменить. Самый простой вариант это либо DWDataRP от Kevin Holman, либо SCOM DataWarehouse Grooming Settings. Я думаю, что те, кто сталкивался с чисткой базы Data Warehouse знакомы с этими тулзами.

DataWarehouse Grooming Settings

Какой из всего этого можно сделать вывод? Если мы хотим построить график из данных в базе Data Warehouse, то у нас всё равно будут средние данные за час.

Например, вот данные в промежутке между 3-мя и 6-ью утра, есть какое-то изменение по CPU, но на самом деле данные выглядят вот так (см. ниже).

У нас нет плавного роста с 3-х утра, а есть ровный скачок в 4:15, далее 30 минутная нагрузка и полный спад. Просто, чтобы вы понимали с какими нюансами придётся столкнуться, если вы вдруг захотите что-то проанализировать. Всё не так очевидно. ;)

Ладно, пора приступить к созданию дашборда. Первым делом добавить новый Datasource. В этом посте написано, как создать, только там мы добавляли доступ к базе OperationsManager, а здесь добавляем OperationsManagerDW.

Открываем Grafana и создаем новый дашборд, название придумайте сами.

В меню Variables создадим новую переменную hostname с типом Constant.

Если вы хотите использовать данные из OperationsManager, тогда смело открывайте первый пост и забирайте все запросы для метрик производительности из него, а вот для Data Warehouse будет всё ниже.

Получаем список хостов из группы All Windows Computers.

Получив список агентов, можно посмотреть, что у нас хранится в Perf.vPerfHourly и как называются счетчики.

Когда получили список ObjectName и CounterName для нашего хоста, можно уже вытащить их значения из DataWarehouse.

Так, я думаю, что теперь логика понятна, как вытаскивать метрики из базы, осталось совсем немного доработать запрос в Grafana, чтобы когда мы переходили с первого дашборда, нам отображались метрики для нужного нам хоста.

Открываем Grafana и создаем новую панель. Наш запрос в Grafana теперь будет выглядеть вот так. $__timeEpoch(Perf.vPerfHourly.DateTime) — объяснит графане, что это datetime, Perf.vPerfHourly.AverageValue as value — это значение, vManagedEntity.DisplayName in(‘$hostname’) — примет в переменную $hostname значение из первого дашборда.

Ну, и теперь набирайтесь терпения, т.к. вам надо создать столько панелей, сколько вы хотите, для всех метрик, которые вам нужны. Да, придется немного посидеть с sql-запросами. После того, как вы создали все нужные вам панели, необходимо настроить линк с первого дашборда в ваш новый.

Открываем наш первый дашборд, выбираем Health State и нажимаем Edit.

Переходим в General, нас интересует Panel Links, вбиваем Title, затем URL на наш второй дашборд и добавляем к нему ?var-hostname=${hostname}

Теперь при клике на красно-желто-зеленый прямоугольник, вас будет перебрасывать в новый дашборд, где вы можете собрать сколько угодно графиков, но уже по конкретному сервису/серверу/приложению. На самом деле, одними графиками дело не обходится, если очень хочется, то можно нарисовать хоть весь статус вашего Distributed Application, понавытаскивать данные в какие-то таблички, подцепить логи и т.д. Если вы дошли до этого места и что-то попробовали, то обязательно поделитесь в комментариях, как все прошло, возможно, что у вас есть какой-то свой опыт и вы хотели бы поделиться им.

И еще один момент про который я хотел бы написать — это как запустить графану «на попробовать». ;) Самый просто вариант взять любой windows хост, хоть клиентскую Windows 10, поставить себе Docker Desktop for Windows. После установки выполнить несколько простых манипуляций: — создать volume для хранения настроек графаны, которую вы запустите в контейнере; — запустить контейнер. Всё.

Вуаля, открываем браузер, идем на localhost:3000, стандартный admin/admin и наслаждаемся.

зыж docker start grafana, чтоб просто запустить контейнер.

зыж спасибо, что дочитали до конца. ;) Лайк. Шер. Алишер. Фидбек в комментарии. Peace.

Играем с Anomaly Detector в Cognitive Services от Microsoft

0

В анализе данных есть несколько направлений для поиска аномалий: детектирование выбросов (Outlier Detection) и «новизны» (Novelty Detection).

Но перед тем, как рассматривать поиск аномалий, необходимо рассмотреть независимое исключение весов. Переход к групповому случаю не представляет существенных сложностей. Следуя стандартной схеме ARD, пусть априорное распределение на веса будет нормальным с центром в нуле p(w) =N(0,α^2), апостериорное — нормальным с произвольными параметрами qφ(w)=N(μ,σ^2), где μ ∈ Rm, α, σ∈Rm×mиα,σ — диагональные матрицы. Далее для упрощения выкладок считается, что σi=σii. KL-дивергенция для отдельного веса wi будет выглядеть так:

Можно исключить веса α, выразив их максимальные значения через μ и σ:

Тогда первую формулу можно упростить:

и итоговая формула примет вид … и тут вы такие «Чиго?! Слышь, Масян, воу, воу, палехче, мы тут пост пришли читать, чо началось-то?». ;)

Чуть меньше года назад когнитивные сервисы Microsoft пополнились новым сервисом — Anomaly Detector. Если простыми словами, то это обычный REST API сервис, который позволяет отслеживать и обнаруживать отклонения в данных временных рядов с помощью машинного обучения. Вы отправляете ему JSON обект, а он скажет, что из этих данных выбивается из общих значений. Данные можно отправлять, как в реалтайме (real-time) или в потоковой передаче, так и просто на проверку целой пачкой (batch).

Сразу, наше любимое, 20 000 запросов в месяц — бесплатно. Мы же любим, когда что-то бесплатно. ;)

Так, это всё классно, но какие данные мы можем туда отправить? Первое, что приходит в голову и каких данных точно в избытке, то это данные системы мониторинга. Почему бы и нет? У нас есть постоянно наполняемая база счетчиков производительности, есть метрики изменений CPU, RAM, объема диска и т.д. К сожалению, у меня нет никаких IoT-устройств, где бы можно было отследить температуру, влажность или другие показания. Как мне кажется, то это один из наглядных примеров для использования Anomaly Detector.

Anomaly Detector можно найти в Marketplace на портале Azure, там ничего сложного. Нашли, создали, развернули.

Данные будем брать из системы мониторинга SCOM (System Center Operations Manager) за последний день обычным SQL-запросом.

Ок, что-то есть, какие-то метрики мы видим, но т.к. нам необходимо немного подготовить данные для Anomaly Detector, надо их чуть-чуть преобразовать. Мне удобней это делать через python. Для этого подключимся к базе сразу через python и соберем все в словаре, который представим в виде JSON. pymssql даёт возможность выполнять sql запрос, а точнее метод fetchall() и получать на выходе словарь (dict).

Время и данные необходимо поместить в timestamp и value в значение ключа series. На выходе получаем файл testdata.json примерно с таким набором {«series»: [{«timestamp»: «2019-10-20T22:02Z», «value»: 6.00938940048218}, {«timestamp»: «2019-10-20T22:07Z», «value»: 5.63296794891357}, {«timestamp»: «2019-10-20T22:37Z», «value»: 5.63296794891357}, {«timestamp»: «2019-10-20T22:42Z», «value»: 11.3306369781494} ….

Теперь надо написать обращение к REST API Anomaly Detector.

subscription_key необходимо подставить из Keys на портале Azure в сервисе Anomaly Detector.

Можно сказать, что цель достигнута…. почти. ;) У меня было два типа данных: с явно выраженной аномалией или, говоря другими словами, скачком по загрузке CPU и «ровные» данные без каких-либо скачков.

С левой стороны аномалий нет, а вот с правой стороны Anomaly Detector посчитал, что индексы 106, 234 и 292 со значениями 20, 19 и 31 явно выбиваются из общих показателей. Чтобы данные сделать более наглядными, надо расчехлить pyplot из python и порисовать графики. ;)

Для этого у Microsoft есть Microsoft Azure Notebooks, где можно запусть Jupyter. Кстати, тоже бесплатный. Наша задача не только построить график полученных данных, но и выделить точки, которые Anomaly Detector считает аномальными.

И …. получаем такой график. Как видим, что вот наши 3 значения. Но я решил пойти дальше и посмотреть, что покажет Anomaly Detector, если мы немного нагрузим CPU … и получился уже вот такой график.

Прямоугольная секция — это данные с предыдущего графика, это наши предыдущие 3 точки, Anomaly Detector их уже не учитывал, а вот резкий скачок, как видим, отметил в 3-х значениях: начало подъёма, пик и среднее значение, которое всё еще выбивается из среднего набора данных.

Я думаю, что это хороший пример, когда для критического сервиса можно подключить такую аналитику. Почему я вспомнил про Anomaly Detector? На прошедшем Microsoft Azure AI Hackathon один из победителей сделал IoT устройство, которое собирало данные с термодатчика внутри жизненно важной среды, отправляло их в Azure IoT-Hub, раз в минуту запускался код в Azure Functions, который собирал данные в Anomaly Detector и если температура начинала расти, то отправлял уведомление через Twilio API в Whatsapp или по SMS. До ужаса простое решение, но работает как часы.

Можно написать бота, которые будет генерировать вот такие картинки с графиками, где уже будет наглядно видно, что что-то начинает идти не так и прикреплять вам в сообщение с данными от мониторинга, разных датчиков и т.д.

Документация по Anomaly Detector — https://docs.microsoft.com/en-us/azure/cognitive-services/anomaly-detector/overview

Ну и наш любимый раздел — «слышь, а чо по деньгам?!» ж)

Serverless в Microsoft Azure или боты для telegram на Azure Functions и python

3

Это продолжение серий постов про «Бомжуем в Microsoft Azure» или как нам запускать сервисы в облаке и при этом не тратить много-много денег.

В Microsoft Azure есть такой сервис Azure Functions — это бессерверные вычисления. Суть его в том, что у вас есть какой-то код/функция, которая запустилась по какому-то триггеру, отработала, сделала что-то и спокойно умерла, ожидая, когда её вызовут еще раз. Такой Function as a Service. Вам не надо настраивать сервера, платформу или инфраструктуру, вы просто берёте свой код и запускаете где-то в облаке.

В Azure Functions существует несколько триггеров, с помощью которых вы можете запустить выполнение функции: HTTPTrigger, TimerTrigger, CosmosDBTrigger, BlobTrigger и т.д. Подробное описание всех триггеров есть в документации. Ажуровские функции поддерживают запуск кода на .net core, node.js, python, java и powershell core (preview) в Linux и Windows среде, включая собранные в docker-контейнерах.

Но почему я решил написать про Azure Functions. Знаете почему? Потому что выполнение функций стоит копейки. 1 миллион запусков в месяц обойдётся в 12,50 рублей. Да, да, двенадцать рублей и пятьдесят копеек. И вот, в один прекрасный субботний вечер, я подумал, а что если запустить телеграмовского бота внутри ажурных функций, но перед тем, как окунуться в мир ажура, надо рассказать про нюансы.

Для telegram, как и для любой платформы существует несколько способов запуска ботов: polling и webhook. Polling не требует сертификатов и публикации вашего приложения, он просто раз в секунду, например, идёт в API мессенджера и спрашивает «Есть чо?», если есть, то в код прилетает целая пачка объектов JSON, с которыми вы уже развлекаетесь. Это просто, не очень быстро работает при больших нагрузках и мессенджеры не любят, когда вы их регулярно пинаете. Webhook же работает наоборот, вы сообщаете мессенджеру endpoint, где живёт ваш фронт и когда в мессенджере происходит какая-то активность, то он просто присылает вам сообщения, но есть нюансы, так как вам требуется публикация вашего приложения, SSL-сертификат и FQDN имя.

В Azure Functions есть Consumption Plan — это оплата за потребление, но у него есть стандартное ограничение на выполнение функции — 5 минут, его можно расширить, но главная идея в том, что мы не будет крутить постоянно запущенный код для бота внутри Azure Functions, мы скажем телеграму, чтобы он сам триггерил функцию на запуск (тот самый Webhook) и вся магия уже будет происходить внутри кода. Для этого будем использовать HTTPTrigger.

Для Azure Functions можно писать и тестировать всё локально в VScode, а уже только потом заливать всё в облако. Нам необходимо создать функцию для анонимного HTTP триггера.

VScode создаст проект, все необходимые файлы и даст возможность запускать локально функции, как будто мы в облаке. ;) Открывайте Debug, запускаем и смотрим, что всё работает, видно, что реквесты летят и видно разные статусы.

Для работы с telegram будем использовать простую либу — pytelegrambotapi. Идём в @botfather в телеграме, получаем токен, тут ничего нового. Плюс нам понадобится ngrok для локального тестирования. Если вы еще с ним не сталкивались, то он просто поднимает тоннель для тестирования приложений локально, может пробросить порт, выдаёт вам домен, поддерживает https и пишет логи. Очень крутая и бесплатная штука.

В нашем проекте надо поправить несколько файлов. В requirements.txt добавляем pyTelegramBotAPI и requests.

host.json

По-дефолту, в Azure Functions URL формируется https://…/api/ЧтоТоЕщё, а если хотите убрать /api/, то надо оставить routePrefix пустым.

function.json

Это уже конфиг запуска функции. ScriptFile — файл запуска, authLevel в нашем случае анонимный, тип триггера, методы и route. Route добавляется к урлу функции, т.к. /api/ мы убрали, то вот route это и есть «ЧтоТоЕщё«.

__init__.py — это просто эхо бот, который отвечает на команду /start

Немного пояснений по коду. Всё, что прилетает в Azure Functions уходит в метод main() в файле __init__.py. Затем данные через триггеры уходят в req, которая описана в function.jsonname. Это основная функция, которая запускается первой, в ней мы и запускаем процессинг обработки сообщений. Для req: func.HttpRequest мы принимаем http-запросы и делаем возврат в func.HttpResponse — 200. Здесь подробнее, что есть в пакете azure.functions.*.

Теперь надо объяснить телеграму, куда слать все сообщения. Для этого в pyTelegramBotAPI есть bot.set_webhook, но с ним лучше особо не играться, т.к. телега просто блокирует запросы от вас, поэтому самый простой вариант это использовать curl или просто открыть в браузере.

После того, как вы установили webhook для телеграма, получили токен для бота, можно запустить локально. Помните, что ngrok при каждом перезапуске в бесплатной версии генерирует вам новый URL. Запускать ngrok надо с параметрами ngrok http 7071 — это означает, что весь трафик будет перенаправлен к вам локально на порт 7071, где крутится локальная функция. Например, webhook c ngrok будет такой — https://0357c88a.ngrok.io/tlg

Развернуть нашу функцию в Azure Functions можно разными способами (Azure CLI, портал Azure, Visual Studio), самое простое использовать VSCode c плагином Azure Functions.

Он создаст ресурсную группу, хранилище, Application Insights для мониторинга и сбора логов и саму функцию.

Вот этот URL+route из function.json и будет нашим webhook для telegram — https://mynewfunctelegram.azurewebsites.net/tlg

Если открыть Live Metrics Stream в Monitoring нашей функции, то будет видно прямой стрим данных и что происходит с ней. ;) То, что вы видите задержку на клиенте это на самом деле проблема между моим прокси и телеграмом, так что Azure Functions отвечает очень бодро.

Видно все, что происходит с функцией, что она получает и куда отправляет, доступен поиск через Log Analytics.

Какой можно сделать вывод из всего этого. Azure Functions клёво, я точно продолжну ставить эксперименты, попробую перетащить туда нашего бота из групп и посмотреть, как это всё будет работать в полупродакшене. Вам не надо думать о сертификатах, есть лайв мониторинг, легко интегрируется с blob storage или azure cosmosdb, быстрый деплой. Короче, есть куда копнуть еще. ;)

зыж ну и прайс, естественно — https://azure.microsoft.com/ru-ru/pricing/details/functions/

Бомжуем в Microsoft Azure или хостим сайты за бакс в месяц: часть 1

2

Представим, что вы хотите разместить простой веб сайт в Microsoft Azure и не собираетесь потратить на это много денег. Что нам для этого надо? Azure WebApp? Но у нас же обычная статика. Отдавать почти 50$ в месяц? Или может запустить в контейнере? Собирать контейнер? Или поднять kubernetes и там создавать свои поды? Поднять свою виртуальную машину и настроить nginx или apache? Серьезно? Нам же нужно просто запулить свой лендинг и наслаждаться.

На самом деле, есть простой выход. В прошлом году, в Azure появилась возможность строить веб сайты на обычном хранилище — Azure Storage. В этом посте мы поговорим только про статику, про запуск более сложных вещей, аля с бэком под flask и vuejs будет в следующем посте. Там тоже есть интересные вариант. ;)

Идея в том, что в свойствах вашего Storage Account есть настройка — Static Website, который создает в блоб хранилище каталог $web, куда будут переправляться все запросы, которые приходят на url вашего Storage Account.

Наша задача просто прописать индекс файл, всё. Затем мы можем открыть в вебе Storage Explorer (preview) или скачать Microsoft Azure Storage Explorer и залить наш веб сайт. Для примера, наш прямой адрес на Storage Account — https://telegramwebsites.z6.web.core.windows.net

Но, мы можем хостить много сайтов на одном Storage Account и при этом платить за это ооооочень не много. Для этого мы будем использовать CDN, которые тарифицируется по потребленному трафику. Я выбрал самый простой вариант — Standard Microsoft CDN.

Внутри Storage Account создадим нужное количество каталогов для наших будущих сайтов. В моём случае это site1, site2, site3.
Для примера я взял шаблоны bootstrap и загрузил их в эти каталоги.

Да, как вы правильно понимаете, если теперь зайти на https://telegramwebsites.z6.web.core.windows.net/site1 или https://telegramwebsites.z6.web.core.windows.net/site2 или https://telegramwebsites.z6.web.core.windows.net/site3, то что-то там откроется, но нас это пока не устраивает. Мы ведь серьезная компания и такой адрес нам не совсем подходит. Кроме этого видно, что из-за путей есть проблемы с загрузкой js и css, но сейчас это не важно.

Вернёмся к CDN. Он нам нужен, чтобы спрятать за своими доменами вот эти созданные каталоги.

Откроем CDN и создадим Endpoints.
В Name будет url нашего входа в CDN, в Origin Hostname — url нашего Storage Account, Origin path — каталог на Storage Account.

Получились вот такие 3 эндпоинта: http://site1.azureedge.net/, https://site2.azureedge.net/, https://site3.azureedge.net/
Если вы перейдёте по ним, то вам уже откроются полноценные веб сайты, которые были выше по урлу storage account. И js, и css успешно подгружаются, где включен https — работает https, все прекрасно. Но еще нет. Теперь мы прикрутим свои домены. ;)) Вы же помните, что мы серьезная организация.

В свойствах каждого Endpoints есть настройка — Custom domains (она, кстати, есть и в Storage Account и если вам нужен только один веб сайт, то там же можно сделать что-то подобное).
Но кроме того, что мы можем туда добавить свой домен, мы можем заказать сертификат от самого DigiCert и всё в одной консоли. ;) Как вам? Есть нюансы.

Перед тем, как добавить домен, нам необходимо объяснять Microsoft Azure, что он наш. Для этого нам необходимо создать cname запись.
Более подробно есть в документации, но конкретно в моём случае, у моего регистратора в панели это выглядит так:
cdnverify.contoso.com CNAME cdnverify.contoso.azureedge.net

Ждём несколько часов, возвращаемся в настройки нашего эндпоинта и добавляем домен. Но и это еще не всё. ;) Теперь мы можем включить https для нашего домена. Тут есть нюанс. Валидация от DigiCert CA происходит через cname на www: www.contoso.com CNAME сontoso.azureedge.net Но вы же прекрасно понимаете, что contoso.com и www.contoso.com это так-то разные вещи, а мы хотим, чтобы работало и на корень, и на www. После того, как DigiCert не найдет cname запись, они отправят вам на почту письмо с подтверждением. Там просто кликнуть ссылку, поставить галку и всё. В моём случае мне пришлось закинуть mx записи на Яндекс и просто форвардить всю почту на один мой аккаунт.
DigiCert будет отправлять на эти ящики:
admin@your-domain-name.com
administrator@your-domain-name.com
webmaster@your-domain-name.com
hostmaster@your-domain-name.com
postmaster@your-domain-name.com
Вот так это выглядит. ;) Они отправили на все.

Кстати, на www можно прописать cname и добавить в Custom Domains. Картинка примерно такая.

А теперь вещи, которые не стоит делать на боевых сайтах. Смотрите, какая ситуация. На www.kodeks12.ru у нас есть cname, который отправляет на https://site3.azureedge.net, но для корня домена нам же требуется прописать А-запись. Вот тут мы сделаем небольшую хитрость, которая показала то, что в принципе все может работать месяцами и никаких проблем пока не было. Мы возьмём nslookup site3.azureedge.net и пропишем IP адрес, которые отдаст нам CDN. Да, это неправильно, да, если что-то пойдёт не так, нам придется менять адреса на DNS, но, как показывает практика — это работает.

Вот наш IP и вот наша А запись.

С www таких проблем не будет, но мне вот глаз режет это www в начале имени домена. Для вариантов аля blog.domain.com таких проблем не будет.
Для примера, на эндпоинт https://site2.azureedge.net я прописал http://azure.aibootcamp.ru/ и http://az.aibootcamp.ru/ И да, туда тоже можно подвязать https. ;)

Подведем итог? Что мы получили?
Мы создали Storage Account — https://telegramwebsites.z6.web.core.windows.net/
Создали каталог — https://telegramwebsites.z6.web.core.windows.net/site3
Прокинули в этот каталог все запросы через CDN — https://site3.azureedge.net/
Привязали домен с https — https://kodeks12.ru

Из https://telegramwebsites.z6.web.core.windows.net/site3 в https://kodeks12.ru

И самое главное. Бабки! Стоит то сколько? Давайте считать. За Custom domains дополнительной оплаты нет, мы платим только за Storage Account. Плюс, мы платим за траффик через CDN. Но стоит это, как бы вам сказать, очень мало.
1,14$ — вот столько стоит storage 1 GB данных и по 100 000 операций чтение/запись в месяц. В МЕСЯЦ, Карл! Один доллар и четырнадцать центов.
А это CDN — First 10 TB /Month — 5.07РУБ per GB. Пять рублей, П Я Т Ь. Да, да, пять рублей. ;) Сами посмотрите — https://azure.microsoft.com/en-us/pricing/details/cdn/
Я открыл расходы по подписке и там как бы вот так:

На этом пока хватит. У нас есть какой-то статичный сайт, все работает. В следующем посте разберемся, как сделать что-то более сложное, в стиле SPA (single page application), но тоже за сущие копейки.

System Center Operations Manager и Grafana: рисуем графики

6

for those people who do not understand Russian please use the google translator

Представим, что у вас есть System Center Operations Manager, агент собирает метрики, что-то там мониторит, мучает WMI ваших систем и наступает тот момент, когда вы хотите собрать дашборд или быстро посмотреть метрики, и вот тут начинается веселье. У нас есть «чудесная» консоль, есть репорт сервер с SSRS, есть даже веб консоль, но всё это такое … ну, вы поняли, не очень быстрое, не очень красивое и прочее.

В мире красноглазых и не очень, я про DevOps если что, есть много интересных и бесплатных решений, и одно их них — это Grafana. С версии 5.0+ она поддерживает источник данных для Microsoft SQL, и тут я подумал, хм, у нас же есть 2 базы данных OperationsManager и OpsMgr Data Warehouse. А почему бы нам «не затолкать» в эту самую Grafana наши метрики. Очень удивило, что в интернете постов на эту тему почти нет. В посте на реддите все закончилось «I just started trying to find useful tables last week. Not much luck so far». Ну ок, будем разбираться.

Есть два способа: правильный и второй.

Способ правильный: берём Telegraf, InfluxDB и Grafana. Telegraf у нас отгружает метрики в базу InfluxDB, а Grafana рисует нам все. На самом деле есть еще более правильный способ. Вы отгружаете метрики в какую-нибудь PostgreSQL и там храните все данные 1-2-3 года или сколько вам надо, а вот для отрисовки в Grafana используете InfluxDB, т.к. она отлично подходит для хранения временных рядов.

Способ второй: у нас уже есть все метрики и все данные в нашей MS SQL базе, а Grafana умеет в t-sql запросы, пишем нужные нам селекты, а Grafana всё рисует. Вот про второй способ и поговорим.

Я не буду писать про то, как установить Grafana, вы можете её сразу запустить в dockere. Напомню только то, что ваша база от SCOMa должна работать в mixed режиме, т.к. из Grafana мы будем подключать через SQL учетку, без всяких Windows аутентификаций. Если у вас Grafana на винде, то забейте, все будет работать. Если у вас настроен krb5.conf, то молодцы. Короче, разберётесь, а то тут еще целый пост можно делать, как аутентифицироваться на «скуле». Ну и понятно, что вы должны нарезать права для чтения — db_datareader.

Grafana поставили, добавляем новый Data Source, заполняем все данные для нашего MS SQL сервера. Добавлю, что пока в этом посте мы будем работать с OperationsManager базой. Да, я знаю, что метрики там хранятся за 7 дней, ну или как у вас настроено в SCOM — Administration — Settings — Database Grooming. С DataWarehouse разберемся потом.

Создаём новый dashboard и сразу идём в его настройки (Settings в правом углу). Нам необходимо создать новую Variables. Идея в том, что в нашем дашборде будет выпадающее меню и в зависимости от выбора в этом меню будут меняться метрики на экране. Привяжемся к имени хостнейма, а точнее выгрузим все FQDN от агентов, которые есть в SCOM.

Отлично, имена хостов у нас есть. Мы создадим несколько панелей: графики с производительностью, список текущих алёртов из консоли и отобразим суммарное здоровье самого агента SCOM.
Поехали.


Создаем новую панель Graph и нарисуем несколько графиков: % Processor Time, % Memory Used, Network Bytes Total/Sec и Disc Average sec/transfer. Можно получить и всё остальное, но как? Для этого надо получить ObjectName и CounterName. Для каждого агента SCOM эти данные будут разные, все зависит от ваших пакетов управлений. Берем имя любого хоста с агентом SCOM и селектим в базу.

Например, контроллер домена. Видим, что кроме метрик производительности, у нас еще есть правила, которые собирают метрики от VMware, от пакета управления Active Directory и т.д.

Для отрисовки панели Graph необходимо передать 3 значения: время, значение и имя метрики. В нашем случае имя метрики будет имя хоста, значение — данные в базе и время. Прямой селект в базу будет такой:

Но для графаны его требуется немного подправить, чтобы как минимум работала кнопка для фильтра по времени и графана понимала, где какие значения. Для этого метрики времени оборачиваем макросом $__timeEpoch(data), добавляем в запрос работу с фильтром $__timeFilter(data) и подключаем нашу переменную $hostname — path in($hostname). Последнее будет передавать в запрос все хостнеймы, которые мы выберем в выпадающем меню нашего дашборда.

Выбираем наш datasource и копи-пастим t-sql запрос.

Создаем еще 3 панели для % Memory Used, Network Bytes Total/Sec и Disc Average sec/transfer.

Если вы всё сделали правильно, то должно быть что-то такое. При выборе хостов в выпадающем меню, они будут добавляться на графики.

Теперь мы можем добавить представление Alerts из консоли Operation Manager. Создадим панель Table и добавим запрос.

! обратите внимание ! Ниже sql запрос, в блоке кода никак не хочет ставить знак < — в двух местах AND av.ResolutionState < 255

Так мы получили все Critical и Warning, которые вы видите каждый день в консоле. Для того, чтобы разукрасить табличку, то на вкладке Column Styles требуется немного поиграть с настройками. Severity возвращает целые значения — 0, 1 и 2.

Теперь можно добавить статусы агентов для класса Windows.Computer. Есть несколько вариантов. Мы можем создать таблицу и выводить статус, либо можем создать панель Singlestat и в зависимости от количества выбранных хостов, панели будут сами отрисовываться в дашборде.

Для таблицы создаём Table, добавляем запрос, меняем в Column Style настройки.

Для Singlestat

Для Singlestat на вкладке потребуется добавить значение hostname в For each value of, тогда при выборе эта панель будет «размножаться», как на скрине выше.

И совсем немного разукрасить в Options.

И вот наш финальный дашборд. Временные интервалы в правом углу и выпадающее меню работают, авторефреш — ок. Энджой.
В будущем разберемся, как сделать дриллдаун по панели и уже провалиться внутрь требуемого сервиса/сервера/тэга.

macOS, Microsoft Office 2016, Configuration Manager и Parallels — управляем обновлениями

0

Собрал пост по крупицам о том, как автоматизировать обновления Microsoft Office 2016 для macOS. Да, вот так вот внезапно. В посте присутствуют такие слова, как bash, python, powershell, docker, ConfigMgr, Parallels и всё только самое современное. ;) Ну, что? Поехали?

Предисловие

Идея в том, что у нас есть пачка девайсов под управление macOS на которых стоит Microsoft Office. Софт на них централизованно катится с ConfigMgr, какие-то апдейты для операционки из аппстора, а вот с офисом беда была. MS Office пока нет в маковском аппсторе, а обновлять и следить за ним очень надо, поэтому было решено, что нам требуется что-то, что будет его обновлять. ;)

Вы ведь знаете, как работают обновления для офиса на Windows? Microsoft выпустила апдейты, wsus отсинхронизировал каталог, вы скачали обновления и раздали их через WSUS или SUP у ConfigMgr, апдейт агенты отчитались с клиентов до WSUS и дальше процесс более-менее понятен. На macOS нет Windows Update Agent, маки не отчитываются на WSUS. Так что же нам с ними делать?

У Microsoft есть Microsoft AutoUpdate (MAU). Вот он и занимается проверкой версий и стучит в CDN Microsoft для проверки и скачиваний последних обновлений. MAU можно скачать здесь — https://docs.microsoft.com/en-us/officeupdates/release-history-microsoft-autoupdate

С версии MAU 3.18 и выше в /Library/Application\ Support/Microsoft/MAU2.0/Microsoft\ AutoUpdate.app/Contents/MacOS появилась консольная утилина msupdate. Весь список команд можно глянуть через ./msupdate —help
Вот она и занимается обновлением офиса. Что нам от неё надо? Она читает настройки из plist com.microsoft.autoupdate2, в котором мы уже можем настроить всё, что нам надо. Запомните главную вещь, настройки MAU берёт только из пользовательского плиста в ~/Library/Preferences/, это важно.

Но мы ведь хотим, чтобы обновления раздавались из внутренней сети, поэтому в первую очередь нам требуется утянуть из CDN все апдейты для офисных продуктов. В этом нам поможет powershell скрипт.
Всего есть 5 каналов поставки офиса: Production (ежемесячные релизы), External (или Insider Slow — ранний доступ), Internal (без понятия, но в документации присутствует), Custom (наш собственный) и InsiderFast (недельные релизы).

Внимание! Одна ветка Production занимает > 13 ГБ, если добавлять остальные, то выйдет > 25 ГБ.

.\psMacUpdatesOFFICEv2.ps1 -channel Production -IISRoot C:\inetpub\wwwroot -IisFolder maucache -TempShare C:\Temp

Скачали? Молодцы.

Первым делом нам надо раскатить на клиентов новую версию MAU, чтобы полностью контролировать ситуацию. Для тех, у кого управление маками нативное через ConfigMgr, то развлекайтесь сами с конвертацией pkg пакета, у меня всё это давно перестало работать на High Sierra. В Parallels все ставится через пакет: installer -pkg Microsoft_AutoUpdate_4.0.18061000_Updater.pkg -target /
И всё, раскатили MAU.

Далее, нам же нужно куда-то сложить 25 гигов, чтобы клиенты могли забрать. Вариантов несколько.

Вариант первый — используем нашу точку распространения на ConfigMgr, а точнее наш IIS. Только нужно чуточку подшаманить.


В Default Web Site создадим директорию, которая будет слинкована на UNC путь, где у нас будут лежать апдейты. Не на диск же Ц всё это складывать. ж) И не забываем добавить MIME types, а то IIS ничего не знает про файлы форматов dmg/pkg и будет возвращать 404.


.dmg — file/download
.pkg — file/download

Вариант два — засунуть всё это в докер образ и с выходом очередных апдейтов для офиса просто делать ребилд докер контейнера.
За основу возьмем контейнер nginx из докерхаба и в две строчки в dockerfile соберём контейнер с апдейтами.

docker build -t office-updates .

Запуск docker run —name office-updates -d -p 8080:80 office-updates

После запуска nginx отдаёт нам всё, что надо.

Вариант два с половинкой — маунтить волюмом в докер шару с апдейтами. Здесь билд уже будет проходить за 3 секунды.

Так, теперь клиенты у нас по http смогут забрать апдейты. Пора разобраться, как им объяснить, где же их забирать и как контролировать этот процесс.

В ConfigMgr у нас есть замечательная штука под названием Configuration Items. Все настройки MAU берёт из пользовательского com.microsoft.autoupdate2. Читаем его: defaults read com.microsoft.autoupdate2 и видим что-то подобное.

В плист надо добавить несколько настроек. Я думаю, что из названия самих настроек всё понятно, кто и что делает. Если нет, то самый подробный документ, I’ve ever seen, лежит здесь и тут. Частота проверки указывается в минутах. Для разных коллекций, могут быть разные настройки и разные каналы обновлений офиса, чтобы мы могли проверить новый релиз на тестовых клиентах.

Нас интересуют эти настройки:

HowToCheck -string AutomaticDownload
DisableInsiderCheckbox -bool TRUE
ChannelName -string ‘Custom’
ManifestServer -string ‘http://srv-sccm-ps/officeupdates/’
UpdateCache -string ‘http://srv-sccm-ps/officeupdates/’
UpdateCheckFrequency -int 240
SendAllTelemetryEnabled -int 0

Но, как выяснилось в процессе тестирования для того, чтобы MAU начал обновлять, то его необходимо ассоциировать по версиям с приложениями Офиса. Значит перед тем, как раздать все настройки в плист, требуется на клиентах сделать всё красиво.

Мы возьмём текущую сессию пользователя, прогоним все приложения Офиса по версии и запишем всё, что нам надо в пользовательский com.microsoft.autoupdate2 вот таким скриптом.

Скрипт для проверки настроек.

Что нам с этим всем делать? Надо создать Configuration Items и всё. ж)

И поймать Success на выходе.

Все логи MAU смотрим в /Library/Logs/Microsoft/autoupdate.log

Как мы видим, клиент успешно забирает xml, если MAU видит, что билд Офиса сменился, там же в логе вы увидите и процесс установки.

Несколько лайфхаков. ж)

Если в stdout вернется еще что-нибудь кроме Success, то клиент будет все равно Non-Compliant. Возможно, что это такое поведение самого агента Parallels. Про ConfigMgr уже не знаю.

Если записываем через su $CurrentloggedInUser -c defaults write /Users/$CurrentloggedInUser/Library/Preferences/com.microsoft.autoupdate2, то плист поломается. Что агент ConfigMgr, что агент Parallels уже всё выполняют с повышенными привилегиями. Не забывайте делать бэкапы плистов, просто поднимать интерактивную сессию sudo -i и там уже проверять, что всё работает так, как надо.

Главный лайфхак. В Windows 10 инсайдер билд notepad уже должен нормально работать с файлами, созданными в Unix, Linux и macOS, но если вы залили шелл скрипт на свою точку распространения, добавили в пакет, поправили файл в блокноте на WS2012 R2, например, то всё, всё сломалось. ;) Помните про это, т.к. после многочасовых траблшутингов можно долго бить себе фейспалмы.