Четыре года назад я писал о своем опыте инвентаризации серверов Exchange в организации.
Для инвентаризации серверов мы используем скрипт Get-ExchangeEnvironment, который за последние годы был модернизирован для поддержки Exchange 2016 и большой кучи CU к Exchange 2013 🙂
Вышел Exchange 2013 CU22, закрывающий критические уязвимости в безопасности, и мы его развернули.
При этом мы столкнулись с парой проблем:
- Пропатченные сервера Exchange стали прикидываться Exchange 2013 CU20. Неожиданно, но это косяк Microsoft. В качестве лечения предлагается вручную исправить параметр реестра, содержащий номер CU (с “20” на “22”).
- Второй подвох ждал нас уже в скрипте инвентаризации: после исправления пункта №1 версия Exchange перестала отображаться.
Реверс инжиниринг скрипта показал, что в скрипте последний “поддерживаемый” CU – CU20:
|
1 2 3 4 5 6 7 8 9 10 |
# 1.5.8 Exchange Service Pack String Mapping $ExSPLevelStrings = @{"0" = "RTM" "1" = "SP1" "2" = "SP2" "3" = "SP3" "4" = "SP4" "SP1" = "SP1" "SP2" = "SP2"} # Add many CUs for ($i = 1; $i -le 20; $i++) { $ExSPLevelStrings.Add("CU$($i)","CU$($i)");} |
Соответственно, для отображения корректной версии “Exchange 2013 CU22” вам нужно увеличить число, выделенное жирным и подчеркнутое, до 22.
P.S. Перечитал старую статью – там тоже были проблемы с отображаемыми CU 🙂
Особенно посмеялся со своей фразы “Исправляем таблицу, предположив, что для Exchange 2013 не будет выпущено больше CU10”.