Известные проблемы в выпуске Azure Local 2408
Область применения: Azure Local 2311.2 и более поздних версий
В этой статье рассматриваются критически важные известные проблемы и их обходные пути в выпуске Azure Local 2408.
Эти заметки о выпуске постоянно обновляются и по мере обнаружения критически важных проблем, требующих обходного решения, добавляются. Перед развертыванием локального экземпляра Azure внимательно просмотрите сведения, содержащиеся здесь.
Важный
Информацию о поддерживаемых путях обновления для этого выпуска см. в разделе Информация о выпуске.
Дополнительные сведения о новых функциях в этом выпуске см. в разделе Что нового в 23H2.
Известные проблемы для версии 2408
Этот выпуск программного обеспечения соответствует номеру версии программного обеспечения 2408.0.29.
Заметки о выпуске этой версии включают вопросы, исправленные в текущем релизе, известные вопросы в этом релизе и вопросы, связанные с заметками о выпуске, перенесенные из предыдущих версий.
Заметка
Подробные сведения об исправлении распространенных известных проблем см. в репозитории GitHub локальной поддержки Azure.
Исправлены проблемы
В этом выпуске исправлены следующие проблемы:
| Особенность | Проблема | Обходное решение или комментарии |
|---|---|---|
| Обновления | Исправлена проблема обновления, связанная с отсутствием поля идентификатора типа ресурса в проверке работоспособности. | |
| Обновления | Исправлена проблема обновления, связанная с различными проверками работоспособности с одинаковым именем. | |
| Управление виртуальными машинами Arc | В крупных сценариях развертывания, таких как обширные развертывания пула узлов AVD или крупномасштабная подготовка виртуальных машин, могут возникнуть проблемы с надежностью, вызванные проблемой внешней библиотеки сокета Hyper-V. |
Известные проблемы в этом выпуске
В следующей таблице перечислены известные проблемы в этом выпуске:
| Особенность | Проблема | Обходное решение |
|---|---|---|
| Восстановление сервера | После восстановления узла и выполнения команды 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 в качестве VHD для создания образа в галерее для развертывания виртуальной машины Arc не поддерживается. | Выполните команду restart-service mochostagent, чтобы перезапустить службу mochostagent. |
| Управление виртуальными машинами Arc | Если вы пытаетесь включить управление гостевыми системами на мигрированной виртуальной машине, операция завершается следующей ошибкой: веб-перехватчик "createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com", (InternalError), запрос был отклонён: OsProfile нельзя изменить после создания ресурса | |
| Сетевые технологии | Если узел настроен с прокси-сервером, содержащим заглавные буквы в адресе, например HTTPS://10.100.000.00:8080, расширения Arc не могут быть установлены или обновлены на узле в существующих сборках, включая версию 2408. Однако узел остается подключенным к 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 может не показывать свое включенное состояние, даже если она включена. Это происходит при использовании Windows Admin Center (Обзор безопасности кластера) или когда этот командлет возвращает False: Get-AzSSecurity -FeatureName SideChannelMitigation. |
В этом выпуске нет обходного решения для исправления выходных данных этих приложений. Чтобы проверить ожидаемое значение, выполните следующий командлет: Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -name "FeatureSettingsOverride*"Ожидаемые выходные данные: FeatureSettingsOverride: 83886152 FeatureSettingsOverrideMask: 3 Если выходные данные соответствуют ожидаемым выходным данным, вы можете безопасно игнорировать выходные данные из Центра администрирования Windows и командлета Get-AzSSecurity. |
| Управление виртуальными машинами Arc | Служба Mochostagent может работать, но может застрять без обновления журналов в течение месяца. Эту проблему можно определить, проверив журналы служб в C:\programdata\mochostagent\logs, чтобы узнать, обновляются ли журналы. |
Выполните следующую команду, чтобы перезапустить службу mochostagent: restart-service mochostagent. |
| Обновление | При обновлении метки с версии 2311 или более ранних сборок до версии 2408 или более поздней, может произойти сбой в операциях добавления и восстановления узлов. Например, можно увидеть ошибку: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
В этом выпуске нет обходного решения. Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт, чтобы определить дальнейшие действия. |
| Обновление | При установке обновления SBE для локальной системы Azure некоторые интерфейсы SBE не выполняются на всех компьютерах, если имя узла в кластере является подмножеством другого имени узла. Например, host-1 — это подмножество host-10. Это может привести к сбоям при сканировании CAU или запуске CAU. | Корпорация Майкрософт рекомендует использовать по крайней мере 2 цифры для количества экземпляров имени узла в соглашениях об именовании узлов. Дополнительные сведения см. в разделе Определение соглашения об именовании. |
Известные проблемы из предыдущих выпусков
В следующей таблице перечислены известные проблемы из предыдущих выпусков:
| Особенность | Вопрос | Обходное решение | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Обновление | При просмотре результатов проверки готовности для локального экземпляра 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 на HCI | Создание кластера AKS завершается сбоем с кодом ошибки Error: Invalid AKS network resource id. Эта проблема может возникнуть, если в связанном логическом сетевом имени присутствует символ подчеркивания. |
Символы подчеркивания не поддерживаются в именах логических сетей. Не используйте подчеркивание в именах логических сетей, развернутых в локальном экземпляре Azure. | ||||||||||||||||||
| Восстановление сервера | В редких случаях операция Repair-Server завершается ошибкой HealthServiceWaitForDriveFW. В этих случаях старые диски из восстановленного узла не удаляются, а новые диски зависают в режиме обслуживания. |
Чтобы предотвратить эту проблему, перед началом работы с Repair-Serverубедитесь, что узел НЕ разблокируется ни через Центр администрирования Windows, ни с помощью командлета PowerShell Suspend-ClusterNode -Drain. Если возникла проблема, обратитесь в службу поддержки Майкрософт для дальнейших действий. |
||||||||||||||||||
| Восстановление сервера | Эта проблема возникает при обновлении одиночного узла локального экземпляра 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. Это связано с проблемой в ходе валидационной проверки, которая ищет специальную запись разрешений для BitLocker с кодом 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 Local версии 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 может завершиться ошибкой, если во время этой операции автоматически созданный временный секрет субъект-сервиса начинается с дефиса. | Повторите развертывание и обновление. Попытка повторить должна регенерировать секрет 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. Неправильный синтаксис содержит неподдерживаемые символы, такие как &,",',<,>. Неправильный синтаксис обнаруживается на более позднем этапе при проверке кластера. |
Убедитесь, что синтаксис пути OU правильный и не включает неподдерживаемых символов. | ||||||||||||||||||
| Развёртывание | Развертывание через Azure Resource Manager прерывается через 2 часа. Развертывания, превышающие 2 часа, отображаются как неудачные в группе ресурсов, хотя кластер успешно создан. | Чтобы отслеживать развертывание на портале Azure, перейдите к ресурсу локального экземпляра Azure, а затем перейдите к новой записи развертывания. | ||||||||||||||||||
| Azure Site Recovery | 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, кнопка повторить попытку отключена. | Чтобы возобновить обновление, выполните следующую команду 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 ресурсы не запускаются после перезагрузки узла и наиболее типична в небольших кластерах. |
Если вы столкнулись с этой проблемой, обратитесь в службу поддержки Майкрософт для дальнейших действий. Они могут работать с вами, чтобы вручную перезапустить ресурсы кластера и возобновить обновление по мере необходимости. | ||||||||||||||||||
| Обновление | При применении обновления кластера к версии 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 минут. | Это временная проблема и может решиться самостоятельно. Подождите несколько минут и повторите операцию. Если проблема сохранится, обратитесь в службу поддержки Майкрософт. |
Дальнейшие действия
- Ознакомьтесь с обзором развертывания.