Серый параметр часового пояса в Windows Server: быстрое решение

Введение

Видеть, что настройка часового пояса в Windows Server неактивна (засерена), раздражает, особенно когда вам нужны корректные временные метки для журналов, аудита или приложений. Вы нажимаете «Изменить часовой пояс», и ничего не происходит, потому что параметр отключен. Эта единственная серая кнопка может заблокировать развертывание, нарушить прохождение проверок соответствия или запутать команды поддержки во время инцидента.

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

Это руководство объясняет, что на самом деле означает «Windows Server часовой пояс неактивен (засерен)», почему это важно и как безопасно это исправить. Вы узнаете, как:

Определить первопричину на своём сервере
Разрешить изменение часового пояса с помощью локальной политики безопасности и групповой политики
Использовать PowerShell и «tzutil» для настройки часового пояса
Обрабатывать особые случаи, такие как контроллеры домена, виртуальные машины и облачные серверы
Применять передовые практики, чтобы проблема не возвращалась

В итоге у вас будет понятный, повторяемый процесс, который можно применить ко всему парку серверов Windows, без рискованных правок реестра и догадок.

Что на самом деле означает «Windows Server часовой пояс неактивен»

Когда администраторы говорят «часовой пояс засерен», они обычно имеют в виду один из следующих видимых симптомов:

Кнопка «Изменить часовой пояс…» в параметрах «Дата и время» отключена.
Выпадающий список часовых поясов в классической панели управления «Дата и время» заблокирован.
Переключатель «Автоматически устанавливать часовой пояс» нельзя изменить.

Windows делает это намеренно, когда у текущего пользователя нет необходимых привилегий или когда политика явно блокирует изменение часового пояса. Сервер следует правилам конфигурации из локальной политики безопасности, доменной групповой политики или эталонных конфигураций безопасности.

Это различие важно. Если вы воспринимаете проблему как баг, вы можете начать пробовать случайные твики реестра или неподдерживаемые утилиты, которые нанесут больший ущерб. Если вы рассматриваете её как проблему прав и политик, вы сможете корректно её устранить и сохранить стабильность.

Понимание симптома помогает перейти к следующему вопросу: почему часовой пояс настолько важен, что Windows и ваша организация вообще его блокируют?

Почему настройки часового пояса важны на современных серверах Windows

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

Ключевые области, зависящие от корректной конфигурации часового пояса:

Журналы событий: журналы безопасности, системы и приложений опираются на точные временные метки.
Устранение неполадок: команды поддержки сопоставляют события между серверами по времени.
Соответствие и аудит: многие стандарты требуют точных, отслеживаемых журналов.
Приложения: некоторые приложения рассчитывают расписания, SLA или рабочие часы, используя локальное время.
Пользовательский опыт: запланированные задачи, отчёты и оповещения могут появляться раньше или позже при неверном часовом поясе.

Если сервер использует неверный часовой пояс, вы можете столкнуться с:

Записями журналов, которые кажутся расположенными не по порядку при сравнении между системами.
Инцидентами, которые сложно восстановить по хронологии, потому что временные метки не совпадают.
Запутанными временными линиями во время расследований инцидентов безопасности или разборов после инцидентов.
Приложениями, показывающими некорректное время для заданий, сообщений или отчётов.

По этой причине многие организации жёстко контролируют настройки времени для сохранения целостности. Они разрешают изменения только через управляемые процессы или определённые администраторские группы. Именно эта защита часто и приводит к симптомам «Windows Server часовой пояс неактивен».

Чтобы решить проблему, нужно определить, что именно вам мешает: разрешения, групповая политика или средства безопасности. Это начинается с наиболее распространённых причин.

Распространённые причины, по которым параметр часового пояса неактивен

В большинстве сред Windows Server параметр часового пояса оказывается засерен по одной из трёх типичных причин. Понимание того, какая из них относится к вашему серверу, избавит от траты времени на заведомо неисправляющие меры.

Недостаточные административные права на сервере

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

Вы локальный пользователь, а не член локальной группы «Администраторы».
Вы доменный пользователь с ограниченными правами на данном сервере.
Контроль учетных записей (UAC) блокирует повышение прав, потому что вы не запускаете инструменты от имени администратора.

Windows рассматривает изменение времени и часового пояса как привилегированные действия. Без соответствующих прав интерфейс просто отключает опцию, а не показывает сообщение об ошибке.

Групповая политика домена, блокирующая настройки часового пояса

На серверах, присоединённых к домену, настройки времени часто контролируются групповой политикой. GPO может:

Убрать право «Изменение часового пояса» у локальных групп.
Применять шаблоны безопасности, блокирующие интерфейс «Дата и время».
Назначать стандартные базовые настройки, ограничивающие изменение времени на всех серверах в OU.

Если групповая политика отбирает это право, исправить ситуацию только локальными изменениями нельзя. Любая локальная корректировка будет перезаписана при следующем обновлении политик. Нужно найти и скорректировать саму доменную политику или обратиться за помощью к команде, управляющей каталогом.

Базовые настройки безопасности и инструменты усиления защиты, ограничивающие изменения

Многие организации применяют средства усиления безопасности или эталонные конфигурации, такие как:

Эталонные настройки безопасности Microsoft для Windows Server
Рекомендации CIS Benchmarks
Сторонние платформы управления конфигурацией или защитой конечных точек

Эти средства часто включают правила, ужесточающие контроль над изменением времени. Даже если групповая политика выглядит незапретительной, эталонная конфигурация может регулярно применять более строгие настройки, из-за чего элемент управления часовым поясом остаётся засеренным.

Теперь, когда вы понимаете распространённые причины, логичный следующий шаг — выполнить несколько базовых проверок. Они покажут, какой уровень управления отвечает за блокировку и какое исправление стоит пробовать первым.

Первичные проверки, прежде чем пытаться исправить часовой пояс

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

Подтвердите версию, редакцию и роль Windows Server

Начните с выяснения, с каким типом сервера вы работаете:

Проверьте версию с помощью «winver» или страницы «Система».
Определите, является ли это Standard, Datacenter или другой редакцией.
Уточните, является ли сервер контроллером домена, членом домена или автономной машиной.

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

Проверьте локальные и доменные права учетной записи

Далее проверьте свою учетную запись и то, как вы запускаете инструменты:

Убедитесь, что вы член локальной группы «Администраторы» или других привилегированных групп.
Если сервер в домене, проверьте членство в группах доменных администраторов или администраторов серверов.
Запускайте параметры даты и времени, PowerShell или командную строку «от имени администратора», чтобы обеспечить повышение прав.

Если вы не можете поднять права до административных, никакие настройки не помогут. Может понадобиться другая учетная запись или временное повышение прав по запросу в вашу команду безопасности или инфраструктуры.

Проверьте синхронизацию времени и сетевой контекст

Наконец, выясните, как сервер синхронизирует время и где он расположен в сети:

Выполните «w32tm /query /status», чтобы узнать текущий источник времени.
Убедитесь, что сервер может обратиться к контроллерам домена или серверам NTP.
Отметьте, расположен ли он в DMZ, кластере или чувствительном сегменте сети с дополнительными политиками.

Если синхронизация времени работает, но часовой пояс неверен, можно сосредоточиться на правах и политиках, не трогая настройки NTP. С этим контекстом вы можете безопасно попробовать первое исправление: настройку локальной политики безопасности на серверах, не заблокированных доменными GPO.

Исправление 1 – Разрешить изменение часового пояса через локальные параметры безопасности

На автономных или слабо управляемых серверах право на изменение часового пояса часто задаётся локальной политикой безопасности. Если групповая политика не переопределяет её, настройка этого параметра может вернуть активность кнопки, не затрагивая доменную конфигурацию.

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

Выполните эти действия на целевом сервере:

Войдите с учетной записью, входящей в локальную группу «Администраторы».
Откройте диалог «Выполнить», введите «secpol.msc» и нажмите Enter.
В консоли локальной политики безопасности перейдите к Локальные политики > Назначение прав пользователя.
Прокрутите вниз и найдите политику с названием «Изменение часового пояса» (Change the time zone).

Если вы не можете открыть локальную политику безопасности или консоль показывает, что параметры управляются групповой политикой, это признак того, что в управлении доменные GPO или средства безопасности. В таком случае переходите к исправлению через групповую политику.

Предоставьте право «Изменение часового пояса» административным ролям

В политике «Change the time zone»:

Дважды щёлкните политику, чтобы открыть её свойства.
Добавьте группы «Администраторы» и любые другие группы администраторов, которым следует разрешить изменение часового пояса.
Удалите лишние группы, которым это право больше не нужно.
Примените изменения и закройте консоль.

Старайтесь держать список как можно более коротким. Это сохраняет безопасность и позволяет тем, кто администрирует сервер, выполнять свои задачи без создания заявок на каждый вызов для смены часового пояса.

Примените изменения и перепроверьте параметр часового пояса

Чтобы применить изменения:

Выйдите из системы и войдите снова или перезапустите сервер, если это допускается окном обслуживания.
Откройте параметры «Дата и время» в Windows Server.
Проверьте, стала ли доступной кнопка «Изменить часовой пояс».
Смените часовой пояс на правильный и проверьте его через PowerShell командой «Get-TimeZone».

Если параметр по-прежнему засерен, скорее всего, доменная групповая политика переопределяет локальные величины. Это ведёт к следующему исправлению, ориентированному на GPO в доменных средах.

Исправление 2 – Устранение ограничений групповой политики на серверах, присоединённых к домену

На серверах в домене групповая политика обычно имеет приоритет над локальными настройками безопасности. Если GPO отказывает в праве «Change the time zone», локальные изменения не переживут обновление политик.

Определите GPO, управляющий настройками времени и часового пояса

Чтобы найти ответственную GPO:

Откройте командную строку или PowerShell от имени администратора.
Выполните «gpresult /h c:\gp.html» и откройте созданный отчёт в браузере.
Просмотрите применённые GPO в разделе конфигурации компьютера на предмет настроек безопасности и назначений прав пользователей.
Либо запустите «rsop.msc», чтобы использовать инструмент «Итоговый набор политик» и изучить эффективные параметры.

Сконцентрируйтесь на политиках, задающих права «Change the time zone» и «Change the system time». Эти записи определяют, будет ли элемент управления часовым поясом доступен или засерен.

Измените GPO, чтобы разрешить «Change the time zone» для целевых серверов

В консоли управления групповыми политиками на контроллере домена или рабочей станции администратора:

Найдите GPO, идентифицированную на предыдущем шаге.
Щёлкните по ней правой кнопкой и выберите «Изменить» (Edit).
Перейдите к Конфигурация компьютера > Политики > Конфигурация Windows > Параметры безопасности > Локальные политики > Назначение прав пользователя.
Откройте политику «Change the time zone».
Добавьте подходящие группы администраторов (например, выделенную группу администраторов серверов).
Убедитесь, что нет записей запрета или неожиданных групп, лишающих права.

Если в вашей организации используются отдельные OU для разных ролей серверов, рассмотрите возможность:

Создания выделенной GPO для серверов приложений, которым нужна большая гибкость.
Привязки её только к соответствующим OU, а не к контроллерам домена или высокочувствительным системам.
Сохранения для контроллеров домена более строгой базовой конфигурации с ограниченными изменениями часового пояса.

Принудительно обновите политики и проверьте изменения на тестовом сервере

Перед внедрением изменений на все серверы безопасно проверьте их:

Примените обновлённую GPO к тестовому серверу в том же OU, что и боевые серверы.
На тестовом сервере выполните «gpupdate /force».
Выйдите из системы и войдите снова, чтобы гарантировать обновление прав пользователей.
Откройте параметры «Дата и время» и убедитесь, что часовой пояс теперь можно изменять.
Подтвердите, что остальные требования безопасности из базовой конфигурации сохраняются.

После успешной проверки на тесте можно с уверенностью распространять изменения на продуктивные серверы. Если графический интерфейс всё ещё заблокирован или вы предпочитаете автоматизацию, следующий подход — использование PowerShell и командной строки.

Исправление 3 – Изменение часового пояса через PowerShell и командную строку

Иногда у администраторов есть право менять часовой пояс, но графический интерфейс остаётся заблокированным из-за ограничений оболочки, кастомных консолей или особенностей политики. В таких случаях PowerShell и «tzutil» часто продолжают работать и дают надёжный обходной путь.

Просмотр и установка часовых поясов с помощью командлетов PowerShell

PowerShell предоставляет встроенные командлеты для управления часовыми поясами, что упрощает задачу:

Откройте PowerShell от имени администратора.
Выполните «Get-TimeZone -ListAvailable», чтобы увидеть все доступные часовые пояса и их идентификаторы.
Найдите точный идентификатор нужного часового пояса, например «UTC» или «Pacific Standard Time».
Выполните «Set-TimeZone -Name “Идентификатор часового пояса”», чтобы применить новый часовой пояс.
Подтвердите изменение командой «Get-TimeZone».

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

Использование «tzutil.exe» для быстрых изменений часового пояса

Команда «tzutil» работает в командной строке или PowerShell и удобна, когда нужен простой, сценарируемый инструмент:

Откройте командную строку от имени администратора.
Выполните «tzutil /l», чтобы получить список доступных часовых поясов с их идентификаторами.
Выполните «tzutil /s “Идентификатор часового пояса”», чтобы установить новый часовой пояс, используя один из перечисленных идентификаторов.
Откройте параметры «Дата и время», чтобы убедиться, что новый часовой пояс применён.

Благодаря лёгкости «tzutil» часто используется в сценариях развертывания, удалённых командах и конвейерах автоматизации.

Сценарная конфигурация часового пояса на множестве серверов

В крупных средах можно комбинировать PowerShell с удалённым выполнением и автоматизацией:

Используйте PowerShell Remoting и «Invoke-Command», чтобы запускать «Set-TimeZone» сразу на нескольких серверах.
Интегрируйте конфигурацию часового пояса в сценарии сборки серверов, средства управления конфигурацией или конвейеры CI/CD.
Фиксируйте каждое изменение в центральном месте, например в CMDB или журналирующей системе.

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

Особые сценарии: контроллеры домена, виртуальные машины и облачные серверы

Определённые типы серверов подчиняются более строгим правилам и требуют повышенного внимания. Изменение часового пояса без плана на таких серверах может вызвать проблемы далеко за пределами одной неактивной кнопки.

Лучшие практики настройки часового пояса на контроллерах домена

Контроллеры домена часто выступают источниками времени для остальных членов домена. Работая с ними, следует:

Поддерживать синхронизацию контроллеров домена с надёжными NTP-источниками.
Использовать по возможности один и тот же часовой пояс для всех контроллеров домена в лесу.
Избегать частых изменений времени или часового пояса на контроллерах домена.
Тестировать любые изменения, связанные со временем, в лабораторном домене до применения в продуктивной среде.

Некорректная конфигурация времени на контроллерах домена может вызывать проблемы доверия, сбои аутентификации и несогласованные журналы по всему домену. Рассматривайте изменения на контроллерах домена как высоко рискованные и всегда следуйте процессу управления изменениями.

Работа с часовым поясом на Hyper-V, VMware и других виртуальных машинах

Виртуальные машины добавляют ещё один слой сложности, потому что гипервизор может влиять на их часы:

Гипервизоры могут синхронизировать время гостя со временем хоста, иногда переопределяя настройки гостевой системы.
Инструменты или агенты VM могут периодически корректировать время по настройкам хоста.
Шаблоны и эталонные образы могут иметь часовой пояс по умолчанию, не совпадающий с целевым регионом.

Лучшей практикой является:

Настройка правильного часового пояса в базовом образе до его клонирования или развертывания.
Принятие решения, кто контролирует синхронизацию времени — хост или гость — и согласованная настройка соответствующих параметров.
Отключение конфликтующей синхронизации времени между хостом и гостем, если вы полагаетесь на доменный NTP.

Настройка часового пояса в Azure, AWS и других облачных платформах

Облачные платформы часто развертывают образы Windows Server с часовым поясом по умолчанию, обычно привязанным к конкретному региону. Для управления часовыми поясами в облаке:

Добавляйте команды настройки часового пояса в сценарии инициализации, cloud-init или аналогичные механизмы.
Используйте инструменты инфраструктуры как кода — ARM, Bicep, Terraform, CloudFormation — чтобы задавать правильный часовой пояс при развертывании.
Убедитесь, что группы авто-масштабирования, наборы масштабирования или пулы VM используют образы с одинаковой, корректной конфигурацией.

Это обеспечивает согласованность облачных серверов, даже когда среда автоматически масштабируется вверх или вниз. Если, несмотря на все усилия, часовой пояс остаётся заблокированным, потребуется более глубокая диагностика.

Устранение неполадок, когда часовой пояс всё ещё неактивен

Когда обычные исправления не помогают, чаще всего другой уровень конфигурации переопределяет ваши изменения. На этом этапе нужно смотреть дальше встроенных средств Windows.

Проверьте, не переопределяют ли настройки средства управления конфигурацией

Ищите централизованные средства управления или безопасности, которые могут навязывать параметры времени:

System Center Configuration Manager (SCCM) или Microsoft Intune.
Инструменты управления конфигурацией, такие как Ansible, Puppet или Chef.
Средства защиты конечных точек, усиления безопасности или контроля соответствия, применяющие базовые настройки.

Эти платформы могут применять временные настройки при каждом цикле обновления. Проверьте их конфигурации на наличие:

Задач или политик, изменяющих время или часовой пояс.
Шаблонов базовых настроек, корректирующих назначение прав пользователей.
Скриптов исправления, возвращающих настройки времени после ручных изменений.

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

Изучите реестр и журналы событий на предмет ошибок, связанных с временем

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

Проверьте в «Просмотре событий» разделы System и Security на наличие ошибок, связанных с временем или политиками.
Ищите предупреждения о назначении прав пользователей или конфликтах групповых политик.
Убедитесь, что служба времени Windows (W32Time) запускается и работает корректно.

Идентификаторы событий и сообщения об ошибках часто показывают, какой компонент заблокировал изменение и когда это произошло. Эта информация очень полезна при эскалации проблемы.

Когда следует эскалировать вопрос в команды безопасности или службы каталогов

Если после проверки всех этих уровней вы всё ещё не можете изменить часовой пояс, пора эскалировать проблему:

Обратитесь к команде безопасности, если, по-видимому, базовая конфигурация или политика безопасности блокирует изменения.
Попросите команду Active Directory или служб каталогов просмотреть доменные GPO, применяемые к серверу.
Предоставьте чёткие симптомы, идентификаторы событий и список уже предпринятых шагов.

Это позволяет сохранить соответствие требованиям безопасности и нормативов и предотвращает случайное нарушение политик. После того как вы восстановите контроль над настройками часового пояса, стоит сделать шаг назад и спроектировать устойчивую стратегию конфигурации времени.

Лучшие практики для времени и часового пояса в Windows Server

Исправление одного сервера полезно, но долговременная стабильность обеспечивается единообразным подходом. Ясная стратегия по времени и часовому поясу снижает количество инцидентов и делает журналы и приложения предсказуемыми.

Выберите между UTC и местным временем для каждого типа нагрузки

Многие команды выбирают одну из двух моделей:

UTC везде: использовать UTC на всех серверах и корректировать время на уровне приложений, панелей мониторинга и отчётов.
Местное время по региону: использовать локальный часовой пояс в каждом регионе, где работают серверы.

UTC упрощает кросс-региональное журналирование и устранение неполадок, особенно в глобальных центрах операций. Местное время может быть удобнее для региональных приложений и команд поддержки, ожидающих локальные временные метки.

Выберите модель для конкретной нагрузки или окружения, задокументируйте её и применяйте последовательно. Избегайте смешивания подходов без веских причин.

Стандартизируйте политики NTP и часового пояса во всех средах

Создайте стандарт того, как серверы поддерживают время:

Определите доверенные источники NTP, внутренние или внешние.
Настройте ясные правила групповой политики для прав на изменение времени и часового пояса.
Используйте один и тот же подход в средах разработки, теста и эксплуатации.

Это делает поведение предсказуемым и уменьшает количество исключений, которые приводят к засеренным настройкам или конфликтующим источникам времени. Включите в общую схему контроллеры домена, серверы приложений и облачные VM.

Наконец, относитесь к конфигурации времени как к части операционных стандартов:

Задокументируйте стандартные настройки времени в регламентах, архитектурных схемах и руководствах по внедрению.
Отслеживайте уход времени и аномалии часовых поясов с помощью инструментов наблюдаемости или SIEM.
Включайте конфигурацию времени в регулярные проверки безопасности и соответствия.

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

Заключение

Неактивный (засеренный) параметр часового пояса в Windows Server — не загадка и обычно не означает поломку. Почти всегда это указывает на то, что права, групповая политика или средства безопасности делают именно то, для чего были созданы. Ваша задача — понять эти механизмы и скорректировать их безопасным, управляемым способом.

Проверив роль сервера и свои права учетной записи, изучив локальную политику безопасности, просмотрев групповую политику и используя PowerShell или «tzutil», вы можете вернуть возможность изменять часовой пояс там, где это нужно. Для контроллеров домена, виртуальных машин и облачных серверов аккуратный и стандартизованный подход предотвращает более серьёзные проблемы.

Комбинируя эти меры с чёткими политиками, автоматизацией и мониторингом, вы редко будете сталкиваться с ситуацией «Windows Server часовой пояс неактивен». Вместо этого вы получите более надёжную и поддающуюся аудиту инфраструктуру, где проблемы, связанные со временем, редки, легко диагностируются и быстро решаются.

Часто задаваемые вопросы

Почему часовой пояс в Windows Server по-прежнему недоступен для изменения (серый), даже если я работаю как администратор?

Даже если вы являетесь локальным или доменным администратором, групповая политика, базовый набор параметров безопасности или инструмент управления конфигурациями могут лишить вашу учетную запись права «Изменение часового пояса». Проверьте локальную политику безопасности, результирующую групповую политику и любые централизованные инструменты, которые могут переопределять эти параметры, а затем скорректируйте соответствующую политику, вместо того чтобы пытаться принудительно вносить локальные изменения.

Безопасно ли изменять часовой пояс на рабочем (production) сервере Windows?

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

Могу ли я автоматизировать настройку часового пояса для новых развертываний Windows Server?

Да. Вы можете автоматизировать настройку часового пояса с помощью команд PowerShell, таких как «Set-TimeZone», или с помощью «tzutil», а также интегрировать их в сценарии сборки, инструменты управления конфигурациями или шаблоны облачного развертывания. Убедитесь, что ваши групповые политики, базовые наборы параметров безопасности и инструменты управления конфигурациями поддерживают одну и ту же модель часовых поясов, чтобы автоматизация и политика оставались согласованными и не конфликтовали друг с другом.

Часовой пояс в Windows Server неактивен: причины, способы устранения и лучшие практики