Известные проблемы в выпуске Azure Local 2411
Область применения: Azure Local 2311.2 и более поздних версий
В этой статье рассматриваются критически важные известные проблемы и их обходные пути в выпуске Azure Local 2411.
Эти заметки о выпуске постоянно обновляются, и по мере обнаружения критически важных проблем, которые требуют обходных решений, они добавляются. Перед развертыванием локального экземпляра Azure внимательно просмотрите сведения, содержащиеся здесь.
Важный
Сведения о поддерживаемых путях обновления для этого выпуска см. в сведения о выпуске.
Дополнительные сведения о новых функциях в этом выпуске см. в Что нового в 23H2.
Известные проблемы для версии 2411
Этот выпуск программного обеспечения сопоставляется с номером версии программного обеспечения 2411.0.24.
Важный
Новые развертывания этого программного обеспечения будут использовать сборку 2411.0.22, в то время как при обновлении с 2408.2 вы получите сборку 2411.0.24. Если вы уже обновили 2408.2 до 2411.0.22, действие не требуется.
Заметки о выпуске этой версии включают проблемы, исправленные в этом выпуске, известные проблемы в этом выпуске и проблемы с заметками о выпуске, перенесенные из предыдущих версий.
Заметка
Подробные сведения об исправлении известных проблем см. в репозитории GitHub Azure локальной поддержки.
Исправлены проблемы
В этом выпуске исправлены следующие проблемы:
| Особенность | Вопрос | Обходное решение или комментарии |
|---|---|---|
| Управление виртуальными машинами Arc | Если вы пытаетесь включить управление гостевыми клиентами на перенесенной виртуальной машине, операция завершается следующей ошибкой: веб-хук "createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com", (InternalError), запрос отклонен: OsProfile невозможно изменить после создания ресурса |
Известные проблемы в этом выпуске
В следующей таблице перечислены известные проблемы в этом выпуске:
| Особенность | Вопрос | Обходное решение |
|---|---|---|
| Уязвимость безопасности | Корпорация Майкрософт определила уязвимость безопасности, которая может предоставлять учетные данные локального администратора, используемые во время создания виртуальных машин Arc в локальной среде Azure для пользователей, не являющихся администраторами, на виртуальной машине и на узлах. Виртуальные машины Arc, работающие в выпусках до выпуска Azure Local 2411, уязвимы. |
Чтобы определить виртуальные машины Arc, для которых необходимо это изменение, и изменить пароли учетных записей, см. подробные инструкции в следующей статье: уязвимость безопасности для виртуальных машин Arc на локальном Azure. |
| Развертывание Модернизировать |
Если часовой пояс не задан в формате UTC перед развертыванием локальной среды Azure, во время проверки возникает ошибка ArcOperationTimeOut. Отображается следующее сообщение об ошибке: OperationTimeOut, не получено обновлений от устройства для операции. | В зависимости от вашего сценария выберите одно из следующих обходных решений для этой проблемы: Сценарий 1. Перед началом развертывания убедитесь, что часовой пояс имеет значение UTC. Подключитесь к каждому из локальных узлов Azure и измените часовой пояс на UTC. Выполните следующую команду: Set-TimeZone -Id "UTC". Сценарий 2. Если вы запустили развертывание без настройки часового пояса UTC и получили ошибку, указанную на этапе проверки, выполните следующие действия: 1. Подключитесь к каждому локальному узлу Azure. Измените часовой пояс в формате UTC с помощью Set-TimeZone -Id "UTC". Перезагрузите узлы.2. После перезапуска узлов перейдите к локальному ресурсу Azure на портале Azure. Запустите проверку еще раз, чтобы устранить проблему и продолжить развертывание или обновление. Подробные инструкции по исправлению см. в руководстве по устранению неполадок в репозитории локальной поддержки Azure GitHub. |
| Обновление | При обновлении с версии 2408.2.7 до 2411.0.24 процесс обновления может завершиться ошибкой со следующим сообщением об ошибке: Type 'CauPreRequisites' of Role 'CAU' raised an exception: Could not finish cau prerequisites due to error 'Cannot remove item C:\UpdateDistribution\<any_file_name>: Access to the path is denied.' |
Подробные инструкции по устранению этой проблемы см. в руководстве по устранению неполадок в локальной среде Azure для обновления. |
| Обновление | При выпуске версии 2411 обновление решения и расширения построителя решений не объединяются в одном процессе обновления. | Чтобы применить пакет расширения построителя решений, потребуется отдельный запуск обновления. |
| Обновление | При применении обновления решения в этом выпуске может произойти ошибка обновления. Это произойдет только в том случае, если обновление было начато до 26 ноября. Проблема, которая вызывает сбой, может привести к одному из следующих сообщений об ошибках: Ошибка 1 - На шаге "обновление ARB и расширения" произошла ошибка: "Clear-AzContext не удалось вызвать с 0, и исключение при вызове "Инициализация" с аргументами «1»: "Ссылка на объект не установлена на экземпляр объекта." в "Clear-AzPowerShellCache". Ошибка 2. Во время выполнения шага "EvalTVMFlow" возникла ошибка "CloudEngine.Actions.InterfaceInvocationFailedException: тип 'EvalTVMFlow' роли 'ArcIntegration' вызвал исключение: этому модулю требуется версия Az.Accounts 3.0.5. Более ранняя версия Az.Accounts импортируется в текущем сеансе PowerShell. Перед импортом этого модуля откройте новый сеанс. Эта ошибка может указывать на то, что в системе установлены несколько несовместимых версий командлетов Azure PowerShell. Сведения об устранении неполадок см. в https://aka.ms/azps-version-error". В зависимости от версии модулей PowerShell, об этой ошибке может быть зарегистрирована для версий 3.0.4 и 3.0.5. |
Подробные инструкции по устранению этой проблемы см. в статье https://aka.ms/azloc-update-30221399. |
Известные проблемы из предыдущих выпусков
В следующей таблице перечислены известные проблемы из предыдущих выпусков:
| Особенность | Вопрос | Обходное решение | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Восстановление сервера | После восстановления узла и выполнения команды Set-AzureStackLCMUserPasswordможет возникнуть следующая ошибка: CloudEngine.Actions.InterfaceInvocationFailedException: Type 'ValidateCredentials' of Role 'SecretRotation' raised an exception: Cannot load encryption certificate. The certificate setting 'CN=DscEncryptionCert' does not represent a valid base-64 encoded certificate, nor does it represent a valid certificate by file, directory, thumbprint, or subject name. at Validate-Credentials |
Выполните следующие действия, чтобы устранить проблему: $NewPassword = <Provide new password as secure string> $OldPassword = <Provide the old/current password as secure string> $Identity = <LCM username> $credential = New-Object -TypeName PSCredential -ArgumentList $Identity, $NewPassword 1. Импортируйте необходимый модуль: Import-Module "C:\Program Files\WindowsPowerShell\Modules\Microsoft.AS.Infra.Security.SecretRotation\PasswordUtilities.psm1" -DisableNameChecking 2. Проверьте состояние группы кластеров ECE: $eceClusterGroup = Get-ClusterGroup | Where-Object {$_.Name -eq "Azure Stack HCI Orchestrator Service Cluster Group"} if ($eceClusterGroup.State -ne "Online") {Write-AzsSecurityError -Message "ECE cluster group is not in an Online state. Cannot continue with password rotation." -ErrRecord $_} 3. Обновите ECE с новым паролем: Write-AzsSecurityVerbose -Message "Updating password in ECE" -Verbose $eceContainersToUpdate = @("DomainAdmin", "DeploymentDomainAdmin", "SecondaryDomainAdmin", "TemporaryDomainAdmin", "BareMetalAdmin", "FabricAdmin", "SecondaryFabric", "CloudAdmin") <br><br> foreach ($containerName in $eceContainersToUpdate) {Set-ECEServiceSecret -ContainerName $containerName -Credential $credential 3>$null 4>$null} <br><br> Write-AzsSecurityVerbose -Message "Finished updating credentials in ECE." -Verbose 4. Обновите пароль в Active Directory: Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Управление виртуальными машинами Arc | Использование экспортированного диска ОС виртуальной машины Azure в качестве виртуального жесткого диска для создания образа галереи для развёртывания виртуальной машины Arc не поддерживается. | Выполните команду restart-service mochostagent, чтобы перезапустить службу mochostagent. |
||||||||||||||||||
| Нетворкинг | Если узел настроен с прокси-сервером с прописными буквами в адресе, например HTTPS://10.100.000.00:8080, расширения Arc не могут установить или обновить узел в существующих сборках, включая версию 2408.1. Однако узел остается подключенным к Arc. | Выполните следующие действия, чтобы устранить проблему: 1. Задайте значения среды в нижнем регистре. [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. Проверьте, были ли заданы значения. [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine").
3. Перезапустите службы Arc. Restart-Service himds
Restart-Service ExtensionService
Restart-Service GCArcService
4. Использовать сигнал для AzcmaAgent с информацией о прокси-сервере, записанной в нижнем регистре. & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url https://10.100.000.00:8080
& 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list |
||||||||||||||||||
| Нетворкинг | Когда машины Arc выходят из строя, на странице "Все кластеры" в новом интерфейсе портала отображается состояние "Частично подключено" или "Не подключено недавно". Даже если компьютеры Arc становятся работоспособными, они могут не отображать состояние "Подключено". | Для этой проблемы нет известного обходного решения. Чтобы проверить состояние подключения, используйте старый интерфейс, чтобы узнать, отображается ли оно как "подключено". | ||||||||||||||||||
| Безопасность | Функция безопасности SideChannelMitigation может не отображать включенное состояние, даже если оно включено. | В этом выпуске нет обходного пути. Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт, чтобы определить дальнейшие действия. | ||||||||||||||||||
| Управление виртуальными машинами Arc | Служба Mochostagent может работать, но может застрять без обновления журналов в течение месяца. Эту проблему можно определить, проверив журналы служб в C:\programdata\mochostagent\logs, чтобы узнать, обновляются ли журналы. |
Выполните следующую команду, чтобы перезапустить службу mochostagent: restart-service mochostagent. |
||||||||||||||||||
| Обновление | При обновлении метки с версии 2311 или более ранней сборки до версии 2408 или более поздней может произойти сбой в операциях добавления и восстановления узла. Например, можно увидеть ошибку: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
В этом выпуске нет обходного пути. Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт, чтобы определить дальнейшие действия. | ||||||||||||||||||
| Обновить | При просмотре результатов проверки готовности для локального экземпляра Azure с помощью Диспетчера обновлений Azure могут быть несколько проверок готовности с одинаковым именем. | В этом выпуске нет известного обходного решения. Выберите Просмотреть сведения, чтобы увидеть конкретную информацию о проверке готовности. | ||||||||||||||||||
| развертывание | В некоторых случаях во время регистрации локальных компьютеров Azure эта ошибка может появиться в журналах отладки: обнаружена внутренняя ошибка сервера. Возможно, не установлен один из обязательных расширений для развертывания устройства. | Выполните следующие действия, чтобы устранить проблему: $Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" } New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController" New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade |
||||||||||||||||||
| Обновить | В этом выпуске возникает периодическая проблема, когда портал Azure ошибочно отображает состояние обновления как не удалось обновить или во время выполнения, хотя обновление завершено. |
Подключиться к локальному экземпляру Azure через удаленный сеанс PowerShell. Чтобы подтвердить состояние обновления, выполните следующие командлеты PowerShell: $Update = get-solutionupdate| ? version -eq "<version string>"Замените строку версии на используемую вами версию. Например, "10.2405.0.23". $Update.stateЕсли статус обновления — установлено, никаких дальнейших действий с вашей стороны не требуется. Портал Azure правильно обновляет состояние в течение 24 часов. Чтобы обновить состояние раньше, выполните следующие действия на одном из узлов. Перезапустите группу кластеров Cloud Management. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| Обновление | Во время первоначального обновления MOC происходит сбой из-за отсутствия целевой версии MOC в кэше каталога. Последующие обновления и повторные попытки показывают MOC в целевой версии, но не приводят к успешному обновлению, и в результате этого обновление Моста ресурсов Arc терпит неудачу. Чтобы проверить эту проблему, соберите журналы обновлений, используя для устранения неполадок обновлений решений Azure Local версии 23H2. Файлы журнала должны отображать аналогичное сообщение об ошибке (текущая версия может отличаться в сообщении об ошибке): [ERROR: { "errorCode": "InvalidEntityError", "errorResponse": "{\n\"message\": \"the cloud fabric (MOC) is currently at version v0.13.1. A minimum version of 0.15.0 is required for compatibility\"\n}" }] |
Выполните следующие действия, чтобы устранить проблему: 1. Чтобы найти версию агента MOC, выполните следующую команду: 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Используйте выходные данные команды, чтобы найти версию MOC из приведенной ниже таблицы, которая соответствует версии агента, и задайте $initialMocVersion этой версии MOC. Задайте $targetMocVersion, найдя локальную сборку Azure, к которой вы обновляетесь, и определите соответствующую версию MOC из следующей таблицы. Используйте эти значения в скрипте устранения рисков, приведенном ниже:
Например, если версия агента — v0.13.0-6-gf13a73f7, v0.11.0-alpha.38, 01/06/2024, то это $initialMocVersion = "1.0.24.10106", а если вы обновляетесь до 2405.0.23, то $targetMocVersion = "1.3.0.10418".3. Выполните следующие команды PowerShell на первом узле: $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# Импорт модуля MOC дважды import-module mocimport-module moc$verbosePreference = "Continue"# Очистка кэша каталога SFS Remove-Item (Get-MocConfig).manifestCache# Установите версию текущей версии MOC до обновления и задайте состояние как сбой обновления Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# Повторное выполнение обновления MOC до требуемой версии Update-Moc -version $targetMocVersion4. Возобновление обновления. |
||||||||||||||||||
| AKS в локальной среде Azure | Создание кластера AKS завершается сбоем из-за Error: Invalid AKS network resource id. Эта проблема может возникать, если связанное имя логической сети содержит подчеркивание. |
Символы подчеркивания не поддерживаются в именах логических сетей. Не используйте подчеркивание в именах логических сетей, развернутых в локальной среде Azure. | ||||||||||||||||||
| Восстановление сервера | В редких случаях операция Repair-Server завершается ошибкой HealthServiceWaitForDriveFW. В этих случаях старые диски из восстановленного узла не удаляются, а новые диски зависают в режиме обслуживания. |
Чтобы предотвратить эту проблему, убедитесь, что НИ В КОЕМ СЛУЧАЕ НЕ освобождаете узел через Центр администрирования Windows или с помощью командлета PowerShell Suspend-ClusterNode -Drain перед началом работы с Repair-Server. Если возникла проблема, обратитесь в службу поддержки Майкрософт для дальнейших действий. |
||||||||||||||||||
| Восстановление сервера | Эта проблема возникает, когда локальный экземпляр Azure с одним узлом обновляется с версии 2311 до версии 2402, а затем выполняется Repair-Server. Операция восстановления завершается ошибкой. |
Перед восстановлением одного узла выполните следующие действия. 1. Запустите версию 2402 для ADPrepTool. Выполните действия, описанные в подготовкеActive Directory. Это действие выполняется быстро и добавляет необходимые разрешения в организационную единицу (OU). 2. Переместите объект компьютера из компьютеров сегмент в корневую подразделение. Выполните следующую команду: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| Развертывание | Если вы подготавливаете Active Directory самостоятельно (не используя скрипт и процедуру, предоставляемую корпорацией Майкрософт), проверка Active Directory может завершиться ошибкой с отсутствием разрешения Generic All. Это связано с проблемой в проверке, которая проверяет наличие выделенной записи разрешений для msFVE-RecoverInformationobjects – General – Permissions Full control, которая требуется для восстановления BitLocker. |
Используйте метод скрипта Prepare AD, или, если вы используете собственный метод, обязательно назначьте конкретные разрешения msFVE-RecoverInformationobjects – General – Permissions Full control. |
||||||||||||||||||
| Развертывание | В этом выпуске возникает редкая проблема, из-за которой запись DNS удаляется во время локального развертывания Azure. В этом случае будет видно следующее исключение: Type 'PropagatePublicRootCertificate' of Role 'ASCA' raised an exception:<br>The operation on computer 'ASB88RQ22U09' failed: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer ASB88RQ22U09.local. Verify that the computer exists on the network and that the name provided is spelled correctly at PropagatePublicRootCertificate, C:\NugetStore\Microsoft.AzureStack, at Orchestration.Roles.CertificateAuthority.10.2402.0.14\content\Classes\ASCA\ASCA.psm1: line 38, at C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 127,at Invoke-EceInterfaceInternal, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 123. |
Проверьте DNS-сервер, чтобы узнать, отсутствуют ли записи DNS узлов. Примените следующие меры по устранению на узлах, где отсутствует запись его DNS. Перезапустите службу DNS-клиента. Откройте сеанс PowerShell и выполните следующий командлет на затронутом узле: Taskkill /f /fi "SERVICES eq dnscache" |
||||||||||||||||||
| Развертывание | В этом выпуске при развертывании на нескольких узлах происходит сбой задачи в удаленном доступе, что приводит к следующему исключению:ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>). |
Устранение рисков заключается в перезапуске агента ECE на затронутом узле. На компьютере откройте сеанс PowerShell и выполните следующую команду:Restart-Service ECEAgent. |
||||||||||||||||||
| Добавить сервер | В этом выпуске и предыдущих выпусках при добавлении компьютера в систему невозможно обновить строку списка обхода прокси-сервера, чтобы включить новый компьютер. Обновление списка переменных среды для обхода прокси-сервера на узлах не приведет к обновлению такого списка на Azure Resource Bridge или AKS. | В этом выпуске нет обходного пути. Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт, чтобы определить дальнейшие действия. | ||||||||||||||||||
| Добавление/Ремонт сервера | В этом выпуске при добавлении или восстановлении компьютера наблюдается сбой, когда сертификаты виртуальных машин программного балансировщика нагрузки или сетевого контроллера копируются с существующих узлов. Сбой заключается в том, что эти сертификаты не были созданы во время развертывания или обновления. | В этом выпуске нет обходного пути. Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт, чтобы определить дальнейшие действия. | ||||||||||||||||||
| Развертывание | В этом выпуске возникает временная проблема, приводяшая к сбою развертывания со следующим исключением:Type 'SyncDiagnosticLevel' of Role 'ObservabilityConfig' raised an exception:*<br>*Syncing Diagnostic Level failed with error: The Diagnostic Level does not match. Portal was not set to Enhanced, instead is Basic. |
Так как это временная проблема, повторная попытка развертывания должна устранить эту проблему. Дополнительные сведения см. в статье о том, как повторно запуститьразвертывания. | ||||||||||||||||||
| Развертывание | В этом выпуске возникла проблема с полем URI/расположения секретов. Это обязательное поле, которое помечается Не обязательно и приводит к сбоям развертывания шаблона Azure Resource Manager. | Используйте пример файла параметров в развертывания локальной версии Azure версии 23H2 с помощью шаблона Azure Resource Manager, чтобы убедиться, что все входные данные предоставляются в требуемом формате, а затем попробуйте развернуть. Если произошел сбой развертывания, необходимо также очистить следующие ресурсы, прежде чем повторно запустить развертывание: 1. Удалите C:\EceStore. 2. Удалите C:\CloudDeployment. 3. Удалите C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
||||||||||||||||||
| Безопасность | Для новых развертываний устройства с поддержкой Secured-core не будут иметь динамический корень измерения (DRTM) по умолчанию. Если вы попытаетесь включить (DRTM) с помощью командлета Enable-AzSSecurity, вы увидите сообщение об ошибке, что параметр DRTM не поддерживается в текущем выпуске. Корпорация Майкрософт рекомендует глубинную защиту, и безопасная загрузка UEFI всё ещё защищает компоненты в цепочке загрузки статического корня доверия (SRT), гарантируя, что они загружаются только при наличии подписи и проверки. |
DRTM не поддерживается в этом выпуске. | ||||||||||||||||||
| Нетворкинг | Проверка среды завершается ошибкой при использовании прокси-сервера. Изначально список исключений отличается для winhttp и wininet, что приводит к сбою проверки. | Выполните следующие обходные действия: 1. Очистите список обхода прокси-сервера перед проверкой работоспособности и перед началом развертывания или обновления. 2. После прохождения проверки дождитесь сбоя развертывания или обновления. 3. Снова задайте список обхода прокси-сервера. |
||||||||||||||||||
| Управление виртуальными машинами Arc | Развертывание или обновление Arc Resource Bridge может завершиться ошибкой, когда автоматически созданный временный секрет для SPN во время этой операции начинается с дефиса. | Повторите развертывание и обновление. Повторная попытка должна заново сгенерировать секрет SPN, и операция, вероятно, завершится успешно. | ||||||||||||||||||
| Управление виртуальными машинами Arc | Расширения Arc на виртуальных машинах Arc продолжают оставаться в состоянии "Создание" на неопределённое время. | Войдите на виртуальную машину, откройте командную строку и введите следующее: Windows: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json Затем найдите свойство resourcename. Удалите GUID, добавляемый в конец имени ресурса, поэтому это свойство соответствует имени виртуальной машины. Затем перезапустите виртуальную машину. |
||||||||||||||||||
| Управление виртуальными машинами Arc | При добавлении нового компьютера в локальный экземпляр Azure путь к хранилищу не создается автоматически для созданного тома. | Вы можете вручную создать путь к хранилищу для любых новых томов. Дополнительные сведения см. в статье Создание пути хранения. | ||||||||||||||||||
| Управление виртуальными машинами Arc | Перезапуск операции виртуальной машины Arc завершается примерно через 20 минут, хотя сама виртуальная машина перезапускается примерно за минуту. | В этом выпуске нет известного обходного решения. | ||||||||||||||||||
| Управление виртуальными машинами Arc | В некоторых случаях состояние логической сети отображается как сбой на портале Azure. Это происходит при попытке удалить логическую сеть без первого удаления ресурсов, таких как сетевые интерфейсы, связанные с этой логической сетью. Вы по-прежнему сможете создавать ресурсы в этой логической сети. Состояние вводит в заблуждение в этом случае. |
Если состояние этой логической сети было успешно на момент развертывания этой сети, можно продолжить создание ресурсов в ней. | ||||||||||||||||||
| Управление виртуальными машинами Arc | В этом выпуске при обновлении виртуальной машины с подключенным к ней диском данных с помощью Azure CLI операция завершается ошибкой со следующим сообщением об ошибке: не удалось найти виртуальный жесткий диск с именем. |
Используйте портал Azure для всех операций обновления виртуальной машины. Дополнительные сведения см. в статье Управление виртуальными машинами Arc и управление ресурсами виртуальных машин Arc. | ||||||||||||||||||
| Обновление | В редких случаях при обновлении локального экземпляра Azure может возникнуть эта ошибка: Type 'UpdateArbAndExtensions' of Role 'MocArb' raised an exception: Exception Upgrading ARB and Extension in step [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Invalid applianceyaml = [C:\AksHci\hci-appliance.yaml]. |
Если вы видите эту проблему, обратитесь в службу поддержки Майкрософт, чтобы помочь вам выполнить следующие действия. | ||||||||||||||||||
| Нетворкинг | В этом выпуске возникает нечасто возникающая проблема с DNS-клиентом, которая приводит к сбою развертывания в двухузловой системе с ошибкой разрешения DNS: При отправке RestRequest произошла ошибка WebException. WebException.Status: NameResolutionFailure. В результате сбоя запись DNS второго узла удаляется вскоре после его создания, что приводит к ошибке DNS. | Перезапустите компьютер. Эта операция регистрирует запись DNS, которая предотвращает удаление. | ||||||||||||||||||
| Azure портал | В некоторых случаях портал Azure может занять некоторое время для обновления, и представление может не быть текущим. | Чтобы просмотреть обновленное представление, может потребоваться 30 минут или более. | ||||||||||||||||||
| Управление виртуальными машинами Arc | Удаление сетевого интерфейса на виртуальной машине Arc на портале Azure не работает в этом выпуске. | Используйте Azure CLI, чтобы сначала удалить сетевой интерфейс, а затем удалить его. Дополнительные сведения см. в статье Удаление сетевого интерфейса и удалениесетевого интерфейса. | ||||||||||||||||||
| Развёртывание | Указание имени подразделения в неправильном синтаксисе не определяется на портале Azure. Неправильный синтаксис содержит неподдерживаемые символы, такие как &,",',<,>. Неправильный синтаксис обнаруживается на более позднем этапе во время проверки системы. |
Убедитесь, что синтаксис пути Организационной единицы корректен и не содержит неподдерживаемых символов. | ||||||||||||||||||
| Развёртывание | Развёртывания с помощью Azure Resource Manager прерываются через 2 часа. Развертывания, превышающие 2 часа, отображаются как неудачные в группе ресурсов, хотя система успешно создана. | Чтобы отслеживать развертывание на портале Azure, откройте локальный экземпляр Azure, а затем перейдите к новой вкладке развертывания. | ||||||||||||||||||
| Azure Site Recovery (восстановление сайтов Azure) | Azure Site Recovery нельзя установить в локальном экземпляре Azure этой версии. | В этом выпуске нет известного обходного решения. | ||||||||||||||||||
| Обновить | При обновлении локального экземпляра Azure с помощью диспетчера обновлений Azure ход обновления и результаты могут не отображаться на портале Azure. | Чтобы обойти эту проблему, на каждом узле добавьте следующий раздел реестра (значение не требуется):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceЗатем на одном из узлов перезапустите группу кластеров Cloud Management. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Это не полностью исправит проблему, так как сведения о ходе выполнения по-прежнему не отображаются в течение периода обновления. Чтобы получить последние сведения об обновлении, можно отследить ход обновления с помощью PowerShell. |
||||||||||||||||||
| Обновление | В редких случаях, если неудачное обновление зависло в состоянии В процессе в Azure Update Manager, кнопка Повторить попытку отключена. | Чтобы возобновить обновление, выполните следующую команду PowerShell:Get-SolutionUpdate
|
Start-SolutionUpdate. |
||||||||||||||||||
| Обновление | В некоторых случаях команды SolutionUpdate могут завершиться ошибкой, если они выполняются после команды Send-DiagnosticData. |
Закройте сеанс PowerShell, используемый для Send-DiagnosticData. Откройте новый сеанс PowerShell и используйте его для SolutionUpdate команд. |
||||||||||||||||||
| Обновление | В редких случаях, при применении обновления с 2311.0.24 до 2311.2.4, системные отчеты о состоянии сообщают "Ход выполнения" вместо ожидаемого "Не удалось выполнить обновление". | Повторите обновление. Если проблема сохранится, обратитесь в службу поддержки Майкрософт. | ||||||||||||||||||
| Обновление | Попытки установки обновлений решения могут завершиться неудачей в конце этапов CAU:There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on.
Эта редкая проблема возникает, если Cluster Name или Cluster IP Address ресурсы не запускались после перезагрузки узла и наиболее типичны в небольших развертываниях. |
Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт для дальнейших действий. Они могут работать с вами, чтобы вручную перезапустить локальные ресурсы Azure и возобновить обновление по мере необходимости. | ||||||||||||||||||
| Обновление | При применении обновления системы к версии 10.2402.3.11 командлет Get-SolutionUpdate может не отвечать и в конечном итоге завершается ошибкой RequestTimeoutException примерно через 10 минут. Это может произойти после сценария добавления или восстановления сервера. |
Используйте командлеты Start-ClusterGroup и Stop-ClusterGroup для перезапуска службы обновления. Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group"
|
Stop-ClusterGroup
Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group"
|
Start-ClusterGroup
Успешный запуск этих командлетов должен привести службу обновления в режим "в сети". |
||||||||||||||||||
| Кластерно-осведомлённое обновление | Не удалось возобновить операцию узла. | Это временная проблема и может решиться самостоятельно. Подождите несколько минут и повторите операцию. Если проблема сохранится, обратитесь в службу поддержки Майкрософт. | ||||||||||||||||||
| Кластерно-осведомлённое обновление | Приостановка операции узла зашла в тупик на более чем 90 минут. | Это временная проблема и может решиться самостоятельно. Подождите несколько минут и повторите операцию. Если проблема сохранится, обратитесь в службу поддержки Майкрософт. |
Дальнейшие действия
- Ознакомьтесь с обзором развертывания.