Джон Сэвилл отвечает на наши вопросы по Azure. Часть I

У меня установлен DirSync для синхронизации с Azure. Существует ли простой способ обновить его до Azure AD Connect?
Azure AD Connect был выпущен 24 июня 2015 года, и сейчас его можно загрузить по адресу: www.microsoft.com/en-us/download/confirmation.aspx?id=47594. После загрузки он будет работать так: обнаружит существующую копию DirSync, автоматически удалит ее, а затем установит Azure AD Connect, обслуживая вашу исходную среду. Если вы повторно запустите мастер установки Azure AD Connect, то можно отрегулировать настройки и добавить дополнительные приложения на экран Start или в меню. Чтобы выполнить детальную настройку, включая параметры разных OU для выполнения ими резервирования, используйте менеджер синхронизации служб Synchronization Service Manager, который является клиентом Microsoft Identity Manager. Его можно найти по адресу: C:Program FilesMicrosoft AzureADSyncUIShellmiisclient.exe.

После развертывания Azure AD Connect вы можете задействовать функцию Azure AD Connect Health, которая поможет отслеживать работоспособность синхронизации. Полную информацию об Azure AD Connect Health можно найти по адресу: https://msdn.microsoft.com/en-us/library/azure/dn906722.aspx.


В предварительном обзоре портала Azure Portal говорится о функции автоматического обновления настроек операционной системы Automatic Updates OS Setting. В чем она заключается?
При помощи новой архитектуры, описанной в предварительном обзоре портала Azure, можно предоставить гораздо более удобный интерфейс, чем позволяет инициализация новой виртуальной машины Azure. Одной из новых функций является настройка автоматического обновления Automatic Updates на значение «включено», On (по умолчанию) или «выключено», Off. Эта настройка ссылается на исходную настройку Windows Update. Оставив настройку по умолчанию, выбранную в Windows Update, вы будете активировать ее же по умолчанию внутри гостевой операционной системы. Эту настройку можно найти на вкладке Optional Configuration — OS Settings, как показано на скриншоте выше.

Подробная информация опубликована в статье по адресу: https://msdn.microsoft.com/en-us/library/azure/jj157194.aspx. Особый акцент сделан на параметр EnableAutomaticUpdates.

Почему я получаю сообщение о возражении, связанное с использованием Switch-AzureMode?
С внедрением менеджера ресурсов Azure Resource Manager появилось два разных компонента операций при взаимодействии с Azure: менеджер служб Azure Service Manager (ASM) и менеджер ресурсов Azure Resource Manager (ARM).

Команда Switch-AzureMode используется для переключения между двумя компонентами. Это необходимо, поскольку команды имеют одно и то же имя в обоих компонентах. Но это становится причиной конфликта, поскольку они используются с разными параметрами. Для решения проблемы в дальнейшем команда Switch-AzureMode больше не будет предоставляться и вместе с командами Azure, которые работают с ASM, переместится в отдельный модуль. Более того, их имена будут изменены. Например, New-AzureVM для ASM будет называться New-ASMVM.

Сейчас вы можете игнорировать это сообщение о возражении. Но имейте в виду, что если вы продолжите использовать PowerShell с ASM, то в дальнейшем команды будут переименованы с Azure на ASM. Обратите внимание, что Microsoft будет предоставлять свой сценарий, который вы сможете использовать и который будет добавлять для команд имя Azure к имени ASM. При этом существующие сценарии ASM будут применяться без модификации.

Более подробную информацию можно найти в материале https://github.com/Azure/azure-powershell/issues/428.

Как мне удержать отдельную виртуальную машину в кластере Hyper-V от динамической миграции на другой узел?
При обычных обстоятельствах любая виртуальная машина в кластере Hyper-V должна иметь возможность запускаться на любом узле в кластере. Это дает максимум гибкости в вопросах регулировки нагрузки, доступности виртуальных машин во время процесса обновления и другого технического обслуживания, а также обеспечения запуска рабочих процессов при незапланированных отказах в работе. Таким образом, ваши параметры настройки не должны ограничивать виртуальные машины от запуска на любом из узлов в кластере. Однако в некоторых случаях (обычно из-за лицензирования ряда приложений, которые привязаны к конкретным физическим процессорам) может потребоваться убедиться, что определенные виртуальные машины могут запускаться только на конкретных хостах в кластере, даже если это означает, что виртуальная машина недоступна во время технического обслуживания или при отказе в работе.


Вы не можете блокировать функцию динамической миграции Live Migration виртуальной машины. Однако решение есть: переадресация возможных владельцев и удаление всех хостов, кроме того, на котором запускается Live Migration. Это можно сделать так:
1. Откройте менеджер кластера Failover Cluster Manager.
2. Во вкладке Roles выберите виртуальную машину.
3. В нижней секции окна разверните ресурс Virtual Machine на вкладке Resources.
4. Правой кнопкой мыши щелкните по VM configuration и выберите пункт Properties.
5. В окне Properties выберите Advanced Properties.
6. Снимите флажки со всех узлов, кроме текущего узла, затем щелкните OK (см. скриншоте выше).

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