Как найти VM, вызывающую ошибку Duplicated IP, средствами PSH

Привет всем.


Маленький life-hack-скрипт, позволяющий средствами VMM PSH обнаружить имена машин, которые вызывают ошибку с дублируемыми IPv4 адресами.

Сценария два:

• пингуем дублирующий узел по IPv4, смотрим arp -a, забираем МАС и подставляем на ввод скрипта;
• задаём  MAC в виде шаблона, к примеру *00:50:56* (такая команда выдаст все  машины с MAC адресами, содержащими паттерн);

ПРИМЕЧАНИЕ! Требуется наличие VirtualMachineManager CMDLets

Import-Module virtualmachinemanager
Write-Host "Script will help you in two ways: "
Write-Host "       - Identify VM name by MAC address to resolve duplicated IPv4 collision"
Write-Host "         (You need to ping the remote server you are looking for by IP and found his MAC with arp -a first)"
Write-Host "       - Identify VM name by MAC address to resolve if some Virtual machines have same MAC"
Write-Host "Enter MAC ID with double dot delimiter (Template:*00:50:56*)" -ForegroundColor Yellow
Write-Host "------------------------------------------------------------" -ForegroundColor Yellow
$MACID = Read-Host
Write-host " "
Write-Host "Searching for MAC: " $MACID -Foreground Green
Write-Host "------------------------------------------------------------" -ForegroundColor Yellow
Sleep 2

$VMArray = Get-SCVirtualMachine -All
FOREACH ($VMsname IN $VMArray)
    {
     $VMsname = $VMsname.Name
     $NetADArray = Get-SCVirtualMachine $VMsName | Get-VirtualNetworkAdapter | Where-Object {$_.EthernetAddress -like $MACID}
     IF ($NetADArray -ne $Null)
        {
         Write-host " "
         Write-Host "MAC Detected" -Foreground Red
         Write-host "VM Name is: " $VMsname -Foreground Yellow
         Write-Host "VM network adapter name is: " $NetADArray.Name -Foreground Yellow
         Write-Host "MAC is: " $NetADArray.EthernetAddress -Foreground Yellow
         Write-host " "
        }
     ELSE
        {
        }
    }
Write-host "done..." -Foreground Green

Ошибки: SMBWitnessClient Event id 8 и SMBWitnessClient Event id 5

В рамках внедрения кластеризованных решений удалось отловить ошибки: SMBWitnessClient Event id 8 и SMBWitnessClient Event id 5.

Ошибка возникает по причине: 
DNS именя ресурса %NetworkName1% и сетевого имени ресурса %DNSName1% не совпадают.

Скриншоты для ресурсов Network Name, пример:

 

 

Можно проверить с помощью команд:

Get-ClusterResource -Name %NetworkName1% | Get-ClusterParameter

Get-ClusterResource -Name %NetworkName2% | Get-ClusterParameter

 

 

В Failover Cluster можно использовать разные имена для DNS имени ресурса и сетевого имени ресурса, это не приводит к проблемам в работе кластера. Однако служба SMB3 witness server по умолчанию считает, что данные имена должны совпадать. Данное поведение by-design в Windows Server 2012 (R2).

 

Ошибку можно устранить назначив для DNS имени ресурса и сетевого имени ресурса одинаковые имена.

 

Сделать это можно командами:

 

Get-ClusterResource “SQL Network Name (%ObjectName1%)” | %{ $_.Name = “%DNSName1%”}

Get-ClusterResource “SQL Network Name (%ObjectName2%)” | %{ $_.Name = “(%DNSName2%”}


Публикую пример:

 

 

 

 

 

 

Проблема CMDBs для CAS и Primary Site, возникающая при размещении на одном SQL кластере.

В рамках развёртывания сложной иерархии ConfigMgr 2012 R2 столкнулись с проблемой, описанной ниже. Удалось её разрешить совместно с инженерами Premier Support Microsoft, за что им большое спасибо.

Описание архитектуры
Существует 2-х узловый SQL (failover) кластер на базе Windows Server 2012 R2 Datacenter. На нём размещаются 2 именованных экземпляра SQL для CAS и Primary Site. Все сертификаты  самоподписанные.


Симптомы

Периодически возникает проблема с невозможностью перевода ресурсов SQL между узлами кластера (при попытке перевода возникают ошибки SQL службы не запускаются).

На серверах SQL, обслуживающих базы данных SCCM с периодичностью каждые 24 часа появляются папки вида SMS_<Site Server FQDN>_SMS_SQL_SERVER<Integer>.

Причина возникновения

Зарегистрированный баг, связанный с одновременным размещением баз данных SCCM разных сайтов на одних и тех же узлах кластера SQL (в разных экземплярах).

Технические подробности ошибки

Ошибка возникает в связи со следующей последовательностью действий:

1)      При установке роли сервера базы данных SQL для SCCM создается специальный сертификат в хранилище MY (HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates) (KEY1). SCCM конфигурирует SQL сервер использовать данный сертификат. В кластеризованном окружении отпечаток его также хранится в ключе 'Certificate' в <HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL<Instance>\MSSQLServer\SuperSocketNetLib> (KEY2).

При установке SQL для другой базы SCCM, работающей в другом экземпляре – у нас появляется второй сертификат в общем хранилище KEY1 и также сертификат в ветке реестра вида KEY2.

2)      Компонент CertMgr сервера SCCM каждые 30 минут проверяет правильность сертификата сервера SQL, именно здесь кроется ошибка в коде – алгоритм выбирает первый попавшийся сертификат из хранилища (KEY1), подпадающий под ряд критериев, и затем сравнивает отпечаток с отпечатком из KEY2 соответствующего экземпляра. Очевидно, для одного из серверов мы получаем совпадение, для другого – всегда несоответствие.

3)      Данное несоответствие вызывает процедуру переустановки компонента на SQL-сервере, которая после первой неудачи повторяется каждые 24 часа. Попытка переустановки завершается неудачей, так как сертификат уже существует. Именно в этот момент появляется новая папка с файлами.

ПРИМЕЧАНИЕ! К сожалению, данный код игнорирует наличие файла no_sms_on_drive.sms, который обычно используется для защиты диска от записи компонентов SCCM (по-умолчанию, всегда выбирается диск с наибольшим объемом свободного места).

Соответственно мы оказываемся в тупиковой ситуации:

1)      Мы не можем ничего сделать с количеством и наличием сертификатов на серверах SQL, так как они необходимы для правильного функционирования компонентов.

2)      Мы не можем повлиять на код, делающий неверный выбор сертификата – в этом и заключается баг. Он проявляется только в данной конфигурации (2 базы в разных экземплярах одного кластера), и так как таких инсталляций немного и, кроме создания лишних папок, к другим ошибкам не приводит – продуктовая группа System Center отложила исправление до следующей версии продукта.

3)      И, наконец, мы не можем отключить переустановку компонента, так как ее инициирует SITE_COMPONENT_MANAGER, необходимый для функционирования массы другого функционала.

Рекомендации

Данное поведение дополнительных угроз, кроме самого факта создания новых папок, не несет.

Объем каждой папки около 1 Мб, соответственно о быстром уменьшении свободного места на диске беспокоиться не стоит (напомню, выбирается диск с наибольшим объемом свободного места). Microsoft рекомендует периодически удалять папки вида SMS_<Site Server FQDN>_SMS_SQL_SERVER<Integer>, оставляя последнюю из созданных по дате. Это можно производить периодически вручную, либо же автоматизировав процесс скриптом/заданием в планировщике.

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

Возможные обходные пути:

• Заскриптовать ручное исправление проблемы – заново давать права учетной записи, под которой работает SQL-сервер;
• Периодически обнаруживать и удалять CMN-файлы из инбокса certmgr;
• использовать PKI-сертификат из выдающего УЦ Microsoft (ADCS), для шифрования соединения БД сайта с сайт-сервером;

Пункт 3 - очень интересен. Судя по лабораторным тестированиям, поведение ConfigMgr, после смены self-signed сертификатов на принадлежащие корпоративному ЦС, меняется: SCCM перестает проверять согласованность Thumbprint’ов для PKI-сертификата и просто работает дальше.

Мы пошли по пути упрощения иерархии. Надеюсь, данная информация поможет кому-либо.