Сетевая диагностика с Get-NetView.

Всем привет.

В книге "Книга рецептов автоматизации Windows Server при помощи PowerShell" Томаса Ли есть ссылка на интересный Powershell модуль сетевой диагностики - Get-NetView.

Автор его позиционирует как модуль решающий проверку сетевой связанности. Get-NetView это инструмент, который собирает подробности относительно вашей сетевой среды, которые способны помочь вам в решении сетевых проблем.

Модуль Get-NetView содержит единственную функцию Get-NetView. Когда вы запускаете эту команду, она вытаскивает воедино гигантский диапазон сведений о сетевой среде и создаёт дополнительно ZIP файл, содержащие подробности жизнеспособности относительно вашей сетевой среды. По умолчанию Get-NetView создаёт папку с результатами на вашем рабочем столе.

Вывод Get-NetView содержит следующие подробности:

• Метаданные Get-NetView
• Содержимое среды хоста (включая ОС, оборудование, домен и имя хоста)
• Физические, виртуальные и контейнерные NIC
• Сетевую конфигурацию (включая IP адресацию, адресацию VFC, соседей и маршруты IP)
• Физическую конфигурацию коммутатора, включая политики Quality of Service (QoS)
• Конфигурацию Hyper-V
• Виртуальные коммутаторы, мосты и NAT Hyper-V
• Драйверы устройств Windows
• Счётчики производительности
• События системы и приложений.

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

Для работы модуля нужен предустановленная PowerShell 7. Видимо так сделано на вырост. Буду полагать что она у вас уже есть.

Находим необходимый модуль Get-NetView в Галерее PS:

Find-Module -Name Get-NetView

Устанавливаем самую последнюю версию Get-NetView:

Install-Module -Name Get-NetView -Force -AllowClobber

Проверяем установленную версию Get-NetView:

Get-Module -Name Get-NetView -ListAvailable

Импортируем модуль Get-NetView:

Import-Module -Name Get-NetView -Force

Готово!

Windows 11 и HyperV.

Всем привет.

После объявления системных требований к Windows 11 появились и способы их обхода. Microsoft же заявил, что если компьютер не будет соответствовать объявленным системным требованиям, то это может вызвать проблему с последующими обновлениями. В случае с Hyper V часть оборудования виртуализирована (кроме процессора) и эти требования играют меньшую роль, чем в случае установке на обычный ПК.

Еще одна важная часть - это ресурсы, которые нужно выделить под Windows 11. Ниже перечислены обязательные требования отсутствие которых приведет к ошибке:

• 4 ГБ ОЗУ;
• Процессор 1 ГГц и 2 ядра;
• TPM 2.0.

Если у вашей виртуальной машины (ВМ) не будет этих ресурсов, то вы столкнетесь с ошибкой:

- этот компьютер не соответствует минимальным требованиям к системе для установки этой версии Windows. Дополнительные сведения см. на сайте aka.ms/WindowsSysReq

- Тhis PC doesn’t meet the minimum system requirements to install this version of Windows. For more information, visit aka.ms/WindowsSysReq

К счастью TPM в рамках HyperV может быть виртуализирован. Т.е. он может быть создан через настройки HyperV. Такие требования, как свободное место на диске 64 Гб, являются опциональными требованиями. По сути проинсталированная Windows 11 займет не более 22 Гб.

Учитывая, что хостовая ОС сама использует оперативную память, а вам нужно установить еще одну для ВМ - физически вы должны иметь минимум 8 Гб на своем компьютере.

Цифровий спадок.

Всім доброго дня.

У сучасному світі значна частина інформації зберігається у цифровому вигляді і часто має дуже велике значення та цінність на рівні з іншими активами та фізичними документами. Компанія MEV провела невелике дослідження на цю тему. Питання було одне - як написати заповіт щодо персональної цифрової інформації довіреним особам у відомих сервісах?

Google.

Ваш обліковий запис Google зберігає в собі колосальний обсяг інформації. Мабуть, навіть більший, ніж ви самі про те підозрюєте. Крім цілком очевидних фотографій з «Google Фото», документів, є файли у Google Drive, історії пошукових запитів і повідомлень електронної пошти. Там також зберігаються записи ваших звернень до Google Асистенту, історія переміщень та звернень до завантажених у пристрій додатків.

Google дозволяє або видалити ваш акаунт, або надати дані з нього довіреним особам завдяки налаштуванням «Про всяк випадок». Компанія пропонує або просто деактивувати ваш акаунт після 3-18 місяців, або надати доступ до частини даних обраним користувачам. 

Як налаштувати умови надання ваших даних довіреним особам:

1. Перейдіть за посиланням на сторінку «Про всяк випадок»;
2. Натисніть «Почати», уточніть період бездіяльності, після закінчення якого акаунт буде видалений, а потім виберіть контакти, за якими вас можна буде заздалегідь про це сповістити;
3. Ви можете вибрати термін деактивації і контакти, за якими вас про неї потрібно сповістити;
4. Виберіть довірену особу, якій ви надасте доступ до своїх даних, і вкажіть її електронну пошту;
5. Виберіть дані, які ви готові надати довіреній особі, і підтвердіть внесення змін.

Facebook.

Тут ще простіше - для передачі облікового запису Facebook автоматично у разі відсутності активності – налаштуйте автоматичне видалення або «Спадкоємця»: 

«Settings» - «General» - «Memorialisation»

Microsoft.

З Microsoft трошки складніше -  сервіси від Microsoft пропонують 2 варіанти розвитку подій:

• або забезпечити автоматичну передачу логіну та паролю довіреній особі.
• або у разі рішення до автоматичного видалення облікового запису, окремих дій не потрібно робити - тобто у разі відсутності активності обліковий запис деактивується через 2 роки автоматично.

Опції щодо автоматичної передачі паролю в Microsoft я так і не знайшов. Врешті решт, я гадаю, що варто просто вести записи своїх паролів в KeePass, або в його онлайн аналозі. Але завчасно потурбуватись щоб доступ до цього записника мала ваша довірена особа.

Щасти.

Слава Україні!

Варианты обмена данными c Zabbix.

Всем привет.  

Zabbix - это популярное средство мониторинга в компьютерных сетях. Основными принципами работы программы заключается во взаимодействии сервера и агентов устанавливающиеся на хосты. В Zabbix доступны и другие инструменты, которые позволяют запускать скрипты, в том числе и Powershell. Такой подход позволяет добавлять в Zabbix нужные для вас данные или вести дополнительную аналитику получая данные с сервера. Итак, помимо штатного мониторинга из коробки существуют следующие варианты получения и отправки данных в Zabbix.

Передача данных на Zabbix-сервер:

- zabbix_sender

- UserParameter

- передача дополнительных параметров

- Discovery Rules и Item Prototype

- любой скрипт с system.run

Получение данных от Zabbix-сервера:

- получаем данные через zabbix_get

- получение данных с API.

Инструменты с помощью которых мы обмениваемся данными в  Zabbix можно разделить на серверные и клиентские. 

Из них создающиеся или хранящиеся на сервере Zabbix:

• скрипты (Scripts) -  это скрипты, которые можно использовать в веб-интерфейсе Zabbix. Визуально это пункты меню;
• External Scripts - папка обычно "/usr/lib/zabbix/externalscripts", в которую можно поместить скрипт и привязать его к какому-то хосту;
• API - HTTP интерфейс, к которому можно обращаться получая большую часть данных или создавать/редактировать существующие элементы.

И клиентские инструменты, которые чаще всего используются на клиентах:

• zabbix_sender - отдельная программа, которая отправляет данные на сервер Zabbix;
• zabbix_get - отдельная программа для получения данных с хостов, на которых установлен zabbix_agent. Обычно используется для тестирования;
• UserParameter - параметр в конфигурации агента на хосте. С помощью его так же можно отправить данные на сервер.
• system.run -  параметр в конфигурации агента на хосте. В отличие от UserParameter позволяет выполнять любой скрипт на клиенте. Хотя и для UserParameter я особых ограничений не заметил, например так UserParameter=admin.local[*],powershell -File "GetAdmins.ps1"

Диагностика сетевого взаимодействия.

Всем привет. 

Существует теория, что любая сетевая проблема начинается с DNS, пока вы не докажете  обратное. Поэтому есть смысл пройтись по диагностике сетевого взаимодействия в вашем домене.

Вы начинаете с получения полного доменного имени (FQDN), fully qualifed domain name своего хоста и значения IP адреса его DNS сервера, а затем проверяете работает ли этот сервер DNS.

Затем вы применяете сконфигурированный сервер DNS на предмет определения значений имён контроллеров домена в своём домене и убеждаетесь что способны достигать каждого контроллера домена как по порту 389 (LDAP), так и по 445 (для GPO). 

Затем вы проверяете доступность шлюза по умолчанию. В конце, уже опционально, вы тестируете возможность достижения удалённого хоста по порту 80 (http) и по порту 443 (HTTP поверх SSL/ TLS). 

В приницпе весь рецепт диагностики состоит из кода Powershell для версии 7.0.

# Получаем значение имени DNS данного хоста

$DNSDomain = $Env:USERDNSDOMAIN

$FQDN      = "$Env:COMPUTERNAME.$DNSDomain"

# Получаем значение адреса этого DNS сервера

$DNSHT = @{

  InterfaceAlias = "Ethernet"

  AddressFamily  = 'IPv4'

}

$DNSServers = (Get-DnsClientServerAddress @DNSHT).ServerAddresses

$DNSServers

# Убеждаемся в доступности этих DNS серверов

Foreach ($DNSServer in $DNSServers) {

  $TestDNS = Test-NetConnection -Port 53 -ComputerName $DNSServer   

  $Result  = $TestDNS ? "Available" : ' Not reachable'

  "DNS Server [$DNSServer] is $Result"

}