Ошибка «Unable To Reach The AWCP Endpoint : https://awcp.air-watch.com/provisioningportal/CSRGenerationHandler.aws/v1»

Столкнулся с такой ошибкой при попытке обновления сертификата APNs на Workspace One:Статья на сайте разработчика мне никак не помогала, т.к. она была старая и решение той проблемы было выполнено давно.
Я начал проверять сетевой трафик Wireshark и обнаружил такое поведение:
на стандартное приветствие TLS Handshake: Hello


удаленный сервер awcp.air-watch.com отвечает Handshake Failure

После этого вспомнили, что на серверах Workspace One ранее были отключены старые ключи шифрования. Включили их снова и после этого ошибка пропала.

Долгий запрос сертификата APNs (Apple MDM) в Workspace One

Обнаружил недавно проблему при запросе сертификата APNs в продукте Workspace ONE (бывший Airwatch) — он выполняется слишком долго (самый первый шаг).
Начал смотреть Procmon куда лезет в файловой системе этот продукт при запросе сертификата и выяснил, что он долго обрабатывает каталог C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SystemCertificates\Request\Certificates. Зашел в него и оказалось что там около 500 тыс. файлов. Через поиск в интернете быстро находится статья о проблеме со старыми версиями Airwatch https://kb.omnissa.com/s/article/82553 В результате, с помощью скрипта https://github.com/sntcz/Clear-MachineKeys  перенес файлы в другой каталог и проблема медленного запроса сертификата больше не проявлялась.

Ошибка в задаче бекапа Veeam Agent

Veeam агент версии — 6.1.0.349
Veeam сервер версии — 12.1.1.56
При бекапе агентом одного из физических серверов возникла ошибка:
Error: AgentManagerService: Failed to start agent, Host ‘MBX01’. The remote procedure call was cancelled. RPC function call failed. Function name: [DoRpc]. Target machine: [::1]
В логах Veeam ничего дополнительного не нашел. Для устранения этой ошибки помог перезапуск сервиса VeeamEndpointBackupSvc на проблемном сервере. Причем сервис не хотел останавливаться, пришлось останавливать процесс Veeam.EndPoint.Service.exe вручную через Task Manager

Проблема с Zabbix Appliance

Проблема:
Скачал и установил готовый appliance от zabbix . Но с ним есть проблемы — при создании снапшота виртуальная машина перестает работать, а при запуске ее вновь ошибка Object type requires hosted I/O Failed to start the virtual machine. Module Disk power on failed. Cannot open the disk ‘/vmfs/volumes/5bcda19c-7fdf91a6-d95f-2c768aae1eb8/zabbix/zabbix_appliance-6.4.10-disk1.vmdk’ or one of the snapshot disks it depends on. После этого ее удается запустить только после исправления виртуального диска командой vmkfstools -x repair. Пытался изменить настройки виртуальной машины, вместо ide контроллера для диска выбирал SCSI, ошибка Unsupported or invalid disk type 7 for ‘scsi0:0’. Ensure that the disk has been imported. Failed to start the virtual machine. Module DevicePowerOn power on failed. Unable to create virtual SCSI device for scsi0:0, ‘/vmfs/volumes/5bcda19c-7fdf91a6-d95f-2c768aae1eb8/zabbix/zabbix_appliance-6.4.10-disk1.vmdk’. Снапшот на выключенной виртуальной машине делается без ошибок.
VMware ESXi, 7.0.3, 21424296
vCenter 7.0.3 22357613
Решение:
Смотрим что творится с дисками виртуальной машины:

Открываем содержимое диска, которое занимает меньше всего пространства и видим:


Видим, что тип диска Sparse, который имеет формат split, делящий диск на 2ГБ куски. Такой тип диска поддерживается  в работе Vmware Workstation. Чтобы корректно работать с ним на VMware Esxi необходимо выполнить конвертацию  диска:

vmkfstools -i zabbix_appliance-6.4.10-disk1.vmdk zabbix_appliance-6.4.10-disk1_new.vmdk

Добавляем новый диск к ВМ, вместо старого
Удаляем старый диск вместе с дескриптором:

vmkfstools -U zabbix_appliance-6.4.10-disk1.vmdk

После восстановления vSphere не работает на нем сеть или ошибка Setting ip/ipv6 configuration failed: (‘ IP configuration not allowed’,)

Привет!
После восстановления из бекапа vCenter 7 вы можете попасть в такое состояние, когда на нем не работает интерфейс  управления, то есть vCenter не доступен по сети. Зайдя в его настройки можно увидеть, что в нем не задан шлюз по-умолчанию, а при попытке его задать и сохранить возникает ошибка:
Setting ip/ipv6 configuration failed: (‘ IP configuration not allowed’,).
Такая ошибка возникла у меня в ситуации, когда vCenter был подключен к порт-группе без эфемерных портов в распределенном коммутаторе. Так как этот коммутатор был создан на том же vCenter, который и был восстановлен, то он, по существу, не позволял подключить новый интерфейс в порт-группе на этом коммутаторе. Чтобы такого не было, надо заранее создавать порт-группу с эфемерными портами. Ну а если уже поздно, то надо действовать по инструкции  с сайта VMware и временно настроить обычный виртуальный коммутатор и подключать сеть виртуальной машины с vCenter к нему. После этого перезагружаем восстановленный Vcenter и шлюз по-умолчанию появится сам в настройках,  сетка на нем заработает.

VMware ESX unrecoverable error. EPT misconfiguration

Столкнулись с проблемой на одном из хостов виртуализации. При миграции с него виртуальных машин на другой хост виртуальная машина с большой долей вероятности перезагружалась. В логах хоста были подобные сообщения:
Error message on <VM_Name> on <HOST_Name> in <Datacenter_Name>: VMware ESX unrecoverable error: (vcpu-2) vcpu-3:EPT misconfiguration: PA 14f11e7f8
Поддержка Vmware обратила внимание, что в логе /var/run/log/vmkernel.log упоминается постоянно одно и тоже виртуальное ядро:
2023-06-02T17:51:18.058Z cpu24:527386)WARNING: World: vm 527386: 8726: vmm0:<VM_Name>:vcpu-0:EPT misconfiguration: PA 2020eb000
2023-06-02T17:51:57.933Z cpu24:527362)WARNING: World: vm 527362: 8726: vmm6:<VM_Name>:vcpu-6:EPT misconfiguration: PA 1a53f87f8
2023-06-02T19:07:30.107Z cpu24:525206)WARNING: World: vm 525206: 8726: vmm1:<VM_Name>:vcpu-1:EPT misconfiguration: PA bf13bf80
2023-06-02T23:10:06.672Z cpu24:535256)WARNING: World: vm 535256: 8726: vmm0:<VM_Name>:vcpu-0:EPT misconfiguration: PA 80578f7f8
2023-06-02T23:11:37.296Z cpu24:535777)WARNING: World: vm 535777: 8726: vmm2:<VM_Name>:vcpu-2:EPT misconfiguration: PA 3651f558
2023-06-03T00:45:52.563Z cpu24:527569)WARNING: World: vm 527569: 8726: vmm3:<VM_Name>:vcpu-3:EPT misconfiguration: PA 14f11e7f8

Оказывается есть  KB от Vmware с аналогичной ситуацией. Что делать?
1) Меняем физически процессорные сокеты местами (если у вас конечно 2 физ. сокета) и переусаживаем планки ОЗУ. Я поменял, в логах стали ошибки уже на ядре cpu56. Значит все верно, проблема в процессоре.
2) Меняем процессор (сокет). Мы заменили и ошибка после этого пропала. Проблема решена.

VMware VCSA «dracut: FATAL: FIPS integrity test failed»

Привет!
Вчера на ровном месте начала возникать ошибка в самом начале  загрузки appliance с VMware vSphere 7 (7.0.3.01500)
dracut: FATAL: FIPS integrity test failed

Временное решение, чтобы система загрузилась: нажать клавишу «E» в момент загрузки GRUB меню и в конце строки с параметрами загрузки системы написать:
fips=0

После этого система загрузится как обычно.
При следующей перезагрузке надо будет повторить данную манипуляцию. Пока проблема, получается, полностью не устранена. Буду в ближайшее время обновлять VCSA
P.S. После загрузки системы я проверял официальным методом — FIPS не включен.
Update от 13.09.2023 года: для решения проблемы необходимо:
1) зайти на vcenter под учеткой root
cd /boot/grub2/
vi grub.cfg
Добавить значение fips=0 после systemd_cmdline
2) При следующем обновлении vcenter, после перезагрузки выполнить команду "mkinitrd -q" в консоли vcenter и удалить параметр "fips=0" из загрузчика

Windows cannot find Microsoft Software License Terms

Если при in-place upgrade операционной системы Windows у вас возникла ошибка «Windows cannot find Microsoft Software License Terms» сразу после этапа выбора операционной системы. Проверьте файл C:\$Windows.~BT\Sources\Panther\setuperr.log (путь может отличаться) на наличие номера ошибки. В моем случае ошибка была с номером 0x060613. Мне помогло, то что нашел решение на сайте technet.microsoft.com, где посоветовали проверить политики безопасности а точнее политику «Manage auditing and security log» узкому кругу лиц, в группу которых не входила учетная запись, которая запускала установщик системы. Я поменял учетку на ту, что имеет более расширенные привилегии и установка прошла успешно.

Veeam. Проблема с бекапом на ленту

В случае если у вас Veeam Backup выдает ошибку «Failed to start new tape backup session: Failed to get last session number, sessions map is empty» или «Failed to get last session number, sessions map is empty. Failed to get last session number, sessions map is empty.«, знайте, что нужно найти последнюю использованную кассету и очистить ее.  После этого можно запускать бекап на ленту вновь и он должен успешно начаться.
У меня эта ошибка началась после того как база Veeam Backup перестала быть доступной в момент бекапа на ленту. Бекап аварийно завершился и больше не запускался, выпадая с ошибкой, указанной выше.

Veeam Backup: existing backup meta file on repository is not synchronized with the DB

Привет! Недавно столкнулся с очередной проблемой на Veeam Backup and Replication 9.5. Сервер Veeam подвис и я не смог к нему подключиться ни через RDP или RPC, ни через managment интерфейс (HP iLO). Пришлось сервер перезагружать по питанию. После этого я попытался запустить задания бекапа, которые не выполнились за прошедшую ночь и тут посыпались одинаковые ошибки:
Cannot proceed with the job: existing backup meta file 'D:\Backup\test.vbm' on repository 'Scale-Out_Repository' is not synchronized with the DB. To resolve this, run repository rescan.
Я попытался сделать сканирование репозитория но ничего не вышло: ошибка появлялась вновь.  При этом задания бекапа логов автоматически запустились через повторный перезапуск сервисов Veeam и начали успешно бекапить SQL.  Попытался создать клон задания — оно начало выполняться. Далее начал смотреть сами vbm  файлы, точнее их содержание и тут обнаружилось: все файлы, на которые ругался Veeam полностью либо частично повреждены, точнее в них содержится набор нечитаемых символов. Так это выглядело в Notepad++:

В логах бекапа SQL логов нашлось более интересная вещь:По крайней мере стало понятно, что произошел какой-то сбой на сервере, в результате которого вместо информации о бекапах текущего задания в файл сам Veeam начал заносить текст со слетевшей кодировкой.
После этого обратился в поддержку Veeam, где они посоветовали удалить файл vbm и запустить задание вновь. О чудо все заработало. Оказывается в случае если в директории нет файла  vbm, то тогда Veeam  берет информацию о бекапе из базы своей базы данных. Вот такая вот интересная история.