Бывают ситуации, когда мы сталкиваемся с нехваткой места на системном диске в ОС Windows Server и возникает необходимость в расширении раздела с ОС. В старых версиях Windows Server расширение системного раздела в любой момент времени обычно не представляло особых сложностей, так как раздел с ОС обычно находился в конце диска и это позволяло быстро без остановки сервера проводить расширение раздела через графическую оснастку Disk Management (diskmgmt.msc). Начиная с Windows Server 2016 в конце системного диска появился дополнительный раздел среды восстановления Windows Recovery Environment (WinRE), который усложнил задачу расширения раздела с ОС. Конечно, в арсенале администратора, всегда остаются такие мощные инструменты как GParted, которые позволяют сделать любую нужную реконфигурацию разделов, но для этого потребуется выключить сервер и выполнять эти процедуры в офлайн режиме. Однако если требуется расширить системный раздел без выключения сервера, то процесс расширения будет более сложный, так как нам потребуется пересоздавать раздел восстановления WinRE. Далее пошагово рассмотрим эту процедуру на примере Windows Server 2022.
В качестве исходной позиции имеется несколько серверов с Microsoft SharePoint Server 2019 с языковым пакетом Language Pack for SharePoint and Project Server 2019 версии 16.0.10417.20041 (это уровень обновления от Августа 2025 года). Необходимо провести процедуру актуализации версии SharePoint Server для закрытия таких известных уязвимостей, как, например, критическая уязвимость 
В пуле серверов Windows Server 2022 с ролью Remote Desktop Session Host (RDSH) в пользовательских сеансах одного из серверов появилась странная проблема - перестало открываться стартовое меню при нажатии кнопки "Пуск" и перестали открываться контекстные меню в некоторых местах на нижней панели задач. Кроме этого перестало запускаться AppX приложение "Параметры" или "Settings" в англоязычном варианте (не путать с классическими апплетами управления *.cpl).
Рассмотрим процедуру обновления драйвера и микрокода для оптического адаптера HPE StoreFabric SN1100Q P9D94A Rev:0A (PN:P9D94-63001 SPS:853011-001) DP FC 16Gb PCI-E HBA (QLogic QLE2692-HP BK3210407-20 F) в среде гипервизора VMware ESXi 8.0 U3, работающего на аппаратной серверной платформе YADRO Vegman R120 G1. Хотя модель сервера здесь не играет принципиального значения и процедура будет схожей для работы на другом серверном железе.
Имеется сервер HPE ProLiant поколения Gen10 c RAID контроллером HPE Smart Array P408i-p SR. На контроллере собран массив RAID 60 из множества накопителей большого объёма. В конфигурации контроллера активирован механизм "Spare Drive" для автоматической "горячей" подмены при отказе любого из накопителей в рабочей RAID группе. И вроде бы всё хорошо и контролируемо. Но однажды может наступить момент, когда в работающем RAID массиве один из накопителей поменяет свой статус на "Predictive Failure". То есть накопитель ещё продолжает работу, но из-за накапливающихся ошибок вероятность его отказа в обозримой перспективе становится весьма неиллюзорной.
При попытке установить гипервизор VMware ESXi 8.0 U3 (из образа VMware-ESXi-8.0.3-24859861-HPE-803.0.0.12.2.0.9-oct2025.iso) на блейд-сервер HPE ProLiant BL460c G8 666157-B21 с установленным модулем сетевой платы HPE FlexFabric 10Gb 2-port 554FLB BL-c FlexLOM Adapter 647586-B21 (647584-001 Rev.0A SP:649940-001) получим предупреждение инсталлятора "
Замечено, что при использовании ОС Windows Server 2022/2025 на аппаратной платформе HPE ProLiant DL380p Gen8 в диспетчере задач Windows Task Manager может некорректно отображаться информация о нагрузке на процессорные ядра сервера. При этом данная проблема может проявляться плавающим образом. Например, имеются два одинаково сконфигурированных хоста виртуализации с одинаковым актуальным набором микрокода и идентичным уровнем обновлений ОС Windows Server 2022 Datacenter. На первом сервере показания нагрузки CPU в диспетчере задач выглядят как вполне работоспособные и правдоподобные. На втором таком же сервере показания нагрузки CPU всегда нулевые.
В ходе проведения очередной процедуры обновления ОС Windows Server 2025 на аппаратной платформе HPE ProLiant DL380p Gen8 после установки обновлений и штатной перезагрузки сервера столкнулись с невозможностью нормального запуска сервера. При загрузке сервера в тот момент, когда обычно начинается запуск ОС с дисков RAID контроллера Smart Array, на консоли сервера появилось сообщение "
В этой заметке мы рассмотрим вариант решения проблемы с неподдерживаемым оптическим адаптером Emulex LightPulse LPE12002 при развёртывании хоста виртуализации на базе VMware ESXi 8.0 U3.
Начиная с Windows Server 2012 в Hyper-V появилась возможность подключать к виртуальной машине виртуальный Fibre Channel Adapter (vFC или vHBA). Эта функция позволяет гостевой системе напрямую работать с физическими SAN-ресурсами через протокол Fibre Channel, используя механизмы N_Port ID Virtualization (NPIV). ВМ получает свой собственный виртуальный HBA, со своим уникальным World Wide Name, и может обращаться к LUN-ам на хранилище так, как если бы она была "настоящим" сервером с физическим FC HBA. Это открывает ряд интересных возможностей: подключение кластеров Windows Server Failover Clustering или SQL Server AlwaysOn напрямую к SAN, использование снапшотов и резервного копирования на уровне СХД, а также гибкое администрирование через знакомые SAN-инструменты. На фоне конкурентов это долгое время было преимуществом Hyper-V, поскольку VMware и другие гипервизоры предлагали аналогичные возможности либо в более дорогих редакциях, либо с ограничениями, тогда как в экосистеме Microsoft vFC сразу интегрировался в стандартные сценарии высокой доступности и корпоративного хранения.
раньше был перед системным и проблем не было. а теперь этот изврат
RSS - Записи
Последние комментарии