Azure Stack Hub: Archivierte Versionshinweise

Artikel
10/30/2024

In diesem Artikel werden die Inhalte der Azure Stack Hub-Updatepakete beschrieben. Das Update enthält Verbesserungen und Fehlerbehebungen für dieses Release von Azure Stack Hub.

Um auf Versionshinweise für eine andere archivierte Version zuzugreifen, verwenden Sie die Dropdown-Auswahlliste oberhalb des Inhaltsverzeichnisses auf der linken Seite.

Buildreferenz 2311

Die Buildnummer des Azure Stack Hub 2311-Updates ist 1.2311.1.22.

Updatetyp

Der Buildtyp des Azure Stack Hub 2311-Updates ist vollständig. Dieser Build enthält nur wichtige Sicherheitsupdates.

Das Update 2311 verfügt über die folgenden erwarteten Laufzeiten basierend auf unseren internen Tests:

4 Knoten: 36-50 Stunden
8 Knoten: 36-50 Stunden
12 Knoten: 50-80 Stunden
16 Knoten: 50-90 Stunden

Wichtig

Getrennte Umgebungen verfügen über zusätzliche Erforderliche Schritte, die diese Dauer erhöhen können. Die erforderlichen Schritte zum Abrufen und Aktualisieren eines SQL Server 2019-Product Keys (PID) finden Sie im folgenden Abschnitt.

Die genaue Dauer des Updates hängt in der Regel von der Kapazität ab, die auf Ihrem System durch Mandanten-Workloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Eine Dauer, die kürzer oder länger als erwartet ist, ist nicht ungewöhnlich und erfordert kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese Laufzeitangleichung ist spezifisch für das 2311-Update und sollte nicht mit anderen Azure Stack Hub-Updates verglichen werden.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Der VPN-Fast-Pfad für Operatoren und für Benutzer ist jetzt allgemein verfügbar. Die neuen VPN-SKUs ermöglichen Szenarien, in denen ein höherer Netzwerkdurchsatz erforderlich ist. Weitere Informationen zu diesem Feature finden Sie in der Dokumentation.
Mit 2311 kündigen wir die öffentliche Vorschau des Azure Stack Hub Load Balancer Standard an. Dieses Feature ermöglicht mehrere Szenarien: Eigenständige VMs können sich in einem Back-End-Pool befinden, HTTPS-Probes, Hochverfügbarkeitsports und TCP-Zurücksetzung im Leerlauf.
Azure Site Recovery befindet sich derzeit in der öffentlichen Vorschau, die einen vereinfachten Bereitstellungsprozess enthält, der nur eine Abhängigkeit erfordert. Wir sind bestrebt, diese Lösung bis zum Zeitpunkt unserer allgemeinen Verfügbarkeit Anfang 2024 weiter zu optimieren, an dem wir beabsichtigen, alle Abhängigkeiten außer dem Site Recovery-Ressourcenanbieter selbst zu beseitigen. In der Zwischenzeit empfehlen wir Ihnen, die öffentliche Vorschau zu testen und feedback zu geben, damit wir die GA-Version verbessern können. Beachten Sie, dass der Übergang von der Vorschau zu GA eine vollständige Neuinstallation der Azure Site Recovery-Lösung erfordert (es ist kein Update- oder Upgradepfad möglich).

Änderungen

2311 führt eine Änderung des Basishostbetriebssystems ein, die auf Windows Server 2022 aktualisiert wurde, um zukünftige Updates und Sicherheitsupdates zu vereinfachen. Diese Änderung ist Teil des Fabric. Azure Stack Hub-Umgebungen mit ausgehender Konnektivität erfordern keine zusätzlichen Änderungen, und das Update wird direkt installiert.

Wichtig

Nicht verbundene Kunden müssen einen SQL Server 2019-Product Key (PID) abrufen und aktualisieren. Sie müssen den Schlüssel abrufen, bevor Sie das Update starten. Wenden Sie sich an den Microsoft-Support, um diesen Schlüssel zu erhalten. Wenn Sie das Update ohne diesen Schlüssel starten, schlägt das Update kurz nach dem Starten fehl, wobei eine Meldung "Vorbereitung der Rollencloud eine Ausnahme ausgelöst hat" angezeigt wird, die Sie bei der Kontaktaufnahme mit dem Support berät. Sie können das Update nach dem Anwenden des neuen Schlüssels fortsetzen.
Ab Azure Stack Hub 2311 veröffentlichen wir keine neuen Versionen des Azure Stack Development Kit (ASDK). Diese Entscheidung ist auf Änderungen an internen Diensten zurückzuführen, die zu erheblicher Komplexität für die ASDK führen würden. Die derzeit veröffentlichte ASDK-Version eignet sich weiterhin für betriebliche, Test- oder Schulungszwecke, einschließlich der Azure Stack Hub Foundation Core-Skripts, die für Azure-Stack-Hub-Foundation-Core verwendet werden.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Azure Stack Hub veröffentlicht regelmäßig Hotfixes. Ab dem Release 2005 werden bei der Aktualisierung auf eine neue Hauptversion (z. B. von 1.2008.x auf 1.2102.x) die aktuellen Hotfixes (sofern verfügbar) in der neuen Hauptversion automatisch installiert. Wenn danach ein Hotfix für Ihren Build veröffentlicht wird, sollten Sie ihn installieren.

Hinweis

Hotfixreleases für Azure Stack Hub sind kumulativ. Sie müssen also nur den neuesten Hotfix installieren, um alle Korrekturen zu erhalten, die in den vorherigen Hotfixreleases für diese Version enthalten waren.

Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Hotfixvoraussetzungen: vor dem Anwenden des 2311-Updates

Die 2311-Version von Azure Stack Hub muss auf der 2306-Version angewendet werden, wobei der folgende Hotfix installiert ist:

Azure Stack Hub Hotfix 1.2306.4.102

Nach erfolgreicher Anwendung des 2311-Updates

Wenn Sie auf eine neue Hauptversion aktualisieren (z. B. 1.2108.x auf 1.2206.x), werden die neuesten Hotfixes (falls vorhanden) in der neuen Hauptversion automatisch installiert. Wenn danach ein Hotfix für Ihren Build veröffentlicht wird, sollten Sie ihn installieren.

Nach der Installation von 2311 sollten Sie diese installieren, wenn alle Hotfixes für 2311 anschließend veröffentlicht werden:

Azure Stack Hub Hotfix 1.2311.3.62

Buildreferenz 2306

Die Buildnummer des Azure Stack Hub 2306-Updates ist 1.2306.2.47.

Updatetyp

Der Buildtyp des Azure Stack Hub 2306-Updates ist vollständig. Dieser Build enthält nur wichtige Sicherheitsupdates.

Das Update 2306 verfügt über die folgenden erwarteten Laufzeiten basierend auf unseren internen Tests:

4 Knoten: 8 bis 28 Stunden
8 Knoten: 11 bis 30 Stunden
12 Knoten: 14 bis 34 Stunden
16 Knoten: 17 bis 40 Stunden

Die genaue Dauer des Updates hängt in der Regel von der Kapazität ab, die auf Ihrem System durch Mandanten-Workloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Eine Dauer, die kürzer oder länger als erwartet ist, ist nicht ungewöhnlich und erfordert kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese Laufzeitannäherung ist spezifisch für das 2306-Update und sollte nicht mit anderen Azure Stack Hub-Updates verglichen werden.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Dieser Build enthält wichtige Sicherheitsupdates. Es gibt keine weiteren wichtigen Featurezufügungen.

Änderungen

Die Azure Stack Hub 2306-Version ist das letzte hauptupdate, das auf integrierten Systemen installiert werden kann, die auf der Broadwell CPU-Plattform von Intel basieren. Die 2311-Versionen (und höher) basieren auf einer Windows Server 2022-Codebasis, die auf der Broadwell-Plattform von Intel nicht unterstützt wird. Wenden Sie sich für alle Fragen zur CPU-Prozessorfamilie oder hardwarebezogenen Fragen an Ihren Hardware-OEM-Partner.
Dieser Build enthält diese wichtigen Sicherheitsupdates.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Hinweis

Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Hotfixvoraussetzungen: vor dem Anwenden des 2306-Updates

Die 2306-Version von Azure Stack Hub muss auf die Version 2301 angewendet werden, wobei der folgende Hotfix installiert ist:

Azure Stack Hub Hotfix 1.2301.3.97

Nach erfolgreicher Anwendung des 2306-Updates

Nach der Installation von 2306 sollten Sie diese installieren, wenn alle Hotfixes für 2306 anschließend veröffentlicht werden:

Azure Stack Hub Hotfix 1.2306.4.98

Buildreferenz 2301

Die Buildnummer des Azure Stack Hub 2301-Updates ist 1.2301.2.58.

Updatetyp

Der Buildtyp des Azure Stack Hub 2301-Updates ist vollständig.

Das Update 2301 verfügt über die folgenden erwarteten Laufzeiten basierend auf unseren internen Tests:

4 Knoten: 8 bis 28 Stunden
8 Knoten: 11 bis 30 Stunden
12 Knoten: 14 bis 34 Stunden
16 Knoten: 17 bis 40 Stunden

Die genaue Dauer des Updates hängt in der Regel von der Kapazität ab, die auf Ihrem System durch Mandanten-Workloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Eine Dauer, die kürzer oder länger als erwartet ist, ist nicht ungewöhnlich und erfordert kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese Laufzeitannäherung ist spezifisch für das Update 2301 und sollte nicht mit anderen Azure Stack Hub-Updates verglichen werden.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Öffentliche Vorschauversion des Azure Site Recovery-Ressourcenanbieters für Azure Stack Hub.
Öffentliche Vorschauversion von VPN Fast Path mit neuen VPN-Gateway-SKUs.
Neue Dokumentation zum VPN Fast Path für Azure Stack Hub-Operatoren und Azure Stack Hub-Benutzer.
Neue VM-Größe Standard_E20_v3 hinzugefügt, um größere Datenbankworkloads zu unterstützen, die mehr als 112 GB Arbeitsspeicher erfordern.
Unterstützung für NVIDIA A100 Tensor GPU hinzugefügt. Überprüfen Sie mit Ihrem OEM, ob Ihre Hardware die GPU-Anforderungen unterstützen kann.
Neue VM-Serie für A100 hinzugefügt. Weitere Informationen finden Sie unter GPUs im Azure Stack Hub.
Dieses Update enthält alle Plattformanforderungen zum Hinzufügen von Azure Site Recovery auf Azure Stack Hub. Das erste Szenario, das wir aktivieren, konzentriert sich auf die Replikation von VMs in zwei Azure Stack Hub-Regionen. ASR auf Azure Stack Hub ist ein Add-On RP, das über die Marketplace-Verwaltung hinzugefügt werden muss.
Es wurde die Möglichkeit für Operatoren hinzugefügt, Statusinformationen für virtuelle Computer in allen Benutzerabonnements im Azure Stack Hub-Verwaltungsportal anzuzeigen.

Änderungen

DER SQL-Ressourcenanbieter 2.0.13 und der MySQL-Ressourcenanbieter 2.0.13 werden veröffentlicht, um einige Änderungen an der Benutzeroberfläche zu berücksichtigen, die in Azure Stack Hub 2301 eingeführt wurden. Aktualisieren Sie den SQL-Ressourcenanbieter und den MySQL-Ressourcenanbieter auf die neueste Version, bevor Sie Azure Stack Hub aktualisieren. Möglicherweise müssen Sie den Browsercache aktualisieren, damit die neuen UI-Änderungen wirksam werden.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Hinweis

Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Hotfixvoraussetzungen: vor dem Anwenden des 2301-Updates

Die 2301-Version von Azure Stack Hub muss auf der Version 2206 angewendet werden, auf der der folgende Hotfix installiert ist:

Azure Stack Hub Hotfix 1.2206.2.77

Nach erfolgreicher Anwendung des 2301-Updates

Nach der Installation von 2301 sollten Sie diese installieren, wenn alle Hotfixes für 2301 anschließend veröffentlicht werden:

Azure Stack Hub Hotfix 1.2301.3.72

Buildreferenz zu 2206

Die Buildnummer des Azure Stack Hub 2206-Updates ist 1.2206.1.24.

Updatetyp

Der Buildtyp des Azure Stack Hub-Updates 2206 ist Vollständig.

Das Update 2206 hat basierend auf unseren internen Tests die folgenden erwarteten Laufzeiten:

4 Knoten: 8 bis 28 Stunden
8 Knoten: 11 bis 30 Stunden
12 Knoten: 14 bis 34 Stunden
16 Knoten: 17 bis 40 Stunden

Die genaue Dauer des Updates hängt in der Regel von der Kapazität ab, die auf Ihrem System durch Mandanten-Workloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Eine Dauer, die kürzer oder länger als erwartet ist, ist nicht ungewöhnlich und erfordert kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese geschätzte Laufzeit ist spezifisch für das Update 2206 und nicht auf andere Azure Stack Hub-Updates übertragbar.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Kunden in der Europäischen Union können jetzt entscheiden, dass alle ihre Daten innerhalb der Grenzen der Europäischen Union gespeichert und verarbeitet werden sollen. Weitere Informationen finden Sie unter Schrems II-Initiative der EU für Azure Stack Hub.
Azure Stack Hub unterstützt jetzt das Abrufen von BitLocker-Schlüsseln für die Verschlüsselung ruhender Daten. Weitere Informationen finden Sie unter Abrufen von BitLocker-Wiederherstellungsschlüsseln.

Änderungen

SQL RP V2 und MySQL RP V2 sind nur für Abonnements verfügbar, denen Zugriff gewährt wurde. Wenn Sie weiterhin SQL RP V1 und MySQL RP V1 verwenden, wird dringend empfohlen, einen Supportfall zu öffnen, um den Upgradeprozess zu durchlaufen, bevor Sie ein Upgrade auf Azure Stack Hub 2206 durchführen.
Dieses Release unterstützt die Azure Stack Hub-Stammzertifikatrotation. Bislang wurde das Stammzertifikat bei der Geheimnisrotation nicht rotiert. Das Stammzertifikat kann nach der Installation des Updates rotiert werden. Führen Sie dazu eine interne Geheimnisrotation durch – entweder, wenn Sie das nächste Mal eine Ablaufbenachrichtigung erhalten, oder davor. Wenn Sie das Stammzertifikat nicht rotieren und/oder keine interne Geheimnisrotation durchführen, kann Ihr Stempel möglicherweise nicht wiederhergestellt werden.

Korrekturen

Korrektur zur Verbesserung des SLB-Durchsatzes.
Ein Problem wurde behoben, das den Zugriff auf das Speichersystem verhindert hat, wenn Skalierungseinheitknoten neu gestartet werden.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Hinweis

Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Hotfixvoraussetzungen: Vor dem Anwenden des Updates 2206

Das Release 2206 von Azure Stack Hub muss auf das Release 2108 mit den folgenden Hotfixes angewendet werden:

Azure Stack Hub Hotfix 1.2108.2.130

Nach erfolgreicher Anwendung des Updates 2206

Wenn Sie auf eine neue Hauptversion (z. B. von 1.2108.x auf 1.2102.x) aktualisieren, werden die aktuellen Hotfixes (sofern verfügbar) in der neuen Hauptversion automatisch installiert. Wenn danach ein Hotfix für Ihren Build veröffentlicht wird, sollten Sie ihn installieren.

Wenn nach der Installation des Updates 2206 Hotfixes für 2206 veröffentlicht werden, sollten Sie diese installieren:

Azure Stack Hub Hotfix 1.2206.2.77

Buildreferenz zu 2102

Die Buildnummer des aktuellen Azure Stack Hub-Updates 2102 lautet 1.2102.30.97. Aktualisierte Build- und Hotfixinformationen finden Sie im Abschnitt Hotfixes.

Updatetyp

Der Buildtyp des Azure Stack Hub-Updates 2102 lautet Vollständig.

Das Update 2102 hatte bei unseren internen Tests die folgenden erwarteten Laufzeiten:

4 Knoten: 8 bis 20 Stunden
8 Knoten: 11 bis 26 Stunden
12 Knoten: 14 bis 32 Stunden
16 Knoten: 17 bis 38 Stunden

Die genaue Dauer des Updates hängt in der Regel von der Kapazität ab, die auf Ihrem System durch Mandanten-Workloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Eine Dauer, die kürzer oder länger als erwartet ist, ist nicht ungewöhnlich und erfordert kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese geschätzte Laufzeit ist spezifisch für das Update 2102 und nicht auf andere Azure Stack Hub-Updates übertragbar.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Dieses Release enthält eine öffentliche Vorschau der Remoteunterstützung, die es einem Microsoft-Supportmitarbeiter ermöglicht, Ihren Supportfall schneller zu bearbeiten, indem er Remotezugriff auf Ihr Gerät gestattet, sodass eine eingeschränkte Problembehandlung und Reparatur erfolgen kann. Sie können dieses Feature aktivieren, indem Sie die Einwilligung erteilen, während Sie die Zugriffsebene und die Zugriffsdauer steuern. Der Support kann erst auf Ihr Gerät zugreifen, nachdem eine Supportanfrage übermittelt wurde. Weitere Informationen finden Sie unter Remoteunterstützung für Azure Stack Hub.
Der Azure Stack Hub-Infrastruktursicherungsdienst unterstützt jetzt progressive Sicherung. Dieses Feature trägt dazu bei, die Speicheranforderungen für den externen Sicherungsspeicherort zu reduzieren, und ändert die Art und Weise, wie Dateien im externen Sicherungsspeicher organisiert werden. Es wird empfohlen, keine Dateien im Stammverzeichnis der Sicherung zu bearbeiten.
Verwaltete Azure Stack Hub-Datenträger unterstützen jetzt Azure Disk-APIs, Version 2019-07-01, mit einer Teilmenge der verfügbaren Features.
Azure Stack Hub Storage unterstützt jetzt Azure Storage-Dienstverwaltungs-APIs, Version 2019-06-01, mit einer Teilmenge der insgesamt verfügbaren Features.
Im Azure Stack Hub-Administratorportal werden nun GPU-bezogene Informationen angezeigt, einschließlich Kapazitätsdaten. Dies erfordert, dass eine GPU im System installiert ist.
Benutzer können jetzt alle unterstützten VM-Größen bereitstellen, indem sie Nvidia T4 über das Azure Stack Hub-Benutzerportal verwenden.
Azure Stack Hub-Operatoren können jetzt die Mehrmandanz in Azure Stack Hub über das Administratorportal konfigurieren. Weitere Informationen finden Sie unter Mehrmandanz konfigurieren.
Azure Stack Hub-Operatoren können jetzt mithilfe des privilegierten Endpunkts einen rechtlichen Hinweis konfigurieren. Weitere Informationen finden Sie unter Azure Stack Hub-Sicherheitskontrollen.
Während des Aktualisierungsprozesses wird die granulare Bitmapreparatur (Granular Bitmap Repair, GBR), eine Optimierung im Speicherreparaturprozess, eingeführt, um nicht synchronisierte Daten zu reparieren. Im Vergleich zum vorherigen Prozess werden kleinere Segmente repariert, was zu einer kürzeren Reparaturzeit und einer kürzeren Updatedauer führt. GBR ist standardmäßig für alle neuen Bereitstellungen von 2102 aktiviert. Bei einem Update auf 2102 von einer früheren Version (2008) wird GBR während des Updates aktiviert. GBR erfordert, dass sich alle physischen Datenträger in einem fehlerfreien Zustand befinden. Daher wurde in der UpdateReadiness-Überprüfung eine zusätzliche Überprüfung hinzugefügt. Patch und Update schlägt zu einem frühen Zeitpunkt fehl, wenn die Überprüfung fehlschlägt. An diesem Punkt muss ein Cloudadministrator Maßnahmen ergreifen, um das Datenträgerproblem zu beheben, bevor das Update fortsetzen kann. Überprüfen Sie die OEM-Kontaktinformationen, um den OEM zu kontaktieren.
Azure Stack Hub unterstützt jetzt neue VM-Größen der Dv3-, Ev3- und SQL-spezifischen D-Serie.
Azure Stack Hub unterstützt jetzt das Hinzufügen von GPUs zu einem vorhandenen System. Um eine GPU hinzuzufügen, führen Sie stop-azurestackaus, führen den Prozess stop-azurestack durch, fügen GPUs hinzu, und führen anschließend start-azurestack bis zum Abschluss aus. Wenn das System bereits über GPUs verfügt, müssen alle zuvor erstellten GPU-VMs stop-deallocated und anschließend neu gestartet werden.
Verkürzte OEM-Updatezeit mithilfe des Live-Updateprozesses.
Die AKS-Engine auf Azure Stack Hub hat die folgenden neuen Features hinzugefügt. Weitere Informationen finden Sie in den Versionshinweisen in der Dokumentation zur AKS-Engine:
- Allgemeine Verfügbarkeit von Ubuntu 18.04
- Unterstützung für Kubernetes 1.17.17 und 1.18.15.
- Befehl „Zertifikatrotation“ in der öffentlichen Vorschau.
- Öffentliche Vorschauversion des CSI-Treibers für Azure Disks.
- Öffentliche Vorschauversion des CSI-Treibers NFS.
- Private Vorschauversion des CSI-Treibers für Azure-Blobs.
- T4 Nvidia GPU unterstützt die private Vorschau.
- Azure Active Directory integriert die private Vorschau.

Verbesserungen

Die Aufbewahrungsdauer für Netzwerkcontrollerprotokolle wurde erhöht, sodass die Protokolle länger verfügbar sind, um Technikern bei der effektiven Problembehandlung zu helfen, auch nachdem ein Problem behoben wurde.
Verbesserungen zum Beibehalten der Protokolle von Netzwerkcontroller, Gateway-VM, Load Balancer und Host-Agent während eines Updates.
Die Löschlogik für Netzwerkressourcen, die durch einen fehlerhaften Bereitstellungsstatus blockiert werden, wurde verbessert.
Der XRP-Arbeitsspeicher wurde auf 14 GB pro VM und der WAS-Arbeitsspeicher auf 10 GB pro VM reduziert. Durch die Vermeidung des anstiegsfähigen VM-Arbeitsspeicherbedarfs können mehr Mandanten-VMs bereitgestellt werden.
Der HTML-Bericht der Protokollsammlung, der eine Momentaufnahme der Dateien auf dem Stempel und der Diagnosefreigabe enthält, verfügt jetzt über eine zusammengefasste Ansicht der gesammelten Dateien, Rollen, Ressourcenanbieter und Ereignisinformationen, um den Erfolg und die Fehlerrate des Protokollsammlungsprozesses besser zu verstehen.
Dem privilegierten Endpunkt (PEP) wurden die PowerShell-Cmdlets Set-AzSLegalNotice und Get-AzSLegalNotice hinzugefügt, um den Inhalt des Bannertexts der Anmeldung nach der Bereitstellung abzurufen und zu aktualisieren.
Active Directory-Zertifikatdienste (ADCS) und die Zertifizierungsstellen-VM wurden vollständig aus Azure Stack Hub entfernt. Dies reduziert den Infrastrukturbedarf und spart bis zu 2 Stunden Updatezeit.

Änderungen

Die Fabric-Ressourcenanbieter-APIs machen jetzt Informationen zu GPUs verfügbar, sofern sie in der Skalierungseinheit verfügbar sind.
Azure Stack Hub-Operatoren können jetzt das GPU-Partitionierungsverhältnis über PowerShell (nur AMD) ändern. Dies erfordert, dass die Zuordnung aller virtuellen Computer freigegeben wird.
Dieser Build enthält eine neue Version von Azure Resource Manager.
Das Azure Stack Hub-Benutzerportal verwendet jetzt die Vollbildumgebung für Lastenausgleichs- und Netzwerksicherheitsgruppen, DNS-Zonen sowie die Erstellung von Datenträgern und VMs.
Im Release 2102 ist das Windows Admin Center (WAC) bei Bedarf über eine entsperrte PEP-Sitzung aktiviert. Standardmäßig ist WAC nicht aktiviert. Um es zu aktivieren, geben Sie das -EnableWac-Flag an, z. B. unlock-supportsession -EnableWac.
Die proaktive Protokollsammlung verwendet einen verbesserten Algorithmus, der Protokolle selbst bei Fehlerbedingungen erfasst, die für einen Bedienenden nicht sichtbar sind. Durch diesen Algorithmus wird sichergestellt, dass die richtigen Diagnoseinformationen zum richtigen Zeitpunkt gesammelt werden, ohne dass eine Interaktion des Operators erforderlich ist. Der Microsoft-Support kann so z. T. schneller mit der Problembehandlung beginnen und Probleme beheben. Die Verbesserungen der ursprünglichen Algorithmen beziehen sich hauptsächlich auf Patch- und Aktualisierungsvorgänge. Die Aktivierung von proaktiven Protokollsammlungen wird empfohlen, da weitere Vorgänge optimiert werden und mehr Vorteile entstehen.
Die Azure Stack Hub-Infrastruktur belegt vorübergehend mehr als 10 GB Arbeitsspeicher.

Korrekturen

Es wurde ein Problem behoben, bei dem interne DNS-Zonen während des Updates nicht mehr synchron waren und das Update fehlschlägt. Diese Korrektur wurde über Hotfixes auf 2008 und 2005 zurückportiert.
Ein Problem wurde behoben, bei dem der Speicherplatz durch Protokolle auf physischen Hosts, Netzwerkcontrollern, Gateways und Lastenausgleichseinheiten erschöpft war. Diese Korrektur wurde auf 2008 zurückportiert.
Es wurde ein Problem behoben, bei dem das Löschen von Ressourcengruppen oder virtuellen Netzwerken aufgrund einer verwaisten Ressource auf der Netzwerkcontrollerebene fehlgeschlagen ist.
Die Größe ND6s_dev wurde aus der VM-Größenauswahl entfernt, da es sich um eine nicht unterstützte VM-Größe handelt.
Es wurde ein Problem behoben, bei dem das Ausführen von Stop-Deallocate auf einem virtuellen Computer dazu führt, dass eine MTU-Konfiguration auf dem virtuellen Computer entfernt wird. Dieses Verhalten ist mit Azure nicht konsistent.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Azure Stack Hub veröffentlicht regelmäßig Hotfixes. Ab Release 2005 werden bei der Aktualisierung auf eine neue Hauptversion (z. B. von 1.2005.x auf 1.2008.x) die aktuellen Hotfixes (sofern verfügbar) in der neuen Hauptversion automatisch installiert. Wenn danach ein Hotfix für Ihren Build veröffentlicht wird, sollten Sie ihn installieren.

Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Hinweis

Hotfixvoraussetzungen: vor dem Anwenden des Updates 2102

Das Release 2102 von Azure Stack Hub muss auf das Release 2008 mit den folgenden Hotfixes angewendet werden:

Azure Stack Hub-Hotfix 1.2008.41.161

Nach erfolgreicher Anwendung des Updates 2102

Wenn Sie auf eine neue Hauptversion (z. B. von 1.2102.x auf 1.2008.x) aktualisieren, werden die aktuellen Hotfixes (sofern verfügbar) in der neuen Hauptversion automatisch installiert. Wenn danach ein Hotfix für Ihren Build veröffentlicht wird, sollten Sie ihn installieren.

Wenn nach der Installation des Updates 2102 Hotfixes für 2102 veröffentlicht werden, sollten Sie diese installieren:

Azure Stack Hub-Hotfix 1.2102.30.148

Versionshinweise für unterstützte Versionen

Versionshinweise für unterstützte Versionen von Azure Stack Hub finden Sie unter Übersicht > Versionshinweise.

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack Hub-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit (ASDK) an.

Wichtig

Wenn die Version der Azure Stack Hub-Instanz mehr als zwei Updates zurückliegt, wird sie als nicht konform eingestuft. Sie müssen mindestens auf die niedrigste unterstützte Version aktualisieren, um Support zu erhalten.

Buildreferenz zu 2108

Die Buildnummer des aktuellen Azure Stack Hub-Updates 2108 lautet 1.2108.2.65. Aktualisierte Build- und Hotfixinformationen finden Sie im Abschnitt Hotfixes.

Updatetyp

Der Buildtyp des Azure Stack Hub-Updates 2108 lautet Vollständig.

Das Update 2108 hatte bei unseren internen Tests die folgenden erwarteten Laufzeiten:

4 Knoten: 8 bis 28 Stunden
8 Knoten: 11 bis 30 Stunden
12 Knoten: 14 bis 34 Stunden
16 Knoten: 17 bis 40 Stunden

Die genaue Dauer des Updates hängt in der Regel von der Kapazität ab, die auf Ihrem System durch Mandanten-Workloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Eine Dauer, die kürzer oder länger als erwartet ist, ist nicht ungewöhnlich und erfordert kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese geschätzte Laufzeit ist spezifisch für das Update 2108 und nicht auf andere Azure Stack Hub-Updates übertragbar.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Azure Stack Hub-Operatoren können jetzt GPU-Kontingente für virtuelle Computer konfigurieren.
Der Notfallzugriff auf virtuelle Computer ist jetzt in Azure Stack Hub verfügbar, ohne sich an den Microsoft-Support wenden zu müssen.
Windows Server 2022 wird jetzt als Gastbetriebssystem unterstützt. Windows Server 2022-VMs müssen mithilfe der automatischen Aktivierung virtueller Computer unter Windows Server in Azure Stack Hub mit Version 2108 oder höher manuell aktiviert werden. Die Aktivierung für frühere Versionen ist nicht möglich.
Ab dieser Version werden Protokolle für proaktive Fehlerereignisse gesammelt und lokal gespeichert, wenn die proaktive Protokollsammlung deaktiviert ist. Auf die lokalen Protokolle kann Microsoft nur im Rahmen eines Supportfalls zugreifen. Der Warnungsbibliothek der proaktiven Protokollsammlung wurden neue Warnungen hinzugefügt.
Zwei neue Dienste, Azure Kubernetes Service und Azure Container Registry, sind mit diesem Release in der öffentlichen Vorschau verfügbar.
Das AzureStack-Modul 2.2.0 wird veröffentlicht, um mit der Azure Stack Hub-Version 2108 übereinzustimmen. Das Versionsupdate umfasst Änderungen im Compute-Administratormodul sowie die neuen Module Azs.ContainerRegistry.Admin und Azs.ContainerService.Admin. Weitere Informationen sind im Änderungsprotokoll verfügbar.
Mit diesem Release werden die Telemetriedaten in ein Azure Storage-Konto hochgeladen, das von Microsoft verwaltet und kontrolliert wird. Der Azure Stack Hub-Telemetriedienst stellt eine Verbindung mit https://*.blob.core.windows.net/ und https://azsdiagprdwestusfrontend.westus.cloudapp.azure.com/ für einen erfolgreichen Telemetriedatenupload zu Microsoft her. Port 443 (HTTPS) muss geöffnet werden. Weitere Informationen finden Sie unter Azure Stack Hub-Telemetriedaten.
Dieses Release enthält eine öffentliche Vorschau der Remoteunterstützung, die es einem Microsoft-Supportmitarbeiter ermöglicht, Ihren Supportfall schneller zu bearbeiten, indem er Remotezugriff auf Ihr Gerät gestattet, sodass eine eingeschränkte Problembehandlung und Reparatur erfolgen kann. Sie können dieses Feature aktivieren, indem Sie die Einwilligung erteilen, während Sie die Zugriffsebene und die Zugriffsdauer steuern. Der Support kann erst auf Ihr Gerät zugreifen, nachdem eine Supportanfrage übermittelt wurde. Weitere Informationen finden Sie unter Remoteunterstützung für Azure Stack Hub.

Verbesserungen

Wenn die externe SMB-Freigabe fast voll ist, wird die Beschreibung der Warnung so angepasst, dass sie mit der progressiven Sicherung übereinstimmt.
Um Uploadfehler zu vermeiden, ist die Anzahl der parallelen Uploads von Infrastruktursicherungsrepositorys jetzt auf die externe SMB-Freigabe begrenzt.
Die Warnung Node-Inaccessible-for-vm-placement wurde durch Warnungen ersetzt, um zwischen den Szenarien host-unresponsive und hostagent-service-on-node-unresponsive zu unterscheiden.
App Service kann jetzt die standardmäßige NAT-IP-Adresse für ausgehende Verbindungen ermitteln.

Änderungen

Bevor Sie das Update 2108 starten, müssen Sie alle virtuellen Computer, die eine GPU verwenden, beenden (die Zuordnung aufheben), um sicherzustellen, dass das Update erfolgreich abgeschlossen werden kann. Dies gilt für AMD- und NVIDIA-GPUs, da sich die zugrunde liegende Implementierung in keine gepoolten Ressourcen ändert.
SQL RP und MySQL RP sind nur für Abonnements verfügbar, für die der Zugriff gewährt wurde. Wenn Sie diese Ressourcenanbieter verwenden möchten oder ein Upgrade von einer früheren Version benötigen, öffnen Sie einen Supportfall, und Microsoft-Supporttechniker können Ihnen bei der Bereitstellung oder dem Upgrade helfen.
Set-AzSLegalNotice löst jetzt die Darstellung eines neuen Bildschirms aus, der die Beschriftungen und Texte enthält, die beim Ausführen des Befehls festgelegt wurden. Dieser Bildschirm wird jedes Mal angezeigt, wenn eine neue Instanz des Portals erstellt wird.

Korrekturen

Ein Problem wurde behoben, bei dem ein Repositoryfehler beim Hochladen auf die externe SMB-Freigabe dazu führte, dass für die gesamte Infrastruktursicherung ein Fehler auftritt.
Es wurde ein Problem behoben, das dazu führte, dass bei der Erstellung von virtuellen Computern der N-Serie mit mehreren GPUs ein Fehler aufgetreten ist.
Es wurde ein Problem behoben, bei dem die Deinstallation einer VM-Erweiterung die geschützten Einstellungen für bestehende VM-Erweiterungen gelöscht hat.
Es wurde ein Problem behoben, das dazu führte, dass externe IP-Adressen von internen Lastenausgleichen verwendet wurden.
Es wurde ein Problem beim Herunterladen von seriellen Protokollen aus dem Portal behoben.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Hinweis

Weitere Informationen zu Hotfixes finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Hotfixvoraussetzungen: vor dem Anwenden des Updates 2108

Das Release 2108 von Azure Stack Hub muss auf das Release 2102 mit den folgenden Hotfixes angewendet werden:

Azure Stack Hub Hotfix 1.2102.31.153

Nach erfolgreicher Anwendung des Updates 2108

Wenn nach der Installation des Updates 2108 Hotfixes für 2108 veröffentlicht werden, sollten Sie diese installieren:

Azure Stack Hub Hotfix 1.2108.2.130

2008 – Buildreferenz

Die Buildnummer des aktuellen Azure Stack Hub-Updates 2008 lautet 1.2008.40.149. Aktualisierte Build- und Hotfixinformationen finden Sie im Abschnitt Hotfixes.

Updatetyp

Der Buildtyp des Azure Stack Hub-Updates 2008 lautet Vollständig.

Das Paket des Updates 2008 ist größer als vorherige Updates. Dies führt zu längeren Downloadzeiten. Das Update bleibt lange im Zustand Wird vorbereitet, und es ist damit zur rechnen, dass dieser Prozess länger dauert als bei vorherigen Updates. Das Update 2008 hat die folgenden erwarteten Laufzeiten in unseren internen Tests - 4 Knoten: 13-20 Stunden, 8 Knoten: 16-26 Stunden, 12 Knoten: 19-32 Stunden, 16 Knoten: 22-38 Stunden. Die genauen Laufzeiten des Updates hängen in der Regel von der Kapazität ab, die auf Ihrem System durch Mandantenworkloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Laufzeiten, die kürzer oder länger als erwartet sind, sind nicht ungewöhnlich und erfordern kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese geschätzte Laufzeit ist spezifisch für das Update 2008 und nicht auf andere Azure Stack Hub-Updates übertragbar.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Azure Stack Hub unterstützt jetzt VNET-Peering, mit dem VNETs verbunden werden können, ohne dass ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) vorhanden ist. Weitere Informationen finden Sie in der neuen VNET-Peering-Dokumentation.
Azure Stack Hub-Blobspeicher ermöglicht es Benutzern jetzt, ein unveränderliches Blob zu verwenden. Durch Festlegen von unveränderlichen Richtlinien für einen Container können Sie unternehmenskritische Datenobjekte in einem WORM-Zustand (Write Once, Read Many) speichern. In diesem Release können unveränderliche Richtlinien nur über die REST-API oder Client-SDKs festgelegt werden. Anfügeblob-Schreibvorgänge sind in diesem Release ebenfalls nicht möglich. Weitere Informationen zu unveränderlichen Blobs finden Sie unter Speichern unternehmenskritischer Blobdaten mit unveränderlichem Speicher.
Azure Stack Hub-Speicher unterstützt jetzt Version 2019-07-07 der Azure Storage-Dienste-APIs. Informationen zu den Azure-Clientbibliotheken, die mit der neuen REST-API-Version kompatibel sind, finden Sie unter Erste Schritte mit den Azure Stack Hub-Speicherentwicklungstools. Die verfügbaren Features der Verwaltungs-APIs für Azure Storage-Dienste, Version 2018-02-01, werden jetzt zum Teil unterstützt.
Azure Stack Hub-Compute unterstützt jetzt Azure Compute-APIs, Version 2020-06-01, mit einer Teilmenge der insgesamt verfügbaren Features.
Verwaltete Azure Stack Hub-Datenträger unterstützen jetzt Azure Disk-APIs, Version 2019-03-01, mit einer Teilmenge der verfügbaren Features.
Vorschau von Windows Admin Center, das nun eine Verbindung mit Azure Stack Hub herstellen kann, um detaillierte Einblicke in die Infrastruktur während Supportvorgängen zu erhalten (Notfallzugriff erforderlich).
Die Möglichkeit, zum Zeitpunkt der Bereitstellung ein Anmeldebanner zum privilegierten Endpunkt (PEP) hinzuzufügen.
Es wurden weiteren Banner für Exklusive Vorgänge veröffentlicht, welche die Sichtbarkeit von Vorgängen verbessern, die derzeit auf dem System ausgeführt werden, und Benutzer daran hindern, irgendeinen anderen exklusiven Vorgang zu initiieren (und spätere Fehler zu verursachen).
Auf jeder Produktseite des Marketplace-Elements für Azure Stack Hub wurden zwei neue Banner eingeführt. Gibt es einen Marketplace-Downloadfehler, können Operatoren Fehlerdetails anzeigen und empfohlene Schritte zum Beheben des Problems ausführen.
Wir haben ein Bewertungstool für Kunden veröffentlicht, damit sie Feedback geben können. Dadurch wird das Azure Stack Hub-Team in die Lage versetzt, die Benutzerfreundlichkeit zu messen und zu optimieren.
Dieses Release von Azure Stack Hub umfasst eine private Vorschau von Azure Kubernetes Service (AKS) und Azure Container Registry (ACR). Der Zweck der privaten Vorschau besteht darin, Feedback zur Qualität, zu den Features und zur Benutzerfreundlichkeit von AKS und ACR in Azure Stack Hub zu erfassen.
Dieses Release enthält eine öffentliche Vorschau von Azure CNI und Windows-Containern mit AKS Engine v0.55.4. Ein Beispiel dazu, wie Sie diese in Ihrem API-Modell verwenden können, finden Sie in diesem Beispiel auf GitHub.
Istio 1.3-Bereitstellung in Clustern, die von AKS Engine v0.55.4 bereitgestellt werden, wird nun unterstützt. Weitere Informationen finden Sie in den Anweisungen hier.
Die Bereitstellung von privaten Clustern mit AKS Engine v0.55.4 wird jetzt unterstützt.
Dieses Release bietet Unterstützung für die Beschaffung von Kubernetes-Konfigurationsgeheimnissen aus Azure- und Azure Stack Hub-Key Vault-Instanzen.

Verbesserungen

Es wurde eine interne Überwachung für den Netzwerkcontroller und SLB-Host-Agents implementiert, sodass Dienste automatisch wiederhergestellt werden, sofern sie in den Zustand „Angehalten“ gewechselt haben.
Die Active Directory-Verbunddienste (AD FS) rufen nun das neue Tokensignaturzertifikat ab, nachdem der Kunde es auf seinem eigenen AD FS-Server rotiert hat. Um diese neue Funktionalität für bereits konfigurierte Systeme nutzen zu können, muss die AD FS-Integration erneut konfiguriert werden. Weitere Informationen finden Sie unter Integrieren der AD FS-Identität in Ihr Azure Stack Hub-Rechenzentrum.
Änderungen am Start- und Herunterfahren-Prozess von Infrastrukturrolleninstanzen und deren Abhängigkeiten auf Skalierungseinheitknoten. Diese Änderungen erhöhen die Zuverlässigkeit für Starten und Beenden von Azure Stack Hub.
Die AzSScenarios-Suite des Test-AzureStack-Validierungstools wurde aktualisiert, damit Cloud-Dienstanbieter diese Suite erfolgreich ausführen können, wenn mehrstufige Authentifizierung für alle Kundenkonten erzwungen wird.
Verbesserte Warnungszuverlässigkeit durch Hinzufügen von Unterdrückungslogik für 29 kundenbezogene Warnungen während Lebenszyklusvorgängen.
Sie können jetzt einen ausführlichen HTML-Bericht der Protokollsammlung anzeigen, der Details zu den Rollen, der Dauer und dem Status der Protokollsammlung enthält. Dieser Bericht soll Benutzern dabei helfen, eine Zusammenfassung der gesammelten Protokolle bereitzustellen. Der Microsoft-Kundendienst kann den Bericht dann schnell auswerten, um die Protokolldaten zu evaluieren und bei der Behebung und Minimierung von Systemproblemen zu helfen.
Die Abdeckung zur Fehlererkennung für die Infrastruktur wurde durch Hinzufügen von sieben neuen Monitoren für Benutzerszenarien, z. B. CPU-Auslastung und Arbeitsspeichernutzung, erweitert, wodurch die Zuverlässigkeit der Fehlererkennung erhöht wird.

Änderungen

Die Ressourcentypeigenschaft supportHttpsTrafficOnly für Speicherkonten wurde in den SRP-API-Versionen 2016-01-01 und 2016-05-01 aktiviert, aber diese Eigenschaft wird in Azure Stack Hub nicht unterstützt.
Der Schwellenwert für die Auslastung der Volumekapazität wurde von 80 % (Warnung) und 90 % (kritisch) auf 90 % (Warnung) und 95 % (kritisch) erhöht. Weitere Informationen finden Sie unter Speicherplatzbenachrichtigungen.
Die AD Graph-Konfigurationsschritte haben sich in diesem Release geändert. Weitere Informationen finden Sie unter Integrieren der AD FS-Identität in Ihr Azure Stack Hub-Rechenzentrum.
Zum Abgleich mit den aktuellen, für Windows Server 2019 definierten bewährten Methoden wechselt Azure Stack Hub zur Verwendung einer zusätzlichen Datenverkehrsklasse oder Priorität, um die Kommunikation zwischen den Servern weiter zu trennen und dadurch die Failovercluster-Steuerungskommunikation zu unterstützen. Das Ergebnis dieser Änderungen bietet eine bessere Resilienz für die Failoverclusterkommunikation. Diese Konfiguration von Datenverkehrsklassen und Bandbreitenreservierung wird durch eine Änderung an den Top-of-Rack (ToR)-Switches der Azure Stack Hub-Lösung und am Host oder an den Servern von Azure Stack Hub erreicht.

Diese Änderungen werden auf der Hostebene eines Azure Stack Hub-Systems hinzugefügt. Wenden Sie sich an ihren OEM, um die Änderungen an den ToR-Netzwerkswitches (Top-of-Rack) vornehmen zu lassen. Diese ToR-Änderung kann entweder vor der Aktualisierung auf Release 2008 oder nach dem Aktualisieren auf 2008 ausgeführt werden. Weitere Informationen finden Sie unter Planen der Netzwerkintegration für Azure Stack.
Die GPU-fähigen VM-Größen NCas_v4 (NVIDIA T4) wurden in diesem Build durch die VM-Größen NCasT4_v3 ersetzt, damit sie mit Azure konsistent sind. Diese sind im Portal noch nicht sichtbar und können nur über Azure Resource Manager-Vorlagen verwendet werden.

Korrekturen

Es wurde ein Problem behoben, bei dem das Löschen einer NSG einer Netzwerkkarte, die keiner aktiven VM zugeordnet, fehlschlägt.
Es wurde ein Problem behoben, bei dem das Ändern des IdleTimeoutInMinutes-Werts für eine öffentliche IP-Adresse, die einem Lastenausgleich zugeordnet ist, die öffentliche IP-Adresse in einen fehlerhaften Zustand versetzt hat.
Das Get-AzsDisk-Cmdlet wurde korrigiert, um den korrekten Attached-Status anstelle von OnlineMigrationfür angefügte verwaltete Datenträger zurückzugeben.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Azure Stack Hub veröffentlicht regelmäßig Hotfixes. Achten Sie darauf, dass Sie den neuesten 2005-Hotfix vor dem Update auf 2008 installieren. Ab Release 2005 werden bei der Aktualisierung auf eine neue Hauptversion (z. B. von 1.2005.x auf 1.2008.x) darüber hinaus die aktuellen Hotfixes in der neuen Hauptversion automatisch installiert (sofern sie beim Herunterladen des Pakets verfügbar sind). Ihre 2008-Installation ist dann auf dem aktuellen Stand und verfügt über alle Hotfixes. Wenn danach dann ein Hotfix für Version 2008 veröffentlicht wird, sollten Sie diesen installieren.

Hinweis

Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Tipp

Wenn Sie über jedes Hotfixrelease benachrichtigt werden möchten, abonnieren Sie den RSS-Feed, um über die einzelnen Hotfixreleases benachrichtigt zu werden.

Nach erfolgreicher Anwendung des Updates 2008

Da Hotfixes für Azure Stack Hub kumulativ sind, sollten Sie als Best Practice alle Hotfixes installieren, die für Ihren Build veröffentlicht wurden, damit die Updates zwischen Hauptversionen so reibungslos wie möglich verlaufen. Wenn Sie die Aktualisierung auf eine neue Hauptversion (z. B. von 1.2005.x auf 1.2008.x) durchführen, werden die aktuellen Hotfixes in der neuen Hauptversion automatisch installiert (sofern sie beim Herunterladen des Pakets verfügbar sind).

Wenn nach der Installation des Updates 2008 Hotfixes für 2008 veröffentlicht werden, sollten Sie sie installieren:

Azure Stack Hub-Hotfix 1.2008.40.154

2005 – archivierte Versionshinweise

Die Buildnummer des Azure Stack Hub-Updates 2005 lautet 1.2005.6.53.

Updatetyp

Der Buildtyp des Azure Stack Hub-Updates 2005 lautet Vollständig.

Das Paket des Updates 2005 ist größer als vorherige Updates. Dies führt zu längeren Downloadzeiten. Das Update bleibt lange im Zustand Wird vorbereitet, und es ist damit zur rechnen, dass dieser Prozess länger dauert als bei vorherigen Updates. Das Update 2005 hat die folgenden erwarteten Laufzeiten in unseren internen Tests - 4 Knoten: 13-20 Stunden, 8 Knoten: 16-26 Stunden, 12 Knoten: 19-32 Stunden, 16 Knoten: 22-38 Stunden. Die genauen Laufzeiten des Updates hängen in der Regel von der Kapazität ab, die auf Ihrem System durch Mandantenworkloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Laufzeiten, die kürzer oder länger als erwartet sind, sind nicht ungewöhnlich und erfordern kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese geschätzte Laufzeit ist spezifisch für das Update 2005 und nicht auf andere Azure Stack Hub-Updates übertragbar.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Dieser Build bietet Unterstützung für 3 neue GPU-VM-Typen: NCv3 (Nvidia V100), NVv4 (AMD MI25) und NCas_v4 (NVIDIA T4) VM-Größen. Kunden, die über die richtige Hardware verfügen und am Azure Stack Hub-GPU-Vorschauprogramm teilnehmen, können VM-Bereitstellungen erfolgreich durchführen. Wenn Sie Interesse haben, können Sie sich unter https://aka.ms/azurestackhubgpupreview für das GPU-Vorschauprogramm registrieren. Weitere Informationen finden Sie hier.
Dieses Release bietet ein neues Feature für autonome Reparaturen, bei denen Fehler erkannt, ihre Auswirkungen bewertet und Systemprobleme sicher behoben werden. Dieses Feature verbessert die Verfügbarkeit des Systems, ohne manuelle Eingriffe zu erfordern. Ab Release 2005 erhalten Kunden daher weniger Warnungen. Bei Fehlern in dieser Pipeline ist nur dann eine Aktion des Azure Stack Hub-Operators erforderlich, wenn er eine entsprechende Benachrichtigung erhält.
Im Azure Stack Hub-Verwaltungsportal ist eine neue Option zum lokalen Speichern von Protokollen für Azure Stack Hub-Kunden verfügbar, deren Systeme per Air Gap isoliert/nicht verbunden sind. Sie können die Protokolle in einer lokalen SMB-Freigabe speichern, wenn Azure Stack Hub nicht mit Azure verbunden ist.
Das Azure Stack Hub-Verwaltungsportal blockiert jetzt bestimmte Vorgänge, wenn bereits ein Systemvorgang ausgeführt wird. Während eines Updates ist es beispielsweise nicht möglich, einen neuen Skalierungseinheitenknoten hinzuzufügen.
Dieses Release bietet auf VMs, die vor Release 1910 erstellt wurden, eine bessere Konsistenz des Fabrics mit Azure. Beim Release 1910 kündigte Microsoft an, dass alle neu erstellten VMs das WireServer-Protokoll verwenden. Dies ermöglicht es Kunden, den gleichen WALA-Agent und Windows-Gast-Agent wie Azure zu verwenden, und vereinfacht die Verwendung von Azure-Images in Azure Stack Hub. Mit diesem Release werden alle VMs, die vor Release 1910 erstellt wurden, automatisch zum WireServer-Protokoll migriert. Dies führt auch zu einer höheren Zuverlässigkeit bei der VM-Erstellung und der Bereitstellung von VM-Erweiterungen sowie einer stabileren Uptime.
Azure Stack Hub-Speicher unterstützt jetzt Version 2019-02-02 der Azure Storage-Dienste-APIs. Bei Azure-Clientbibliotheken ist diese Version mit der neuen REST-API-Version kompatibel. Weitere Informationen finden Sie unter Azure Stack Hub-Speicherentwicklungstools.
Azure Stack Hub unterstützt jetzt die neue Version von CreateUiDefinition (Version 2).
Neuer Leitfaden für VM-Batchbereitstellungen. Weitere Informationen finden Sie in diesem Artikel.
Der Azure Stack Hub Marketplace CoreOS Container Linux-Element nähert sich dem Ende seiner Lebensdauer. Weitere Informationen finden Sie unter Migrieren von CoreOS Container Linux.

Verbesserungen

Verbesserungen der Protokolle und Ereignisse des Speicherinfrastruktur-Clusterdiensts. Protokolle und Ereignisse des Speicherinfrastruktur-Clusterdiensts werden bis zu 14 Tage aufbewahrt, um eine bessere Diagnose und Problembehandlung zu ermöglichen.
Verbesserungen, die die Zuverlässigkeit beim Starten und Beenden von Azure Stack Hub erhöhen.
Verbesserungen, die die Laufzeit des Updates durch Dezentralisierung und Entfernung von Abhängigkeiten verringern. Im Vergleich zum Update 2002 verkürzt sich die Laufzeit bei einem Stempel mit vier Knoten von 15 – 42 Stunden auf 13 – 20 Stunden, bei acht Knoten von 20 – 50 auf 16 – 26 Stunden, bei 12 Knoten von 20 – 60 auf 19 – 32 Stunden und bei 16 Knoten von 25 – 70 auf 22 – 38 Stunden. Die genauen Laufzeiten des Updates hängen in der Regel von der Kapazität ab, die auf Ihrem System durch Mandantenworkloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware.
Das Update schlägt nun frühzeitig fehl, wenn bestimmte nicht behebbare Fehler vorliegen.
Verbesserte Resilienz des Updatepakets während des Downloads aus dem Internet.
Verbesserte Resilienz beim Beenden und Aufheben der Zuordnung einer VM.
Verbesserte Resilienz des Netzwerkcontroller-Host-Agents.
Der CEF-Nutzlast der Syslog-Nachrichten wurden weitere Felder zur Anzeige der Quell-IP-Adresse und des Kontos hinzugefügt, die zum Verbinden des privilegierten Endpunkts und Wiederherstellungsendpunkts verwendet werden. Weitere Informationen finden Sie unter Integrieren von Azure Stack Hub in Überwachungslösungen mithilfe der Syslog-Weiterleitung.
Der Liste von Ereignissen, die über den Syslog-Client ausgegeben werden, wurden Windows Defender-Ereignisse (Ereignis-IDs 5001, 5010, 5012) hinzugefügt.
Im Azure Stack-Administratorportal wurden Warnungen für Windows Defender-bezogene Ereignisse hinzugefügt, um Informationen zur Defender-Plattform, Inkonsistenzen der Signaturversion und nicht behandelte erkannte Schadsoftware zu melden.
Es wurde Unterstützung für vier Border-Geräte für die Integration von Azure Stack Hub in Ihr Rechenzentrum hinzugefügt.

Änderungen

Die Aktionen zum Beenden, Herunterfahren und Neustarten einer Infrastrukturrolleninstanz wurden aus dem Verwaltungsportal entfernt. Die entsprechenden APIs wurden auch im Fabric-Ressourcenanbieter entfernt. Die folgenden PowerShell-Cmdlets im Admin RM-Modul und az preview für Azure Stack Hub funktionieren nicht mehr: Stop-AzsInfrastructureRoleInstance, Disable-InfrastructureRoleInstance und Restart-InfrastructureRoleInstance. Diese Cmdlets werden aus dem nächsten Release des AZ-Administratormoduls für Azure Stack Hub entfernt.
Azure Stack Hub 2005 unterstützt jetzt nur App Service in Azure Stack Hub 2020 (Version 87.x).
Die für die Hardwareüberwachung erforderliche Benutzerverschlüsselungseinstellung wurde von DES in AES geändert, um die Sicherheit zu erhöhen. Wenden Sie sich an Ihren Hardwarepartner, um zu erfahren, wie Sie die Einstellung im Baseboard-Verwaltungscontroller (Baseboard Management Controller, BMC) ändern. Nachdem die Änderung im BMC erfolgt ist, fordert dieser möglicherweise, dass Sie den Befehl Set-BmcCredential noch mal mit dem privilegierten Endpunkt ausführen. Weitere Informationen finden Sie unter Rotieren von Geheimnissen in Azure Stack Hub.

Korrekturen

Es wurde ein Problem behoben, das zu einem Fehler bei der Reparatur eines Skalierungseinheitenknoten führen konnte, weil der Pfad zum Betriebssystem-Basisimage nicht gefunden wurde.
Es wurde ein Problem beim horizontalen Herunter- und Hochskalieren für die unterstützende Infrastrukturrolle behoben, das einen kaskadierenden Effekt auf die Reparatur von Skalierungseinheitenknoten hat.
Es wurde ein Problem behoben, bei dem die Erweiterung „.VHD“ (anstelle von „.vhd“) nicht zulässig war, wenn Operatoren im Azure Stack Hub-Administratorportal unter Alle Diensten > Compute > VM-Images > Hinzufügen eigene Images hinzufügten.
Es wurde ein Problem behoben, bei dem ein vorheriger VM-Neustart nach einem anderen VM-Aktualisierungsvorgang (Hinzufügen von Datenträgern, Tags usw.) einen nachfolgenden unerwarteten Neustart verursachte.
Es wurde ein Problem behoben, bei dem die Erstellung einer doppelten DNS-Zone dazu führte, dass das Portal nicht mehr reagierte. Nun sollte ein entsprechender Fehler angezeigt werden.
Es wurde ein Problem behoben, bei dem von Get-AzureStackLogs nicht die erforderlichen Protokolle zum Beheben von Netzwerkproblemen gesammelt wurden.
Es wurde ein Problem behoben, bei dem im Portal weniger Netzwerkschnittstellenkarten angefügt werden konnten, als tatsächlich zulässig sind.
Die Codeintegritätsrichtlinie wurde korrigiert, damit für bestimmte interne Software keine Verstoßereignisse ausgegeben werden. Dadurch werden irrelevante Daten in den über den Syslog-Client ausgegebenen Ereignissen zu Verstößen gegen die Codeintegrität reduziert.
Das Set-TLSPolicy-Cmdlet wurde korrigiert, um eine neue Richtlinie ohne Neustart des HTTPS-Diensts oder Hosts zu erzwingen.
Es wurde ein Problem behoben, bei dem die Verwendung eines Linux-NTP-Servers fälschlicherweise zu Warnungen im Verwaltungsportal führt.
Es wurde ein Problem behoben, bei dem ein Failover der Backup Controller-Dienstinstanz zur Deaktivierung automatischer Sicherungen führte.
Es wurde ein Problem behoben, bei dem die interne Geheimnisrotation fehlschlägt, wenn Infrastrukturdienste keine Internetverbindung haben.
Es wurde ein Problem behoben, bei dem Benutzer Abonnementberechtigungen nicht über die Azure Stack Hub-Portale anzeigen konnten.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Azure Stack Hub veröffentlicht regelmäßig Hotfixes. Ab Release 2005 werden bei der Aktualisierung auf eine neue Hauptversion (z. B. von 1.2002.x auf 1.2005.x) die aktuellen Hotfixes (sofern verfügbar) in der neuen Hauptversion automatisch installiert. Wenn danach ein Hotfix für Ihren Build veröffentlicht wird, sollten Sie ihn installieren.

Hinweis

Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Voraussetzungen: Vor dem Anwenden des Updates 2005

Das Release 2005 von Azure Stack Hub muss auf das Release 2002 mit den folgenden Hotfixes angewendet werden:

Azure Stack Hub-Hotfix 1.2002.66.173

Nach erfolgreicher Anwendung des Updates 2005

Ab Release 2005 werden bei der Aktualisierung auf eine neue Hauptversion (z. B. von 1.2002.x auf 1.2005.x) die aktuellen Hotfixes (sofern verfügbar) in der neuen Hauptversion automatisch installiert.

Wenn nach der Installation des Updates 2005 Hotfixes für 2005 veröffentlicht werden, sollten Sie sie installieren:

Azure Stack Hub Hotfix 1.2005.35.112

2002: Archivierte Versionshinweise

In diesem Artikel werden die Inhalte der Azure Stack Hub-Updatepakete beschrieben. Das Update enthält Verbesserungen und Fehlerbehebungen für die aktuelle Version von Azure Stack Hub.

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack Hub-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit (ASDK) an.

Wichtig

Updateplanung

Stellen Sie vor dem Anwenden des Updates sicher, dass Sie die folgenden Informationen überprüfen:

Unterstützung bei der Problembehandlung von Updates und dem Updateprozess finden Sie unter Problembehandlung bei Patch- und Updateproblemen für Azure Stack Hub.

Herunterladen des Updates

Sie können das Azure Stack Hub-Updatepaket mit dem Downloadprogramm für das Azure Stack Hub-Update herunterladen.

2002 – Buildreferenz

Die Buildnummer des Azure Stack Hub-Updates 2002 lautet 1.2002.0.35.

Wichtig

Mit dem Azure Stack Hub 2002-Update erweitert Microsoft vorübergehend die Azure Stack Hub-Supportrichtlinienanweisungen. Wir arbeiten weltweit mit Kunden zusammen, die auf COVID-19 reagieren. In diesem Zusammenhang müssen die Kunden ggf. wichtige Entscheidungen für ihre Azure Stack Hub-Systeme und deren Aktualisierung und Verwaltung treffen und daher sicherstellen, dass die Geschäftsabläufe in ihrem Rechenzentrum weiterhin normal erfolgen. Zur Unterstützung der Kunden bietet Microsoft eine temporäre Erweiterung zur Änderung der Supportrichtlinien an, die die drei letzten Updateversionen umfasst. In diesem Rahmen werden das neu veröffentlichte Update 2002 sowie die drei letzten Updateversionen (z. B. 1910, 1908 und 1907) unterstützt.

Updatetyp

Der Buildtyp des Azure Stack Hub 2002-Updates lautet Vollständig.

Das Paket des Updates 2002 ist größer als bei vorherigen Updates. Dies führt zu längeren Downloadzeiten. Das Update bleibt lange im Zustand Wird vorbereitet, und es ist damit zur rechnen, dass dieser Prozess länger dauert als bei vorherigen Updates. Das Update 2002 hat die folgenden erwarteten Laufzeiten in unseren internen Test- 4 Knoten: 15-42 Stunden, 8 Knoten: 20-50 Stunden, 12 Knoten: 20-60 Stunden, 16 Knoten: 25-70 Stunden. Die genauen Laufzeiten des Updates hängen in der Regel von der Kapazität ab, die auf Ihrem System durch Mandantenworkloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Laufzeiten, die kürzer oder länger als erwartet sind, sind nicht ungewöhnlich und erfordern kein Eingreifen durch den Azure Stack Hub-Operator, sofern das Update nicht fehlschlägt. Diese geschätzte Laufzeit ist spezifisch für das Update 2002 und nicht auf andere Azure Stack Hub-Updates übertragbar.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Es ist eine neue Version (1.8.1) von Azure Stack Hub-PowerShell-Modulen für Administratoren basierend auf AzureRM verfügbar.
Eine neue Version der Azure Stack Hub-Administrator-REST-API ist verfügbar. Details zu Endpunkten und Breaking Changes finden Sie in der API-Referenz.
Neue Azure PowerShell-Mandantenmodule werden am 15. April 2020 für Azure Stack Hub veröffentlicht. Die derzeit verwendeten Azure RM-Module funktionieren weiterhin, werden aber nach Build 2002 nicht mehr aktualisiert.
Im Azure Stack Hub-Administratorportal wurde eine neue Warnung hinzugefügt, um Konnektivitätsprobleme mit dem konfigurierten Syslog-Server zu melden. Der Titel der Warnung lautet The Syslog client encountered a networking issue while sending a Syslog message (Der Syslog-Client hat beim Senden einer Syslog-Nachricht ein Netzwerkproblem erkannt).
Im Azure Stack Hub-Administratorportal wurde eine neue Warnung hinzugefügt, um Konnektivitätsprobleme mit dem NTP-Server (Network Time Protocol) zu melden. Der Titel der Warnung lautet Invalid Time Source on [node name] (Ungültige Zeitquelle auf [Knotenname]).
Für das Java-SDK wurden aufgrund einer grundlegenden Änderung in Update 2002 in Bezug auf TLS-Einschränkungen neue Pakete veröffentlicht. Sie müssen die neue Java-SDK-Abhängigkeit installieren. Sie finden die Anleitung unter Java und API-Versionsprofile.
Eine neue Version (1.0.5.10) von System Center Operations Manager – Azure Stack Hub MP ist verfügbar und ist aufgrund von grundlegenden API-Änderungen für alle Systeme erforderlich, auf denen 2002 ausgeführt wird. Die API-Änderungen wirken sich auf die Dashboards zur Sicherungs- und Speicherleistung aus. Wir empfehlen Ihnen, zuerst alle Systeme auf 2002 zu aktualisieren, bevor Sie das MP-Update durchführen.

Verbesserungen

Dieses Update enthält Änderungen des Updateprozesses, mit denen die Leistung der zukünftigen vollständigen Updates erheblich verbessert wird. Diese Änderungen werden mit dem nächsten vollständigen Update nach Release 2002 wirksam. Sie sind vor allem auf die Verbesserung der Phase ausgerichtet, in der ein vollständiges Update durchgeführt wird und die Hostbetriebssysteme aktualisiert werden. Die Verbesserung der Updateleistung für Hostbetriebssysteme führt zu einer erheblichen Reduzierung des Zeitfensters, in dem sich bei vollständigen Updates Beeinträchtigungen für Mandantenworkloads ergeben.
Mit dem Azure Stack Hub Readiness Checker-Tool wird jetzt die AD Graph-Integration überprüft, indem alle TCP/IP-Ports verwendet werden, die AD Graph zugeordnet sind.
Für das Offlinesyndikationstool wurden Verbesserungen in Bezug auf die Zuverlässigkeit durchgeführt. Das Tool ist nicht mehr auf GitHub verfügbar und wurde in den PowerShell-Katalog verschoben. Weitere Informationen finden Sie unter Herunterladen von Marketplace-Elementen in Azure Stack Hub.
Eine neue Überwachungsfunktion wird eingeführt. Die Warnung bei wenig freiem Speicherplatz für physische Hosts und Infrastruktur-VMs wird von der Plattform automatisch bereinigt. Nur wenn bei dieser Aktion ein Fehler auftritt, wird die Warnung im Azure Stack Hub-Administratorportal angezeigt, damit der Operator entsprechende Maßnahmen ergreifen kann.
Verbesserungen in Bezug auf die Erfassung von Diagnoseprotokollen. Mit der neuen Umgebung wird die Erfassung von Diagnoseprotokollen optimiert und vereinfacht, indem die Anforderung zum Vorabkonfigurieren eines Blobspeicherkontos beseitigt wird. Die Speicherumgebung ist so vorkonfiguriert, dass Sie vor dem Erstellen einer Supportanfrage Protokolle senden können und so weniger Zeit für einen Anruf beim Support verloren geht.
Die Zeit für die proaktive und bedarfsabhängige Sammlung von Protokollen konnte jeweils um 80 % reduziert werden. Die Protokollerfassung kann länger als erwartet dauern, aber von Azure Stack Hub-Operators muss keine Aktion durchgeführt werden, sofern die Protokollerfassung nicht fehlschlägt.
Der Downloadstatus eines Azure Stack Hub-Updatepakets wird jetzt auf dem Updateblatt angezeigt, nachdem ein Update initiiert wurde. Dies gilt nur für verbundene Azure Stack Hub-Systeme, bei denen Updatepakete per automatischem Download vorbereitet werden.
Verbesserungen in Bezug auf die Zuverlässigkeit für den Netzwerkcontroller-Host-Agent.
Es wurde ein neuer Microservice mit dem Namen DNS Orchestrator eingeführt, mit dem die Resilienzlogik für die internen DNS-Dienste bei Patch- und Updatevorgängen verbessert wird.
Es wurde eine neue Anforderungsüberprüfung hinzugefügt, damit beim Erstellen von VMs für ungültige Blob-URIs für den Parameters des Startdiagnose-Speicherkontos ggf. ein Fehler erkannt wird.
Für Rdagent und den Host-Agent wurden Verbesserungen in Bezug auf die automatische Wiederherstellung und Protokollierung vorgenommen. Dies sind zwei Dienste auf dem Host, mit denen CRUD-Vorgänge für VMs durchgeführt werden.
Der Marketplace-Verwaltung wurde ein neues Feature hinzugefügt, mit dem Microsoft Attribute hinzufügen kann, die für Administratoren das Herunterladen von Marketplace-Produkten blockieren, die mit ihrer Azure Stack-Instanz inkompatibel sind (aufgrund verschiedener Eigenschaften, z. B. Azure Stack-Version oder Abrechnungsmodell). Diese Attribute können nur von Microsoft hinzugefügt werden. Weitere Informationen finden Sie unter Herunterladen von Marketplace-Elementen mithilfe des Portals.

Änderungen

Im Administratorportal wird mit einem Symbol neben der Azure Stack-Region jetzt angezeigt, ob ein Vorgang aktiv ist. Wenn Sie den Mauszeiger auf das Symbol bewegen, wird der Name des Vorgangs angezeigt. So können Sie ermitteln, welche Systemvorgänge im Hintergrund ausgeführt werden, z. B. ein Sicherungsauftrag oder eine Speichererweiterung. Diese Vorgänge können ggf. mehrere Stunden dauern.

Die folgenden Administrator-APIs sind veraltet und wurden eingestellt:

Ressourcenanbieter	Resource	Version
Microsoft.Storage.Admin	Bauernhöfe	2015-12-01-preview
Microsoft.Storage.Admin	farms/acquisitions	2015-12-01-preview
Microsoft.Storage.Admin	farms/shares	2015-12-01-preview
Microsoft.Storage.Admin	farms/storageaccounts	2015-12-01-preview

Die folgenden Administrator-APIs wurden durch eine neuere Version (2018-09-01) ersetzt:

Ressourcenanbieter Resource Version

Microsoft.Backup.Admin backupLocation 2016-05-01

Microsoft.Backup.Admin backups 2016-05-01

Microsoft.Backup.Admin Vorgänge 2016-05-01
Wenn Sie einen virtuellen Windows-Computer mithilfe von PowerShell erstellen, müssen Sie das Flag provisionvmagent hinzufügen, wenn vom virtuellen Computer Erweiterungen bereitgestellt werden sollen. Ohne dieses Flag wird der virtuelle Computer ohne den Gast-Agent erstellt, sodass keine VM-Erweiterungen bereitgestellt werden können:
```
$VirtualMachine = Set-AzureRmVMOperatingSystem `
   -VM $VirtualMachine `
   -Windows `
   -ComputerName "MainComputer" `
   -Credential $Credential -ProvisionVMAgent
```

Ressourcenanbieter	Resource	Version
Microsoft.Backup.Admin	backupLocation	2016-05-01
Microsoft.Backup.Admin	backups	2016-05-01
Microsoft.Backup.Admin	Vorgänge	2016-05-01

Korrekturen

Es wurde ein Problem behoben, das zu Problemen mit der Internetverbindung führte, wenn mehrere öffentliche IP-Adressen für die gleiche NIC auf einem virtuellen Computer hinzugefügt wurden. Eine NIC mit zwei öffentlichen IP-Adressen funktioniert jetzt wie erwartet.
Es wurde ein Problem behoben, bei dem eine Warnung mit dem Hinweis ausgelöst wurde, dass das Azure AD-Basisverzeichnis konfiguriert werden muss.
Es wurde ein Problem behoben, bei dem eine Warnung nicht automatisch geschlossen wurde. Die Warnung hat den Hinweis enthalten, dass das Azure AD-Basisverzeichnis konfiguriert werden muss, aber sie wurde nach dem Beheben des Problems nicht geschlossen.
Es wurde ein Problem behoben, bei dem für Updates während der Vorbereitungsphase ein Fehler aufgetreten ist, weil es zu internen Fehlern beim Updateressourcenanbieter gekommen ist.
Es wurde ein Problem behoben, bei dem für Vorgänge des Add-On-Ressourcenanbieters ein Fehler aufgetreten ist, nachdem die Azure Stack Hub-Geheimnisrotation durchgeführt wurde.
Es wurde ein Problem behoben, das aufgrund einer hohen Arbeitsspeicherauslastung für die ERCS-Rolle eine häufige Ursache von Azure Stack Hub-Updatefehlern war.
Es wurde ein Fehler auf dem Updateblatt behoben, bei dem der Updatestatus während der Vorbereitungsphase eines Azure Stack Hub-Updates nicht als Wird vorbereitet, sondern als Wird installiert angezeigt wurde.
Es wurde ein Problem behoben, bei dem das RSC-Feature auf den virtuellen Switches zu Inkonsistenzen geführt hat und der Datenverkehr verworfen wurde, der über ein Lastenausgleichsmodul geflossen ist. Das RSC-Feature ist jetzt standardmäßig deaktiviert.
Es wurde ein Problem behoben, aufgrund dessen mehrere IP-Konfigurationen auf einer Netzwerkschnittstelle (Network Interface, NIC) zu einer fehlerhaften Weiterleitung von Datenverkehr und Unterbrechung der ausgehenden Verbindung geführt haben.
Es wurde ein Problem behoben, bei dem die MAC-Adresse einer NIC zwischengespeichert wurde und die Zuweisung dieser Adresse zu einer anderen Ressource zu VM-Bereitstellungsfehlern geführt hat.
Es wurde ein Problem behoben, bei dem für Windows-VM-Images aus dem RETAIL-Kanal die Lizenz per AVMA nicht aktiviert werden konnte.
Es wurde ein Problem behoben, bei dem VMs nicht erstellt werden konnten, wenn die Anzahl von virtuellen Kernen, die von der VM angefordert wurden, der Anzahl von physischen Kernen des Knoten entsprochen hat. Es ist jetzt zulässig, dass VMs über eine Anzahl von virtuellen Kernen verfügen, die kleiner oder gleich der Anzahl von physischen Kernen des Knotens ist.
Es wurde ein Problem behoben, bei dem es nicht zugelassen wurde, dass der Lizenztyp auf „Null“ festgelegt wird, um Images mit nutzungsbasierter Bezahlung auf BYOL umzustellen.
Es wurde ein Problem behoben, damit Erweiterungen einer VM-Skalierungsgruppe hinzugefügt werden können.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Hotfixes

Azure Stack Hub veröffentlicht regelmäßig Hotfixes. Installieren Sie den aktuellen Azure Stack Hub-Hotfix für 1910, bevor Sie Azure Stack Hub auf 2002 aktualisieren.

Hinweis

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Weitere Informationen zu Hotfixes finden Sie unter Azure Stack Hub-Wartungsrichtlinie.

Voraussetzungen: Vor dem Anwenden des 2002-Updates

Das Release 2002 von Azure Stack Hub muss auf das Release 1910 mit den folgenden Hotfixes angewendet werden:

Azure Stack Hub-Hotfix 1.1910.84.230

Nach erfolgreicher Anwendung des Updates 2002

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes.

Azure Stack Hub-Hotfix 1.2002.68.177

1910 – archivierte Versionshinweise

In diesem Artikel werden die Inhalte der Azure Stack Hub-Updatepakete beschrieben. Das Update enthält Verbesserungen und Fehlerbehebungen für die aktuelle Version von Azure Stack Hub.

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack Hub-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit (ASDK) an.

Wichtig

Updateplanung

Stellen Sie vor dem Anwenden des Updates sicher, dass Sie die folgenden Informationen überprüfen:

Unterstützung bei der Problembehandlung von Updates und dem Updateprozess finden Sie unter Problembehandlung bei Patch- und Updateproblemen für Azure Stack Hub.

Herunterladen des Updates

Sie können das Azure Stack Hub-Updatepaket mit dem Downloadprogramm für das Azure Stack Hub-Update herunterladen.

1910 – Buildreferenz

Die Buildnummer des Azure Stack Hub-Updates 1910 lautet 1.1910.0.58.

Updatetyp

Ab Release 1908 wurde das zugrunde liegende Betriebssystem, unter dem Azure Stack Hub ausgeführt wird, auf Windows Server 2019 aktualisiert. Dieses Update ermöglicht wichtige grundlegende Verbesserungen und die Option, Azure Stack Hub um weitere Funktionen zu erweitern.

Beim Azure Stack Hub-Update 1910 handelt es sich um einen Build vom Typ Express.

Das Paket des Updates 1910 ist größer als bei vorherigen Updates. Der Download dauert dadurch länger. Das Update bleibt lange im Zustand Wird vorbereitet, und es ist damit zu rechnen, dass dieser Prozess länger dauert als bei vorherigen Updates. Das Update 1910 dauert etwa zehn Stunden – unabhängig von der Anzahl physischer Knoten in Ihrer Azure Stack Hub-Umgebung. Die genauen Laufzeiten des Updates hängen in der Regel von der Kapazität ab, die auf Ihrem System durch Mandantenworkloads beansprucht wird, sowie von der Netzwerkkonnektivität Ihres Systems (falls eine Verbindung mit dem Internet besteht) und den Spezifikationen Ihrer Systemhardware. Es ist nicht ungewöhnlich, dass Laufzeiten länger dauern als erwartet. In diesem Fall ist nur dann ein Eingreifen durch den Azure Stack Hub-Operator erforderlich, wenn ein Updatefehler auftritt. Diese geschätzte Laufzeit ist spezifisch für das Update 1910 und nicht auf andere Azure Stack Hub-Updates übertragbar.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack Hub.

Neues

Im Administratorportal werden nun die IP-Adressen des privilegierten Endpunkts im Menü mit den Regionseigenschaften angezeigt, um die Ermittlung zu vereinfachen. Darüber hinaus werden der derzeit konfigurierte Zeitserver sowie DNS-Weiterleitungen angezeigt. Weitere Informationen finden Sie unter Verwenden des privilegierten Endpunkts in Azure Stack Hub.
Das Integritäts- und Überwachungssystem von Azure Stack Hub kann nun im Falle eines Fehlers Warnungen für verschiedene Hardwarekomponenten auslösen. Für diese Warnungen ist möglicherweise eine zusätzliche Konfiguration erforderlich. Weitere Informationen finden Sie unter Überwachen von Azure Stack Hub-Hardwarekomponenten.
Cloud-init-Unterstützung für Azure Stack Hub: Cloud-init ist ein weit verbreiteter Ansatz, um eine Linux-VM anzupassen, während sie zum ersten Mal gestartet wird. Sie können mit cloud-init Pakete installieren und Dateien schreiben oder Benutzer und Sicherheit konfigurieren. Da cloud-init während des ersten Startvorgangs aufgerufen wird, müssen Sie keine zusätzlichen Schritte oder Agents auf Ihre Konfiguration anwenden. Die Ubuntu-Images im Marketplace wurden aktualisiert, um cloud-init für die Bereitstellung zu unterstützen.
Azure Stack Hub unterstützt jetzt alle Microsoft Azure Linux-Agents als Azure.
Es ist eine neue Version von Azure Stack Hub-PowerShell-Modulen für Administratoren verfügbar.
Neue Azure PowerShell-Mandantenmodule wurden am 15. April 2020 für Azure Stack Hub veröffentlicht. Die derzeit verwendeten Azure RM-Module funktionieren weiterhin, werden aber nach Build 2002 nicht mehr aktualisiert.
Das Cmdlet Set-AzSDefenderManualUpdate wurde im privilegierten Endpunkt (PEP) hinzugefügt, um die manuelle Aktualisierung für Windows Defender-Definitionen in der Azure Stack Hub-Infrastruktur zu konfigurieren. Weitere Informationen finden Sie unter Aktualisieren von Windows Defender Antivirus in Azure Stack Hub.
Das Cmdlet Set-AzSDnsForwarder wurde im privilegierten Endpunkt (PEP) hinzugefügt, um die Weiterleitungseinstellungen der DNS-Server in Azure Stack Hub zu ändern. Weitere Informationen finden Sie unter DNS-Integration in Azure Stack Hub-Datencenter.
Die Unterstützung der Verwaltung von Kubernetes-Clustern per AKS-Engine wurde hinzugefügt. Ab diesem Update können Kunden Kubernetes-Produktionscluster bereitstellen. Die AKS-Engine ermöglicht Benutzern Folgendes:
- Verwalten des Lebenszyklus ihrer Kubernetes-Cluster. Sie können Cluster erstellen, aktualisieren und skalieren.
- Verwalten ihrer Cluster mithilfe verwalteter Images, die von den AKS- und Azure Stack Hub-Teams erstellt wurden.
- Nutzen eines Kubernetes-Cloudanbieters mit Azure Resource Manager-Integration, der Cluster mit nativen Azure-Ressourcen erstellt
- Bereitstellen und Verwalten ihrer Cluster in verbundenen oder getrennten Azure Stack Hub-Stempeln
- Verwenden von Azure-Hybridfeatures:
  - Integration mit Azure Arc
  - Integration mit Azure Monitor für Container
- Verwenden von Windows-Containern mit AKS-Engine
- Erhalten von Microsoft- und Engineering-Support für ihre Bereitstellungen.

Verbesserungen

In Azure Stack Hub wurde die Funktion für die automatische Behebung von Patch- und Updateproblemen verbessert, die zuvor Updatefehler verursachten oder verhinderten, dass Betreiber ein Azure Stack Hub-Update initiieren konnten. Daher sind in der Gruppe Test-AzureStack -UpdateReadiness weniger Tests enthalten. Weitere Informationen finden Sie unter Überprüfen des Azure Stack Hub-Systemstatus. Die folgenden drei Tests bleiben in der Gruppe UpdateReadiness:
- AzSInfraFileValidation
- AzSActionPlanStatus
- AzsStampBMCSummary
Es wurde eine Überwachungsregel hinzugefügt, um eine Meldung zu generieren, wenn ein externes Gerät (beispielsweise ein USB-Schlüssel) in einen Knoten der Azure Stack Hub-Infrastruktur eingebunden wird. Das Überwachungsprotokoll wird über syslog ausgegeben und wird als Microsoft-Windows-Security-Auditing angezeigt: 6416|Plug & Play Ereignisse. Weitere Informationen zum Konfigurieren des Syslog-Clients finden Sie unter Integrieren von Azure Stack in Überwachungslösungen mithilfe der Syslog-Weiterleitung.
Azure Stack Hub wird für die internen Zertifikate auf RSA-Schlüssel mit 4096 Bit umgestellt. Im Zuge der internen Geheimnisrotation werden alte 2048-Bit-Zertifikate durch Zertifikate mit einer Länge von 4096 Bit ersetzt. Weitere Informationen zur Geheimnisrotation in Azure Stack Hub finden Sie unter Rotieren von Geheimnissen in Azure Stack Hub.
Bei mehreren internen Komponenten wurde ein Upgrade der Komplexität von Kryptografiealgorithmen und der Schlüsselstärke durchgeführt, um der Richtlinie 15 des Ausschusses für nationale Sicherheitssysteme (Committee on National Security Systems – Policy 15, CNSSP-15) zu entsprechen, die Best Practices für die Verwendung öffentlicher Standards für einen sicheren Informationsaustausch enthält. Die Verbesserungen umfassen unter anderem AES256 für die Kerberos-Authentifizierung und SHA384 für die VPN-Verschlüsselung. Weitere Informationen zu CNSSP-15 finden Sie auf der Richtlinienseite des Ausschusses für nationale Sicherheitssysteme.

Aufgrund des obigen Upgrades verfügt Azure Stack Hub nun über neue Standardwerte für IPsec-/IKEv2-Konfigurationen. Die neuen Standardwerte aufseiten von Azure Stack Hub lauten wie folgt:

Parameter der IKE-Phase 1 (Hauptmodus)

Eigenschaft	Wert
IKE-Version	IKEv2
Diffie-Hellman-Gruppe	ECP384
Authentifizierungsmethode	Vorinstallierter Schlüssel
Verschlüsselung und Hashalgorithmen	AES256, SHA384
SA-Gültigkeitsdauer (Zeit)	28.800 Sekunden

Parameter der IKE-Phase 2 (Schnellmodus)

Eigenschaft	Wert
IKE-Version	IKEv2
Verschlüsselung und Hashalgorithmen (Verschlüsselung)	GCMAES256
Verschlüsselung und Hashalgorithmen (Authentifizierung)	GCMAES256
SA-Gültigkeitsdauer (Zeit)	27.000 Sekunden
SA-Gültigkeitsdauer (KB)	33.553.408
Perfect Forward Secrecy (PFS)	ECP384
Dead Peer Detection	Unterstützt

Diese Änderungen wurden auch in der Dokumentation der IPsec-/IKE-Parameter berücksichtigt.

Der Dienst für die Infrastruktursicherung verbessert die Logik, die den gewünschten freien Speicherplatz für Sicherungen berechnet, anstatt einen festen Schwellenwert zu verwenden. Der Dienst ermittelt anhand der Größe einer Sicherung, der Aufbewahrungsrichtlinie, der Reserve und der aktuellen Auslastung des externen Speicherorts, ob eine Warnung für den Operator ausgelöst werden muss.

Änderungen

Beim Herunterladen von Marketplace-Elementen von Azure in Azure Stack Hub gibt es eine neue Benutzeroberfläche, über die Sie eine Version des Elements angeben können, wenn mehrere Versionen vorhanden sind. Die neue Benutzeroberfläche steht in Szenarien mit und ohne Verbindung zur Verfügung. Weitere Informationen finden Sie unter Herunterladen vorhandener Marketplace-Elemente aus Azure und Veröffentlichen in Azure Stack Hub.
Ab dem Release 1910 benötigt das Azure Stack Hub-System einen zusätzlichen privaten internen IP-Adressraum der Größe „/20“. Weitere Informationen finden Sie unter Planen der Netzwerkintegration für Azure Stack.
Der Dienst für die Infrastruktursicherung löscht unvollständig hochgeladene Sicherungsdaten, wenn die Kapazität des externen Speicherorts während des Uploadvorgangs nicht ausreicht.
Der Dienst für die Infrastruktursicherung fügt der Sicherungsnutzlast für AAD-Bereitstellungen den Identitätsdienst hinzu.
Das Azure Stack Hub-PowerShell-Modul wurde für das Release 1910 auf die Version 1.8.0 aktualisiert.
Die Änderungen umfassen Folgendes:
- Neues DRP-Administratormodul: Der Bereitstellungsressourcenanbieter (Deployment Resource Provider, DRP) ermöglicht orchestrierte Bereitstellungen von Ressourcenanbietern in Azure Stack Hub. Diese Befehle interagieren mit der Azure Resource Manager-Ebene, um mit DRP zu interagieren.
- BRP:
  - Unterstützung der Wiederherstellung einzelner Rollen für die Sicherung der Azure Stack-Infrastruktur
  - Hinzufügung des Parameters RoleName zum Cmdlet Restore-AzsBackup
- FRP: Breaking Changes für Ressourcen vom Typ Laufwerk und Volume mit der API-Version 2019-05-01. Die Features werden von Azure Stack Hub 1910 und höher unterstützt:
  - Der Wert von ID, Name, HealthStatus und OperationalStatus wurde geändert.
  - Unterstützte neue Eigenschaften FirmwareVersion, IsIndicationEnabled, Manufacturer und StoragePool für Ressourcen vom Typ Laufwerk
  - Die Eigenschaften CanPool und CannotPoolReason von Ressourcen des Typs Laufwerk sind veraltet. Verwenden Sie stattdessen OperationalStatus.

Korrekturen

Es wurde ein Problem behoben, das die Erzwingung der TLS 1.2-Richtlinie in Umgebungen verhindert hat, die vor dem Azure Stack Hub-Release 1904 bereitgestellt wurden.
Es wurde ein Problem behoben, das dazu führte, dass ein virtueller Ubuntu 18.04-Computer, der mit aktivierter SSH-Autorisierung erstellt wurde, keine Verwendung der SSH-Schlüssel für die Anmeldung zuließ.
Kennwort zurücksetzen wurde von der Benutzeroberfläche für VM-Skalierungsgruppen entfernt.
Es wurde ein Problem behoben, das dazu führte, dass beim Löschen des Lastenausgleichs im Portal das Objekt auf der Infrastrukturebene nicht gelöscht wurde.
Es wurde ein Problem behoben, durch das in der Warnung für die Gatewaypoolauslastung im Administratorportal ein falscher Prozentsatz angezeigt wurde.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack Hub finden Sie unter Azure Stack Hub-Sicherheitsupdates.

Der Bericht zu den Qualys-Sicherheitsrisiken für diese Version kann von der Qualys-Website heruntergeladen werden.

Hotfixes

Azure Stack Hub veröffentlicht regelmäßig Hotfixes. Installieren Sie den aktuellen Azure Stack Hub-Hotfix für 1908, bevor Sie Azure Stack Hub auf 1910 aktualisieren.

Hinweis

Azure Stack Hub-Hotfixes gelten nur für integrierte Azure Stack Hub-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Voraussetzungen: Vor dem Anwenden des Updates 1910

Das Release 1910 von Azure Stack Hub muss auf das Release 1908 mit den folgenden Hotfixes angewendet werden:

Azure Stack Hub-Hotfix 1.1908.51.133

Nach erfolgreicher Anwendung des Updates 1910

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack Hub-Hotfix 1.1910.63.186

1908 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

In diesem Artikel werden die Inhalte der Azure Stack-Updatepakete beschrieben. Das Update enthält Neuerungen, Verbesserungen und Fehlerbehebungen für diese Version von Azure Stack.

Um auf Versionshinweise für eine andere Version zuzugreifen, verwenden Sie die Dropdown-Auswahlliste oberhalb des Inhaltsverzeichnisses auf der linken Seite.

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Wichtig

Wenn die Version der Azure Stack-Instanz mehr als zwei Updates zurückliegt, wird sie als nicht konform eingestuft. Sie müssen mindestens auf die niedrigste unterstützte Version aktualisieren, um Support zu erhalten.

Updateplanung

Stellen Sie vor dem Anwenden des Updates sicher, dass Sie die folgenden Informationen überprüfen:

Unterstützung bei der Problembehandlung von Updates und dem Updateprozess finden Sie unter Problembehandlung bei Patch- und Updateproblemen für Azure Stack.

1908 – Buildreferenz

Die Buildnummer des Azure Stack-Updates 1908 lautet 1.1908.4.33.

Updatetyp

Beachten Sie für 1908, dass das zugrunde liegende Betriebssystem, auf dem Azure Stack ausgeführt wird, auf Windows Server 2019 aktualisiert wurde. So werden wichtige grundlegende Verbesserungen ermöglicht, und in naher Zukunft kann Azure Stack um weitere Funktionen erweitert werden.

Der Buildtyp des Azure Stack-Updates 1908 lautet Vollständig. Daher hat das Update 1908 eine längere Laufzeit als Express-Updates wie 1906 und 1907. Genaue Laufzeiten für vollständige Updates hängen in der Regel von der Anzahl der Knoten ab, die Ihre Azure Stack-Instanz enthält, der auf Ihrem System von Mandantenworkloads verbrauchten Kapazität, der Netzwerkkonnektivität Ihres Systems (falls es mit dem Internet verbunden ist) und Ihrer Hardwarekonfiguration. Das Update 1908 hat die folgenden erwarteten Laufzeiten in unserem internen Test: 4 Knoten - 42 Stunden, 8 Knoten - 50 Stunden, 12 Knoten - 60 Stunden, 16 Knoten - 70 Stunden. Updatelaufzeiten, die länger als diese erwarteten Werte dauern, sind nicht ungewöhnlich und erfordern kein Eingreifen seitens des Azure Stack-Betreibers, sofern es für das Update nicht zu einem Fehler kommt.

Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack.

Genaue Laufzeiten des Updates hängen in der Regel von der auf Ihrem System durch Mandantenworkloads verwendeten Kapazität ab, der Netzwerkkonnektivität Ihres Systems (falls mit dem Internet verbunden) und der Konfiguration Ihrer Systemhardware.
Laufzeiten, die länger als den erwarteten Wert dauern, sind nicht ungewöhnlich und erfordern kein Eingreifen durch den Azure Stack-Operator, es sei denn, das Update schlägt fehl.
Dieser Näherungswert der Laufzeit ist spezifisch für das Update 1908 und nicht auf andere Azure Stack-Updates übertragbar.

Neues

Beachten Sie für 1908, dass das zugrunde liegende Betriebssystem, auf dem Azure Stack ausgeführt wird, auf Windows Server 2019 aktualisiert wurde. So werden wichtige grundlegende Verbesserungen ermöglicht, und in naher Zukunft kann Azure Stack um weitere Funktionen erweitert werden.
Für alle Komponenten der Azure Stack-Infrastruktur wird jetzt der FIPS 140-2-Modus verwendet.
Azure Stack-Operatoren können jetzt Portalbenutzerdaten entfernen. Weitere Informationen finden Sie unter Löschen von Portalbenutzerdaten aus Azure Stack.

Verbesserungen

Es wurden Verbesserungen an der Azure Stack-Verschlüsselung von ruhenden Daten vorgenommen, um Geheimnisse dauerhaft im Hardware-TPM (Trusted Platform Module) der physischen Knoten zu speichern.

Änderungen

Hardwareanbieter veröffentlichen das OEM-Erweiterungspaket 2.1 oder höher zur gleichen Zeit wie Azure Stack, Version 1908. Das OEM-Erweiterungspaket 2.1 oder höher ist eine Voraussetzung für Version 1908 von Azure Stack. Weitere Informationen zum Herunterladen des OEM-Erweiterungspakets 2.1 oder höher erhalten Sie von Hardwareanbieter Ihres Systems und im Artikel zu OEM-Updates.

Korrekturen

Es wurden ein Problem mit der Kompatibilität zukünftiger Azure Stack-OEM-Updates und ein Problem mit der VM-Bereitstellung bei Verwendung von Kundenbenutzerimages behoben. Dieses Problem wurde in Version 1907 gefunden und mit dem Hotfix KB4517473 behoben.
Es wurde ein Problem mit einem OEM-Firmwareupdate behoben und in Test-AzureStack eine Fehldiagnose zur Integrität des Fabric-Rings korrigiert. Dieses Problem wurde in Version 1907 gefunden und mit dem Hotfix KB4515310 behoben.
Es wurde ein Problem mit dem Prozess für OEM-Firmwareupdates behoben. Dieses Problem wurde in Version 1907 gefunden und mit dem Hotfix KB4515650 behoben.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack finden Sie unter Azure Stack-Sicherheitsupdates.

Herunterladen des Updates

Sie können das Paket mit dem Azure Stack-Update 1908 auf der Azure Stack-Downloadseite herunterladen.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie den aktuellen Azure Stack-Hotfix für 1907 installieren, bevor Sie Azure Stack auf 1908 aktualisieren.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Voraussetzungen: Vor dem Anwenden des Updates 1908

Version 1908 von Azure Stack muss auf Version 1907 mit den folgenden Hotfixes angewendet werden:

Azure Stack-Hotfix 1.1907.17.54

Für das Azure Stack-Update 1908 ist Azure Stack-OEM-Version 2.1 oder höher vom Hardwareanbieter Ihres Systems erforderlich. OEM-Updates enthalten Treiber- und Firmwareupdates Ihrer Azure Stack-Systemhardware. Weitere Informationen zum Anwenden von OEM-Updates finden Sie unter Apply Azure Stack original equipment manufacturer (OEM) updates (Anwenden von Azure Stack-OEM-Updates).

Nach erfolgreicher Anwendung des Updates 1908

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack-Hotfix 1.1908.6.37

1907 – archivierte Versionshinweise

In diesem Artikel werden die Inhalte der Azure Stack-Updatepakete beschrieben. Das Update enthält Neuerungen, Verbesserungen und Fehlerbehebungen für diese Version von Azure Stack.

Um auf Versionshinweise für eine andere Version zuzugreifen, verwenden Sie die Dropdown-Auswahlliste oberhalb des Inhaltsverzeichnisses auf der linken Seite.

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Wichtig

Updateplanung

Stellen Sie vor dem Anwenden des Updates sicher, dass Sie die folgenden Informationen überprüfen:

Unterstützung bei der Problembehandlung von Updates und dem Updateprozess finden Sie unter Problembehandlung bei Patch- und Updateproblemen für Azure Stack.

1907 – Buildreferenz

Die Buildnummer des Azure Stack-Updates 1907 ist 1.1907.0.20.

Updatetyp

Der Buildtyp des Azure Stack 1907-Updates lautet Express. Weitere Informationen zu Update-Buildtypen finden Sie im Artikel Verwalten von Updates in Azure Stack. Auf der Grundlage interner Tests lässt sich sagen, dass das Update 1907 etwa 13 Stunden dauert.

Genaue Laufzeiten des Updates hängen in der Regel von der auf Ihrem System durch Mandantenworkloads verwendeten Kapazität ab, der Netzwerkkonnektivität Ihres Systems (falls mit dem Internet verbunden) und der Konfiguration Ihrer Systemhardware.
Laufzeiten, die länger als den erwarteten Wert dauern, sind nicht ungewöhnlich und erfordern kein Eingreifen durch den Azure Stack-Operator, es sei denn, das Update schlägt fehl.
Dieser Näherungswert der Laufzeit ist spezifisch für das Update 1907 und nicht auf andere Azure Stack-Updates übertragbar.

Inhalt des Updates

Neues

Allgemein verfügbare Version des Azure Stack-Sammlungsdiensts für Diagnoseprotokolle, um die Sammlung von Diagnoseprotokollen zu vereinfachen und zu verbessern. Der Azure Stack-Sammlungsdienst für Diagnoseprotokolle stellt ein vereinfachtes Verfahren zum Sammeln und Teilen von Diagnoseprotokollen mit Microsoft Customer Support Services (CSS) zur Verfügung. Dieser Sammlungsdienst für Diagnoseprotokolle bietet eine neue Benutzeroberfläche im Azure Stack-Verwaltungsportal, mit der Operatoren beim Erreichen bestimmter kritischer Warnschwellen Diagnoseprotokolle automatisch auf einen Speicherblob hochladen oder den gleichen Vorgang auf Anforderung ausführen können. Weitere Informationen finden Sie im Artikel Sammlung von Diagnoseprotokollen.
Allgemein verfügbare Version der Azure Stack-Netzwerkinfrastruktur-Überprüfung als Teil des Azure Stack-Überprüfungstools Test-AzureStack. Die Azure Stack-Netzwerkinfrastrukur stellt einen Teil von Test-AzureStack dar und ermöglicht das Bestimmen eines Fehlers in der Netzwerkinfrastruktur von Azure Stack. Der Test überprüft die Konnektivität der Netzwerkinfrastruktur, indem er das softwaredefinierte Netzwerk von Azure Stack umgeht. Er veranschaulicht Verbindungen von einer öffentlichen VIP mit den konfigurierten DNS-Forwardern, NTP-Servern und Identitätsendpunkten. Außerdem überprüft er die Konnektivität mit Azure, wenn Azure AD als Identitätsanbieter verwendet wird, oder mit dem Partnerserver, wenn ADFS verwendet wird. Weitere Informationen finden Sie im Artikel zum Azure Stack-Überprüfungstool.
Ein internes Rotationsverfahren für Geheimnisse wurde hinzugefügt, um interne SQL-TLS-Zertifikate nach Bedarf während eines Systemupdates zu rotieren.

Verbesserungen

Auf dem Azure Stack-Updateblatt wird jetzt eine Zeit für den Letzten abgeschlossenen Schritt für aktive Updates angezeigt. Diese kann angezeigt werden, indem auf dem Updateblatt auf ein laufendes Update geklickt wird. Der Letzte abgeschlossene Schritt ist dann im Abschnitt Update-Ausführungsdetails verfügbar.
Verbesserungen an den Operatoraktionen Start-AzureStack und Stop-AzureStack. Die für den Start von Azure Stack erforderliche Zeit wurde um durchschnittlich 50 % reduziert. Die für das Herunterfahren von Azure Stack erforderliche Zeit wurde um durchschnittlich 30 % reduziert. Die durchschnittlichen Zeiten für Start und Herunterfahren bleiben gleich, wenn sich die Anzahl der Knoten in einer Skalierungseinheit erhöht.
Verbesserte Fehlerbehandlung für das Marketplace-Tool bei getrennter Verbindung. Bei einem Downloadfehler oder einem Teilerfolg wird bei der Verwendung von Export-AzSOfflineMarketplaceItem eine detaillierte Fehlermeldung mit weiteren Details zum Fehler und Schritten zur Entschärfung angezeigt, sofern vorhanden.
Verbesserte Leistung bei der Erstellung verwalteter Datenträger aus einem großen Seitenblob/einer großen Momentaufnahme. Bisher wurde beim Erstellen eines großen Datenträgers ein Zeitlimit ausgelöst.

Verbesserte Integritätsprüfung von virtuellen Datenträgern vor dem Herunterfahren eines Knotens, um ein unerwartetes Trennen virtueller Datenträger zu verhindern.
Verbesserte Speicherung interner Protokolle für Administratorvorgänge. Dies führt zu einer verbesserten Leistung und Zuverlässigkeit bei Administratorvorgängen, indem die Arbeitsspeicher- und Speicherplatznutzung durch interne Protokollprozesse minimiert wird. Möglicherweise bemerken Sie darüber hinaus verbesserte Seitenladezeiten des Updateblatts im Verwaltungsportal. Im Rahmen dieser Verbesserung stehen Updateprotokolle, die älter als 6 Monate sind, im System nicht mehr zur Verfügung. Wenn Sie Protokolle für diese Updates benötigen, achten Sie darauf, dass Sie für alle Updateausführungen, die älter als 6 Monate sind, die Zusammenfassung herunterladen, bevor Sie das Update 1907 durchführen.

Änderungen

Version 1907 von Azure Stack enthält eine Warnmeldung, in der Operatoren darauf hingewiesen werden, dass sie das OEM-Paket des Systems auf Version 2.1 oder höher aktualisieren müssen, bevor sie ein Update auf Version 1908 ausführen können. Weitere Informationen zum Anwenden von Azure Stack-OEM-Updates finden Sie unter Apply Azure Stack original equipment manufacturer (OEM) updates (Anwenden von Azure Stack-OEM-Updates).
Es wurde eine neue Ausgangsregel (HTTPS) hinzugefügt, um dem Azure Stack-Sammlungsdienst für Diagnoseprotokolle die Kommunikation zu ermöglichen. Weitere Informationen finden Sie unter Integration des Azure Stack-Rechenzentrums – Veröffentlichen von Endpunkten.
Der Infrastruktur-Sicherungsdienst löscht jetzt teilweise hochgeladene Sicherungen, wenn der externe Speicherort an seine Kapazitätsgrenze stößt.
Infrastruktursicherungen enthalten keine Sicherung von Domänendienstdaten mehr. Dies betrifft nur Systeme, die Azure Active Directory als Identitätsanbieter verwenden.
Wir überprüfen jetzt, ob ein Image, das auf dem Blatt Compute -> VM-Images erfasst wird, den Typ „Seitenblob“ aufweist.

Korrekturen

Es wurde ein Problem behoben, bei dem für Herausgeber, Angebote und SKUs in Resource Manager-Vorlagen Groß-/Kleinschreibung unterschieden wurde: Das Image wurde nicht für die Bereitstellung abgerufen, wenn die Imageparameter nicht die identische Groß-/Kleinschreibung wie Herausgeber, Angebot und SKU aufwiesen.

Es wurde ein Problem mit Fehlern bei Sicherungen mit einer Fehlermeldung PartialSucceeded behoben, bei denen während der Sicherung von Metadaten des Speicherdiensts ein Zeitlimit auftrat.
Es wurde ein Problem behoben, bei dem das Löschen von Benutzerabonnements zu verwaisten Ressourcen führte.
Es wurde ein Problem behoben, bei dem das Beschreibungsfeld beim Erstellen eines Angebots nicht gespeichert wurde.
Es wurde ein Problem behoben, bei dem ein Benutzer mit Nur Lesen-Berechtigungen Ressourcen erstellen, bearbeiten und löschen konnte. Nun kann der Benutzer nur dann Ressourcen erstellen, wenn die Berechtigung Mitwirkender zugewiesen ist.

Es wurde ein Problem behoben, bei dem aufgrund einer vom WMI-Anbieterhost gesperrten DLL-Datei ein Fehler beim Update auftritt.
Es wurde ein Problem beim Updatedienst behoben, das die Anzeige von verfügbaren Updates auf der Updatekachel oder im Ressourcenanbieter verhinderte. Dieses Problem wurde in Version 1906 gefunden und mit dem Hotfix KB4511282 behoben.
Es wurde ein Problem behoben, das zu Updatefehlern führen konnte, weil die Verwaltungsebene aufgrund einer falschen Konfiguration fehlerhaft wurde. Dieses Problem wurde in Version 1906 gefunden und mit dem Hotfix KB4512794 behoben.
Es wurde ein Problem behoben, das Benutzer daran hinderte, die Bereitstellung von Images von Drittanbietern aus dem Marketplace abzuschließen. Dieses Problem wurde in Version 1906 gefunden und mit dem Hotfix KB4511259 behoben.
Es wurde ein Problem behoben, das dazu führen konnte, dass aufgrund des Absturzes des Benutzerimage-Managerdiensts Fehler bei der Erstellung von VMs aus verwalteten Images auftraten. Dieses Problem wurde in Version 1906 gefunden und mit dem Hotfix KB4512794 behoben.
Es wurde ein Problem behoben, bei dem bei VM-CRUD-Vorgängen ein Fehler auftreten konnte, weil der Cache des App-Gateways nicht wie erwartet aktualisiert wurde. Dieses Problem wurde in Version 1906 gefunden und mit dem Hotfix KB4513119 behoben.
Es wurde ein Problem beim Integritätsressourcenanbieter behoben, das sich auf die Verfügbarkeit der Blätter „Region“ und „Benachrichtigung“ im Verwaltungsportal auswirkte. Dieses Problem wurde in Version 1906 gefunden und mit dem Hotfix KB4512794 behoben.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack finden Sie unter Azure Stack-Sicherheitsupdates.

Herunterladen des Updates

Sie können das Paket mit dem Azure Stack-Update 1907 auf der Azure Stack-Downloadseite herunterladen.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie den aktuellen Azure Stack-Hotfix für 1906 installieren, bevor Sie Azure Stack auf 1907 aktualisieren.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Vor dem Anwenden des Updates 1907

Version 1907 von Azure Stack muss auf Version 1906 mit den folgenden Hotfixes angewendet werden:

Azure Stack-Hotfix 1.1906.15.60

Nach erfolgreicher Anwendung des Updates 1907

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack-Hotfix 1.1907.17.54

1906 – archivierte Versionshinweise

In diesem Artikel werden die Inhalte der Azure Stack-Updatepakete beschrieben. Das Update enthält Neuerungen, Verbesserungen und Fehlerbehebungen für diese Version von Azure Stack.

Um auf Versionshinweise für eine andere Version zuzugreifen, verwenden Sie die Dropdown-Auswahlliste oberhalb des Inhaltsverzeichnisses auf der linken Seite.

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Wichtig

Updateplanung

Stellen Sie vor dem Anwenden des Updates sicher, dass Sie die folgenden Informationen überprüfen:

Unterstützung bei der Problembehandlung von Updates und dem Updateprozess finden Sie unter Problembehandlung bei Patch- und Updateproblemen für Azure Stack.

1906 – Buildreferenz

Die Buildnummer des Azure Stack-Updates 1906 ist 1.1906.0.30.

Updatetyp

Der Buildtyp des Azure Stack 1906-Updates lautet Express. Weitere Informationen zu Update-Buildtypen finden Sie im Artikel Verwalten von Updates in Azure Stack. Das Update 1906 dauert etwa 10 Stunden, unabhängig von der Anzahl der physischen Knoten in Ihrer Azure Stack-Umgebung. Genaue Laufzeiten des Updates hängen in der Regel von der auf Ihrem System durch Mandantenworkloads verwendeten Kapazität ab, der Netzwerkkonnektivität Ihres Systems (falls mit dem Internet verbunden) und den Spezifikationen Ihrer Systemhardware. Laufzeiten, die länger als den erwarteten Wert dauern, sind nicht ungewöhnlich und erfordern kein Eingreifen durch den Azure Stack-Operator, es sei denn, das Update schlägt fehl. Dieser Näherungswert der Laufzeit ist spezifisch für das Update 1906 und nicht auf andere Azure Stack-Updates übertragbar.

Inhalt des Updates

Ein Set-TLSPolicy-Cmdlet wurde im privilegierten Endpunkt (PEP) hinzugefügt, um TLS 1.2 für alle Endpunkte zu erzwingen. Weitere Informationen finden Sie unter Azure Stack-Sicherheitskontrollen.
Ein Get-TLSPolicy-Cmdlet wurde im privilegierten Endpunkt (PEP) hinzugefügt, um die angewendete TLS-Richtlinie abzurufen. Weitere Informationen finden Sie unter Azure Stack-Sicherheitskontrollen.
Ein internes Rotationsverfahren für Geheimnisse wurde hinzugefügt, um interne TLS-Zertifikate nach Bedarf während eines Systemupdates zu rotieren.
Eine Schutzvorrichtung wurde hinzugefügt, um das Ablaufen interner Geheimnisse zu verhindern, indem die Rotation interner Geheimnisse, falls eine kritische Warnung bei ablaufenden Geheimnissen ignoriert wird, zu erzwingen. Dies sollte nicht als normales Verfahren angesehen und auch nicht so verwendet werden. Die Geheimnisrotation sollte während eines Wartungsfensters eingeplant werden. Weitere Informationen finden Sie unter Azure Stack: Geheimnisrotation.
Visual Studio Code wird jetzt in Azure Stack-Bereitstellungen, die AD FS verwenden, unterstützt.

Verbesserungen

Das Cmdlet Get-GraphApplication im privilegierten Endpunkt zeigt jetzt den Fingerabdruck des aktuell verwendeten Zertifikats an. Dies verbessert die Zertifikatverwaltung für Dienstprinzipale, wenn Azure Stack mit AD FS bereitgestellt wird.
Neue Regeln für die Systemüberwachung wurden hinzugefügt, um die Verfügbarkeit von AD Graph und AD FS zu überprüfen, einschließlich der Möglichkeit zum Auslösen von Warnungen.
Verbesserungen an der Zuverlässigkeit des Sicherungsressourcenanbieters, wenn der Dienst für die Infrastruktursicherung auf eine andere Instanz verschoben wird.
Optimierung der Leistung des externen Geheimnisrotationsverfahrens, um eine einheitliche Ausführungszeit bereitzustellen, um die Planung des Wartungsfensters zu erleichtern.
Das Cmdlet Test-AzureStack berichtet jetzt zu internen Geheimnissen, die dabei sind, abzulaufen (kritische Warnungen).
Ein neuer Parameter ist für das Cmdlet Register-CustomAdfs im privilegierten Endpunkt verfügbar, der es ermöglicht, die Überprüfung der Zertifikatssperrliste zu überspringen, wenn die Verbundvertrauensstellung für AD FS konfiguriert wird.
Das Release 1906 führt bessere Sichtbarkeit des Updatestatus ein, sodass Sie sicher sein können, dass Updates nicht angehalten sind. Dies führt zu einer Erhöhung der Gesamtzahl der Updateschritte, die Operatoren auf dem Blatt Update angezeigt werden. Möglicherweise bemerken Sie auch, dass mehr Updateschritte gleichzeitig ausgeführt werden als bei früheren Updates.

Netzwerkupdates

Die im DHCP-Responder festgelegte Leasedauer wurde so aktualisiert, dass sie mit Azure konsistent ist.
Verbesserte Wiederholungsraten für den Ressourcenanbieter im Falle der fehlerhaften Bereitstellung von Ressourcen.
Die SKU-Option Standard wurde sowohl aus dem Load Balancer als auch der öffentlichen IP-Adresse entfernt, da dies zurzeit nicht unterstützt wird.

Änderungen

Das Erstellen eine Speicherkontoerfahrung ist jetzt mit Azure konsistent.
Auslöser für Warnungen bei Ablauf interner Geheimnisse wurden geändert:
- Warnungen werden jetzt 90 Tage vor dem Ablauf von Geheimnissen ausgelöst.
- Kritische Warnungen werden jetzt 30 Tage vor dem Ablauf von Geheimnissen ausgelöst.
Zeichenfolgen im Ressourcenanbieter für die Infrastruktursicherung wurden hinsichtlich konsistenter Terminologie aktualisiert.

Korrekturen

Ein Problem wurde behoben, bei dem das Ändern der Größe einer VM mit verwaltetem Datenträger mit einem Fehler Interner Vorgangsfehler fehlschlug.
Ein Problem wurde behoben, bei dem die fehlgeschlagene Erstellung eines Benutzerimages den Dienst, der Images verwaltet, in einen ungültigen Zustand versetzt. Hierdurch wird das Löschen des fehlerhaften Images und die Erstellung neuer Images blockiert. Dies ist auch im Hotfix 1905 behoben.
Aktive Warnungen wegen abgelaufener interner Geheimnisse werden jetzt nach erfolgreicher Ausführung der internen Geheimnisrotation automatisch geschlossen.
Ein Problem wurde behoben, bei dem die erste Ziffer der Updatedauer auf der Registerkarte „Updateverlauf“ abgeschnitten wurde, wenn das Update länger als 99 Stunden ausgeführt wurde.
Das Blatt Update enthält eine Option Fortsetzen für fehlgeschlagene Updates.
In den Administrator- und Benutzerportalen wurde das Problem im Marketplace behoben, bei dem die Docker-Erweiterung fehlerhaft von der Suche zurückgegeben wurde, aber keine weitere Maßnahme ergriffen werden konnte, da sie nicht in Azure Stack verfügbar war.
Ein Problem in der Benutzeroberfläche für die Vorlagenbereitstellung wurde behoben, bei dem Parameter nicht aufgefüllt wurden, wenn der Vorlagenname mit „_“ (Unterstrich) begann.
Ein Problem auf der Benutzeroberfläche zum Erstellen von VM-Skalierungsgruppen wurde behoben, bei dem „CentOS 7.2-basiert“ als Option für die Bereitstellung angeboten wird. CentOS 7.2 ist in Azure Stack nicht verfügbar. Wir stellen jetzt CentOS 7.5 als Option für die Bereitstellung zur Verfügung.
Sie können jetzt eine Skalierungsgruppe über das Blatt VM-Skalierungsgruppen entfernen.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack finden Sie unter Azure Stack-Sicherheitsupdates.

Herunterladen des Updates

Sie können das Paket mit dem Azure Stack-Update 1906 auf der Azure Stack-Downloadseite herunterladen.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie den aktuellen Azure Stack-Hotfix für 1905 installieren, bevor Sie Azure Stack auf 1906 aktualisieren. Installieren Sie nach der Aktualisierung alle verfügbaren Hotfixes für Version 1906.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Vor dem Anwenden des Updates 1906

Version 1906 von Azure Stack muss auf Version 1905 mit den folgenden Hotfixes angewendet werden:

Azure Stack-Hotfix 1.1905.3.48

Nach erfolgreicher Anwendung des Updates 1906

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack-Hotfix 1.1906.15.60

Nächste Schritte

Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.
Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.

1905 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

In diesem Artikel wird der Inhalt des Updatepakets 1905 beschrieben. Das Update enthält Neuerungen, Verbesserungen und Fehlerbehebungen für diese Version von Azure Stack. Dieser Artikel enthält die folgenden Informationen:

Beschreibung der Neuerungen, Verbesserungen, Fehlerbehebungen und Sicherheitsupdates
Updateplanung

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1905 ist 1.1905.0.40.

Updatetyp

Der Azure Stack 1905-Update-Buildtyp lautet Vollständig. Daher hat das Update 1905 eine längere Laufzeit als Express-Updates wie 1903 und 1904. Genaue Laufzeiten für vollständige Updates hängen in der Regel von der Anzahl der Knoten ab, die Ihre Azure Stack-Instanz enthält, der auf Ihrem System von Mandantenworkloads verbrauchten Kapazität, der Netzwerkkonnektivität Ihres Systems (falls es mit dem Internet verbunden ist) und Ihrer Hardwarekonfiguration. Das Update 1905 hat die folgenden erwarteten Laufzeiten in unserem internen Test: 4 Knoten - 35 Stunden, 8 Knoten - 45 Stunden, 12 Knoten - 55 Stunden, 16 Knoten - 70 Stunden. Laufzeiten von 1905, die länger als diese erwarteten Werte sind, sind nicht ungewöhnlich und erfordern kein Eingreifen seitens des Azure Stack-Operators, es sei denn, das Update schlägt fehl. Weitere Informationen zu Update-Buildtypen finden Sie unter Verwalten von Updates in Azure Stack.

Inhalt des Updates

Mit diesem Update kann das Updatemodul in Azure Stack die Firmware der Knoten von Skalierungseinheiten aktualisieren. Hierfür ist ein kompatibles Updatepaket von den Hardwarepartnern erforderlich. Ausführlichere Informationen zur Verfügbarkeit erhalten Sie bei Ihrem Hardwarepartner.
Windows Server 2019 wird jetzt unterstützt und ist für die Syndizierung über den Azure Stack-Marketplace verfügbar. Mit diesem Update kann Windows Server 2019 auf einem 2016-Host jetzt erfolgreich aktiviert werden.
Eine neue Azure-Kontoerweiterung für Visual Studio Code ermöglicht es Entwicklern, Azure Stack zu nutzen, indem sie sich anmelden und Abonnements anzeigen. Darüber hinaus können sie auch noch einige andere Dienste nutzen. Die neue Azure-Kontoerweiterung funktioniert sowohl in Azure AD- (Azure Active Directory) als auch in AD FS-Umgebungen und erfordert nur eine kleine Änderung an den Benutzereinstellungen von Visual Studio Code. Für Visual Studio Code ist es erforderlich, dass einem Dienstprinzipal eine Berechtigung erteilt wird, um in dieser Umgebung ausgeführt zu werden. Importieren Sie zu diesem Zweck das Identitätsskript, und führen Sie die in Mehrinstanzenfähigkeit in Azure Stack angegebenen Cmdlets aus. Dafür sind eine Aktualisierung des Basisverzeichnisses und die Registrierung des Gastmandantenverzeichnisses für jedes Verzeichnis erforderlich. Nach dem Update auf 1905 oder höher wird eine Benachrichtigung angezeigt, dass der Basisverzeichnismandant, für den der Dienstprinzipal von Visual Studio Code enthalten ist, aktualisiert werden muss.

Verbesserungen

Im Rahmen der Erzwingung von TLS 1.2 in Azure Stack wurden die folgenden Erweiterungen auf diese Versionen aktualisiert:
- microsoft.customscriptextension-arm-1.9.3
- microsoft.iaasdiagnostics-1.12.2.2
- microsoft.antimalware-windows-arm-1.5.5.9
- microsoft.dsc-arm-2.77.0.0
- microsoft.vmaccessforlinux-1.5.2
Laden Sie diese Versionen der Erweiterungen sofort herunter, damit für neue Bereitstellungen der Erweiterung keine Fehler auftreten, wenn TLS 1.2 in einem zukünftigen Release erzwungen wird. Legen Sie immer autoUpgradeMinorVersion=true fest, damit Nebenversionsupdates (z. B. von 1.8 auf 1.9) automatisch durchgeführt werden.
Eine neue Übersicht für Hilfe und Support im Azure Stack-Portal erleichtert Betreibern das Prüfen der Supportoptionen, das Inanspruchnehmen von Expertenhilfe und Erhalten von weiteren Informationen zu Azure Stack. In integrierten Systemen wird beim Erstellen einer Supportanfrage der Azure Stack-Dienst vorab ausgewählt. Wir empfehlen dringend, dass Kunden anstelle des globalen Azure-Portals diese Vorgehensweise zum Übermitteln von Tickets nutzen. Weitere Informationen finden Sie unter Microsoft Azure Stack: Hilfe und Support.
Wenn das Onboarding für mehrere Azure Active Directory-Instanzen durchgeführt wird (über diesen Prozess), kann auf das erneute Ausführen des Skripts ggf. verzichtet werden, falls bestimmte Updates auftreten oder Änderungen an der Autorisierung mit dem Azure AD-Dienstprinzipal zu fehlenden Rechten führen. Dies kann zu verschiedenen Problemen führen: von einer Sperrung des Zugriffs für bestimmte Features bis zu diskreteren Ausfällen, die sich nur schwer zum ursprünglichen Problem nachverfolgen lassen. Als Gegenmaßnahme wurde mit Version 1905 ein neues Feature eingeführt, mit dem diese Berechtigungen überprüft werden und eine Warnung erstellt wird, wenn bestimmte Konfigurationsprobleme ermittelt werden. Diese Überprüfung wird einmal pro Stunde durchgeführt, und es werden die Aktionen zur Behebung angezeigt, die zum Lösen des Problems erforderlich sind. Die Warnung wird geschlossen, wenn sich alle Mandanten in einem fehlerfreien Zustand befinden.
Die Zuverlässigkeit von Vorgängen für Infrastruktursicherungen während des Dienstfailovers wurde verbessert.
Eine neue Version des Azure Stack-Nagios-Plug-Ins ist verfügbar, für das die Azure Active Directory-Authentifizierungsbibliotheken (ADAL) zur Authentifizierung genutzt werden. Das Plug-In unterstützt für Azure Stack jetzt auch Bereitstellungen vom Typ „Azure AD“ und „Active Directory-Verbunddienste (AD FS)“. Weitere Informationen finden Sie auf der Website zum Nagios-Plug-In.
Das neue Hybridprofil 2019-03-01-Hybrid wurde veröffentlicht. Es unterstützt alle aktuellen Features in Azure Stack. Sowohl Azure PowerShell als auch Azure CLI unterstützen das Profil 2019-03-01-Hybrid. Für .NET, Ruby, Node.js, Go und Python SDKs wurden Pakete veröffentlicht, die das Profil 2019-03-01-Hybrid unterstützen. Die entsprechende Dokumentation und einige Beispiele wurden aktualisiert, um die Änderungen widerzuspiegeln.
Das Node.js SDK unterstützt jetzt API-Profile. Pakete, die das Profil 2019-03-01-Hybrid unterstützen, werden veröffentlicht.
Das Azure Stack-Update 1905 fügt zwei neue Infrastrukturrollen hinzu, um die Zuverlässigkeit und Unterstützbarkeit der Plattform zu verbessern:
- Infrastrukturring: In Zukunft wird der Infrastrukturring containerisierte Versionen vorhandener Infrastrukturrollen hosten, z. B. xrp, die derzeit eigene, festgelegte Infrastruktur-VMs erfordern. Dies verbessert die Zuverlässigkeit der Plattform und verringert die Anzahl von Infrastruktur-VMs, die Azure Stack benötigt. Dies wiederum verringert in der Folge den Gesamtressourcenverbrauch von Azure Stack-Infrastrukturrollen in der Zukunft.
- Supportring: In Zukunft wird der Supportring verwendet, um erweiterte Supportszenarien für Kunden zu behandeln.
Darüber hinaus haben wir eine zusätzliche Instanz der Domänencontroller-VM hinzugefügt, um die Verfügbarkeit dieser Rolle zu verbessern.

Diese Änderungen erhöht den Ressourcenverbrauch der Azure Stack-Infrastruktur auf folgende Weise:

Azure Stack-SKU Anstieg des Computeverbrauchs Anstieg des Arbeitsspeicherverbrauchs

4 Knoten 22 vCPU 28 GB

8 Knoten 38 vCPU 44 GB

12 Knoten 54 vCPU 60 GB

16 Knoten 70 vCPU 76 GB

Azure Stack-SKU	Anstieg des Computeverbrauchs	Anstieg des Arbeitsspeicherverbrauchs
4 Knoten	22 vCPU	28 GB
8 Knoten	38 vCPU	44 GB
12 Knoten	54 vCPU	60 GB
16 Knoten	70 vCPU	76 GB

Änderungen

Mit Azure Stack wird eine zusätzliche Infrastrukturrolleninstanz für Domänendienste hinzugefügt, um die Zuverlässigkeit und Verfügbarkeit bei der geplanten und ungeplanten Wartung zu erhöhen.
Mit diesem Update wird die Hardware bei Vorgängen zum Reparieren und Hinzufügen von Knoten überprüft, um sicherzustellen, dass in einer Skalierungseinheit homogene Skalierungseinheitknoten verwendet werden.
Wenn geplante Sicherungen nicht durchgeführt werden können und der definierte Aufbewahrungszeitraum überschritten wird, wird mit dem Infrastructure Backup Controller dafür gesorgt, dass mindestens eine erfolgreiche Sicherung aufbewahrt wird.

Korrekturen

Es wurde ein Fehler behoben, bei dem eine Warnung zum Computehost-Agent angezeigt wird, nachdem ein Knoten in der Skalierungseinheit neu gestartet wurde.
Es wurden Probleme mit der Marketplace-Verwaltung im Administratorportal behoben, bei denen nach dem Anwenden von Filtern falsche Ergebnisse und im Herausgeberfilter doppelte Herausgebernamen angezeigt wurden. Außerdem wurde die Leistung verbessert, damit Ergebnisse schneller angezeigt werden.
Es wurde ein Problem auf dem Blatt mit den verfügbaren Sicherungen behoben, bei dem eine neue verfügbare Sicherung aufgeführt wurde, bevor der Upload an den externen Speicherort abgeschlossen war. Die verfügbare Sicherung wird jetzt erst dann in der Liste angezeigt, nachdem der Upload an den Speicherort erfolgreich abgeschlossen wurde.

Es wurde ein Problem mit dem Abrufen von Wiederherstellungsschlüsseln während eines Sicherungsvorgangs behoben.

Es wurde ein Problem behoben, bei dem für die Version des OEM-Updates im Betreiberportal „Undefiniert“ angezeigt wurde.

Sicherheitsupdates

Informationen zu Sicherheitsupdates in diesem Update von Azure Stack finden Sie unter Azure Stack-Sicherheitsupdates.

Updateplanung

Stellen Sie vor dem Anwenden des Updates sicher, dass Sie die folgenden Informationen überprüfen:

Herunterladen des Updates

Sie können das Paket mit dem Azure Stack-Update 1905 auf der Azure Stack-Downloadseite herunterladen. Stellen Sie bei Verwendung des Downloadtools sicher, dass Sie die neueste Version und keine zwischengespeicherte Kopie aus Ihrem Verzeichnis „Downloads“ verwenden.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie den aktuellen Azure Stack-Hotfix für 1904 installieren, bevor Sie Azure Stack auf 1905 aktualisieren.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Vor dem Anwenden des Updates 1905

Version 1905 von Azure Stack muss auf Version 1904 mit den folgenden Hotfixes angewendet werden:

Azure Stack-Hotfix 1.1904.4.45

Nach erfolgreicher Anwendung des Updates 1905

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack-Hotfix 1.1905.3.48

Automatische Updatebenachrichtigungen

Für Kunden mit Systemen, die über das Infrastrukturnetzwerk auf das Internet zugreifen können, wird im Bedienerportal die Meldung Update verfügbar angezeigt. Für Systeme ohne Internetzugriff kann die ZIP-Datei mit der entsprechenden XML-Datei heruntergeladen und installiert werden.

Nächste Schritte

Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.
Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.

1904 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

In diesem Artikel wird der Inhalt des Updatepakets 1904 beschrieben. Das Update enthält Neuerungen, Verbesserungen und Fehlerbehebungen für diese Version von Azure Stack. Dieser Artikel enthält die folgenden Informationen:

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1904 ist 1.1904.0.36.

Updatetyp

Der Buildtyp des Azure Stack 1904-Updates lautet Express. Weitere Informationen zu Update-Buildtypen finden Sie im Artikel Verwalten von Updates in Azure Stack. Das Update 1904 dauert etwa 16 Stunden, die genauen Zeiten können jedoch variieren. Dieser Näherungswert der Laufzeit ist spezifisch für das Update 1904 und nicht auf andere Azure Stack-Updates übertragbar.

Inhalt des Updates

Verbesserungen

In 1904 wurden signifikante Verbesserungen am SDN-Stapel (Software-Defined Networking) vorgenommen. Dank dieser Maßnahmen wird die allgemeine Wartung und Zuverlässigkeit des SDN-Stapels in Azure Stack vereinfacht bzw. verbessert.
Im Administratorportal wurde eine Benachrichtigung für den Fall hinzugefügt, dass der derzeit angemeldete Benutzer nicht über die erforderlichen Berechtigungen verfügt, damit das Dashboard richtig geladen werden kann. Außerdem ist ein Link zur Dokumentation vorhanden, in der beschrieben ist, welche Konten über die passenden Berechtigungen verfügen. Dies hängt vom Identitätsanbieter ab, der während der Bereitstellung verwendet wird.
Es wurden Verbesserungen in Bezug auf die Resilienz und Betriebszeit von VMs durchgeführt. Dies bedeutet auch eine Lösung für das Szenario, bei dem alle VMs in den Offlinezustand versetzt werden, wenn das Speichervolume mit den VM-Konfigurationsdateien offline geschaltet wird.

Es wurde eine Optimierung in Bezug auf die Anzahl von gleichzeitig evakuierten VMs hinzugefügt und der Bandbreitenverbrauch beschränkt, um die Gefahr von Spannungsabfällen oder Stromausfällen für VMs zu minimieren, wenn das Netzwerk stark ausgelastet ist. Durch diese Änderung wird die VM-Betriebszeit erhöht, wenn ein System aktualisiert wird.

Es wurde eine Verbesserung der Ressourcendrosselung bei einem System unter Volllast durchgeführt, um zu verhindern, dass die Plattformressourcen durch interne Prozesse erschöpft werden und es im Portal zu Fehlern bei Vorgängen kommt.
Aufgrund der verbesserten Filterfunktionen können Bediener mehrere Filter gleichzeitig anwenden. Sie können auf der neuen Benutzeroberfläche nur nach der Spalte Name sortieren.
Verbesserungen des Prozesses zum Löschen von Angeboten, Plänen, Kontingenten und Abonnements. Sie können über das Administratorportal jetzt Angebote, Kontingente, Pläne und Abonnements löschen, wenn das betreffende Objekt nicht über Abhängigkeiten verfügt. Weitere Informationen finden Sie in diesem Artikel.

Das Volume für syslog-Nachrichten wurde verbessert. Nicht erforderliche Ereignisse werden herausgefiltert, und es wird ein Konfigurationsparameter angegeben, um den gewünschten Schweregrad für weitergeleitete Nachrichten auszuwählen. Weitere Informationen zum Konfigurieren des Schweregrads finden Sie unter Integration des Azure Stack-Datencenters: syslog-Weiterleitung.

Dem Cmdlet Get-AzureStackLog wurde eine neue Funktion hinzugefügt, indem der zusätzliche Parameter -OutputSASUri bereitgestellt wurde. Sie können jetzt Azure Stack-Protokolle aus Ihrer Umgebung erfassen und im angegebenen Azure Storage-Blobcontainer speichern. Weitere Informationen finden Sie unter Azure Stack-Diagnose.
Es wurde eine neue Speicherüberprüfung in der Gruppe "Test-AzureStackUpdateReadiness" hinzugefügt, die überprüft, ob genügend Arbeitsspeicher im Stapel verfügbar ist, damit das Update erfolgreich abgeschlossen werden kann.

Es wurden Verbesserungen an Test-AzureStack in Bezug auf die Auswertung der Service Fabric-Integrität vorgenommen.

Hardwareupdates wurden verbessert, um die Dauer für die Durchführung von Updates der Laufwerkfirmware auf zwei bis vier Stunden zu verringern. Mit dem Updatemodul wird basierend auf dem Inhalt des Pakets dynamisch ermittelt, welche Teile des Updates ausgeführt werden müssen.

Es wurden stabile Vorabüberprüfungen von Vorgängen hinzugefügt, um störende Vorgänge von Infrastrukturrolleninstanzen zu verhindern, die sich auf die Verfügbarkeit auswirken.

Verbesserungen der Idempotenz des Sicherungsaktionsplans der Infrastruktur.

Verbesserungen der Azure Stack-Protokollsammlung. Diese Verbesserungen führen zu einem verringerten Zeitaufwand für das Abrufen der Protokolle. Darüber hinaus generiert das Cmdlet Get-AzureStackLog keine Standardprotokolle für die OEM-Rolle mehr. Sie müssen das Cmdlet Invoke-AzureStackOnDemandLog ausführen und die Rolle zum Abrufen der OEM-Protokolle angeben. Weitere Informationen finden Sie unter Azure Stack-Diagnose.
In Azure Stack wird jetzt die Verbunddaten-URL für die Datencenterintegration mit ADFS überwacht. Auf diese Weise wird die Zuverlässigkeit während der Geheimnisrotation der ADFS-Instanz bzw. -Farm des Kunden verbessert.

Änderungen

Die Option, mit der Azure Stack-Bediener Infrastrukturrolleninstanzen über das Administratorportal herunterfahren konnten, wurde entfernt. Mit der Neustartfunktionalität wird sichergestellt, dass ein korrekter Versuch zum Herunterfahren durchgeführt wird, bevor die Infrastrukturrolleninstanz neu gestartet wird. Für erweiterte Szenarien bleibt die API- und PowerShell-Funktionalität verfügbar.

Es gibt eine neue Marketplace-Verwaltungsoberfläche mit separaten Bildschirmen für Marketplace-Images und Ressourcenanbieter. Bisher ist das Fenster Ressourcenanbieter noch leer, aber in zukünftigen Versionen werden neue PaaS-Dienstangebote angezeigt und können im Fenster Ressourcenanbieter verwaltet werden.

Änderungen an der Updateoberfläche im Betreiberportal. Es ist ein neues Raster für Ressourcenanbieterupdates vorhanden. Die Möglichkeit zum Aktualisieren von Ressourcenanbietern ist noch nicht verfügbar.

Änderungen an der Benutzeroberfläche für die Updateinstallation im Bedienerportal. Damit Azure Stack-Bediener auf ein Updateproblem richtig reagieren können, werden im Portal jetzt basierend auf der Integrität der Skalierungseinheit spezifischere Empfehlungen bereitgestellt. Dies erfolgt automatisch, indem Test-AzureStack ausgeführt wird und die Ergebnisse analysiert werden. Anhand des Ergebnisses wird der Bediener angewiesen, eine von zwei Maßnahmen zu ergreifen:
- Im Portal wird eine nicht kritische Warnung mit einem Hinweis der folgenden Art angezeigt: „Für das letzte Update ist ein Eingreifen erforderlich. Microsoft empfiehlt das Erstellen einer Serviceanfrage während der normalen Geschäftszeiten. Im Rahmen des Updateprozesses wird der Vorgang „Test-AzureStack“ durchgeführt, und basierend auf der Ausgabe wird die am besten geeignete Warnung generiert. In diesem Fall wurde der Test „Test-AzureStack“ bestanden.“
- Im Portal wird die folgende kritische Warnung angezeigt: „Beim letzten Update ist ein Fehler aufgetreten. Microsoft empfiehlt, so schnell wie möglich eine Serviceanfrage zu erstellen. Im Rahmen des Updateprozesses wird der Vorgang „Test-AzureStack“ durchgeführt, und basierend auf der Ausgabe wird die am besten geeignete Warnung generiert. In diesem Fall wurde der Test „Test-AzureStack“ nicht bestanden.“
Es wurde ein Update auf Version 2.2.38.0 des Azure Linux-Agents durchgeführt. Aufgrund dieser Unterstützung können Kunden einheitliche Linux-Images zwischen Azure und Azure Stack nutzen.
Änderungen an den Updateprotokollen im Bedienerportal. Anforderungen zum Abrufen der Protokolle für erfolgreiche Updates sind nicht mehr verfügbar. Protokolle für fehlerhafte Updates sind weiterhin zum Download verfügbar, da sie zur Diagnose verwendet werden können.

Korrekturen

Es wurde ein Problem behoben, bei dem die syslog-Konfiguration bei einem Updatezyklus nicht beibehalten wurde, sodass der syslog-Client seine Konfiguration verliert und die syslog-Nachrichten nicht mehr weitergeleitet werden. Die syslog-Konfiguration wird jetzt beibehalten.
Es wurde ein CRP-Problem behoben, bei dem die Aufhebung der Zuordnung von VMs blockiert wurde. Wenn eine VM viele große verwaltete Datenträger enthalten hat, konnte es bisher vorkommen, dass beim Aufheben der Zuordnung der VM ein Zeitlimitfehler aufgetreten ist.
Es wurde ein Problem mit dem Windows Defender-Modul behoben, bei dem der Zugriff auf die Speicherung von Skalierungseinheiten beeinträchtigt wurde.
Es wurde ein Problem mit dem Benutzerportal behoben, bei dem das Zugriffsrichtlinienfenster für Blobspeicherkonten nicht geladen werden konnte.
Es wurde ein Problem im Administrator- und im Benutzerportal behoben, bei dem fehlerhafte Benachrichtigungen zum globalen Azure-Portal angezeigt wurden.
Es wurde ein Problem im Benutzerportal behoben, bei dem die Auswahl der Kachel Feedback dazu geführt hat, dass eine leere Browserregisterkarte geöffnet wurde.
Es wurde ein Portalproblem behoben, bei dem eine Änderung einer statischen IP-Adresse für eine IP-Konfiguration, die an den Netzwerkadapter einer VM-Instanz gebunden war, zur Anzeige einer Fehlermeldung geführt hat.
Es wurde ein Problem im Benutzerportal behoben, bei dem beim Vorgang Netzwerkschnittstelle anfügen für eine vorhandene VM über das Fenster Netzwerk ein Fehler mit einer Fehlermeldung aufgetreten ist.
Es wurde ein Problem behoben, bei dem Azure Stack das Anfügen von mehr als vier Netzwerkschnittstellen (NICs) an eine VM-Instanz nicht unterstützt hat.
Es wurde ein Problem im Portal behoben, bei dem das Hinzufügen einer Eingangssicherheitsregel und das Auswählen von Diensttag als Quelle dazu geführt hat, dass mehrere Optionen angezeigt wurden, die für Azure Stack nicht verfügbar sind.
Es wurde ein Problem behoben, bei dem Netzwerksicherheitsgruppen (NSGs) in Azure Stack nicht auf die gleiche Weise wie in der globalen Azure-Umgebung funktioniert haben.
Es wurde ein Problem mit der Marketplace-Verwaltung behoben, bei dem alle heruntergeladenen Produkte ausgeblendet werden, wenn die Registrierung abläuft oder entfernt wird.
Es wurde ein Problem behoben, bei dem beim Ausführen des Befehls Set-AzureRmVirtualNetworkGatewayConnection in PowerShell für eine vorhandene Verbindung eines Gateways für virtuelle Netzwerke die Fehlermeldung Ungültiger gemeinsam verwendeter Schlüssel konfiguriert... angezeigt wurde.
Es wurde ein Problem behoben, bei dem der Netzwerkressourcenanbieter nicht mit dem Netzwerkcontroller synchron war, sodass eine doppelte Ressourcenanforderung durchgeführt wurde. In einigen Fällen ist die übergeordnete Ressource hierbei in einem Fehlerzustand verblieben.
Es wurde ein Problem behoben, bei dem Folgendes aufgetreten ist: Wenn einem Benutzer die Rolle „Mitwirkender“ für ein Abonnement zugewiesen wurde, aber nicht explizit Leseberechtigungen, wurde beim Versuch, eine Änderung einer Ressource zu speichern, der Fehler ...Client „somelogonaccount@domain.com“ mit der Objekt-ID „{GUID}“ hat keine Berechtigung zum Ausführen der Aktion... generiert.
Es wurde ein Problem behoben, bei dem der Marketplace-Verwaltungsbildschirm leer war, wenn das Offlinesyndikationstool zum Hochladen von Images verwendet wurde und für ein oder mehrere Images die Symbol-URI(s) gefehlt haben.
Es wurde ein Problem behoben, aufgrund dessen Produkte, bei deren Download ein Fehler aufgetreten ist, nicht aus der Marketplace-Verwaltung gelöscht werden konnten.

Sicherheitsupdates

Dieses Update von Azure Stack enthält keine Sicherheitsupdates für das zugrunde liegende Betriebssystem, von dem Azure Stack gehostet wird.

Updateplanung

Stellen Sie vor dem Anwenden des Updates sicher, dass Sie die folgenden Informationen überprüfen:

Hinweis

Achten Sie darauf, dass Sie für die Planung und Größenanpassung Ihrer Workloads die neueste Version des Tools Azure Stack Capacity Planner verwenden. Die neueste Version umfasst Fehlerbehebungen und neue Features, die mit jedem Azure Stack-Update veröffentlicht werden.

Herunterladen des Updates

Sie können das Paket mit dem Azure Stack-Update 1904 auf der Azure Stack-Downloadseite herunterladen.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie den aktuellen Azure Stack-Hotfix für 1903 installieren, bevor Sie Azure Stack auf 1904 aktualisieren.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Vor dem Anwenden des Updates 1904

Version 1904 von Azure Stack muss auf Version 1903 mit den folgenden Hotfixes angewendet werden:

Azure Stack-Hotfix 1.1903.2.39

Nach erfolgreicher Anwendung des Updates 1904

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in unserer Wartungsrichtlinie.

Azure Stack-Hotfix 1.1904.4.45

Automatische Updatebenachrichtigungen

Nächste Schritte

Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.
Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.

1903 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

Dieser Artikel beschreibt den Inhalt des Updatepakets 1903. Das Update enthält Verbesserungen, Fehlerbehebungen und neue Funktionen für diese Version von Azure Stack. In diesem Artikel werden auch bekannte Probleme in diesem Release beschrieben, und er enthält einen Link zum Herunterladen des Updates. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1903 ist 1.1903.0.35.

Updatetyp

Der Azure Stack 1903-Update-Buildtyp lautet Express. Weitere Informationen zu Update-Buildtypen finden Sie im Artikel Verwalten von Updates in Azure Stack. Die zu erwartende Dauer bis zum Abschluss von Update 1903 beträgt ca. 16 Stunden, aber die genauen Zeiten können variieren. Dieser Näherungswert der Laufzeit ist spezifisch für das Update 1903 und sollte nicht auf andere Azure Stack-Updates übertragen werden.

Wichtig

Die Nutzlast 1903 umfasst kein ASDK-Release.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie den aktuellen Azure Stack-Hotfix für 1902 installieren, bevor Sie Azure Stack auf 1903 aktualisieren.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Azure Stack-Hotfixes

1902: KB 4500637 – Azure Stack Hotfix 1.1902.3.75
1903: KB 4500638 – Azure Stack Hotfix 1.1903.2.39

Verbesserungen

Es wurde ein Netzwerkfehler behoben, durch den verhindert wurde, dass Änderungen des Werts Leerlauftimeout (Minuten) für eine Öffentliche IP-Adresse wirksam wurden. Bisher wurden Änderungen dieses Werts ignoriert, damit unabhängig von allen Änderungen, die Sie durchgeführt haben, immer der Standardwert „4 Minuten“ verwendet wurde. Mit dieser Einstellung wird gesteuert, wie viele Minuten eine TCP-Verbindung geöffnet bleiben soll, ohne dass Clients Keep-Alive-Meldungen senden müssen. Beachten Sie hierbei Folgendes: Dieser Fehler hat sich nur auf öffentliche IP-Adressen der Instanzebene und nicht auf öffentliche IP-Adressen ausgewirkt, die einem Lastenausgleich zugewiesen waren.
Es wurden Verbesserungen an der Zuverlässigkeit des Updatemoduls vorgenommen, z. B. automatische Behebung von häufigen Problemen, damit Updates ohne Unterbrechung angewendet werden.
Es wurden Verbesserungen an der Erkennung und Behebung von Zuständen mit wenig freiem Speicherplatz vorgenommen.
Azure Stack unterstützt jetzt Microsoft Azure-Linux-Agents mit einer höheren Version als 2.2.35. Aufgrund dieser Unterstützung können Kunden einheitliche Linux-Images zwischen Azure und Azure Stack nutzen. Dies wurde im Rahmen der Hotfixes 1901 und 1902 hinzugefügt.

Verwaltung von Geheimnissen

Azure Stack unterstützt jetzt die Rotation des Stammzertifikats, das von Zertifikaten für die Rotation externer Geheimnisse verwendet wird. Weitere Informationen finden Sie in diesem Artikel.
1903 enthält Leistungsverbesserungen für die Geheimnisrotation, mit der die Zeit zum Ausführen der Rotation interner Geheimnisse reduziert wird.

Voraussetzungen

Wichtig

Installieren Sie den aktuellen Azure Stack-Hotfix für 1902 (falls vorhanden), bevor Sie auf 1903 aktualisieren.

Achten Sie darauf, dass Sie für die Planung und Größenanpassung Ihrer Workloads die neueste Version von Azure Stack Capacity Planner verwenden. Die neueste Version umfasst Fehlerbehebungen und neue Features, die mit jedem Azure Stack-Update veröffentlicht werden.
Bevor Sie mit der Installation dieses Updates beginnen, sollten Sie Test-AzureStack mit dem folgenden Parameter ausführen, um den Status von Azure Stack zu überprüfen und alle gefundenen operativen Probleme (einschließlich aller Warnungen und Fehler) zu beheben. Überprüfen Sie auch aktive Warnungen, und führen Sie die Behebung für Einträge durch, für die eine Aktion erforderlich ist:
```
Test-AzureStack -Group UpdateReadiness
```
Wenn Azure Stack von System Center Operations Manager verwaltet wird, müssen Sie das Management Pack für Microsoft Azure Stack auf Version 1.0.3.11 aktualisieren, bevor Sie das Update 1903 anwenden.
Das Paketformat für das Azure Stack-Update wurde ab Release 1902 von .bin/.exe/.xml in .zip/.xml geändert. Kunden mit verbundenen Azure Stack-Skalierungseinheiten sehen im Portal die Meldung Update verfügbar. Kunden ohne Verbindung können die ZIP-Datei mit der entsprechenden XML-Datei jetzt einfach herunterladen und importieren.

Bekannte Probleme mit dem Updateprozess

Wenn Sie versuchen, ein Azure Stack-Update zu installieren, wird für den Status des Updates möglicherweise ein Fehler ausgegeben und der Zustand in PreparationFailed geändert. Der Grund dafür ist, dass der Updateressourcenanbieter (Update Resource Provider, URP) die Dateien aus dem Speichercontainer nicht ordnungsgemäß auf eine Infrastrukturfreigabe zur Verarbeitung übertragen kann. Ab Version 1901 (1.1901.0.95) können Sie dieses Problem umgehen, indem Sie erneut auf Aktualisieren (nicht auf Fortsetzen) klicken. Der URP bereinigt dann die Dateien aus dem vorherigen Versuch und startet den Download erneut.
Wenn Sie Test-AzureStack ausführen, wird eine Warnmeldung des Baseboard-Verwaltungscontrollers (BMC) angezeigt. Sie können diese Warnung problemlos ignorieren.

Während der Installation dieses Updates werden unter Umständen Warnungen mit folgender Meldung angezeigt: Fehler: Die Vorlage für FaultType UserAccounts.New fehlt. Sie können diese Warnungen problemlos ignorieren. Die Warnungen werden automatisch geschlossen, nachdem die Installation dieses Updates abgeschlossen wurde.

Schritte nach dem Update

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie sowohl unter Hotfixes als auch Wartungsrichtlinie.
Rufen Sie die Verschlüsselungsschlüssel für ruhende Daten ab, und speichern Sie diese sicher außerhalb Ihrer Azure Stack-Bereitstellung. Befolgen Sie die Anleitungen zum Abrufen der Schlüssel.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Wenn Sie im Benutzerportal im Dashboard versuchen, auf die Kachel Feedback zu klicken, wird eine leere Browserregisterkarte geöffnet. Zur Problemumgehung können Sie über Azure Stack UserVoice eine UserVoice-Anfrage erstellen.

Wenn Sie im Administrator- oder im Benutzerportal nach „Docker“ suchen, wird das Element nicht ordnungsgemäß zurückgegeben. Es ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Blatt mit einem Fehlerhinweis angezeigt.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Die zwei administrativen Abonnementtypen, die in Version 1804 eingeführt wurden, sollten nicht verwendet werden. Die Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Wenn Sie im Benutzerportal in einem Speicherkonto zu einem Blob navigieren und versuchen, in der Navigationsstruktur die Option Zugriffsrichtlinie zu öffnen, wird das nachfolgende Fenster nicht geladen. Zum Umgehen dieses Problems können mit den folgenden PowerShell-Cmdlets Zugriffsrichtlinien jeweils erstellt, abgerufen, festgelegt und gelöscht werden:

Wenn Sie im Benutzerportal versuchen, ein Blob mit der Option OAuth (Vorschau) hochzuladen, wird für die Aufgabe eine Fehlermeldung angezeigt. Laden Sie das Blob mit der Option SAS hoch, um dieses Problem zu umgehen.
Wenn Sie bei den Azure Stack-Portalen angemeldet sind, werden ggf. Benachrichtigungen zum globalen Azure-Portal angezeigt. Sie können diese Benachrichtigungen sicher ignorieren, da sie derzeit nicht für Azure Stack gelten (z. B. "1 neues Update – Die folgenden Updates sind jetzt verfügbar: Azure-Portal April 2019-Update").
Wenn Sie im Benutzerportal im Dashboard versuchen, die Kachel Feedback auszuwählen, wird eine leere Browserregisterkarte geöffnet. Zur Problemumgehung können Sie über Azure Stack UserVoice eine UserVoice-Anfrage erstellen.

Compute

Wenn Sie einen neuen virtuellen Windows-Computer erstellen, wird möglicherweise der folgende Fehler angezeigt:

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Der Fehler tritt auf, wenn Sie die Startdiagnose bei einem virtuellen Computer aktivieren, aber Ihr Startdiagnose-Speicherkonto löschen. Um dieses Problem zu umgehen, erstellen Sie das Speicherkonto erneut mit demselben Namen wie zuvor.

Die Benutzeroberfläche zum Erstellen von Virtual Machine Scale Sets bietet „CentOS 7.2-basiert“ als Option für die Bereitstellung an. Da dieses Image im Azure Stack-Marketplace nicht verfügbar ist, wählen Sie entweder ein anderes Betriebssystem für Ihre Bereitstellung aus, oder verwenden Sie eine Azure Resource Manager-Vorlage mit einem anderen CentOS-Image, das vor der Bereitstellung vom Bediener aus dem Marketplace heruntergeladen wurde.

Nach dem Anwenden des Updates 1903 können beim Bereitstellen von VMs mit Managed Disks die folgenden Probleme auftreten:
- Wenn das Abonnement vor dem Update 1808 erstellt wurde, schlägt die Bereitstellung eines virtuellen Computers mit Managed Disks möglicherweise mit einer internen Fehlermeldung fehl. Führen Sie die folgenden Schritte für jedes Abonnement aus, um den Fehler zu beheben:
  1. Navigieren Sie im Mandantenportal zu Abonnements, und suchen Sie nach dem Abonnement. Wählen Sie Ressourcenanbieter und dann Microsoft.Compute aus, und klicken Sie dann auf Erneut registrieren.
  2. Navigieren Sie unter dem gleichen Abonnement zu Zugriffssteuerung (IAM), und überprüfen Sie, ob Azure Stack – Verwalteter Datenträger aufgeführt wird.
- Wenn Sie eine Umgebung mit mehreren Mandanten konfiguriert haben, schlägt die Bereitstellung von virtuellen Computern in einem Abonnement, dem ein Gastverzeichnis zugeordnet ist, möglicherweise mit einer internen Fehlermeldung fehl. Zum Beheben des Fehlers führen Sie die in diesem Artikel beschriebenen Schritte aus, um alle Gastverzeichnisse neu zu konfigurieren.
Ein virtueller Ubuntu 18.04-Computer, der mit aktivierter SSH-Autorisierung erstellt wurde, lässt nicht zu, dass Sie die SSH-Schlüssel für die Anmeldung verwenden. Um dieses Problem zu umgehen, verwenden Sie VM-Zugriff für die Linux-Erweiterung, um SSH-Schlüssel nach der Bereitstellung zu implementieren, oder verwenden Sie kennwortbasierte Authentifizierung.

Wenn Sie nicht über einen Hardwarelebenszyklus-Host (Hardware Lifecycle Host, HLH) verfügen: Vor Build 1902 mussten Sie die Gruppenrichtlinie Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen auf LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt) festlegen. Seit Build 1902 müssen Sie den Wert Nicht definiert beibehalten oder die Richtlinie auf Nur NTLMv2-Antworten senden (Standardwert) festlegen. Andernfalls können Sie keine PowerShell-Remotesitzung einrichten, und der Fehler Zugriff verweigert wird angezeigt:

$Session = New-PSSession -ComputerName x.x.x.x -ConfigurationName PrivilegedEndpoint -Credential $Cred
New-PSSession : [x.x.x.x] Connecting to remote server x.x.x.x failed with the following error message : Access is denied. For more information, see the
about_Remote_Troubleshooting Help topic.
At line:1 char:12
+ $Session = New-PSSession -ComputerName x.x.x.x -ConfigurationNa ...
+            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed

Sie können eine Skalierungsgruppe nicht über das Blatt VM-Skalierungsgruppen entfernen. Wählen Sie zur Problemumgehung die Skalierungsgruppe aus, die Sie entfernen möchten, und klicken Sie dann im Bereich Übersicht auf die Schaltfläche Löschen.
Bei der Erstellung von VMs in einer Verfügbarkeitsgruppe mit drei Fehlerdomänen und der Erstellung einer Instanz einer VM-Skalierungsgruppe tritt während des Updatevorgangs in einer Azure Stack-Umgebung mit vier Knoten der Fehler FabricVmPlacementErrorUnsupportedFaultDomainSize auf. Sie können einzelne VMs in einer Verfügbarkeitsgruppe mit zwei Fehlerdomänen erfolgreich durchführen. Die Erstellung der Skalierungsgruppeninstanz ist während des Updatevorgangs in einer Azure Stack-Umgebung mit vier Knoten aber immer noch nicht verfügbar.

Netzwerk

Im Azure Stack-Portal wird, wenn Sie eine statische IP-Adresse für eine IP-Konfiguration ändern, die an einen Netzwerkadapter gebunden ist, die an eine VM-Instanz angefügt ist, eine Warnmeldung angezeigt, die besagt:

The virtual machine associated with this network interface will be restarted to utilize the new private IP address...

Sie können diese Meldung gefahrlos ignorieren. Die IP-Adresse wird auch dann geändert, wenn die VM-Instanz nicht neu gestartet wird.

Wenn Sie im Portal eine eingehende Sicherheitsregel hinzufügen und als Quelle Diensttag auswählen, werden mehrere Optionen in der Liste Quelltag angezeigt, die für Azure Stack nicht verfügbar sind. Die einzigen Optionen, die in Azure Stack gültig sind, lauten folgendermaßen:
- Internet
- VirtualNetwork
- AzureLoadBalancer
Die anderen Optionen werden nicht als Quelltags in Azure Stack unterstützt. Auf ähnliche Weise wird, wenn Sie eine ausgehende Sicherheitsregel hinzufügen und als Ziel Diensttag auswählen, dieselbe Liste von Optionen für Quelltag angezeigt. Die einzigen gültigen Optionen sind dieselben wie für Quelltag, wie in der vorherigen Liste beschrieben.
Netzwerksicherheitsgruppen (NSGs) funktionieren in Azure Stack nicht auf die gleiche Weise wie in Azure weltweit. In Azure können Sie mehrere Ports für eine NSG-Regel festlegen (mit dem Portal, PowerShell und Resource Manager). In Azure Stack können Sie jedoch nicht mehrere Ports für eine NSG-Regel über das Portal festlegen. Um dieses Problem zu umgehen, verwenden Sie eine Resource Manager-Vorlage oder PowerShell, um diese zusätzlichen Regeln festzulegen.

Azure Stack unterstützt derzeit unabhängig von der Instanzgröße das Anfügen von höchstens vier Netzwerkschnittstellen (NICs) an eine VM-Instanz.

App Service

Mandanten müssen den Speicherressourcenanbieter vor dem Erstellen ihrer ersten Azure-Funktion im Abonnement registrieren.
Einige Benutzeroberflächen im Mandantenportal sind aufgrund einer Inkompatibilität mit dem Portalframework in 1903 fehlerhaft, z. B. die Benutzeroberfläche für Bereitstellungsslots, Tests in der Produktion und Websiteerweiterungen. Verwenden Sie das Azure App Service PowerShell-Modul oder die Azure CLI, um dieses Problem zu umgehen. Die Portalumgebung wird im bevorstehenden Release von Azure App Service unter Azure Stack 1.6 (Update 6) wiederhergestellt.

Syslog

Die syslog-Konfiguration wird bei einem Updatezyklus nicht beibehalten, sodass der syslog-Client seine Konfiguration verliert und die syslog-Nachrichten nicht mehr weitergeleitet werden. Dieses Problem betrifft alle Versionen von Azure Stack ab der allgemeinen Verfügbarkeit des syslog-Clients (1809). Um dieses Problem zu umgehen, konfigurieren Sie den syslog-Client nach Anwenden eines Azure Stack-Updates neu.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1903 hier herunterladen.

Nur in verbundenen Szenarios überprüfen Azure Stack-Bereitstellungen in regelmäßigen Abständen einen gesicherten Endpunkt und benachrichtigen Sie automatisch, wenn ein Update für Ihre Cloud verfügbar ist. Weitere Informationen finden Sie unter Verwalten von Updates für Azure Stack.

Nächste Schritte

Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.
Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.

1902 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

Dieser Artikel beschreibt den Inhalt des Updatepakets 1902. Das Update enthält Verbesserungen, Fehlerbehebungen und neue Funktionen für diese Version von Azure Stack. In diesem Artikel werden auch bekannte Probleme in diesem Release beschrieben, und er enthält einen Link zum Herunterladen des Updates. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1902 ist 1.1902.0.69.

Updatetyp

Der Azure Stack 1902-Update-Buildtyp lautet Vollständig. Weitere Informationen zu Update-Buildtypen finden Sie im Artikel Verwalten von Updates in Azure Stack.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie das aktuelle Azure Stack-Hotfix für 1901 installieren, bevor Sie Azure Stack auf 1902 aktualisieren.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Azure Stack-Hotfixes

1901: KB 4500636 – Azure Stack Hotfix 1.1901.5.109
1902: KB 4500637 – Azure Stack Hotfix 1.1902.3.75

Voraussetzungen

Wichtig

Sie können 1902 direkt auf der Grundlage des Release 1.1901.0.95 oder 1.1901.0.99 installieren, ohne zuvor einen 1901-Hotfix zu installieren. Wenn Sie jedoch den älteren Hotfix 1901.2.103 installiert haben, müssen Sie den neueren Hotfix 1901.3.105 installieren, bevor Sie mit 1902 fortfahren.

Bevor Sie mit der Installation dieses Updates beginnen, führen Sie Test-AzureStack mit den folgenden Parametern aus, um den Status von Azure Stack zu überprüfen und alle gefundenen operativen Probleme (einschließlich aller Warnungen und Fehler) zu beheben. Überprüfen Sie auch aktive Warnungen, und führen Sie die Behebung für Einträge durch, für die eine Aktion erforderlich ist:
```
Test-AzureStack -Include AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
```
Wenn der Parameter AzsControlPlane bei der Ausführung von Test-AzureStack enthalten ist, wird in der Ausgabe von Test-AzureStack der folgende Fehler angezeigt: FAIL Azure Stack Control Plane Websites Summary (FEHLER: Websitezusammenfassung der Azure Stack-Steuerungsebene). Sie können diesen spezifischen Fehler ignorieren.
Wenn Azure Stack von System Center Operations Manager verwaltet wird, müssen Sie das Management Pack für Microsoft Azure Stack auf Version 1.0.3.11 aktualisieren, bevor Sie das Update 1902 anwenden.
Das Paketformat für das Azure Stack-Update wurde ab Release 1902 von .bin/.exe/.xml in .zip/.xml geändert. Kunden mit verbundenen Azure Stack-Skalierungseinheiten sehen im Portal die Meldung Update verfügbar. Kunden ohne Verbindung können die ZIP-Datei mit der entsprechenden XML-Datei jetzt einfach herunterladen und importieren.

Verbesserungen

In Build 1902 wird eine neue Benutzeroberfläche im Azure Stack-Administratorportal zum Erstellen von Plänen, Angeboten, Kontingenten und Add-On-Plänen eingeführt. Weitere Informationen (einschließlich Screenshots) finden Sie unter Erstellen von Plänen, Angeboten und Kontingenten.

Verbesserungen der Zuverlässigkeit der Kapazitätserweiterung beim Hinzufügen eines Knotens, wenn die Skalierungseinheit vom Zustand der Speichererweiterung in den Ausführungszustand umgeschaltet wird.

Zum Verbessern der Paketintegrität und -sicherheit sowie zum Vereinfachen der Verwaltung für die Offlineerfassung hat Microsoft das Format des Updatepakets von EXE- und BIN-Dateien in eine ZIP-Datei geändert. Das neue Format verbessert die Zuverlässigkeit des Entpackungsprozesses, der mitunter Verzögerungen bei der Vorbereitung des Updates verursachen kann. Das gleiche Paketformat gilt auch für Updatepakete von Ihrem OEM.
Um die Benutzerfreundlichkeit von Azure Stack bei der Ausführung von Test-AzureStack zu verbessern, können Benutzer nun einfach „Test-AzureStack -Group UpdateReadiness“ verwenden, anstatt zehn zusätzliche Parameter nach einer Include-Anweisung zu übergeben.
```
  Test-AzureStack -Group UpdateReadiness  
```
Zum Verbessern der allgemeinen Zuverlässigkeit und Verfügbarkeit von zentralen Infrastrukturdiensten während des Updateprozesses werden im Rahmen des Plans mit den Updateaktionen automatische globale Wartungen vom nativen Ressourcenanbieter erkannt und bei Bedarf aufgerufen. Workflows zur globalen Wartung vom Typ „Reparieren“ umfassen folgende Schritte:
- Suchen nach VMs in der Infrastruktur, die sich in einem nicht optimalen Zustand befinden, und diese bei Bedarf reparieren
- Suchen nach Problemen im Rahmen des Steuerungsplans mit dem SQL-Dienst und diese bei Bedarf reparieren
- Überprüfen des Status des Software Load Balancer-Diensts (SLB) als Teil des Netzwerkcontrollers (NC) und diesen bei Bedarf reparieren
- Überprüfen des Status des Netzwerkcontrollerdiensts (NC) und diesen bei Bedarf reparieren
- Status der ERCS-Service Fabric-Knoten (Emergency Recovery Console Service) überprüfen und diese bei Bedarf reparieren
- Überprüfen des Status der Infrastrukturrolle und diese bei Bedarf reparieren
- Status der ACS-Service Fabric-Knoten (Azure Consistent Storage) überprüfen und diese bei Bedarf reparieren

Verbesserungen der Azure Stack-Diagnosetools, um die Zuverlässigkeit und Leistung der Protokollsammlung zu verbessern. Zusätzliche Protokollierung für Netzwerk- und Identitätsdienste.

Verbesserungen der Zuverlässigkeit von Test-AzureStack für den Bereitschaftstest der Geheimnisrotation.

Verbesserungen zum Steigern der Zuverlässigkeit von AD Graph bei der Kommunikation mit der Active Directory-Umgebung eines Kunden

Verbesserungen der Hardwarebestandssammlung in Get-AzureStackStampInformation.
Zum Verbessern der Zuverlässigkeit von Vorgängen, die auf der ERCS-Infrastruktur ausgeführt werden, wird der Arbeitsspeicher für jede ERCS-Instanz von 8 GB auf 12 GB erhöht. Bei einer Installation integrierter Azure Stack-Systeme führt dies zu einer Erhöhung von insgesamt 12 GB.

Mit 1902 wird ein Problem im Netzwerkcontroller-VSwitch-Dienst behoben, bei dem alle VMs eines bestimmten Knotens in den Offlinezustand versetzt wurden. Bei diesem Problem kam es zu einem Hängen in einem Verlustzustand der primären Instanz, bei dem die primäre Instanz nicht erreichbar ist und für die Rolle kein Failover auf eine andere fehlerfreie Instanz ausgeführt wird. Dieses Problem konnte nur behoben werden, indem der Microsoft-Support zurate gezogen wurde.

Wichtig

Vergewissern Sie sich auf dem Blatt Kapazität, dass Ihr Azure Stack-Stempel mehr als 12 GB verfügbaren Speicherplatz aufweist, damit der Patch- und Updateprozess die geringstmögliche Downtime des Mandanten verursacht. Nach der erfolgreichen Installation des Updates wird die Erhöhung des Arbeitsspeichers auf dem Blatt Kapazität angezeigt.

Common Vulnerabilities and Exposures (CVE, allgemeine Sicherheitslücken und Schwachstellen)

Dieses Update installiert die folgenden Sicherheitsupdates:

Weitere Informationen zu diesen Sicherheitsrisiken finden Sie unter den obigen Links oder im Microsoft Knowledge Base-Artikel 4487006.

Bekannte Probleme mit dem Updateprozess

Wenn Sie versuchen, ein Azure Stack-Update zu installieren, wird für den Status des Updates möglicherweise ein Fehler ausgegeben und der Zustand in PreparationFailed geändert. Der Grund dafür ist, dass der Updateressourcenanbieter (Update Resource Provider, URP) die Dateien aus dem Speichercontainer nicht ordnungsgemäß auf eine Infrastrukturfreigabe zur Verarbeitung übertragen kann. Ab Version 1901 (1.1901.0.95) können Sie dieses Problem umgehen, indem Sie erneut auf Aktualisieren (nicht auf Fortsetzen) klicken. Der URP bereinigt dann die Dateien aus dem vorherigen Versuch und startet den Download erneut.
Wenn Sie Test-AzureStack ausführen, wird eine Warnmeldung des Baseboard-Verwaltungscontrollers (BMC) angezeigt. Sie können diese Warnung problemlos ignorieren.
Während der Installation dieses Updates werden unter Umständen Warnungen mit folgender Meldung angezeigt: „Fehler: Die Vorlage für FaultType UserAccounts.New fehlt.“ Sie können diese Warnungen problemlos ignorieren. Die Warnungen werden automatisch geschlossen, nachdem die Installation dieses Updates abgeschlossen wurde.

Schritte nach dem Update

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie sowohl unter Hotfixes als auch Wartungsrichtlinie.
Rufen Sie die Verschlüsselungsschlüssel für ruhende Daten ab, und speichern Sie diese sicher außerhalb Ihrer Azure Stack-Bereitstellung. Befolgen Sie die Anleitungen zum Abrufen der Schlüssel.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Wenn Sie im Administrator- oder im Benutzerportal nach „Docker“ suchen, wird das Element nicht ordnungsgemäß zurückgegeben. Es ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Blatt mit einem Fehlerhinweis angezeigt.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Die zwei administrativen Abonnementtypen, die in Version 1804 eingeführt wurden, sollten nicht verwendet werden. Die Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Wenn Sie im Benutzerportal in einem Speicherkonto zu einem Blob navigieren und versuchen, in der Navigationsstruktur die Option Zugriffsrichtlinie zu öffnen, wird das nachfolgende Fenster nicht geladen. Zum Umgehen dieses Problems können mit den folgenden PowerShell-Cmdlets Zugriffsrichtlinien jeweils erstellt, abgerufen, festgelegt und gelöscht werden:

Compute

Wenn Sie einen neuen virtuellen Windows-Computer erstellen, wird möglicherweise der folgende Fehler angezeigt:

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Der Fehler tritt auf, wenn Sie die Startdiagnose bei einem virtuellen Computer aktivieren, aber Ihr Startdiagnose-Speicherkonto löschen. Um dieses Problem zu umgehen, erstellen Sie das Speicherkonto erneut mit demselben Namen wie zuvor.

Auf der Benutzeroberfläche zum Erstellen von VM-Skalierungsgruppen wird „CentOS 7.2-basiert“ als Option für die Bereitstellung angeboten. Da dieses Image in Azure Stack nicht verfügbar ist, wählen Sie entweder ein anderes Betriebssystem für Ihre Bereitstellung aus, oder verwenden Sie eine Azure Resource Manager-Vorlage mit einem anderen CentOS-Image, das vor der Bereitstellung vom Operator aus dem Marketplace heruntergeladen wurde.

Nach dem Anwenden des Updates 1902 können beim Bereitstellen von VMs mit Managed Disks die folgenden Probleme auftreten:
- Wenn das Abonnement vor dem Update 1808 erstellt wurde, schlägt die Bereitstellung eines virtuellen Computers mit Managed Disks möglicherweise mit einer internen Fehlermeldung fehl. Führen Sie die folgenden Schritte für jedes Abonnement aus, um den Fehler zu beheben:
  1. Navigieren Sie im Mandantenportal zu Abonnements, und suchen Sie nach dem Abonnement. Wählen Sie Ressourcenanbieter und dann Microsoft.Compute aus, und klicken Sie dann auf Erneut registrieren.
  2. Navigieren Sie unter dem gleichen Abonnement zu Zugriffssteuerung (IAM), und überprüfen Sie, ob Azure Stack – Verwalteter Datenträger aufgeführt wird.
- Wenn Sie eine Umgebung mit mehreren Mandanten konfiguriert haben, schlägt die Bereitstellung von virtuellen Computern in einem Abonnement, dem ein Gastverzeichnis zugeordnet ist, möglicherweise mit einer internen Fehlermeldung fehl. Zum Beheben des Fehlers führen Sie die in diesem Artikel beschriebenen Schritte aus, um alle Gastverzeichnisse neu zu konfigurieren.
Ein virtueller Ubuntu 18.04-Computer, der mit aktivierter SSH-Autorisierung erstellt wurde, lässt nicht zu, dass Sie die SSH-Schlüssel für die Anmeldung verwenden. Um dieses Problem zu umgehen, verwenden Sie VM-Zugriff für die Linux-Erweiterung, um SSH-Schlüssel nach der Bereitstellung zu implementieren, oder verwenden Sie kennwortbasierte Authentifizierung.
Sie können eine Skalierungsgruppe nicht über das Blatt VM-Skalierungsgruppen entfernen. Wählen Sie zur Problemumgehung die Skalierungsgruppe aus, die Sie entfernen möchten, und klicken Sie dann im Bereich Übersicht auf die Schaltfläche Löschen.
Bei der Erstellung von VMs in einer Verfügbarkeitsgruppe mit drei Fehlerdomänen und der Erstellung einer Instanz einer VM-Skalierungsgruppe tritt während des Updatevorgangs in einer Azure Stack-Umgebung mit vier Knoten der Fehler FabricVmPlacementErrorUnsupportedFaultDomainSize auf. Sie können einzelne VMs in einer Verfügbarkeitsgruppe mit zwei Fehlerdomänen erfolgreich durchführen. Die Erstellung der Skalierungsgruppeninstanz ist während des Updatevorgangs in einer Azure Stack-Umgebung mit vier Knoten aber immer noch nicht verfügbar.

Netzwerk

Im Azure Stack-Portal wird, wenn Sie eine statische IP-Adresse für eine IP-Konfiguration ändern, die an einen Netzwerkadapter gebunden ist, die an eine VM-Instanz angefügt ist, eine Warnmeldung angezeigt, die besagt:

The virtual machine associated with this network interface will be restarted to utilize the new private IP address....

Sie können diese Meldung gefahrlos ignorieren. Die IP-Adresse wird auch dann geändert, wenn die VM-Instanz nicht neu gestartet wird.

Wenn Sie im Portal eine eingehende Sicherheitsregel hinzufügen und als Quelle Diensttag auswählen, werden mehrere Optionen in der Liste Quelltag angezeigt, die für Azure Stack nicht verfügbar sind. Die einzigen Optionen, die in Azure Stack gültig sind, lauten folgendermaßen:
- Internet
- VirtualNetwork
- AzureLoadBalancer
Die anderen Optionen werden nicht als Quelltags in Azure Stack unterstützt. Auf ähnliche Weise wird, wenn Sie eine ausgehende Sicherheitsregel hinzufügen und als Ziel Diensttag auswählen, dieselbe Liste von Optionen für Quelltag angezeigt. Die einzigen gültigen Optionen sind dieselben wie für Quelltag, wie in der vorherigen Liste beschrieben.
Netzwerksicherheitsgruppen (NSGs) funktionieren in Azure Stack nicht auf die gleiche Weise wie in Azure weltweit. In Azure können Sie mehrere Ports für eine NSG-Regel festlegen (mit dem Portal, PowerShell und Resource Manager). In Azure Stack können Sie jedoch nicht mehrere Ports für eine NSG-Regel über das Portal festlegen. Um dieses Problem zu umgehen, verwenden Sie eine Resource Manager-Vorlage oder PowerShell, um diese zusätzlichen Regeln festzulegen.

Azure Stack unterstützt derzeit unabhängig von der Instanzgröße das Anfügen von höchstens vier Netzwerkschnittstellen (NICs) an eine VM-Instanz.
Wenn Sie im Benutzerportal versuchen, einen Back-End-Pool einem Lastenausgleich hinzuzufügen, wird für den Vorgang eine Fehlermeldung der Art Fehler beim Aktualisieren des Lastenausgleichs... angezeigt. Verwenden Sie für die Problemumgehung PowerShell, die Befehlszeilenschnittstelle (CLI) oder eine Azure Resource Manager-Vorlage, um den Back-End-Pool einer Lastenausgleichsressource zuzuordnen.
Wenn Sie im Benutzerportal versuchen, eine NAT-Regel für eingehenden Datenverkehr für einen Lastenausgleich hinzuzufügen, wird für den Vorgang eine Fehlermeldung der Art Fehler beim Aktualisieren des Lastenausgleichs... angezeigt. Verwenden Sie für die Problemumgehung PowerShell, die Befehlszeilenschnittstelle (CLI) oder eine Azure Resource Manager-Vorlage, um den Back-End-Pool einer Lastenausgleichsressource zuzuordnen.
Im Benutzerportal wird im Fenster Lastenausgleich erstellen eine Option zum Erstellen einer Lastenausgleichs-SKU vom Typ Standard angezeigt. Diese Option wird in Azure Stack nicht unterstützt.

App Service

Sie müssen den Speicherressourcenanbieter vor dem Erstellen Ihrer ersten Azure-Funktion im Abonnement registrieren.

Syslog

Die syslog-Konfiguration wird bei einem Updatezyklus nicht beibehalten, sodass der syslog-Client seine Konfiguration verliert und die syslog-Nachrichten nicht mehr weitergeleitet werden. Dieses Problem betrifft alle Versionen von Azure Stack ab der allgemeinen Verfügbarkeit des syslog-Clients (1809). Um dieses Problem zu umgehen, konfigurieren Sie den syslog-Client nach Anwenden eines Azure Stack-Updates neu.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1902 hier herunterladen.

Nächste Schritte

Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.
Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.

1901 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

Dieser Artikel beschreibt den Inhalt des Updatepakets 1901. Das Update enthält Verbesserungen, Fehlerbehebungen und neue Funktionen für diese Version von Azure Stack. In diesem Artikel werden auch bekannte Probleme in diesem Release beschrieben, und er enthält einen Link zum Herunterladen des Updates. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Nach dem 26. Februar 2019 ist die Buildnummer des Azure Stack-Updates 1901 1.1901.0.95.XX.X oder 1.1901.0.99. Hinweis:

Wichtig

Microsoft hat ein Problem festgestellt, das Kunden betreffen kann, die von 1811 (1.1811.0.101) auf 1901 aktualisieren, und hat zur Behebung des Problems ein aktualisiertes Paket für das Update 1901 veröffentlicht: Build 1.1901.0.99 (aktualisiert von 1.1901.0.95). Für Kunden, die bereits auf 1.1901.0.95 aktualisiert haben, ist keine weitere Aktion erforderlich.

Kunden mit Verbindung, die derzeit 1811 verwenden, sehen das neue Paket für 1901 (1.1901.0.99) automatisch im Administratorportal und sollten es installieren, sobald sie dazu bereit sind. Kunden ohne Verbindung können das neue Paket für 1901 wie hier beschrieben herunterladen und importieren.

Kunden mit einer Version des Updates 1901 sind nicht betroffen, wenn sie das nächste vollständige Paket oder Hotfixpaket installieren.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie das neueste Azure Stack-Hotfix für 1811 installieren, bevor Sie Azure Stack auf 1901 aktualisieren.

Azure Stack-Hotfixes gelten nur für integrierte Azure Stack-Systeme. Versuchen Sie nicht, Hotfixes auf dem ASDK zu installieren.

Azure Stack-Hotfixes

Wenn Sie bereits über 1901 verfügen und noch keine Hotfixes installiert haben, können Sie 1902 direkt installieren, ohne zuerst Hotfix 1901 zu installieren.

1811: Kein aktueller Hotfix verfügbar.
1901: KB 4500636 – Azure Stack Hotfix 1.1901.5.109

Voraussetzungen

Wichtig

Installieren Sie den neuesten Azure Stack-Hotfix für 1811 (falls vorhanden), bevor Sie auf 1901 aktualisieren. Wenn Sie bereits über 1901 verfügen und noch keine Hotfixes installiert haben, können Sie 1902 direkt installieren, ohne zuerst Hotfix 1901 zu installieren.

Bevor Sie mit der Installation dieses Updates beginnen, führen Sie Test-AzureStack mit den folgenden Parametern aus, um den Status von Azure Stack zu überprüfen und alle gefundenen operativen Probleme (einschließlich aller Warnungen und Fehler) zu beheben. Überprüfen Sie auch aktive Warnungen, und führen Sie die Behebung für Einträge durch, für die eine Aktion erforderlich ist:
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
```
Wenn Azure Stack von System Center Operations Manager verwaltet wird, müssen Sie das Management Pack für Microsoft Azure Stack auf Version 1.0.3.11 aktualisieren, bevor Sie das Update 1901 anwenden.

Neue Funktionen

Dieses Update enthält die folgenden neuen Funktionen und Verbesserungen für Azure Stack:

Mit verwalteten Images in Azure Stack können Sie ein verwaltetes Image-Objekt auf einem generalisierten virtuellen Computer (sowohl nicht verwaltet als auch verwaltet) erstellen, der fortan nur noch virtuelle Computer auf verwalteten Datenträgern erstellen kann. Weitere Informationen finden Sie unter Azure Stack Managed Disks.
AzureRm 2.4.0
- AzureRm.Profile
  Fehlerbehebung: Import-AzureRmContext zum korrekten Deserialisieren des gespeicherten Tokens.
- AzureRm.Resources
  Fehlerbehebung: Get-AzureRmResource zum Abfragen nach Ressourcentyp ohne Berücksichtigung von Groß-/Kleinschreibung.
- Azure.Storage
  Das AzureRm-Rollupmodul enthält nun die bereits veröffentlichte Version 4.5.0, welche api-version 2017-07-29 unterstützt.
- AzureRm.Storage
  Das AzureRm-Rollupmodul enthält nun die bereits veröffentlichte Version 5.0.4, welche api-version 2017-10-01 unterstützt.
- AzureRm.Compute
  Zusätzliche einfache Parametersätze in New-AzureRmVM und New-AzureRmVmss hinzugefügt, Parameter -Image unterstützt Angabe von Benutzerimages.
- AzureRm.Insights
  Das AzureRm-Rollupmodul enthält nun die bereits veröffentlichte Version 5.1.5, welche api-version 2018-01-01 für Metriken und Ressourcentypen für Metrikdefinitionen unterstützt.
AzureStack 1.7.1: Hierbei handelt es sich um ein Breaking Change-Release. Details zu Breaking Changes finden Sie unter https://aka.ms/azspshmigration171.
- Azs.Backup.Admin Module
  Breaking Change: Änderungen am zertifikatbasierten Verschlüsselungsmodus werden gesichert. Unterstützung für symmetrische Schlüssel ist veraltet.
- Azs.Fabric.Admin Module
  Get-AzsInfrastructureVolume ist veraltet. Verwenden Sie das neue Cmdlet Get-AzsVolume.
  Get-AzsStorageSystem ist veraltet. Verwenden Sie das neue Cmdlet Get-AzsStorageSubSystem.
  Get-AzsStoragePool ist veraltet. Das StorageSubSystem-Objekt enthält die Kapazitätseigenschaft.
- Azs.Compute.Admin Module
  Fehlerkorrektur - Add-AzsPlatformImage, : Get-AzsPlatformImageAnruf ConvertTo-PlatformImageObject nur im Erfolgspfad.
  BugFix - Add-AzsVmExtension, : Get-AzsVmExtensionCalling ConvertTo-VmExtensionObject only in the success path.
- Azs.Storage.Admin Module
  Fehlerbehebung: Neues Speicherplatzkontingent verwendet Standardwerte, wenn keine angegeben werden.

Die Referenz für die aktualisierten Module finden Sie in der Referenz zum Azure Stack-Modul.

Behobene Probleme

Ein Problem wurde behoben, bei dem das Portal eine Option zum Erstellen von richtlinienbasierten VPN-Gateways angezeigt hat, die in Azure Stack nicht unterstützt werden. Diese Option wurde aus dem Portal entfernt.

Ein Problem wurde behoben, bei dem nach der Aktualisierung der DNS-Einstellungen von Azure Stack-DNS zu Benutzerdefiniertes DNS die Instanzen nicht mit der neuen Einstellung aktualisiert wurden.
Ein Problem wurde behoben, bei dem bei der Bereitstellung von VMs mit Größen, die das Suffix v2 enthalten (z. B. Standard_A2_v2), das Suffix mit klein geschriebenem „v“ angegeben werden musste: Standard_A2_v2. Wie in globalen Azure-Umgebungen können Sie nun Standard_A2_V2 (groß geschriebenes „V“) verwenden.

Ein Problem wurde behoben, bei dem Portal eine Warnung ausgegeben hat, wenn Sie es zum Erstellen virtueller Computer (VMs) in einer Premium-VM-Größe (DS, Ds_v2, FS, FSv2) verwendet haben. Der virtuelle Computer wurde in einem Standardspeicherkonto erstellt. Funktionen, IOPs oder die Abrechnung waren zwar nicht beeinträchtigt, die Warnung wurde aber dennoch behoben.

Ein Problem wurde behoben, bei dem die Health Controller-Komponente die folgenden Warnungen generiert hat. Die Warnungen konnten sicher ignoriert werden:
- Warnung 1:
  - NAME: Infrastrukturrolle fehlerhaft
  - SCHWEREGRAD: Warnung
  - KOMPONENTE: Health Controller
  - BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
- Warnung 2:
  - NAME: Infrastrukturrolle fehlerhaft
  - SCHWEREGRAD: Warnung
  - KOMPONENTE: Health Controller
  - BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.

Ein Fehler wurde behoben, bei dem der unter Computekontingenttypen festgelegte Wert 0 für Managed Disks-Kontingenten dem Standardwert 2048 GiB entsprach. Der Nullwert für Kontingente wird jetzt berücksichtigt.

Ein Fehler wurde behoben, bei dem bei Verwendung der PowerShell-Cmdlets Start-AzsScaleUnitNode oder Stop-AzsScaleUnitNode zum Verwalten von Skalierungseinheiten beim ersten Versuch, die Skalierungseinheit zu starten oder zu beenden, ein Fehler auftreten konnte.

Ein Fehler wurde behoben, bei dem beim Registrieren des Ressourcenanbieters Microsoft.Insight in den Abonnementeinstellungen und beim Erstellen eines virtuellen Windows-Computers mit aktivierter Gastbetriebssystemdiagnose im Diagramm mit der CPU-Nutzung in Prozent auf der Übersichtsseite des virtuellen Computers keine Metrikdaten angezeigt wurden. Die Daten werden nun korrekt angezeigt.
Ein Fehler wurde behoben, bei dem das Ausführen des Cmdlets Get-AzureStackLog nach Ausführung von Test-AzureStack in derselben Sitzung für den privilegierten Endpunkt (PEP) einen Fehler verursacht hat. Sie können jetzt dieselbe PEP-Sitzung verwenden, in der Sie Test-AzureStack ausgeführt haben.

Ein Fehler in automatischen Sicherungen wurde behoben, bei dem der Planungsdienst unerwartet in den deaktivierten Zustand gewechselt ist.

Die Schaltfläche Gateway zurücksetzen, die einen Fehler verursacht hat, wenn sie angeklickt wurde, wurde aus dem Azure Stack-Portal entfernt. Diese Schaltfläche hat in Azure Stack keine Funktion, da Azure Stack ein mehrinstanzenfähiges Gateway anstatt dedizierte VM-Instanzen für jedes Mandanten-VPN-Gateway verwendet. Daher wurde sie entfernt, um Verwirrung zu vermeiden.

Der Link Wirksame Sicherheitsregel wurde vom Blatt Netzwerkeigenschaften entfernt, da dieses Feature in Azure Stack nicht unterstützt wird. Durch das Vorhandensein des Links entstand der Eindruck, dass dieses Feature unterstützt wird, jedoch nicht funktioniert. Um Verwirrung zu vermeiden, haben wir den Link entfernt.

Ein Fehler wurde behoben, bei dem nach dem Anwenden eines Updates von einem OEM auf Azure Stack die Benachrichtigung Update verfügbar im Azure Stack-Administratorportal nicht angezeigt wurde.

Änderungen

Sicherheitsverbesserungen in diesem Update führen zu einem Anstieg der Größe der Sicherung der Verzeichnisdienstrolle. Eine aktualisierte Anleitung zur Dimensionierung für den externen Speicherort finden Sie in der [Dokumentation zur Sicherung der Infrastruktur../azure-stack-backup-reference.md#storage-location-sizing). Diese Änderung führt dazu, dass die Sicherung wegen der größeren Menge zu übertragender Daten länger braucht bis zum Abschluss. Diese Änderung betrifft integrierte Systeme.
Ab Januar 2019, können Sie Kubernetes-Cluster in verbundenen Azure Stack-Stapeln bereitstellen, die bei Active Directory-Verbunddiensten (AD FS) registriert sind (Internetzugriff erforderlich). Befolgen Sie die Anweisungen hier, um das neue Kubernetes-Marketplace-Element herunterzuladen. Befolgen Sie die Anweisungen hier, um einen Kubernetes-Cluster bereitzustellen. Beachten Sie die neuen Parameter, mit denen angegeben wird, ob das Zielsystem bei ADD oder AD FS registriert ist. Bei AD FS sind neue Felder verfügbar, um die Parameter der Key Vault-Instanz einzugeben, in der das Bereitstellungszertifikat gespeichert ist.

Beachten Sie, dass für die Bereitstellung von Kubernetes-Clustern auch mit AD FS-Unterstützung Internetzugriff erforderlich ist.
Nach der Installation von Updates oder Hotfixes für Azure Stack können neue Funktionen eingeführt werden, die u. U. das Gewähren neuer Berechtigungen für eine oder mehrere Identitätsanwendungen erfordern. Das Gewähren dieser Berechtigungen erfordert Administratorzugriff auf das Stammverzeichnis und kann daher nicht automatisch erfolgen. Zum Beispiel:
```
$adminResourceManagerEndpoint = "https://adminmanagement.<region>.<domain>"
$homeDirectoryTenantName = "<homeDirectoryTenant>.onmicrosoft.com" # This is the primary tenant Azure Stack is registered to

Update-AzsHomeDirectoryTenant -AdminResourceManagerEndpoint $adminResourceManagerEndpoint `
   -DirectoryTenantName $homeDirectoryTenantName -Verbose
```
Es gibt eine neue Überlegung für die genaue Planung von Azure Stack-Kapazität. Mit dem Update 1901 gibt es jetzt ein Limit für die Gesamtzahl virtueller Computer, die erstellt werden können. Dieses Limit soll temporär sein, um Lösungsinstabilitäten zu vermeiden. Die Ursache des Stabilitätsproblems bei einer höheren Anzahl von VMs wird behandelt, aber es steht noch kein genauer Zeitplan für die Korrektur fest. Mit dem Update 1901 gibt es jetzt ein Limit pro Server von 60 VMs bei einem Gesamtlösungslimit von 700. Beispielsweise wäre ein Azure Stack-VM-Limit bei 8 Servern 480 (8 * 60). Bei einer Azure Stack-Lösung mit 12 bis 16 Servern wäre das Limit 700. Dieses Limit wurde unter Berücksichtigung aller Überlegungen hinsichtlich der Computekapazität eingerichtet, z. B. der Resilienzreserve und des CPU-Verhältnisses virtuell zu physisch, die ein Operator bei dem Stamp erhalten möchte. Weitere Informationen finden Sie in der neuen Version von Capacity Planner.
Wenn die VM-Skalierungsgrenze erreicht wurde, würden die folgenden Fehlercodes als Ergebnis zurückgegeben: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.
Die Compute-API-Version wurde auf 2017-12-01 erhöht.
Die Infrastruktursicherung erfordert jetzt nur ein Zertifikat mit einem öffentlichen Schlüssel (. CER) für die Verschlüsselung von Sicherungsdaten. Die Unterstützung für symmetrische Verschlüsselungsschlüssel ist ab 1901 veraltet. Wenn die Infrastruktursicherung vor der Aktualisierung auf 1901 konfiguriert wurde, werden die Verschlüsselungsschlüssel beibehalten. Es gibt mindestens zwei weitere Updates mit Unterstützung für Abwärtskompatibilität, um Sicherungseinstellungen zu aktualisieren. Weitere Informationen finden Sie unter Bewährte Methoden für den Infrastructure Backup-Dienst.

Common Vulnerabilities and Exposures (CVE, allgemeine Sicherheitslücken und Schwachstellen)

Dieses Update installiert die folgenden Sicherheitsupdates:

Weitere Informationen zu diesen Sicherheitslücken erhalten Sie durch Klicken auf die vorhergehenden Links oder im Microsoft Knowledge Base-Artikel 4480977.

Bekannte Probleme mit dem Updateprozess

Wenn Sie versuchen, ein Azure Stack-Update zu installieren, wird für den Status des Updates möglicherweise ein Fehler ausgegeben und der Zustand in PreparationFailed geändert. Der Grund dafür ist, dass der Updateressourcenanbieter (Update Resource Provider, URP) die Dateien aus dem Speichercontainer nicht ordnungsgemäß auf eine Infrastrukturfreigabe zur Verarbeitung übertragen kann. Ab Version 1901 (1.1901.0.95) können Sie dieses Problem umgehen, indem Sie erneut auf Aktualisieren (nicht auf Fortsetzen) klicken. Der URP bereinigt dann die Dateien aus dem vorherigen Versuch und startet den Download erneut.
Wenn während der Ausführung von Test-AzureStack entweder der Test AzsInfraRoleSummary oder der Test AzsPortalApiSummary fehlschlägt, werden Sie aufgefordert, Test-AzureStack mit dem Parameter -Repair auszuführen. Wenn Sie diesen Befehl ausführen, schlägt er mit folgender Fehlermeldung fehl: Unexpected exception getting Azure Stack health status. Cannot bind argument to parameter 'TestResult' because it is null.
Wenn Sie Test-AzureStack ausführen, wird eine Warnmeldung des Baseboard-Verwaltungscontrollers (BMC) angezeigt. Sie können diese Warnung problemlos ignorieren.
Während der Installation dieses Updates werden unter Umständen Warnungen mit folgender Meldung angezeigt: „Fehler: Die Vorlage für FaultType UserAccounts.New fehlt.“ Sie können diese Warnungen problemlos ignorieren. Die Warnungen werden automatisch geschlossen, nachdem die Installation dieses Updates abgeschlossen wurde.

Schritte nach dem Update

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie sowohl unter Hotfixes als auch Wartungsrichtlinie.
Rufen Sie die Verschlüsselungsschlüssel für ruhende Daten ab, und speichern Sie diese sicher außerhalb Ihrer Azure Stack-Bereitstellung. Befolgen Sie die Anleitungen zum Abrufen der Schlüssel.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Wenn Sie im Administrator- oder im Benutzerportal nach „Docker“ suchen, wird das Element nicht ordnungsgemäß zurückgegeben. Es ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Blatt mit einem Fehlerhinweis angezeigt.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Die zwei administrativen Abonnementtypen, die in Version 1804 eingeführt wurden, sollten nicht verwendet werden. Die Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Compute

Wenn Sie einen neuen virtuellen Windows-Computer erstellen, wird möglicherweise der folgende Fehler angezeigt:

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Der Fehler tritt auf, wenn Sie die Startdiagnose bei einem virtuellen Computer aktivieren, aber Ihr Startdiagnose-Speicherkonto löschen. Um dieses Problem zu umgehen, erstellen Sie das Speicherkonto erneut mit demselben Namen wie zuvor.

Die Benutzeroberfläche zum Erstellen von VM-Skalierungsgruppen bietet „CentOS 7.2-basiert“ als Option für die Bereitstellung an. Da dieses Image in Azure Stack nicht verfügbar ist, wählen Sie entweder ein anderes Betriebssystem für Ihre Bereitstellung aus, oder verwenden Sie eine Azure Resource Manager-Vorlage mit einem anderen CentOS-Image, das vor der Bereitstellung vom Operator aus dem Marketplace heruntergeladen wurde.

Nach dem Anwenden des Updates 1901 können beim Bereitstellen von virtuellen Computern mit Managed Disks die folgenden Probleme auftreten:
- Wenn das Abonnement vor dem Update 1808 erstellt wurde, schlägt die Bereitstellung eines virtuellen Computers mit Managed Disks möglicherweise mit einer internen Fehlermeldung fehl. Führen Sie die folgenden Schritte für jedes Abonnement aus, um den Fehler zu beheben:
  1. Navigieren Sie im Mandantenportal zu Abonnements, und suchen Sie nach dem Abonnement. Wählen Sie Ressourcenanbieter und dann Microsoft.Compute aus, und klicken Sie dann auf Erneut registrieren.
  2. Navigieren Sie unter dem gleichen Abonnement zu Zugriffssteuerung (IAM), und überprüfen Sie, ob AzureStack-DiskRP-Client aufgeführt ist.
- Wenn Sie eine Umgebung mit mehreren Mandanten konfiguriert haben, schlägt die Bereitstellung von virtuellen Computern in einem Abonnement, dem ein Gastverzeichnis zugeordnet ist, möglicherweise mit einer internen Fehlermeldung fehl. Zum Beheben des Fehlers führen Sie die in diesem Artikel beschriebenen Schritte aus, um alle Gastverzeichnisse neu zu konfigurieren.
Ein virtueller Ubuntu 18.04-Computer, der mit aktivierter SSH-Autorisierung erstellt wurde, lässt nicht zu, dass Sie die SSH-Schlüssel für die Anmeldung verwenden. Um dieses Problem zu umgehen, verwenden Sie VM-Zugriff für die Linux-Erweiterung, um SSH-Schlüssel nach der Bereitstellung zu implementieren, oder verwenden Sie kennwortbasierte Authentifizierung.
Sie können eine Skalierungsgruppe nicht über das Blatt VM-Skalierungsgruppen entfernen. Wählen Sie zur Problemumgehung die Skalierungsgruppe aus, die Sie entfernen möchten, und klicken Sie dann im Bereich Übersicht auf die Schaltfläche Löschen.

Netzwerk

Im Azure Stack-Portal wird, wenn Sie eine statische IP-Adresse für eine IP-Konfiguration ändern, die an einen Netzwerkadapter gebunden ist, die an eine VM-Instanz angefügt ist, eine Warnmeldung angezeigt, die besagt:

The virtual machine associated with this network interface will be restarted to utilize the new private IP address....

Sie können diese Meldung gefahrlos ignorieren. Die IP-Adresse wird auch dann geändert, wenn die VM-Instanz nicht neu gestartet wird.

Wenn Sie im Portal eine eingehende Sicherheitsregel hinzufügen und als Quelle Diensttag auswählen, werden mehrere Optionen in der Liste Quelltag angezeigt, die für Azure Stack nicht verfügbar sind. Die einzigen Optionen, die in Azure Stack gültig sind, lauten folgendermaßen:
- Internet
- VirtualNetwork
- AzureLoadBalancer
  
  Die anderen Optionen werden nicht als Quelltags in Azure Stack unterstützt. Auf ähnliche Weise wird, wenn Sie eine ausgehende Sicherheitsregel hinzufügen und als Ziel Diensttag auswählen, dieselbe Liste von Optionen für Quelltag angezeigt. Die einzigen gültigen Optionen sind dieselben wie für Quelltag, wie in der vorherigen Liste beschrieben.
Netzwerksicherheitsgruppen (NSGs) funktionieren in Azure Stack nicht auf die gleiche Weise wie in Azure weltweit. In Azure können Sie mehrere Ports für eine NSG-Regel festlegen (mit dem Portal, PowerShell und Resource Manager). In Azure Stack können Sie jedoch nicht mehrere Ports für eine NSG-Regel über das Portal festlegen. Um dieses Problem zu umgehen, verwenden Sie eine Resource Manager-Vorlage oder PowerShell, um diese zusätzlichen Regeln festzulegen.

Azure Stack unterstützt derzeit unabhängig von der Instanzgröße das Anfügen von höchstens vier Netzwerkschnittstellen (NICs) an eine VM-Instanz.

App Service

Sie müssen den Speicherressourcenanbieter vor dem Erstellen Ihrer ersten Azure-Funktion im Abonnement registrieren.

Syslog

Die syslog-Konfiguration wird bei einem Updatezyklus nicht beibehalten, sodass der syslog-Client seine Konfiguration verliert und die syslog-Nachrichten nicht mehr weitergeleitet werden. Dieses Problem betrifft alle Versionen von Azure Stack ab der allgemeinen Verfügbarkeit des syslog-Clients (1809). Um dieses Problem zu umgehen, konfigurieren Sie den syslog-Client nach Anwenden eines Azure Stack-Updates neu.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1901 hier herunterladen.

Nächste Schritte

Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.
Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.

1811 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

Dieser Artikel beschreibt den Inhalt des Updatepakets 1811. Das Updatepaket enthält Verbesserungen, Fehlerbehebungen und neue Funktionen für diese Version von Azure Stack. In diesem Artikel werden auch bekannte Probleme in diesem Release beschrieben, und er enthält einen Link, damit Sie das Update herunterladen können. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1811 ist 1.1811.0.101.

Hotfixes

Azure Stack veröffentlicht regelmäßig Hotfixes. Stellen Sie sicher, dass Sie das neueste Azure Stack-Hotfix für 1809 installieren, bevor Sie Azure Stack auf 1811 aktualisieren.

Azure Stack-Hotfixes

1809: KB 4481548 – Azure Stack Hotfix 1.1809.12.114
1811: Kein aktueller Hotfix verfügbar.

Voraussetzungen

Wichtig

Während der Installation des Updates 1811 müssen Sie sicherstellen, dass alle Instanzen des Administratorportals geschlossen sind. Das Benutzerportal kann geöffnet bleiben, aber das Administratorportal muss geschlossen sein.

Bereiten Sie Ihre Azure Stack-Bereitstellung für den Azure Stack-Erweiterungshost vor. Bereiten Sie Ihr System mithilfe der folgenden Anleitungen vor: Vorbereiten des Erweiterungshosts für Azure Stack.
Installieren Sie den neuesten Azure Stack-Hotfix für 1809, bevor Sie auf 1811 aktualisieren.
Bevor Sie mit der Installation dieses Updates beginnen, führen Sie Test-AzureStack mit den folgenden Parametern aus, um den Status von Azure Stack zu überprüfen und alle gefundenen operativen Probleme (einschließlich aller Warnungen und Fehler) zu beheben. Überprüfen Sie auch aktive Warnungen, und lösen Sie solche auf, die eine Aktion erfordern.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
```
Wenn Sie die Anforderungen für den Erweiterungshost nicht erfüllen, wird in der Ausgabe von Test-AzureStack die folgende Meldung angezeigt:

To proceed with installation of the 1811 update, you will need to import the SSL certificates required for Extension Host, which simplifies network integration and increases the security posture of Azure Stack. Refer to this link to prepare for Extension Host: https://learn.microsoft.com/azure-stack/operator/azure-stack-extension-host-prepare
Das Azure Stack-Update 1811 erfordert, dass Sie die obligatorischen Erweiterungshostzertifikate ordnungsgemäß in Ihre Azure Stack-Umgebung importiert haben. Um mit der Installation des Updates 1811 fortzufahren, müssen Sie die für den Erweiterungshost erforderlichen SSL-Zertifikate importieren. Informationen zum Importieren der Zertifikate finden Sie in diesem Abschnitt.

Wenn Sie alle Warnungen ignorieren und trotzdem die Installation des Updates 1811 durchführen, schlägt das Update in etwa 1 Stunde mit der folgenden Meldung fehl:

The required SSL certificates for the Extension Host have not been found. The Azure Stack update will halt. Refer to this link to prepare for Extension Host: https://learn.microsoft.com/azure-stack/operator/azure-stack-extension-host-prepare, then resume the update. Exception: The Certificate path does not exist: [certificate path here]

Nachdem Sie die obligatorischen Erweiterungshostzertifikate ordnungsgemäß importiert haben, können Sie das Update 1811 aus dem Administratorportal fortsetzen. Zwar rät Microsoft Azure Stack-Betreibern, während des Updateprozesses ein Wartungsfenster zu planen, doch sollte ein Fehler aufgrund der fehlenden Erweiterungshostzertifikate keine Auswirkungen auf vorhandene Workloads oder Dienste haben.

Während der Installation dieses Updates ist das Azure Stack-Benutzerportal nicht verfügbar, solange der Erweiterungshost konfiguriert wird. Die Konfiguration des Erweiterungshosts kann bis zu fünf Stunden dauern. Während dieser Zeit können Sie den Status eines Updates überprüfen oder eine nicht erfolgreiche Updateinstallation über PowerShell für Azure Stack-Administratoren oder über den privilegierten Endpunkt fortsetzen.
Wenn Azure Stack von System Center Operations Manager verwaltet wird, müssen Sie das Management Pack für Microsoft Azure Stack auf Version 1.0.3.11 aktualisieren, bevor Sie das Update 1811 anwenden.

Neue Funktionen

Dieses Update enthält die folgenden neuen Funktionen und Verbesserungen für Azure Stack:

In diesem Release ist der Erweiterungshost aktiviert. Der Erweiterungshost vereinfacht die Netzwerkintegration und verbessert die Sicherheitsausrichtung von Azure Stack.
Unterstützung für Geräteauthentifizierung mit Active Directory-Verbunddiensten (AD FS) wurde hinzugefügt, insbesondere wenn die Azure-Befehlszeilenschnittstelle verwendet wird. Weitere Informationen finden Sie unter Verwenden von API-Versionsprofilen mit der Azure CLI in Azure Stack.
Unterstützung für Dienstprinzipale, die einen geheimen Clientschlüssel mit Active Directory-Verbunddiensten (AD FS) verwenden, wurde hinzugefügt. Weitere Informationen finden Sie unter Erstellen von Dienstprinzipalen für AD FS.
Diese Version fügt Unterstützung für die folgenden Azure Storage Service-API-Versionen hinzu: 2017-07-29, 2017-11-09. Unterstützung wird auch für die folgenden Azure Storage Resource Provider-API-Versionen hinzugefügt: 2016-05-01, 2016-12-01, 2017-06-01 und 2017-10-01. Weitere Informationen finden Sie unter Azure Stack-Speicher: Unterschiede und Überlegungen.
Neue privilegierte Endpunktbefehle zum Aktualisieren und Entfernen von Dienstprinzipalen für AD FS wurden hinzugefügt. Weitere Informationen finden Sie unter Erstellen von Dienstprinzipalen für AD FS.
Neue Vorgänge für Skalierungseinheitknoten wurden hinzugefügt, die einem Azure Stack-Betreiber erlauben, einen Skalierungseinheitknoten zu starten, zu beenden und herunterzufahren. Weitere Informationen finden Sie unter Knotenaktionen für Skalierungseinheiten in Azure Stack.
Ein neues Blatt mit Regionseigenschaften wurde hinzugefügt, auf dem Registrierungsdetails der Umgebung angezeigt werden. Sie können diese Informationen anzeigen, indem Sie auf die Kachel Regionsverwaltung im Standarddashboard im Administratorportal klicken und dann Eigenschaften auswählen.
Ein neuer privilegierter Endpunktbefehl wurde hinzugefügt, der die BMC-Anmeldeinformationen mit Benutzernamen und Kennwort aktualisiert, die zur Kommunikation mit dem physischen Computer verwendet werden. Weitere Informationen finden Sie unter Aktualisieren der BMC-Anmeldeinformationen (Baseboard Management Controller, Baseboard-Verwaltungscontroller).
Die Möglichkeit, über das Hilfe- und Supportsymbol (Fragezeichen) oben rechts im Administrator- und Benutzerportal auf die Azure-Roadmap zuzugreifen, wurde hinzugefügt, ähnlich wie dies auch im Azure-Portal verfügbar ist.
Eine verbesserte Marketplace-Verwaltungserfahrung für getrennte Benutzer wurde hinzugefügt. Der Uploadprozess zum Veröffentlichen eines Marketplace-Elements in einer getrennten Umgebung wurde zu einem Schritt vereinfacht, sodass das Bild und das Marketplace-Paket nicht mehr getrennt hochgeladen werden müssen. Das hochgeladene Produkt wird auch auf dem Blatt für die Marketplace-Verwaltung angezeigt.
Dieses Release verkürzt das erforderliche Wartungsfenster für die Geheimnisrotation durch Hinzufügen der Möglichkeit, nur externe Zertifikate während der Geheimnisrotation von Azure Stack zu rotieren.
Azure Stack PowerShell wurde auf Version 1.6.0 aktualisiert. Das Update enthält Unterstützung für die neuen speicherbezogenen Funktionen in Azure Stack. Weitere Informationen finden Sie in den Anmerkungen zur Version für das Azure Stack-Verwaltungsmodul 1.6.0 im PowerShell-Katalog. Informationen zum Aktualisieren oder Installieren von Azure Stack-PowerShell finden Sie unter Installieren von PowerShell für Azure Stack.
Managed Disks ist jetzt standardmäßig aktiviert, wenn virtuelle Computer über das Azure Stack-Portal erstellt werden. Zusätzliche Schritte, die erforderlich sind, damit Managed Disks Fehler bei der VM-Erstellung vermeidet, finden Sie im Abschnitt Bekannte Probleme.
Dieses Release führt Warnungsaktionen Reparieren für Azure Stack-Bediener ein. Einige Warnungen in 1811 bieten eine Schaltfläche Reparieren in der Warnmeldung, die Sie auswählen können, um das Problem zu beheben. Weitere Informationen finden Sie unter Überwachen von Integrität und Warnungen in Azure Stack.
Updates für die Updateerfahrung in Azure Stack. Die Updateverbesserungen umfassen:
- Registerkarten, die die Updates vom Updateverlauf trennen, damit sich in Ausführung befindliche Updates und abgeschlossene Updates besser nachverfolgen lassen.
- Verbesserte Zustandsvisualisierungen im Abschnitt „Essentials“ mit neuen Symbole und Layout für aktuelle und OEM-Versionen sowie Datum der letzten Aktualisierung.
- Über den Link Anzeigen für die Spalte mit den Versionshinweisen gelangt der Benutzer direkt zu der Dokumentation, die für dieses Update spezifisch ist, anstatt zur generischen Updateseite.
- Auf der Registerkarte Updateverlauf wurden bisher Laufzeiten für jedes der Updates bestimmt sowie erweiterte Filterfunktionen.
- Azure Stack-Skalierungseinheiten, die verbunden sind, werden weiterhin automatisch mit Update verfügbar versehen, sobald sie verfügbar sind.
- Azure Stack-Skalierungseinheiten, die nicht verbunden sind, können die Updates wie vorher auch importieren.
- Beim Prozess des Herunterladens der JSON-Protokolle aus dem Portal gibt es keine Änderungen. Azure Stack-Betreibern werden sich erweiternde Schritte angezeigt, die den Fortschritt darstellen.
  
  Weitere Informationen finden Sie unter Anwenden von Updates in Azure Stack.

Behobene Probleme

Ein Problem wurde behoben, bei dem die Ansicht für die Nutzungsdaten öffentlicher IP-Adressen denselben EventDateTime-Wert für jeden Datensatz anzeigte, statt den TimeDate-Stempel, der anzeigt, wann der Datensatz jeweils erstellt wurde. Sie können jetzt diese Daten nutzen, um eine genaue Buchhaltung über die Nutzung öffentlicher IP-Adressen durchzuführen.

Ein Problem wurde behoben, das auftrat, wenn ein neuer virtueller Computer (VM) mithilfe des Azure Stack-Portals erstellt wurde. Durch die Auswahl der VM-Größe wurde in der Spalte USD/Monat die Meldung Nicht verfügbar angezeigt. Diese Spalte wird nicht mehr angezeigt. Die Anzeige der VM-Preisspalte wird in Azure Stack nicht unterstützt.

Ein Problem wurde behoben, bei dem im Administratorportal beim Zugriff auf die Details eines Benutzerabonnements nach dem Schließen des Blatts und dem Klicken auf Aktuell der Name des Benutzerabonnements nicht angezeigt wurde. Der Name des Benutzerabonnements wird jetzt angezeigt.

Ein Problem wurde behoben, bei dem sowohl im Administrator- als auch im Benutzerportal das Klicken auf die Portaleinstellungen und das Auswählen von Alle Einstellungen und private Dashboards löschen nicht wie erwartet funktionierte. Es wurde auch keine Fehlerbenachrichtigung angezeigt. Diese Option funktioniert jetzt ordnungsgemäß.

Ein Problem wurde behoben, bei dem in den Administrator- und Benutzerportalen unter Alle Dienste die Ressource DDoS Protection-Pläne nicht ordnungsgemäß aufgeführt wurde. Es ist in Azure Stack nicht verfügbar. Die Auflistung wurde entfernt.

Ein Problem wurde behoben, bei dem bei der Installation einer neuen Azure Stack-Umgebung, die Warnung, dass eine Aktivierung erforderlich ist, nicht angezeigt wurde. Sie wird nun korrekt angezeigt.

Ein Problem wurde behoben, das die Anwendung von RBAC-Richtlinien auf eine Benutzergruppe verhinderte, wenn ADFS verwendet wurde.

Ein Problem wurde behoben, bei dem Infrastruktursicherungen fehlschlugen, weil vom öffentlichen VIP-Netzwerk nicht auf den Dateiserver zugegriffen werden konnte. Diese Korrektur verschiebt den Dienst für die Infrastruktursicherung zurück in das öffentliche Infrastrukturnetzwerk. Wenn Sie den neuesten Azure Stack-Hotfix für 1809 angewendet haben, der dieses Problem behebt, nimmt das 1811-Update keine weiteren Änderungen vor.

Ein Problem wurde behoben, bei dem das Konto, mit dem Sie sich beim Administrator- oder Benutzerportal von Azure Stack angemeldet hatten, als Unbekannter Benutzer angezeigt wurde. Diese Meldung wurde angezeigt, wenn für das Konto kein Vorname oder Nachname angegeben war.

Ein Problem wurde behoben, bei dem durch die Verwendung des Portals zum Erstellen einer VM-Skalierungsgruppe das Dropdownmenü Instanzgröße bei Verwendung von Internet Explorer nicht ordnungsgemäß geladen wurde. Dieser Browser funktioniert jetzt ordnungsgemäß.

Ein Problem wurde behoben, bei dem falsch positive Warnungen generiert wurden, die anzeigten, dass eine Infrastrukturrolleninstanz nicht verfügbar ist oder dass der Knoten „Skalierungseinheit“ offline ist.

Ein Problem wurde behoben, bei dem die VM-Übersichtsseite das VM-Metrikendiagramm nicht ordnungsgemäß anzeigen kann.

Änderungen

Eine neue Methode zum Anzeigen und Bearbeiten der Kontingente in einem Plan wird in 1811 eingeführt. Weitere Informationen finden Sie unter Anzeigen eines vorhandenen Kontingents.

Sicherheitsverbesserungen in diesem Update führen zu einem Anstieg der Größe der Sicherung der Verzeichnisdienstrolle. Aktualisierte Größenanpassungsinformationen für den externen Speicherort finden Sie in der Dokumentation zur Sicherung der Infrastruktur. Diese Änderung führt dazu, dass die Sicherung wegen der größeren Menge zu übertragender Daten länger braucht bis zum Abschluss. Diese Änderung betrifft integrierte Systeme.
Das vorhandene PEP-Cmdlet zum Abrufen der BitLocker-Wiederherstellungsschlüssel wurde in 1811 von „Get-AzsCsvsRecoveryKeys“ in „Get-AzsRecoveryKeys“ umbenannt. Weitere Informationen zum Abrufen der BitLocker-Wiederherstellungsschlüssel finden Sie unter Anleitungen zum Abrufen der Schlüssel.

Common Vulnerabilities and Exposures (CVE, allgemeine Sicherheitslücken und Schwachstellen)

Dieses Update installiert die folgenden Sicherheitsupdates:

Weitere Informationen zu diesen Sicherheitslücken erhalten Sie durch Klicken auf die vorhergehenden Links oder im Microsoft Knowledge Base-Artikel 4478877.

Bekannte Probleme mit dem Updateprozess

Wenn Sie das PowerShell-Cmdlet Get-AzureStackLog nach Ausführung von Test-AzureStack in derselben Sitzung für den privilegierten Endpunkt (PEP) ausführen, kommt es für Get-AzureStackLog zu einem Fehler. Um dieses Problem zu umgehen, schließen Sie die PEP-Sitzung, in der Sie Test-AzureStack ausgeführt haben, und öffnen Sie anschließend eine neue Sitzung zur Ausführung von Get-AzureStackLog.
Stellen Sie sicher, dass während der Installation des Updates 1811 alle Instanzen des Administratorportals geschlossen sind. Das Benutzerportal kann geöffnet bleiben, aber das Administratorportal muss geschlossen sein.
Wenn während der Ausführung von Test-AzureStack entweder der Test AzsInfraRoleSummary oder der Test AzsPortalApiSummary fehlschlägt, werden Sie aufgefordert, Test-AzureStack mit dem Parameter -Repair auszuführen. Wenn Sie diesen Befehl ausführen, schlägt er mit folgender Fehlermeldung fehl: Unexpected exception getting Azure Stack health status. Cannot bind argument to parameter 'TestResult' because it is null.. Dieses Problem wird in einem zukünftigen Release behoben.
Während der Installation des Updates 1811 ist das Azure Stack-Benutzerportal nicht verfügbar, solange der Erweiterungshost konfiguriert wird. Die Konfiguration des Erweiterungshosts kann bis zu fünf Stunden dauern. Während dieser Zeit können Sie den Status eines Updates überprüfen oder eine nicht erfolgreiche Updateinstallation über PowerShell für Azure Stack-Administratoren oder über den privilegierten Endpunkt fortsetzen.
Während der Installation des Updates 1811 steht möglicherweise das Benutzerportal-Dashboard nicht zur Verfügung, und Anpassungen können verloren gehen. Sie können das Dashboard nach Abschluss des Updates auf die Standardeinstellung zurücksetzen, indem Sie die Portaleinstellungen öffnen und Standardeinstellungen wiederherstellen auswählen.
Wenn Sie Test-AzureStack ausführen, wird eine Warnmeldung des Baseboard-Verwaltungscontrollers (BMC) angezeigt. Sie können diese Warnung problemlos ignorieren.
Während der Installation dieses Updates werden unter Umständen Warnungen mit folgender Meldung angezeigt: „Fehler: Die Vorlage für FaultType UserAccounts.New fehlt.“ Sie können diese Warnungen problemlos ignorieren. Die Warnungen werden automatisch geschlossen, nachdem die Installation dieses Updates abgeschlossen wurde.
Wenn Sie ein Update Ihres OEM auf Azure Stack angewendet haben, wird die Benachrichtigung „Update verfügbar“ möglicherweise nicht im Azure Stack-Administratorportal angezeigt. Um das Microsoft-Update zu installieren, befolgen Sie die Anweisungen unter [Anwenden von Updates in Azure Stack](../azure-stack-apply-updates.md), um es manuell herunterzuladen und zu installieren.

Schritte nach dem Update

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie sowohl unter Hotfixes als auch Wartungsrichtlinie.
Rufen Sie die Verschlüsselungsschlüssel für ruhende Daten ab, und speichern Sie diese sicher außerhalb Ihrer Azure Stack-Bereitstellung. Befolgen Sie die Anleitungen zum Abrufen der Schlüssel.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Wenn Sie im Administrator- oder im Benutzerportal nach „Docker“ suchen, wird das Element nicht ordnungsgemäß zurückgegeben. Es ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Blatt mit einem Fehlerhinweis angezeigt.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Die zwei administrativen Abonnementtypen, die in Version 1804 eingeführt wurden, sollten nicht verwendet werden. Die Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Integrität und Überwachung

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:
- Warnung 1:
  - NAME: Infrastrukturrolle fehlerhaft
  - SCHWEREGRAD: Warnung
  - KOMPONENTE: Health Controller
  - BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
- Warnung 2:
  - NAME: Infrastrukturrolle fehlerhaft
  - SCHWEREGRAD: Warnung
  - KOMPONENTE: Health Controller
  - BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
  Beide Warnungen können ignoriert werden. Sie werden nach einem bestimmten Zeitraum automatisch geschlossen.

Compute

Beim Erstellen eines neuen virtuellen Windows-Computer s erfordert das Blatt Einstellungen, dass Sie einen öffentlichen eingehenden Port auswählen, um fortzufahren. In 1811 ist diese Einstellung zwar erforderlich, hat aber keine Auswirkungen. Dies liegt daran, dass die Funktion von Azure Firewall abhängig ist, die in Azure Stack nicht implementiert ist. Sie können Keine öffentlichen Eingangsports oder eine beliebige der anderen Optionen auswählen, um mit dem Erstellen des virtuellen Computers fortzufahren. Die Einstellung hat keine Auswirkungen.
Wenn Sie einen neuen virtuellen Windows-Computer erstellen, wird möglicherweise der folgende Fehler angezeigt:

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Der Fehler tritt auf, wenn Sie die Startdiagnose bei einem virtuellen Computer aktivieren, aber Ihr Startdiagnose-Speicherkonto löschen. Um dieses Problem zu umgehen, erstellen Sie das Speicherkonto erneut mit demselben Namen wie zuvor.
Beim Erstellen eines virtuellen Computers der Dv2-Serie gestatten Ihnen D11-14v2 VMs das Erstellen von 4, 8, 16 bzw. 32 Datenträgern. Im Bereich „VM erstellen“ werden jedoch 8, 16, 32 und 64 Datenträger angezeigt.
Verwendungseinträge in Azure Stack können unerwartete Großschreibung enthalten, z. B.:

{"Microsoft.Resources":{"resourceUri":"/subscriptions/<subid>/resourceGroups/ANDREWRG/providers/Microsoft.Compute/ virtualMachines/andrewVM0002","location":"twm","tags":"null","additionalInfo": "{\"ServiceType\":\"Standard_DS3_v2\",\"ImageType\":\"Windows_Server\"}"}}

In diesem Beispiel sollte der Name der Ressourcengruppe AndrewRG lauten. Sie können diese Inkonsistenz problemlos ignorieren.

Um VMs mit Größen bereitzustellen, die das Suffix v2 enthalten – z. B. Standard_A2_v2 –, geben Sie das Suffix mit klein geschriebenem „v“ an: Standard_A2_v2. Verwenden Sie nicht Standard_A2_V2 mit groß geschriebenem „V“. Dies funktioniert in der globalen Azure-Umgebung und ist eine Inkonsistenz in Azure Stack.

Bei Verwendung des Add-AzsPlatformImage-Cmdlets müssen Sie den -OsUri-Parameter als Speicherkonto-URI beim Hochladen des Datenträgers verwenden. Wenn Sie den lokalen Pfad des Datenträgers verwenden, schlägt das Cmdlet mit der folgenden Fehlermeldung fehl:

Long running operation failed with status 'Failed'

Wenn Sie das Portal zum Erstellen virtueller Computer in einer Premium-VM-Größe (DS, Ds_v2, FS, FSv2) verwenden, wird der virtuelle Computer in einem Standardspeicherkonto erstellt. Die Erstellung in einem Standardspeicherkonto wirkt sich nicht auf die Funktionalität, IOPs oder die Abrechnung aus. Sie können die folgende Warnung problemlos ignorieren:

You've chosen to use a standard disk on a size that supports premium disks. This could impact operating system performance and is not recommended. Consider using premium storage (SSD) instead.

Die Benutzeroberfläche zum Erstellen von VM-Skalierungsgruppen bietet „CentOS 7.2-basiert“ als Option für die Bereitstellung an. Da dieses Image in Azure Stack nicht verfügbar ist, wählen Sie entweder ein anderes Betriebssystem für Ihre Bereitstellung aus, oder verwenden Sie eine Azure Resource Manager-Vorlage mit einem anderen CentOS-Image, das vor der Bereitstellung vom Operator aus dem Marketplace heruntergeladen wurde.

Wenn Sie die PowerShell-Cmdlets Start-AzsScaleUnitNode oder Stop-AzsScaleunitNode verwenden, um Skalierungseinheiten zu verwalten, tritt beim ersten Versuch, die Skalierungseinheit zu starten oder zu beenden, möglicherweise ein Fehler auf. Wenn beim ersten Ausführen des Cmdlets ein Fehler auftritt, führen Sie das Cmdlet ein zweites Mal aus. Bei der zweiten Ausführung sollte der Vorgang erfolgreich abgeschlossen werden.

Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Sie eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Managed Disks erstellt zwei neue Computekontingenttypen zur Begrenzung der maximalen Kapazität von verwalteten Datenträgern, die bereitgestellt werden können. Standardmäßig werden für jeden Kontingenttyp von verwalteten Datenträgern 2.048 GiB zugeordnet. Allerdings können die folgenden Probleme auftreten:
- Bei Kontingenten, die vor dem Update 1808 erstellt wurden, werden im Administratorportal für das „Managed Disks“-Kontingent 0 Werte angezeigt, obwohl 2.048 GiB zugeordnet wurden. Sie können den Wert auf der Grundlage Ihrer tatsächlichen Anforderungen erhöhen oder verringern. Dann setzt der neu festgelegte Kontingentwert den Standardwert 2.048 GiB außer Kraft.
- Wenn Sie den Kontingentwert auf „0“ aktualisieren, entspricht dies dem Standardwert 2.048 GiB. Als Problemumgehung können Sie den Kontingentwert auf „1“ festlegen.

Nach dem Anwenden des Updates 1811 können beim Bereitstellen von virtuellen Computern mit Managed Disks die folgenden Probleme auftreten:
- Wenn das Abonnement vor dem Update 1808 erstellt wurde, schlägt die Bereitstellung eines virtuellen Computers mit Managed Disks möglicherweise mit einer internen Fehlermeldung fehl. Führen Sie die folgenden Schritte für jedes Abonnement aus, um den Fehler zu beheben:
  1. Navigieren Sie im Mandantenportal zu Abonnements, und suchen Sie nach dem Abonnement. Wählen Sie Ressourcenanbieter und dann Microsoft.Compute aus, und klicken Sie dann auf Erneut registrieren.
  2. Navigieren Sie unter dem gleichen Abonnement zu Zugriffssteuerung (IAM), und überprüfen Sie, ob die Rolle AzureStack-DiskRP-Client aufgeführt wird.
- Wenn Sie eine Umgebung mit mehreren Mandanten konfiguriert haben, schlägt die Bereitstellung von virtuellen Computern in einem Abonnement, dem ein Gastverzeichnis zugeordnet ist, möglicherweise mit einer internen Fehlermeldung fehl. Zum Beheben des Fehlers führen Sie die in diesem Artikel beschriebenen Schritte aus, um alle Gastverzeichnisse neu zu konfigurieren.
Ein virtueller Ubuntu 18.04-Computer, der mit aktivierter SSH-Autorisierung erstellt wurde, lässt nicht zu, dass Sie die SSH-Schlüssel für die Anmeldung verwenden. Um dieses Problem zu umgehen, verwenden Sie VM-Zugriff für die Linux-Erweiterung, um SSH-Schlüssel nach der Bereitstellung zu implementieren, oder verwenden Sie kennwortbasierte Authentifizierung.

Netzwerk

Wenn Sie unter Netzwerk auf VPN Gateway erstellen klicken, um eine VPN-Verbindung einzurichten, wird als VPN-Typ Richtlinienbasiert aufgeführt. Wählen Sie diese Option nicht aus. Nur die Option Routenbasiert wird in Azure Stack unterstützt.

Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse zurückgewiesen.

In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.

Während der Geheimnisrotation von Azure Stack sind öffentliche IP-Adressen für einen Zeitraum von zwei bis fünf Minuten nicht erreichbar.

In Szenarien, in denen der Mandant über einen S2S-VPN-Tunnel auf VMs zugreift, kann es passieren, dass bei Verbindungsversuchen Fehler auftreten, wenn das lokale Subnetz dem lokalen Netzwerkgateway erst nach der Erstellung des Gateways hinzugefügt wurde.
Im Azure Stack-Portal wird, wenn Sie eine statische IP-Adresse für eine IP-Konfiguration ändern, die an einen Netzwerkadapter gebunden ist, die an eine VM-Instanz angefügt ist, eine Warnmeldung angezeigt, die besagt:

The virtual machine associated with this network interface will be restarted to utilize the new private IP address....

Sie können diese Meldung gefahrlos ignorieren. Die IP-Adresse wird auch dann geändert, wenn die VM-Instanz nicht neu gestartet wird.
Im Portal auf dem Blatt Netzwerkeigenschaften befindet sich ein Link für Wirksame Sicherheitsregeln für jeden Netzwerkadapter. Wenn Sie diesen Link auswählen, wird ein neues Blatt geöffnet, auf dem die Fehlermeldung Not Found. angezeigt wird. Dieser Fehler tritt auf, weil Azure Stack noch keine Wirksamen Sicherheitsregeln unterstützt.
Wenn Sie im Portal eine eingehende Sicherheitsregel hinzufügen und als Quelle Diensttag auswählen, werden mehrere Optionen in der Liste Quelltag angezeigt, die für Azure Stack nicht verfügbar sind. Die einzigen Optionen, die in Azure Stack gültig sind, lauten folgendermaßen:
- Internet
- VirtualNetwork
- AzureLoadBalancer
  
  Die anderen Optionen werden nicht als Quelltags in Azure Stack unterstützt. Auf ähnliche Weise wird, wenn Sie eine ausgehende Sicherheitsregel hinzufügen und als Ziel Diensttag auswählen, dieselbe Liste von Optionen für Quelltag angezeigt. Die einzigen gültigen Optionen sind dieselben wie für Quelltag, wie in der vorherigen Liste beschrieben.
Das PowerShell-Cmdlet New-AzureRmIpSecPolicy unterstützt keine Einstellung DHGroup24 für den Parameter DHGroup.
Netzwerksicherheitsgruppen (NSGs) funktionieren in Azure Stack nicht auf die gleiche Weise wie in Azure weltweit. In Azure können Sie mehrere Ports für eine NSG-Regel festlegen (mit dem Portal, PowerShell und Resource Manager). In Azure Stack können Sie nicht mehrere Ports für eine NSG-Regel über das Portal festlegen. Um dieses Problem zu umgehen, verwenden Sie eine Resource Manager-Vorlage, um diese zusätzlichen Regeln festzulegen.

Infrastructure Backup

Nach dem Aktivieren automatischer Sicherungen wechselt der Planungsdienst unerwartet in den deaktivierten Zustand. Der Sicherungscontrollerdienst erkennt, dass automatische Sicherungen deaktiviert sind und löst eine Warnung im Administratorportal aus. Diese Warnung wird erwartet, wenn automatische Sicherungen deaktiviert sind.
- Ursache: Dieses Problem ist auf einen Fehler im Dienst zurückzuführen, der zu Einem Verlust der Planerkonfiguration führt. Dieser Fehler ändert weder den Speicherort noch den Benutzernamen, das Kennwort oder den Verschlüsselungsschlüssel.
- Behebung: Um dieses Problem zu beheben, öffnen Sie das Blatt mit den Einstellungen des Sicherungscontrollers im Ressourcenanbieter der Infrastruktursicherung, und wählen Sie " Automatische Sicherungen aktivieren" aus. Stellen Sie sicher, dass Sie die gewünschte Häufigkeit und den Aufbewahrungszeitraum festlegen.
- Vorkommen: Niedrig

App Service

Sie müssen den Speicherressourcenanbieter vor dem Erstellen Ihrer ersten Azure-Funktion im Abonnement registrieren.

Syslog

Die syslog-Konfiguration wird bei einem Updatezyklus nicht beibehalten, sodass der syslog-Client seine Konfiguration verliert und die syslog-Nachrichten nicht mehr weitergeleitet werden. Dieses Problem betrifft alle Versionen von Azure Stack ab der allgemeinen Verfügbarkeit des syslog-Clients (1809). Um dieses Problem zu umgehen, konfigurieren Sie den syslog-Client nach Anwenden eines Azure Stack-Updates neu.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1811 hier herunterladen.

Nächste Schritte

Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.
Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

1809 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

Dieser Artikel beschreibt den Inhalt des Updatepakets 1809. Das Updatepaket enthält Verbesserungen, Fehlerbehebungen und bekannten Probleme für diese Version von Azure Stack. Dieser Artikel enthält auch einen Link, damit Sie das Update herunterladen können. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1809 ist 1.1809.0.90.

Neue Funktionen

Dieses Update enthält die folgenden Verbesserungen für Azure Stack:

Mit diesem Release unterstützen integrierte Azure Stack-Systeme Konfigurationen mit 4 bis 16 Knoten. Sie können den Azure Stack Capacity Planner verwenden, um Unterstützung bei der Planung der Azure Stack-Kapazität und -Konfiguration zu erhalten.

Azure Stack-Syslog-Client (Allgemeine Verfügbarkeit): Dieser Client ermöglicht die Weiterleitung von Überwachungen, Warnungen und Sicherheitsprotokollen der Azure Stack-Infrastruktur an einen Syslog-Server oder an SIEM-Software (Security Information and Event Management) außerhalb von Azure Stack. Der Syslog-Client unterstützt jetzt die Angabe des Ports, an dem der Syslog-Server lauscht.

Mit diesem Release ist der Syslog-Client allgemein verfügbar und kann in Produktionsumgebungen verwendet werden.

Weitere Informationen finden Sie unter Azure Stack-Syslog-Weiterleitung.
Sie können die Registrierungsressource in Azure zwischen Ressourcengruppen verschieben, ohne sich erneut registrieren zu müssen. Cloudlösungsanbieter (Cloud Solution Providers, CSPs) können ebenfalls die Registrierungsressource zwischen Abonnements verschieben, sofern sowohl das alte als auch das neue Abonnement der gleichen CSP-Partner-ID zugeordnet sind. Dies wirkt sich nicht auf die vorhandenen Mandantenzuordnungen des Kunden aus.
Unterstützung für das Zuweisen mehrerer IP-Adressen pro Netzwerkschnittstelle wurde hinzugefügt. Ausführlichere Informationen finden Sie unter Zuweisen von mehreren IP-Adressen zu virtuellen Computern mithilfe von PowerShell.

Behobene Probleme

Im Portal sind die Angaben zur freien/verwendeten Kapazität im Speicherdiagramm jetzt exakt. Sie können jetzt zuverlässiger prognostizieren, wie viele VMs Sie erstellen können.

Folgendes Problem wurde behoben: Beim Erstellen von virtuellen Computern im Azure Stack-Benutzerportal zeigte das Portal eine falsche Anzahl von Datenträgern an, die an eine VM der Serie DS angefügt werden können. VMs der Serie DS können so viele Datenträger wie bei der Azure-Konfiguration aufnehmen.
Die folgenden Probleme mit verwalteten Datenträgern wurden in Version 1809 und im Azure Stack-Hotfix 1.1808.9.117 für Version 1808 behoben:
- Beim Anfügen von SSD-Datenträgern an virtuelle Computer mit verwalteten Datenträgern einer Premium-Größe (DS, DSv2, Fs, Fs_V2) trat folgender Fehler auf: Fehler beim Aktualisieren der Datenträger für den virtuellen Computer „vmname“. Fehler: Der angeforderte Vorgang kann nicht ausgeführt werden, weil der Speicherkontotyp „Premium_LRS“ für die VM-Größe „Standard_DS/Ds_V2/FS/Fs_v2“ nicht unterstützt wird.
- Beim Erstellen eines verwalteten Datenträgers VM mithilfe von createOption: Attach tritt der folgende Fehler auf: Fehler beim Vorgang mit langer Ausführungszeit mit dem Status „Fehler“. Zusätzliche Information: „Interner Ausführungsfehler“ ErrorCode: InternalExecutionError ErrorMessage: Interner Ausführungsfehler.
  
  Dieses Problem wurde jetzt behoben.
Ein Problem mit öffentlichen IP-Adressen, die mithilfe der dynamischen Zuordnungsmethode bereitgestellt wurden und nach der Ausgabe eines Befehls zum Beenden und Aufheben der Zuordnung nicht unbedingt beibehalten werden, wurde behoben. Sie werden jetzt beibehalten.
Wenn eine VM vor Version 1808 beendet und ihre Zuordnung aufgehoben wurde, konnte sie nach dem Update auf 1808 nicht neu zugeordnet werden. Dieses Problem wurde in Version 1809 behoben. Instanzen, die sich in diesem Zustand befanden und nicht gestartet werden konnten, können in Version 1809 mit dieser Lösung gestartet werden. Die Lösung verhindert außerdem, dass dieses Problem erneut auftritt.

Änderungen

Der Infrastruktursicherungsdienst wird aus dem öffentlichen Infrastrukturnetzwerk in das öffentliche VIP-Netzwerk verschoben. Kunden müssen sicherstellen, dass der Dienst aus dem öffentlichen VIP-Netzwerk auf den Sicherungsspeicherort zugreifen kann.

Wichtig

Sollten Sie über eine Firewall verfügen, die aus dem öffentlichen VIP-Netzwerk keine Verbindungen mit dem Dateiserver zulässt, führt diese Änderung dazu, dass bei Infrastruktursicherungen der Fehler 53 („Der Netzwerkpfad wurde nicht gefunden.“) auftritt. Hierbei handelt es sich um einen Breaking Change ohne sinnvolle Problemumgehung. Aufgrund von Kundenfeedback wird die Änderung von Microsoft per Hotfix zurückgesetzt. Weitere Informationen zu verfügbaren Hotfixes für 1809 finden Sie im Abschnitt mit den Schritten nach dem Updatevorgang. Wenden Sie den bereitgestellten Hotfix nach dem Update auf 1809 nur an, wenn das öffentliche VIP-Netzwerk aufgrund Ihrer Netzwerkrichtlinien nicht auf Infrastrukturressourcen zugreifen kann. In 1811 wird diese Änderung auf alle Systeme angewendet. Wenn Sie den Hotfix in 1809 angewendet haben, ist keine weitere Aktion erforderlich.

Common Vulnerabilities and Exposures (CVE, allgemeine Sicherheitslücken und Schwachstellen)

Dieses Update installiert die folgenden Sicherheitsupdates:

Weitere Informationen zu diesen Sicherheitslücken erhalten Sie durch Klicken auf die Links oben oder in den Microsoft Knowledge Base-Artikeln 4457131 und 4462917.

Voraussetzungen

Installieren Sie das neueste Azure Stack-Hotfix für 1808, bevor Sie 1809 anwenden. Weitere Informationen finden Sie hier: KB 4481066 – Azure Stack-Hotfix: Azure Stack-Hotfix 1.1808.9.117. Zwar empfiehlt Microsoft den neuesten verfügbaren Hotfix, doch ist die mindestens erforderliche Version für die Installation von 1809 „1.1808.5.110“.
Bevor Sie mit der Installation dieses Updates beginnen, führen Sie Test-AzureStack mit den folgenden Parametern aus, um den Status von Azure Stack zu überprüfen und alle gefundenen operativen Probleme (einschließlich aller Warnungen und Fehler) zu beheben. Überprüfen Sie auch aktive Warnungen, und lösen Sie solche auf, die eine Aktion erfordern.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
```
Wenn Azure Stack von System Center Operations Manager verwaltet wird, müssen Sie das Management Pack für Microsoft Azure Stack auf Version 1.0.3.11 aktualisieren, bevor Sie das Update 1809 anwenden.

Bekannte Probleme mit dem Updateprozess

Wenn Sie Test-AzureStack nach dem Update 1809 ausführen, wird eine Warnmeldung des Baseboard-Verwaltungscontrollers angezeigt. Sie können diese Warnung problemlos ignorieren.

Während der Installation dieses Updates werden unter Umständen Warnungen mit folgender Meldung angezeigt: Fehler: Die Vorlage für FaultType UserAccounts.New fehlt. Sie können diese Warnungen problemlos ignorieren. Diese Warnungen werden automatisch nach der Installation dieses Updates geschlossen.
Versuchen Sie nicht, während der Installation dieses Updates virtuelle Computer zu erstellen. Weitere Informationen zum Verwalten von Updates finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Wenn Sie ein Update Ihres OEM auf Azure Stack angewendet haben, wird die Benachrichtigung Update verfügbar im Azure Stack-Verwaltungsportal möglicherweise nicht angezeigt. Um das Microsoft-Update zu installieren, befolgen Sie die Anweisungen unter Anwenden von Updates in Azure Stack, um es manuell herunterzuladen und zu installieren.

Schritte nach dem Update

Wichtig

Bereiten Sie Ihre Azure Stack-Bereitstellung für den Erweiterungshost vor, der mit dem nächsten Updatepaket aktiviert wird. Bereiten Sie Ihr System mithilfe der folgenden Anleitung vor: Vorbereiten auf den Erweiterungshost für Azure Stack.

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln sowie in unserer Wartungsrichtlinie.

KB 4481548 – Azure Stack-Hotfix: Azure Stack-Hotfix 1.1809.12.114

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Die technische Dokumentation für Azure Stack konzentriert sich auf das neueste Release. Aufgrund von Portaländerungen zwischen den Releases kann das, was bei der Verwendung der Azure Stack-Portale angezeigt wird, von dem abweichen, was in der Dokumentation angezeigt wird.

Im Administratorportal wird beim Zugriff auf die Details eines Benutzerabonnements nach dem Schließen des Blatts und dem Klicken auf Aktuell der Name des Benutzerabonnements nicht angezeigt.

Sowohl im Administrator- als auch im Benutzerportal funktioniert das Klicken auf die Portaleinstellungen und das Auswählen von Alle Einstellungen und private Dashboards löschen nicht wie erwartet. Es wird eine Fehlerbenachrichtigung angezeigt.

In den Administrator- und Benutzerportalen wird unter Alle Dienste die Ressource DDoS Protection-Pläne nicht ordnungsgemäß aufgeführt. Es ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Fehler angezeigt, der besagt, dass das Portal das Marketplace-Element nicht erstellen konnte.

Wenn Sie im Administrator- oder im Benutzerportal nach „Docker“ suchen, wird das Element nicht ordnungsgemäß zurückgegeben. Es ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Blatt mit einem Fehlerhinweis angezeigt.

Das Konto, mit dem Sie sich beim Administrator- oder Benutzerportal von Azure Stack anmelden, wird als Unbekannter Benutzer angezeigt. Diese Meldung wird angezeigt, wenn für das Konto kein Vorname oder Nachname angegeben wurde. Um dieses Problem zu umgehen, bearbeiten Sie das Benutzerkonto so, dass der Vor- oder Nachname angegeben wird. Sie müssen sich dann abmelden und erneut am Portal anmelden.

Wenn Sie das Portal verwenden, um eine VM-Skalierungsgruppe zu erstellen, wird das Dropdownmenü Instanzgröße bei Verwendung von Internet Explorer nicht richtig geladen. Um dieses Problem zu umgehen, nutzen Sie einen anderen Browser beim Verwenden des Portals zum Erstellen einer VMSS.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Bei der Installation einer neuen Azure Stack-Umgebung, die diese Version ausführt, wird die Warnung, dass eine Aktivierung erforderlich ist, möglicherweise nicht angezeigt. Die Aktivierung ist erforderlich, damit Sie die Marketplace-Syndikation verwenden können.

Die zwei administrativen Abonnementtypen, die in Version 1804 eingeführt wurden, sollten nicht verwendet werden. Die Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Integrität und Überwachung

Die folgenden Warnungen werden in Ihrem Azure Stack-System möglicherweise wiederholt angezeigt und dann nicht mehr angezeigt:
- Infrastrukturrolleninstanz nicht verfügbar
- Skalierungseinheitknoten ist offline.
Führen Sie das Cmdlet Test-AzureStack aus, um die Integrität der Infrastrukturrolleninstanzen und Skalierungseinheitenknoten zu überprüfen. Wenn von Test-AzureStack keine Probleme gefunden werden, können Sie diese Warnungen ignorieren. Wenn ein Problem erkannt wird, können Sie versuchen, die Infrastrukturrolleninstanz oder den Knoten über das Verwaltungsportal oder PowerShell zu starten.

Dieses Problem wurde im aktuellen Hotfixrelease 1809 behoben. Sie sollten diesen Hotfix daher unbedingt installieren, falls das Problem auftritt.

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:

Warnung 1:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Warnung 2:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Beide Alarme können ignoriert werden und werden nach einer gewissen Zeit automatisch geschlossen.

Möglicherweise wird eine Warnung für die Storage-Komponente mit den folgenden Details angezeigt:
- NAME: Interner Kommunikationsfehler des Storage-Diensts
- SCHWEREGRAD: Kritisch
- KOMPONENTE: Storage
- BESCHREIBUNG: Beim Senden von Anforderungen an die folgenden Knoten ist ein interner Kommunikationsfehler des Storage-Diensts aufgetreten.
  
  Die Warnung kann ignoriert werden, Sie müssen sie jedoch manuell schließen.

Wenn Sie als Azure Stack-Operator eine Fehlermeldung über unzureichenden Speicher erhalten und virtuelle Computer der Mandanten nicht mit einem Fabric-VM-Erstellungsfehler bereitgestellt werden können, verfügt der Azure Stack-Stempel möglicherweise nicht über genügend Arbeitsspeicher. Mit dem Azure Stack Capacity Planner können Sie die verfügbare Kapazität für Ihre Workloads besser bestimmen.

Compute

Beim Erstellen eines virtuellen Computers der Dv2-Serie gestatten Ihnen D11-14v2 VMs das Erstellen von 4, 8, 16 bzw. 32 Datenträgern. Im Bereich „VM erstellen“ werden jedoch 8, 16, 32 und 64 Datenträger angezeigt.

Um VMs mit Größen bereitzustellen, die das Suffix v2 enthalten – z.B. Standard_A2_v2 –, geben Sie das Suffix mit klein geschriebenem „v“ an: Standard_A2_v2. Verwenden Sie nicht Standard_A2_V2 mit groß geschriebenem „V“. Dies funktioniert in der globalen Azure-Umgebung und ist eine Inkonsistenz in Azure Stack.

Wenn Sie einen neuen virtuellen Computer (VM) über das Azure Stack-Portal erstellen und die VM-Größe auswählen, wird die Spalte „USD/Monat“ mit der Meldung Nicht verfügbar angezeigt. Diese Spalte sollte nicht angezeigt werden. Die Anzeige der VM-Preisspalte wird in Azure Stack nicht unterstützt.

Bei Verwendung des Add-AzsPlatformImage-Cmdlets müssen Sie den -OsUri-Parameter als Speicherkonto-URI beim Hochladen des Datenträgers verwenden. Wenn Sie den lokalen Pfad des Datenträgers verwenden, tritt bei dem Cmdlet folgender Fehler auf: Fehler beim Vorgang mit langer Ausführungszeit mit dem Status „Fehler“.

Wenn Sie das Portal zum Erstellen virtueller Computer in einer Premium-VM-Größe (DS, Ds_v2, FS, FSv2) verwenden, wird der virtuelle Computer in einem Standardspeicherkonto erstellt. Die Erstellung in einem Standardspeicherkonto wirkt sich nicht auf die Funktionalität, IOPs oder die Abrechnung aus.

Sie können die Warnung, die besagt, sicher ignorieren: Sie haben sich entschieden, einen Standarddatenträger auf einer Größe zu verwenden, die Premium-Datenträger unterstützt. Dies kann sich auf die Leistung des Betriebssystems auswirken und wird nicht empfohlen. Erwägen Sie stattdessen die Verwendung von Premium-Speicher (SSD).

Die Benutzeroberfläche zum Erstellen von VM-Skalierungsgruppen bietet „CentOS 7.2-basiert“ als Option für die Bereitstellung an. Da dieses Image in Azure Stack nicht verfügbar ist, wählen Sie entweder ein anderes Betriebssystem für Ihre Bereitstellung aus, oder verwenden Sie eine Azure Resource Manager-Vorlage mit einem anderen CentOS-Image, das vor der Bereitstellung vom Operator aus dem Marketplace heruntergeladen wurde.

Wenn Sie die PowerShell-Cmdlets Start-AzsScaleUnitNode oder Stop-AzsScaleunitNode verwenden, um Skalierungseinheiten zu verwalten, tritt beim ersten Versuch, die Skalierungseinheit zu starten oder zu beenden, möglicherweise ein Fehler auf. Wenn beim ersten Ausführen des Cmdlets ein Fehler auftritt, führen Sie das Cmdlet ein zweites Mal aus. Bei der zweiten Ausführung sollte der Vorgang erfolgreich sein.

Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Benutzer eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Wenn Sie den Microsoft.Insight-Ressourcenanbieter in den Abonnementeinstellungen registrieren und einen virtuellen Windows-Computer mit aktivierter Gastbetriebssystemdiagnose erstellen, werden im Diagramm mit der CPU-Nutzung in Prozent auf der Übersichtsseite des virtuellen Computers keine Metrikdaten angezeigt.

Navigieren Sie zum Anzeigen von Metrikdaten (etwa das Diagramm „CPU-Prozentsatz“ für den virtuellen Computer) zum Fenster Metriken, und zeigen Sie alle unterstützten Metriken für Windows-VM-Gäste an.

Managed Disks erstellt zwei neue Computekontingenttypen zur Begrenzung der maximalen Kapazität von verwalteten Datenträgern, die bereitgestellt werden können. Standardmäßig werden für jeden Kontingenttyp von verwalteten Datenträgern 2.048 GiB zugeordnet. Allerdings können die folgenden Probleme auftreten:
- Bei Kontingenten, die vor dem Update 1808 erstellt wurden, werden im Administratorportal für das „Managed Disks“-Kontingent 0 Werte angezeigt, obwohl 2.048 GiB zugeordnet wurden. Sie können den Wert auf der Grundlage Ihrer tatsächlichen Anforderungen erhöhen oder verringern. Dann setzt der neu festgelegte Kontingentwert den Standardwert 2.048 GiB außer Kraft.
- Wenn Sie den Kontingentwert auf „0“ aktualisieren, entspricht dies dem Standardwert 2.048 GiB. Als Problemumgehung können Sie den Kontingentwert auf „1“ festlegen.

Nach dem Anwenden des Updates 1809 können beim Bereitstellen von virtuellen Computern mit Managed Disks die folgenden Probleme auftreten:
- Wenn das Abonnement vor dem Update 1808 erstellt wurde, schlägt die Bereitstellung eines virtuellen Computers mit Managed Disks möglicherweise mit einer internen Fehlermeldung fehl. Führen Sie die folgenden Schritte für jedes Abonnement aus, um den Fehler zu beheben:
  1. Navigieren Sie im Mandantenportal zu Abonnements, und suchen Sie nach dem Abonnement. Klicken Sie auf Ressourcenanbieter, klicken Sie dann auf Microsoft.Compute, und klicken Sie anschließend auf Erneut registrieren.
  2. Navigieren Sie unter dem gleichen Abonnement zu Zugriffssteuerung (IAM), und überprüfen Sie, ob die Rolle AzureStack-DiskRP-Client aufgeführt wird.
- Wenn Sie eine Umgebung mit mehreren Mandanten konfiguriert haben, schlägt die Bereitstellung von virtuellen Computern in einem Abonnement, dem ein Gastverzeichnis zugeordnet ist, möglicherweise mit einer internen Fehlermeldung fehl. Zum Beheben des Fehlers führen Sie die in diesem Artikel beschriebenen Schritte aus, um alle Gastverzeichnisse neu zu konfigurieren.
Ein virtueller Ubuntu 18.04-Computer, der mit aktivierter SSH-Autorisierung erstellt wurde, lässt nicht zu, dass Sie die SSH-Schlüssel für die Anmeldung verwenden. Um dieses Problem zu umgehen, verwenden Sie VM-Zugriff für die Linux-Erweiterung, um SSH-Schlüssel nach der Bereitstellung zu implementieren, oder verwenden Sie kennwortbasierte Authentifizierung.

Netzwerk

Wenn Sie unter Netzwerk auf VPN Gateway erstellen klicken, um eine VPN-Verbindung einzurichten, wird als VPN-Typ Richtlinienbasiert aufgeführt. Wählen Sie diese Option nicht aus. Nur die Option Routenbasiert wird in Azure Stack unterstützt.

Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse blockiert.

In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.

Während der Geheimnisrotation von Azure Stack sind öffentliche IP-Adressen für einen Zeitraum von zwei bis fünf Minuten nicht erreichbar.

In Szenarien, in denen der Mandant über einen S2S-VPN-Tunnel auf seine VMs zugreift, kann es passieren, dass bei Verbindungsversuchen Fehler auftreten, wenn das lokale Subnetz dem lokalen Netzwerkgateway erst nach der Erstellung des Gateways hinzugefügt wurde.

App Service

Benutzer müssen den Speicherressourcenanbieter vor dem Erstellen seiner ersten Azure-Funktion im Abonnement registrieren.

Verbrauch

Die Ansicht für die Nutzungsdaten öffentlicher IP-Adressen zeigt den gleichen EventDateTime-Wert für jeden Datensatz an statt des TimeDate-Stempels, der anzeigt, wann der Datensatz jeweils erstellt wurde. Derzeit können Sie diese Daten nicht nutzen, um die Nutzung öffentlicher IP-Adressen exakt nachzuhalten.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1809 hier herunterladen.

Nächste Schritte

Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.
Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

1808 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

Dieser Artikel beschreibt den Inhalt des Updatepakets 1808. Das Updatepaket enthält Verbesserungen, Fehlerbehebungen und bekannten Probleme für diese Version von Azure Stack. Dieser Artikel enthält auch einen Link, damit Sie das Update herunterladen können. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1808 ist 1.1808.0.97.

Neue Funktionen

Dieses Update enthält die folgenden Verbesserungen für Azure Stack.

Alle Azure Stack-Umgebungen verwenden nun das Zeitzonenformat Koordinierte Weltzeit (UTC). Alle Protokolldaten und zugehörigen Informationen werden nun im UTC-Format angezeigt. Wenn Sie ein Update aus einer früheren Version ausführen, die nicht mit UTC installiert wurde, wird Ihre Umgebung auf UTC aktualisiert.

Managed Disks werden unterstützt. Sie können jetzt Managed Disks in virtuellen Azure Stack-Computern und VM-Skalierungsgruppen verwenden. Weitere Informationen finden Sie unter Azure Stack Managed Disks: Unterschiede und Überlegungen.

Azure Monitor. Wie in Azure stellt Azure Monitor in Azure Stack grundlegende Infrastrukturmetriken und Protokolle für die meisten Dienste bereit. Weitere Informationen finden Sie unter Azure Monitor in Azure Stack.

Vorbereiten auf den Erweiterungshost. Sie können Azure Stack mit dem Erweiterungshost sicherer machen, indem Sie die Anzahl der erforderlichen TCP/IP-Ports reduzieren. Mit dem Update 1808 können Sie sich vorbereiten und Azure Stack für den Erweiterungshost bereit machen. Weitere Informationen finden Sie unter Vorbereiten auf den Erweiterungshost für Azure Stack.

Katalogelemente für Virtual Machine Scale Sets sind jetzt integriert. Das Virtual Machine Scale Set-Katalogelement steht jetzt in den Benutzer- und Administratorportalen zur Verfügung, ohne dass es heruntergeladen werden muss. Wenn Sie ein Upgrade auf 1808 ausführen, steht es nach Abschluss des Upgrades zur Verfügung.

Skalierung der VM-Skalierungsgruppe. Sie können das Portal verwenden, um eine VM-Skalierungsgruppe zu skalieren (VMSS, Virtual Machine Scale Set).

Unterstützung für benutzerdefinierte IPsec-/IKE-Richtlinienkonfigurationen für VPN-Gateways in Azure Stack.

Kubernetes-Marketplace-Element. Sie können nun Kubernetes-Cluster mithilfe des Kubernetes-Marketplace-Elements bereitstellen. Benutzer können das Kubernetes-Element auswählen und einige Parameter eingeben, um einen Kubernetes-Cluster in Azure Stack bereitzustellen. Der Zweck der Vorlagen ist es, es den Benutzern einfach zu machen, in wenigen Schritten dev/test-Kubernetes-Bereitstellungen einzurichten.

Blockchainvorlagen. Sie können jetzt Ethereum-Konsortiumbereitstellungen in Azure Stack ausführen. Sie finden drei neue Vorlagen in den Azure Stack-Schnellstartvorlagen. Sie ermöglichen es dem Benutzer, ein Ethereum-Konsortiumnetzwerk mit mehreren Elementen mit minimalen Azure- und Ethereum-Kenntnissen bereitzustellen und zu konfigurieren. Der Zweck der Vorlagen ist es, es den Benutzern einfach zu machen, in wenigen Schritten dev/test-Blockchainbereitstellungen einzurichten.

Das API-Versionsprofil 2017-03-09-profile wurde in 2018-03-01-hybrid aktualisiert. API-Profile geben den Azure-Ressourcenanbieter und die API-Version für Azure-REST-Endpunkte an. Weitere Informationen zu Profilen finden Sie unter Verwalten von API-Versionsprofilen in Azure Stack.

Behobene Probleme

Wir haben das Problem bei der Erstellung einer Verfügbarkeitsgruppe im Portal behoben, das dazu führte, dass die Gruppe eine Fehlerdomäne und eine Updatedomäne von 1 hatte.

Die Skalierungseinstellungen für Skalierungsgruppen für virtuelle Computer sind nun im Portal verfügbar.

Das Problem, das verhindert hat, dass einige VM-Größen der F-Serie bei der Auswahl einer VM-Größe für die Bereitstellung nicht angezeigt wurden, ist nun behoben.

Verbesserungen für die Leistung beim Erstellen von virtuellen Computern und optimierte Verwendung des zugrunde liegenden Speichers.
Es wurden verschiedene Fehlerbehebungen hinsichtlich der Leistung, Stabilität, Sicherheit und des von Azure Stack eingesetzten Betriebssystems vorgenommen.

Änderungen

Schnellstarttutorials im Benutzerportaldashboard weisen jetzt Links zu relevanten Artikeln in der Azure Stack-Dokumentation auf.

Alle Dienste ersetzt Weitere Dienste in den Azure Stack-Administrator- und -Benutzerportalen. Sie können nun Alle Dienste als Alternative zum Navigieren in den Azure Stack-Portalen wie in den Azure-Portalen verwenden.

+ Ressource erstellen ersetzt + Neu in den Azure Stack Administrator- und Benutzerportalen. Sie können nun Ressource erstellen als Alternative zum Navigieren in den Azure Stack-Portalen wie in den Azure-Portalen verwenden.

Die VM-Größen Basic A stehen für das Erstellen von VM-Skalierungsgruppen (VMSS) über das Portal nicht mehr zur Verfügung. Verwenden Sie PowerShell oder eine Vorlage, um eine VMSS mit dieser Größe zu erstellen.

Common Vulnerabilities and Exposures (CVE, allgemeine Sicherheitslücken und Schwachstellen)

Dieses Update installiert die folgenden Updates:

Weitere Informationen zu diesen Sicherheitslücken erhalten Sie durch Klicken auf die vorhergehenden Links oder im Microsoft Knowledge Base-Artikel 4343887.

Dieses Update enthält auch die Minderung des Sicherheitsrisikos für die spekulative Ausführung des Seitenkanals, bekannt als L1 Terminal Fault (L1TF), beschrieben in der Microsoft-Sicherheitsempfehlung ADV180018.

Voraussetzungen

Installieren Sie das Azure Stack-Update 1807, bevor Sie das Azure Stack-Update 1808 anwenden.
Bevor Sie mit der Installation dieses Updates beginnen, führen Sie Test-AzureStack mit den folgenden Parametern aus, um den Status von Azure Stack zu überprüfen und alle gefundenen operativen Probleme (einschließlich aller Warnungen und Fehler) zu beheben. Überprüfen Sie auch aktive Warnungen, und lösen Sie solche auf, die eine Aktion erfordern.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
```

Bekannte Probleme mit dem Updateprozess

Wenn Sie Test-AzureStack nach dem Update 1808 ausführen, wird eine Warnmeldung des Baseboard Management Controllers (BMC) angezeigt. Sie können diese Warnung problemlos ignorieren.

Während der Installation dieses Updates werden unter Umständen Warnungen mit folgender Meldung angezeigt: Fehler: Die Vorlage für FaultType UserAccounts.New fehlt. Sie können diese Warnungen problemlos ignorieren. Diese Warnungen werden automatisch nach der Installation dieses Updates geschlossen.

Versuchen Sie nicht, während der Installation dieses Updates virtuelle Computer zu erstellen. Weitere Informationen zum Verwalten von Updates finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.

Wenn ein Update eine Aktion erfordert, wird die entsprechende Warnung unter bestimmten Umständen möglicherweise nicht generiert. Der genaue Status wird im Portal dennoch angegeben und nicht beeinträchtigt.

Schritte nach dem Update

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln sowie in unserer Wartungsrichtlinie.

KB 4465859 – Azure Stack-Hotfix: Azure Stack-Hotfix 1.1808.2.104

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Die technische Dokumentation für Azure Stack konzentriert sich auf das neueste Release. Aufgrund von Portaländerungen zwischen den Releases kann das, was bei der Verwendung der Azure Stack-Portale angezeigt wird, von dem abweichen, was in der Dokumentation angezeigt wird.

Es kann sein, dass im Portal ein leeres Dashboard angezeigt wird. Klicken Sie zum Wiederherstellen des Dashboards auf Dashboard bearbeiten, klicken Sie dann mit der rechten Maustaste, und wählen Sie Auf Standardzustand zurücksetzen aus.

Im Administratorportal wird beim Zugriff auf die Details eines Benutzerabonnements nach dem Schließen des Blatts und dem Klicken auf Aktuell der Name des Benutzerabonnements nicht angezeigt.

Sowohl im Administrator- als auch im Benutzerportal funktioniert das Klicken auf die Portaleinstellungen und das Auswählen von Alle Einstellungen und private Dashboards löschen nicht wie erwartet. Es wird eine Fehlerbenachrichtigung angezeigt.

In den Administrator- und Benutzerportalen wird unter Alle Dienste die Ressource DDoS Protection-Pläne nicht ordnungsgemäß aufgeführt. Sie ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Fehler angezeigt, der besagt, dass das Portal das Marketplace-Element nicht erstellen konnte.

Wenn Sie im Administrator- oder im Benutzerportal nach „Docker“ suchen, wird das Element nicht ordnungsgemäß zurückgegeben. Sie ist in Azure Stack nicht verfügbar. Wenn Sie versuchen, sie zu erstellen, wird ein Blatt mit einem Fehlerhinweis angezeigt.

Das Konto, mit dem Sie sich beim Administrator- oder Benutzerportal von Azure Stack anmelden, wird als Unbekannter Benutzer angezeigt. Dieses Verhalten tritt auf, wenn für das Konto kein Vorname oder Nachname angegeben wurde. Um dieses Problem zu umgehen, bearbeiten Sie das Benutzerkonto so, dass der Vor- oder Nachname angegeben wird. Sie müssen sich dann abmelden und erneut am Portal anmelden.

Wenn Sie das Portal verwenden, um eine VM-Skalierungsgruppe zu erstellen, wird das Dropdownmenü Instanzgröße bei Verwendung von Internet Explorer nicht richtig geladen. Um dieses Problem zu umgehen, nutzen Sie einen anderen Browser beim Verwenden des Portals zum Erstellen einer VMSS.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Bei der Installation einer neuen Azure Stack-Umgebung, die diese Version ausführt, wird die Warnung, dass eine Aktivierung erforderlich ist, möglicherweise nicht angezeigt. Die Aktivierung ist erforderlich, damit Sie die Marketplace-Syndikation verwenden können.

Die zwei administrativen Abonnementtypen, die in Version 1804 eingeführt wurden, sollten nicht verwendet werden. Die Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Integrität und Überwachung

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:

Warnung 1:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Warnung 2:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Beide Alarme können ignoriert werden und werden nach einer gewissen Zeit automatisch geschlossen.

Möglicherweise wird eine Warnung für die Storage-Komponente mit den folgenden Details angezeigt:
- NAME: Interner Kommunikationsfehler des Storage-Diensts
- SCHWEREGRAD: Kritisch
- KOMPONENTE: Storage
- BESCHREIBUNG: Beim Senden von Anforderungen an die folgenden Knoten ist ein interner Kommunikationsfehler des Storage-Diensts aufgetreten.
  
  Die Warnung kann ignoriert werden, Sie müssen sie jedoch manuell schließen.

Wenn Sie als Azure Stack-Operator eine Fehlermeldung über unzureichenden Speicher erhalten und virtuelle Computer der Mandanten nicht mit einem Fabric-VM-Erstellungsfehler bereitgestellt werden können, verfügt der Azure Stack-Stempel möglicherweise nicht über genügend Arbeitsspeicher. Mit dem Azure Stack Capacity Planner können Sie die verfügbare Kapazität für Ihre Workloads besser bestimmen.

Compute

Wenn Sie einen neuen virtuellen Computer (VM) über das Azure Stack-Portal erstellen und die VM-Größe auswählen, wird die Spalte „USD/Monat“ mit der Meldung Nicht verfügbar angezeigt. Diese Spalte sollte nicht angezeigt werden. Die Anzeige der VM-Preisspalte wird in Azure Stack nicht unterstützt.

Nach dem Anwenden des Updates 1808 können beim Bereitstellen von virtuellen Computern mit Managed Disks die folgenden Probleme auftreten:
1. Wenn das Abonnement vor dem Update 1808 erstellt wurde, kann die Bereitstellung eines virtuellen Computers mit Managed Disks mit einer internen Fehlermeldung fehlschlagen. Führen Sie die folgenden Schritte für jedes Abonnement aus, um den Fehler zu beheben:
  1. Navigieren Sie im Mandantenportal zu Abonnements, und suchen Sie nach dem Abonnement. Klicken Sie auf Ressourcenanbieter, klicken Sie dann auf Microsoft.Compute, und klicken Sie anschließend auf Erneut registrieren.
  2. Navigieren Sie unter dem gleichen Abonnement zu Zugriffssteuerung (IAM), und überprüfen Sie, ob Azure Stack: Verwalteter Datenträger aufgeführt ist.
2. Wenn Sie eine Umgebung mit mehreren Mandanten konfiguriert haben, kann die Bereitstellung von virtuellen Computern in einem Abonnement, dem ein Gastverzeichnis zugeordnet ist, mit einer internen Fehlermeldung fehlschlagen. Führen Sie die folgenden Schritte aus, um den Fehler zu beheben:
  1. Wenden Sie den Azure Stack-Hotfix 1808 an.
  2. Führen Sie die in diesem Artikel beschriebenen Schritte aus, um alle Gastverzeichnisse neu zu konfigurieren.

Bei Verwendung des Add-AzsPlatformImage-Cmdlets müssen Sie den -OsUri-Parameter als Speicherkonto-URI beim Hochladen des Datenträgers verwenden. Wenn Sie den lokalen Pfad des Datenträgers verwenden, schlägt das Cmdlet mit dem folgenden Fehler fehl: Fehler beim vorgang mit langer Ausführung mit dem Status Fehlgeschlagen.

Das Anfügen von SSD-Datenträgern an virtuelle Computer mit verwalteten Datenträgern der Größe „Premium“ (DS, DSv2, Fs, Fs_V2) schlägt mit dem folgenden Fehler fehl: Fehler beim Aktualisieren der Datenträger für den virtuellen Computer „vmname“. Fehler: Der angeforderte Vorgang kann nicht ausgeführt werden, weil der Speicherkontotyp „Premium_LRS“ für die VM-Größe „Standard_DS/Ds_V2/FS/Fs_v2“ nicht unterstützt wird.

Um dieses Problem zu umgehen, verwenden Sie Datenträger vom Typ Standard_LRS anstelle von Premium_LRS. Das Verwenden von Datenträgern des Typs Standard_LRS ändert IOPs oder die Abrechnungskosten nicht.

Wenn Sie das Portal zum Erstellen virtueller Computer in einer Premium-VM-Größe (DS, Ds_v2, FS, FSv2) verwenden, wird der virtuelle Computer in einem Standardspeicherkonto erstellt. Die Erstellung in einem Standardspeicherkonto wirkt sich nicht auf die Funktionalität, IOPs oder die Abrechnung aus.

Sie können die Warnung, die besagt, sicher ignorieren: Sie haben sich entschieden, einen Standarddatenträger auf einer Größe zu verwenden, die Premium-Datenträger unterstützt. Dies kann sich auf die Leistung des Betriebssystems auswirken und wird nicht empfohlen. Erwägen Sie stattdessen die Verwendung von Premium-Speicher (SSD).

Die Benutzeroberfläche zum Erstellen von VM-Skalierungsgruppen (VMSS) bietet als Option für die Bereitstellung eine CentOS 7.2-basierte Bereitstellung an. Da dieses Image in Azure Stack nicht verfügbar ist, wählen Sie entweder ein anderes Betriebssystem für Ihre Bereitstellung aus, oder verwenden Sie eine Azure Resource Manager-Vorlage mit einem anderen CentOS-Image, das vor der Bereitstellung vom Operator aus dem Marketplace heruntergeladen wurde.

Wenn Sie die PowerShell-Cmdlets Start-AzsScaleUnitNode oder Stop-AzsScaleunitNode verwenden, um Skalierungseinheiten zu verwalten, tritt beim ersten Versuch, die Skalierungseinheit zu starten oder zu beenden, möglicherweise ein Fehler auf. Wenn beim ersten Ausführen des Cmdlets ein Fehler auftritt, führen Sie das Cmdlet ein zweites Mal aus. Bei der zweiten Ausführung sollte der Vorgang erfolgreich sein.

Beim Erstellen von virtuellen Computern im Azure Stack-Benutzerportal zeigt das Portal eine falsche Anzahl von Datenträgern an, die an eine VM der Serie DS angefügt werden können. VMs der Serie DS können so viele Datenträger wie bei der Azure-Konfiguration aufnehmen.

Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Benutzer eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Wenn Sie den Ressourcenanbieter Microsoft.Insight in den Abonnementeinstellungen registrieren und eine Windows-VM mit aktivierter Gastbetriebssystemdiagnose erstellen, können im Diagramm „CPU-Prozentsatz“ auf der Übersichtsseite der VM keine Metrikdaten angezeigt werden.

Navigieren Sie zum Anzeigen des Diagramms „CPU-Prozentsatz“ für die VM zum Blatt Metriken, und zeigen Sie alle unterstützten Gastmetriken für Windows-VMs an.

Netzwerk

Wenn Sie unter Netzwerk auf VPN Gateway erstellen klicken, um eine VPN-Verbindung einzurichten, wird als VPN-Typ Richtlinienbasiert aufgeführt. Wählen Sie diese Option nicht aus. Nur die Option Routenbasiert wird in Azure Stack unterstützt.

Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse blockiert.

In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.

Öffentliche IP-Adressen, die mithilfe der dynamischen Zuordnungsmethode bereitgestellt wurden, werden nach der Ausgabe eines Befehls zum Beenden und Aufheben der Zuordnung nicht unbedingt beibehalten.

Während der Geheimnisrotation von Azure Stack sind öffentliche IP-Adressen für einen Zeitraum von zwei bis fünf Minuten nicht erreichbar.

In Szenarien, in denen der Mandant über einen S2S-VPN-Tunnel auf seine VMs zugreift, kann es passieren, dass bei Verbindungsversuchen Fehler auftreten, wenn das lokale Subnetz dem lokalen Netzwerkgateway erst nach der Erstellung des Gateways hinzugefügt wurde.

App Service

Benutzer müssen den Speicherressourcenanbieter vor dem Erstellen seiner ersten Azure-Funktion im Abonnement registrieren.

Um die Infrastruktur (Worker-, Verwaltungs-, Front-End-Rollen) aufzuskalieren, müssen Sie PowerShell verwenden, wie in den Anmerkungen zu dieser Version für die Berechnung beschrieben.

Verbrauch

Die Ansicht „Verwendung“ für die Nutzungsdaten öffentlicher IP-Adressen zeigt den gleichen EventDateTime-Wert für jeden Datensatz anstatt des TimeDate-Stempels, der anzeigt, wann dieser jeweils erstellt wurde. Derzeit können Sie diese Daten nicht nutzen, um eine genaue Buchhaltung über die Nutzung öffentlicher IP-Adressen durchzuführen.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1808 hier herunterladen.

Nächste Schritte

Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.
Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

1807 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

Dieser Artikel beschreibt den Inhalt des Updatepakets 1807. Dieses Update enthält Verbesserungen, Fehlerbehebungen und bekannten Probleme für diese Version von Azure Stack sowie Informationen darüber, wo das Update heruntergeladen werden kann. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1807 ist 1.1807.0.76.

Neue Funktionen

Dieses Update enthält die folgenden Verbesserungen für Azure Stack.

Starten von Sicherungen anhand eines vordefinierten Zeitplans: Als Appliance kann Azure Stack nun automatisch Infrastruktursicherungen regelmäßig auslösen, um Benutzereingriffe zu eliminieren. Zudem bereinigt Azure Stack auch automatisch die externe Freigabe für Sicherungen, die älter als die definierte Aufbewahrungsdauer sind. Weitere Informationen finden Sie unter Aktivieren der Sicherung für Azure Stack mit PowerShell.

Zur Gesamtsicherungszeit wurde die Datenübertragungszeit addiert. Weitere Informationen finden Sie unter Aktivieren der Sicherung für Azure Stack mit PowerShell.

Die externe Kapazität für Sicherungen zeigt jetzt die richtige Kapazität der externen Freigabe an. (Bisher war dies harter Code auf 10 GB.) Weitere Informationen finden Sie unter Aktivieren der Sicherung für Azure Stack mit PowerShell.

Erweitern der Kapazität durch Hinzufügen zusätzlicher Knoten von Skalierungseinheiten.

Azure Resource Manager-Vorlagen unterstützen jetzt das condition-Element: Sie können jetzt eine Ressource in einer Azure Resource Manager-Vorlage mit einer Bedingung bereitstellen. Sie können Ihre Vorlage für die Bereitstellung einer Ressource auf Grundlage einer Bedingung (beispielsweise das Vorhandensein eines Parameterwerts) entwerfen. Informationen zur Verwendung einer Vorlage als Bedingung finden Sie unter Bedingtes Bereitstellen einer Ressource und Abschnitt „Variablen“ von Azure Resource Manager-Vorlagen in der Azure-Dokumentation.

Sie können Vorlagen auch zum Bereitstellen von Azure-Ressourcen für mehrere Abonnements oder Ressourcengruppen verwenden.

Die Unterstützung der Microsoft.Network-API-Ressourcenversion wurde aktualisiert und umfasst nun Unterstützung für die API-Version 2017-10-01 von 2015-06-15 für Azure Stack-Netzwerkressourcen. Die Unterstützung für Ressourcenversionen zwischen 2017-10-01 und 2015-06-15 ist nicht in diesem Release enthalten. Weitere Informationen zu den Funktionsunterschieden finden Sie unter Überlegungen zu Azure Stack-Netzwerken.

Azure Stack bietet jetzt Unterstützung für Reverse-DNS-Lookups für extern zugängliche Azure Stack-Infrastrukturendpunkte (d.h. für Portal, Verwaltungsportal, Verwaltung und Administratorverwaltung). Dies ermöglicht die Auflösung der Namen von externen Azure Stack-Endpunkten über eine IP-Adresse.

Azure Stack unterstützt jetzt das Hinzufügen zusätzlicher Netzwerkschnittstellen zu einer vorhandenen VM. Diese Funktion ist über das Portal, PowerShell und die Befehlszeilenschnittstelle verfügbar. Weitere Informationen finden Sie unter Hinzufügen oder Entfernen von Netzwerkschnittstellen in der Azure-Dokumentation.

An Netzwerkverbrauchseinheiten wurden Verbesserungen bezüglich der Genauigkeit und Resilienz vorgenommen. Netzwerkverbrauchseinheiten sind jetzt genauer und berücksichtigen angehaltene Abonnements, Ausfallzeiten und Racebedingungen.

Benachrichtigung über verfügbares Update. In verbundenen Azure Stack-Bereitstellungen wird nun in regelmäßigen Abständen ein gesicherter Endpunkt überprüft und ermittelt, ob ein Update für Ihre Cloud verfügbar ist. Diese Benachrichtigung wird auf der Kachel „Update“ angezeigt, wie dies auch nach dem manuellen Überprüfen und Importieren eines neuen Updates der Fall ist. Weitere Informationen finden Sie unter Verwalten von Updates für Azure Stack.

Verbesserungen am Azure Stack-Syslog-Client (Vorschaufeature). Dieser Client ermöglicht die Weiterleitung von Überwachungen und Protokollen der Azure Stack-Infrastruktur an einen Syslog-Server oder eine SIEM-Software (Security Information & Event Management) außerhalb von Azure Stack. Der Syslog-Client unterstützt jetzt das TCP-Protokoll mit Nur-Text- oder die TLS 1.2-Verschlüsselung (Letzteres ist die Standardkonfiguration). Sie können die TLS-Verbindung nur mit Serverauthentifizierung oder mit gegenseitiger Authentifizierung konfigurieren.

Verwenden Sie zum Konfigurieren der Kommunikation des Syslog-Clients mit dem Syslog-Server (beispielsweise Protokoll, Verschlüsselung und Authentifizierung) das Cmdlet Set-SyslogServer. Dieses Cmdlet ist über den privilegierten Endpunkt (PEP) verfügbar.

Verwenden Sie zum Hinzufügen des clientseitigen Zertifikats für die gegenseitige TLS 1.2-Authentifizierung des Syslog-Clients das Cmdlet „Set-SyslogClient“ in der PEP-Sitzung.

Mit diesem Vorschaufeature können Sie eine deutlich größere Anzahl von Überwachungen und Warnungen anzeigen.

Da sich dieses Feature noch in der Vorschauphase befindet, sollten Sie es nicht in Produktionsumgebungen verwenden.

Weitere Informationen finden Sie unter Azure Stack-Syslog-Weiterleitung.

Azure Resource Manager enthält den Namen der Region. In diesem Release enthalten aus der Azure Resource Manager-Vorlage abgerufene Objekte jetzt das Attribut „Regionsname“. Wenn ein vorhandenes PowerShell-Skript das Objekt direkt an ein anderes Cmdlet übergibt, kann bei der Ausführung des Skripts ein Fehler auftreten. Dies ist das mit Azure Resource Manager konforme Verhalten und erfordert, dass der aufrufende Client das Attribut „Region“ subtrahiert. Weitere Informationen zum Azure Resource Manager finden Sie in der Dokumentation zum Azure Resource Manager.

Änderungen an der Funktion „Delegierte Anbieter“. Beginnend mit dem Update 1807 wird das Modell für delegierte Anbieter vereinfacht, damit es besser auf das Modell für Azure-Handelspartner ausgerichtet ist, und delegierte Anbieter können keine anderen delegierten Anbieter erstellen. Dadurch vereinfacht sich das Modell wesentlich, und die Funktion „Delegierte Anbieter“ wird auf einer einzelnen Ebene verfügbar. Um den Übergang zum neuen Modell und die Verwaltung der Abonnements zu ermöglichen, können die Benutzerabonnements jetzt zwischen neuen oder vorhandenen Abonnements für delegierte Anbieter verschoben werden, die zum selben Verzeichnismandanten gehören. Benutzerabonnements, die zum Abonnement für Standardanbieter gehören, können auch in die Abonnements für delegierte Anbieter im gleichen Verzeichnismandanten verschoben werden. Weitere Informationen finden Sie unter Delegieren von Angeboten in Azure Stack.

Kürzere VM-Erstellungszeit für VMs, die mit aus dem Azure Marketplace heruntergeladenen Images erstellt werden.

Verbesserte Benutzerfreundlichkeit von Azure Stack Capacity Planner. Der Azure Stack Capacity Planner umfasst jetzt eine vereinfachte Umgebung für die Eingabe von S2D-Caches und S2D-Kapazitäten beim Definieren von Lösungs-SKUs. Die Beschränkung auf 1.000 virtuelle Computer wurde aufgehoben.

Behobene Probleme

Die Zuverlässigkeit des Updateprozesses wurde durch verschiedene Verbesserungen erhöht. Zudem wurde durch die Behebung von Fehlern in der zugrunde liegenden Infrastruktur die potenzielle Downtime für Workloads während der Aktualisierung minimiert.

Es wurde ein Problem behoben, bei dem ein geänderter Kontingentgrenzwert nicht für bestehende Abonnements galt. Wenn Sie nun einen Kontingentgrenzwert für eine Netzwerkressource erhöhen, die Teil eines mit einem Benutzerabonnement verknüpften Angebots und Plans ist, gilt der neue Grenzwert sowohl für die bereits bestehenden als auch für neue Abonnements.

Sie können jetzt erfolgreich Aktivitätsprotokolle für Systeme abfragen, die in einer UTC+N-Zeitzone bereitgestellt sind.

Die Vorprüfung der Sicherungskonfigurationsparameter (Pfad/Benutzername/Kennwort/Verschlüsselungsschlüssel) legt keine falschen Einstellungen mehr in der Sicherungskonfiguration fest. (Früher wurden für die Sicherung falsche Einstellungen festgelegt, wodurch beim Auslösen der Sicherung ein Fehler aufgetreten ist.)

Die Sicherungsliste wird nun aktualisiert, wenn Sie die Sicherung manuell von der externen Freigabe löschen.

Das Update auf diese Version setzt den Standardbesitzer des Standardanbieterabonnements nicht mehr auf den integrierten CloudAdmin-Benutzer zurück, wenn es mit AD FS bereitgestellt wird.

Wenn Sie die Datencenterintegration einrichten, greifen Sie nicht mehr über eine Azure-Dateifreigabe auf die AD FS-Metadatendatei zu. Weitere Informationen finden Sie unter Einrichten der AD FS-Integration durch Bereitstellen einer Verbundmetadatendatei.

Es wurde ein Problem behoben, das verhinderte, dass Benutzer eine vorhandene öffentliche IP-Adresse, die zuvor einer Netzwerkschnittstelle oder einem Load Balancer zugewiesen war, einer neuen Netzwerkschnittstelle oder einem neuen Load Balancer zuweisen.

Wenn Sie im Verwaltungs- oder Benutzerportal für ein Speicherkonto die Option Übersicht auswählen, werden alle erwarteten Informationen richtig im Bereich Zusammenfassung angezeigt.

Wenn Sie im Verwaltungs- oder Benutzerportal für ein Speicherkonto die Option Tags auswählen, werden die Informationen jetzt richtig angezeigt.

In dieser Version von Azure Stack wurde das Problem behoben, durch das die Anwendung von Treiberupdates aus OEM-Erweiterungspaketen verhindert wurde.

Wir haben ein Problem behoben, aufgrund dessen Sie keine VMs auf dem Blatt „Compute“ löschen konnten, wenn beim Erstellen der VM ein Fehler auftrat.

Die Warnung für niedrige Arbeitsspeicherkapazität wird nicht mehr fälschlicherweise angezeigt.
Es wurden verschiedene Fehlerbehebungen hinsichtlich der Leistung, Stabilität, Sicherheit und des von Azure Stack eingesetzten Betriebssystems vorgenommen.

Common Vulnerabilities and Exposures (CVE, allgemeine Sicherheitslücken und Schwachstellen)

Azure Stack verwendet die Server Core-Installationen von Windows Server 2016 zum Hosten der wichtigsten Infrastrukturkomponenten. Mit diesem Release werden die folgenden Windows Server 2016-Updates auf den Infrastrukturservern für Azure Stack installiert:

Weitere Informationen zu diesen Sicherheitslücken erhalten Sie durch Klicken auf die Links oben oder in den Microsoft Knowledge Base-Artikeln 4338814 und 4345418.

Voraussetzungen

Installieren Sie das Azure Stack 1805-Update, bevor Sie das Azure Stack 1807-Update anwenden. Es gab kein Update 1806.
Installieren Sie das neueste verfügbare Update oder Hotfix für Version 1805.
Bevor Sie mit der Installation dieses Updates beginnen, führen Sie Test-AzureStack mit den folgenden Parametern aus, um den Status von Azure Stack zu überprüfen und alle gefundenen operativen Probleme (einschließlich aller Warnungen und Fehler) zu beheben. Überprüfen Sie auch aktive Warnungen, und lösen Sie solche auf, die eine Aktion erfordern.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
```

Bekannte Probleme mit dem Updateprozess

Während der Installation dieses Updates werden unter Umständen Warnungen mit folgender Meldung angezeigt: Fehler: Die Vorlage für FaultType UserAccounts.New fehlt. Sie können diese Warnungen problemlos ignorieren. Diese Warnungen werden automatisch nach der Installation dieses Updates geschlossen.

Versuchen Sie nicht, während der Installation dieses Updates virtuelle Computer zu erstellen. Weitere Informationen zum Verwalten von Updates finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.

Wenn ein Update eine Aktion erfordert, wird die entsprechende Warnung unter bestimmten Umständen möglicherweise nicht generiert. Der genaue Status wird im Portal dennoch angegeben und nicht beeinträchtigt.

Schritte nach dem Update

Installieren Sie nach der Installation dieses Updates alle entsprechenden Hotfixes. Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln sowie in unserer Wartungsrichtlinie.

KB 4464231 – Azure Stack-Hotfix: Azure Stack-Hotfix 1.1807.1.78

Nach der Installation dieses Updates sehen Sie einen verbesserten Status für fehlerhafte Updateinstallationen. Dies kann Informationen zu Fehlern bei vorherigen Updateinstallationen enthalten, die entsprechend den beiden neuen ZUSTAND-Kategorien überarbeitet wurden. Bei diesen neuen ZUSTAND-Kategorien handelt es sich um PreparationFailed und InstallationFailed.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Die technische Dokumentation für Azure Stack konzentriert sich auf das neueste Release. Aufgrund von Portaländerungen zwischen den Releases kann das, was bei der Verwendung der Azure Stack-Portale angezeigt wird, von dem abweichen, was in der Dokumentation angezeigt wird.
Die Funktion, mit der im Administratorportal eine neue Supportanfrage über die Dropdownliste geöffnet wird, ist nicht verfügbar. Verwenden Sie für in Azure Stack integrierte Systeme stattdessen den folgenden Link: https://aka.ms/newsupportrequest.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Bei der Installation einer neuen Azure Stack-Umgebung, die diese Version ausführt, wird die Warnung, dass eine Aktivierung erforderlich ist, möglicherweise nicht angezeigt. Die Aktivierung ist erforderlich, damit Sie die Marketplace-Syndikation verwenden können.

Die zwei administrativen Abonnementtypen, die in Version 1804 eingeführt wurden, sollten nicht verwendet werden. Die Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Möglicherweise haben Sie die horizontale Scrollleiste am unteren Rand des Verwaltungs- und Benutzerportals nicht verwendet. Wenn Sie nicht auf die horizontale Bildlaufleiste zugreifen können, verwenden Sie die Breadcrumb-Leiste, um zu einem vorherigen Blatt im Portal zu navigieren. Wählen Sie hierzu den Namen des Blattes, das Sie anzeigen möchten, aus der Breadcrumb-Liste oben links im Portal aus.

Es ist es u.U. nicht möglich, Compute- oder Speicherressourcen im Administratorportal anzuzeigen. Grund für dieses Problem ist ein Fehler bei der Installation des Updates, der dazu führt, dass das Update fälschlicherweise als erfolgreich gemeldet wird. Wenn dieses Problem auftritt, wenden Sie sich an Microsoft Customer Support Services, um Unterstützung zu erhalten.

Es kann sein, dass im Portal ein leeres Dashboard angezeigt wird. Wählen Sie zum Wiederherstellen des Dashboards oben rechts im Portal das Zahnradsymbol und dann die Option Standardeinstellungen wiederherstellen.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Integrität und Überwachung

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:

Warnung 1:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Warnung 2:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Beide Alarme können ignoriert werden und werden nach einer gewissen Zeit automatisch geschlossen.

Möglicherweise wird eine Warnung für die Storage-Komponente mit den folgenden Details angezeigt:
- NAME: Interner Kommunikationsfehler des Storage-Diensts
- SCHWEREGRAD: Kritisch
- KOMPONENTE: Storage
- BESCHREIBUNG: Beim Senden von Anforderungen an die folgenden Knoten ist ein interner Kommunikationsfehler des Storage-Diensts aufgetreten.
  
  Die Warnung kann ignoriert werden, Sie müssen sie jedoch manuell schließen.

Wenn Sie als Azure Stack-Operator eine Fehlermeldung über unzureichenden Speicher erhalten und virtuelle Computer der Mandanten nicht mit einem Fabric-VM-Erstellungsfehler bereitgestellt werden können, verfügt der Azure Stack-Stempel möglicherweise nicht über genügend Arbeitsspeicher. Mit dem Azure Stack Capacity Planner können Sie die verfügbare Kapazität für Ihre Workloads besser bestimmen.

Compute

Wenn Sie die PowerShell-Cmdlets Start-AzsScaleUnitNode oder Stop-AzsScaleunitNode verwenden, um Skalierungseinheiten zu verwalten, tritt beim ersten Versuch, die Skalierungseinheit zu starten oder zu beenden, möglicherweise ein Fehler auf. Wenn beim ersten Ausführen des Cmdlets ein Fehler auftritt, führen Sie das Cmdlet ein zweites Mal aus. Bei der zweiten Ausführung sollte der Vorgang erfolgreich sein.

Bei der Auswahl der Größe des virtuellen Computers für die Bereitstellung eines virtuellen Computers sind einige VM-Größen der Serie F beim Erstellen einer VM nicht als Teil der Größenauswahl sichtbar. Folgende VM-Größen werden im Selektor nicht angezeigt: F8s_v2, F16s_v2, F32s_v2 und F64s_v2.
Um das Problem zu umgehen, verwenden Sie eine der folgenden Methoden zum Bereitstellen einer VM. Bei jeder Methode müssen Sie die gewünschte VM-Größe angeben.
- Azure Resource Manager-Vorlage: Wenn Sie eine Vorlage verwenden, legen Sie vmSize in der Vorlage entsprechend der gewünschten VM-Größe fest. Der folgende Eintrag z.B. wird zum Bereitstellen einer VM mit der Größe F32s_v2 verwendet:
```
    "properties": {
    "hardwareProfile": {
            "vmSize": "Standard_F32s_v2"
    },
```
- Azure CLI: Sie können den Befehl az vm create verwenden und die VM-Größe als Parameter angeben, ähnlich wie --size "Standard_F32s_v2".
- PowerShell: Mit PowerShell können Sie New-AzureRMVMConfig mit dem Parameter verwenden, der die VM-Größe angibt, ähnlich wie -VMSize "Standard_F32s_v2".

Die Skalierungseinstellungen für Skalierungsgruppen für virtuelle Computer sind im Portal nicht verfügbar. Dieses Problem können Sie umgehen, indem Sie Azure PowerShell verwenden. Aufgrund der Versionsunterschiede bei PowerShell müssen Sie den -Name-Parameter statt des -VMScaleSetName-Parameters verwenden.

Wenn Sie im Portal unter Neu>Berechnen>Verfügbarkeitsgruppe eine Verfügbarkeitsgruppe erstellen, können Sie nur eine Verfügbarkeitsgruppe mit einer Fehlerdomäne und einer Updatedomäne erstellen. Erstellen Sie bei der Erstellung eines neuen virtuellen Computers zur Problemumgehung die Verfügbarkeitsgruppe mithilfe von PowerShell, der CLI oder im Portal.

Beim Erstellen von virtuellen Computern im Azure Stack-Benutzerportal zeigt das Portal eine falsche Anzahl von Datenträgern an, die an eine VM der Serie DS angefügt werden können. VMs der Serie DS können so viele Datenträger wie bei der Azure-Konfiguration aufnehmen.

Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Benutzer eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Wenn Sie den Microsoft.Insight-Ressourcenanbieter in den Abonnementeinstellungen registrieren und einen virtuellen Windows-Computer mit aktivierter Gastbetriebssystemdiagnose erstellen, werden auf der Übersichtsseite des virtuellen Computers keine Metrikdaten angezeigt.

Navigieren Sie zum Anzeigen von Metrikdaten (etwa das Diagramm „CPU-Prozentsatz“ für den virtuellen Computer) zum Blatt Metriken, und zeigen Sie alle unterstützten Gastbetriebssystemmetriken für virtuelle Windows-Computer an.

Netzwerk

Wenn Sie unter Netzwerk auf VPN Gateway erstellen klicken, um eine VPN-Verbindung einzurichten, wird als VPN-Typ Richtlinienbasiert aufgeführt. Wählen Sie diese Option nicht aus. Nur die Option Routenbasiert wird in Azure Stack unterstützt.

Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse blockiert.

In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.

Öffentliche IP-Adressen, die mithilfe der dynamischen Zuordnungsmethode bereitgestellt wurden, werden nach der Ausgabe eines Befehls zum Beenden und Aufheben der Zuordnung nicht unbedingt beibehalten.

Während der Geheimnisrotation von Azure Stack sind öffentliche IP-Adressen für einen Zeitraum von zwei bis fünf Minuten nicht erreichbar.

In Szenarien, in denen der Mandant über einen S2S-VPN-Tunnel auf seine VMs zugreift, kann es passieren, dass bei Verbindungsversuchen Fehler auftreten, wenn das lokale Subnetz dem lokalen Netzwerkgateway erst nach der Erstellung des Gateways hinzugefügt wurde.

SQL und MySQL

Sonderzeichen, einschließlich Leerzeichen und Interpunktion, werden im Namen für die Familie nicht unterstützt, wenn Sie die SKU für die SQL- und MySQL-Ressourcenanbieter erstellen.

Auf Servern, die SQL oder MySQL hosten, kann nur der Ressourcenanbieter Elemente erstellen. Die auf einem Hostserver erstellten Elemente, die nicht vom Ressourcenanbieter erstellt wurden, könnten zu einem Zustand ohne Entsprechung führen.

Hinweis

Nachdem Sie ein Update auf diese Version von Azure Stack ausgeführt haben, können Sie die zuvor bereitgestellten SQL- und MySQL-Ressourcenanbieter weiterhin verwenden. Es wird empfohlen, SQL und MySQL zu aktualisieren, sobald ein neues Release verfügbar ist. Wenden Sie Updates wie bei Azure Stack sequenziell auf die Ressourcenanbieter SQL und MySQL an. Wenn Sie z.B. Version 1804 verwenden, wenden Sie zuerst Version 1805 an, und aktualisieren Sie sie dann auf 1807.

Die Installation dieses Updates wirkt sich nicht auf die aktuelle Verwendung der von Ihren Benutzern verwendeten Ressourcenanbieter SQL oder MySQL aus. Unabhängig von der Version der Ressourcenanbieter, die Sie verwenden, bleiben Ihre Benutzerdaten in deren Datenbanken davon unberührt und stehen weiterhin für den Zugriff zur Verfügung.

App Service

Benutzer müssen den Speicherressourcenanbieter vor dem Erstellen seiner ersten Azure-Funktion im Abonnement registrieren.

Um die Infrastruktur (Worker-, Verwaltungs-, Front-End-Rollen) aufzuskalieren, müssen Sie PowerShell verwenden, wie in den Anmerkungen zu dieser Version für die Berechnung beschrieben.

App Service kann zurzeit nur im Abonnement für Standardanbieter bereitgestellt werden.

Verbrauch

Die Ansicht „Verwendung“ für die Nutzungsdaten öffentlicher IP-Adressen zeigt den gleichen EventDateTime-Wert für jeden Datensatz anstatt des TimeDate-Stempels, der anzeigt, wann dieser jeweils erstellt wurde. Derzeit können Sie diese Daten nicht nutzen, um eine genaue Buchhaltung über die Nutzung öffentlicher IP-Adressen durchzuführen.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1807 hier herunterladen.

Nächste Schritte

Informationen zur Wartungsrichtlinie für integrierte Azure Stack-Systeme und dazu, wie Sie vorgehen müssen, um den unterstützten Zustand des Systems aufrechtzuerhalten, finden Sie unter Azure Stack-Wartungsrichtlinie.
Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.
Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

1805 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

In diesem Artikel wird beschrieben, welche Verbesserungen und Fehlerbehebungen in diesem Updatepaket 1805 enthalten sind, welche Probleme dieser Version bekannt sind und wo das Update heruntergeladen werden kann. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1805 ist 1.1805.1.47.

Tipp

Basierend auf Kundenfeedback wurde das Versionsschema für Microsoft Azure Stack aktualisiert. Ab diesem Update – 1805 – stellt das neue Schema die aktuelle Cloudversion besser dar.

Das Versionsschema lautet nun Version.YearYearMonthMonth.MinorVersion.BuildNumber, wobei der zweite und dritte Satz die Version und das Release angeben. Beispielsweise stellt 1805.1 die RTM-Version (Freigabe zur Fertigung) von 1805 dar.

Neue Funktionen

Dieses Update enthält die folgenden Verbesserungen für Azure Stack.

Azure Stack enthält jetzt einen Syslog-Client als Vorschaufunktion. Dieser Client ermöglicht die Weiterleitung von Überwachungs- und Sicherheitsprotokollen der Azure Stack-Infrastruktur an einen Syslog-Server oder eine SIEM-Software (Security Information and Event Management) außerhalb von Azure Stack. Derzeit unterstützt der Syslog-Client nur nicht authentifizierte UDP-Verbindungen über den Standardport 514. Die Nutzlast der einzelnen Syslog-Nachrichten wird im allgemeinen Ereignisformat (Common Event Format, CEF) formatiert.

Verwenden Sie zum Konfigurieren des Syslog-Clients das Cmdlet Set-SyslogServer, das im privilegierten Endpunkt verfügbar ist.

Mit dieser Vorschau werden möglicherweise die folgenden drei Warnungen angezeigt. Wenn sie in Azure Stack angezeigt werden, enthalten diese Warnungen Beschreibungen und Anleitungen zur Behebung von Problemen.
- TITEL: Codeintegrität deaktivieren
- TITEL: Codeintegrität im Überwachungsmodus
- TITEL: Benutzerkonto erstellt
Solange diese Funktion nur als Vorschau verfügbar ist, sollte sie nicht in Produktionsumgebungen eingesetzt werden.

Behobene Probleme

Wir haben das Problem behoben, das das Öffnen einer neuen Supportanfrage aus dem Dropdownmenü innerhalb des Verwaltungsportals blockiert hat. Diese Option funktioniert jetzt wie vorgesehen.
Es wurden verschiedene Fehlerbehebungen hinsichtlich der Leistung, Stabilität, Sicherheit und des von Azure Stack eingesetzten Betriebssystems vorgenommen.

Voraussetzungen

Installieren Sie das Azure Stack-Update 1804, bevor Sie das Azure Stack-Update 1805 anwenden.
Installieren Sie das neueste verfügbare Update oder den Hotfix für Version 1804.
Führen Sie vor Beginn der Installation von Update 1805 Test-AzureStack aus, um den Status Ihrer Azure Stack-Instanz zu überprüfen und ggf. Betriebsprobleme zu beheben. Überprüfen Sie auch aktive Warnungen, und lösen Sie solche auf, die eine Aktion erfordern.

Bekannte Probleme mit dem Updateprozess

Während der Installation des Updates 1805 werden unter Umständen Warnungen mit folgender Meldung angezeigt: Fehler: Die Vorlage für FaultType UserAccounts.New fehlt. Sie können diese Warnungen problemlos ignorieren. Diese Warnungen werden automatisch geschlossen, nachdem das Update 1805 durchgeführt wurde.

Versuchen Sie nicht, während der Installation dieses Updates virtuelle Computer zu erstellen. Weitere Informationen zum Verwalten von Updates finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.

Schritte nach dem Update

Installieren Sie nach der Installation von 1805 alle entsprechenden Hotfixes. Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln sowie in unserer Wartungsrichtlinie.

KB 4344102 – Azure Stack Hotfix 1.1805.7.57.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zu dieser Buildversion vorgestellt.

Portal

Die technische Dokumentation für Azure Stack konzentriert sich auf das neueste Release. Aufgrund von Portaländerungen zwischen den Releases kann das, was bei der Verwendung der Azure Stack-Portale angezeigt wird, von dem abweichen, was in der Dokumentation angezeigt wird.

Pläne, die einem Benutzerabonnement als Add-On-Plan hinzugefügt wurden, können nicht gelöscht werden, auch wenn Sie den Plan aus dem Benutzerabonnement entfernen. Der Plan ist so lange vorhanden, bis die Abonnements gelöscht werden, die auf den Add-On-Plan verweisen.

Sie können mit dieser Version von Azure Stack keine Treiberupdates mit einem OEM-Erweiterungspaket durchführen. Dafür gibt es keine Problemumgehung.

Wenn Sie im Verwaltungs- oder Benutzerportal Übersicht für ein Speicherkonto auswählen, werden die Informationen aus dem Bereich Zusammenfassung nicht angezeigt. Im Bereich „Zusammenfassung“ werden Informationen über das Konto angezeigt, z.B. Ressourcengruppe, Speicherort, und Abonnement-ID. Weitere Optionen für die Übersicht sind verfügbar, z. B. Dienste und Überwachung sowie Optionen zum Öffnen im Explorer oder zum Löschen eines Speicherkontos.

Nicht verfügbare Informationen lassen sich mit dem PowerShell-Cmdlet Get-azureRMstorageaccount anzeigen.

Wenn Sie im Verwaltungs- oder Benutzerportal Tags für ein Speicherkonto auswählen, werden die Informationen nicht geladen und nicht angezeigt.

Nicht verfügbare Informationen lassen sich mit dem PowerShell-Cmdlet Get-AzureRmTag anzeigen.

Wenn Sie AD FS für Ihr Azure Stack-Identitätssystem verwenden und auf diese Version von Azure Stack aktualisieren, wird der Standardbesitzer des Abonnements für Standardanbieter auf den integrierten CloudAdmin-Benutzer zurückgesetzt.
Problemumgehung: Um dieses Problem nach der Installation dieses Updates zu beheben, führen Sie Schritt 3 unter Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbieter-Vertrauensstellung in Azure Stack aus, um den Besitzer des Abonnements für Standardanbieter zurückzusetzen.

Einige administrative Abonnementtypen sind nicht verfügbar. Wenn Sie Azure Stack auf diese Version aktualisieren, werden die zwei Abonnementtypen, die mit Version 1804 eingeführt wurden, nicht in der Konsole angezeigt. Dies entspricht dem erwarteten Verhalten. Die nicht verfügbaren Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Möglicherweise haben Sie die horizontale Scrollleiste am unteren Rand des Verwaltungs- und Benutzerportals nicht verwendet. Wenn Sie nicht auf die horizontale Bildlaufleiste zugreifen können, verwenden Sie die Breadcrumb-Leiste, um zu einem vorherigen Blatt im Portal zu navigieren. Wählen Sie hierzu den Namen des Blattes, das Sie anzeigen möchten, aus der Breadcrumb-Liste oben links im Portal aus.

Es ist es u.U. nicht möglich, Compute- oder Speicherressourcen im Administratorportal anzuzeigen. Grund für dieses Problem ist ein Fehler bei der Installation des Updates, der dazu führt, dass das Update fälschlicherweise als erfolgreich gemeldet wird. Wenn dieses Problem auftritt, wenden Sie sich an Microsoft Customer Support Services, um Unterstützung zu erhalten.

Es kann sein, dass im Portal ein leeres Dashboard angezeigt wird. Wählen Sie zum Wiederherstellen des Dashboards oben rechts im Portal das Zahnradsymbol und dann die Option Standardeinstellungen wiederherstellen.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Integrität und Überwachung

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:

Warnung 1:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Warnung 2:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Beide Warnungen #1 und #2 können ignoriert werden und werden nach einer gewissen Zeit automatisch geschlossen.

Möglicherweise wird Ihnen die folgende Warnung für Kapazität angezeigt. Bei dieser Warnung kann der in der Beschreibung angegebene Prozentsatz des verfügbaren Speichers variieren:

Warnung #3:
- NAME: Niedrige Arbeitsspeicherkapazität
- SCHWEREGRAD: Kritisch
- KOMPONENTE: Kapazität
- BESCHREIBUNG: Die Region hat mehr als 80,00 % des verfügbaren Speichers verbraucht. Beim Erstellen von virtuellen Computern mit großem Arbeitsspeicher kann ein Fehler auftreten.
In dieser Version von Azure Stack kann diese Warnung nicht ordnungsgemäß ausgelöst werden. Wenn die Mandanten-VMs weiterhin erfolgreich bereitgestellt werden, können Sie diese Warnung ignorieren.

Warnung #3 wird nicht automatisch geschlossen. Wenn Sie diese Warnung schließen, wird dieselbe Warnung von Azure Stack innerhalb von 15 Minuten erstellt.

Wenn Sie als Azure Stack-Operator eine Fehlermeldung über unzureichenden Speicher erhalten und virtuelle Computer der Mandanten nicht mit einem Fabric-VM-Erstellungsfehler bereitgestellt werden können, verfügt der Azure Stack-Stempel möglicherweise nicht über genügend Arbeitsspeicher. Mit dem Azure Stack Capacity Planner können Sie die verfügbare Kapazität für Ihre Workloads besser bestimmen.

Compute

Bei der Auswahl der Größe des virtuellen Computers für die Bereitstellung eines virtuellen Computers sind einige VM-Größen der Serie F beim Erstellen einer VM nicht als Teil der Größenauswahl sichtbar. Folgende VM-Größen werden im Selektor nicht angezeigt: F8s_v2, F16s_v2, F32s_v2 und F64s_v2.
Um das Problem zu umgehen, verwenden Sie eine der folgenden Methoden zum Bereitstellen einer VM. Bei jeder Methode müssen Sie die gewünschte VM-Größe angeben.
- Azure Resource Manager-Vorlage: Wenn Sie eine Vorlage verwenden, legen Sie vmSize in der Vorlage entsprechend der gewünschten VM-Größe fest. Der folgende Eintrag z.B. wird zum Bereitstellen einer VM mit der Größe F32s_v2 verwendet:
```
    "properties": {
    "hardwareProfile": {
            "vmSize": "Standard_F32s_v2"
    },
```
- Azure CLI: Sie können den Befehl az vm create verwenden und die VM-Größe als Parameter angeben, ähnlich wie --size "Standard_F32s_v2".
- PowerShell: Mit PowerShell können Sie New-AzureRMVMConfig mit dem Parameter verwenden, der die VM-Größe angibt, ähnlich wie -VMSize "Standard_F32s_v2".

Die Skalierungseinstellungen für Skalierungsgruppen für virtuelle Computer sind im Portal nicht verfügbar. Dieses Problem können Sie umgehen, indem Sie Azure PowerShell verwenden. Aufgrund der Versionsunterschiede bei PowerShell müssen Sie den -Name-Parameter statt des -VMScaleSetName-Parameters verwenden.

Wenn Sie im Portal unter Neu>Berechnen>Verfügbarkeitsgruppe eine Verfügbarkeitsgruppe erstellen, können Sie nur eine Verfügbarkeitsgruppe mit einer Fehlerdomäne und einer Updatedomäne erstellen. Erstellen Sie bei der Erstellung eines neuen virtuellen Computers zur Problemumgehung die Verfügbarkeitsgruppe mithilfe von PowerShell, der CLI oder im Portal.

Beim Erstellen von virtuellen Computern im Azure Stack-Benutzerportal zeigt das Portal eine falsche Anzahl von Datenträgern an, die an eine VM der Serie DS angefügt werden können. VMs der Serie DS können so viele Datenträger wie bei der Azure-Konfiguration aufnehmen.

Falls bei der Erstellung eines VM-Images ein Fehler auftritt, wird dem Blatt „Berechnung der VM-Images“ ggf. ein fehlerhaftes Element hinzugefügt, das nicht gelöscht werden kann.

Erstellen Sie zur Problemumgehung ein neues VM-Image mit einer Dummy-VHD, die per Hyper-V erstellt werden kann (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Das Problem, mit dem das Löschen des fehlerhaften Elements verhindert wird, sollte durch diesen Vorgang behoben werden. Anschließend können Sie das Element 15 Minuten nach der Erstellung des Dummy-Images erfolgreich löschen.

Danach können Sie versuchen, das VM-Image, bei dem zuvor ein Fehler aufgetreten ist, erneut herunterzuladen.

Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Benutzer eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Netzwerk

Sie können benutzerdefinierte Routen weder im Verwaltungs- noch im Benutzerportal erstellen. Dieses Problem umgehen Sie, indem Sie Azure PowerShell verwenden.

Wenn Sie unter Netzwerk auf VPN Gateway erstellen klicken, um eine VPN-Verbindung einzurichten, wird als VPN-Typ Richtlinienbasiert aufgeführt. Wählen Sie diese Option nicht aus. Nur die Option Routenbasiert wird in Azure Stack unterstützt.

Nachdem Sie eine VM erstellt und einer öffentlichen IP-Adresse zugeordnet haben, können Sie die Zuordnung dieser VM zu dieser IP-Adresse nicht mehr aufheben. Die Aufhebung der Zuordnung war scheinbar erfolgreich, aber die zuvor zugewiesene öffentliche IP-Adresse bleibt der ursprünglichen VM zugeordnet.

Derzeit müssen Sie ausschließlich neue öffentliche IP-Adressen für die Erstellung neuer VMs verwenden.

Dieses Verhalten tritt auch dann auf, wenn Sie die IP-Adresse einem neuen virtuellen Computer neu zuordnen (gewöhnlich als VIP-Austausch bezeichnet). Alle künftigen Versuche, eine Verbindung über diese IP-Adresse herzustellen, führen dazu, dass eine Verbindung mit dem ursprünglichen virtuellen Computer (und nicht mit dem neuen) hergestellt wird.

Wenn Sie eine Kontingentgrenze für eine Netzwerkressource heraufsetzen, die Teil eines Angebots und eines Plans ist, das bzw. der mit einem Mandantenabonnement verbunden ist, wird die neue Grenze nicht auf dieses Abonnement angewendet. Der neue Grenzwert gilt jedoch für neue Abonnements, die nach Heraufsetzen der Kontingentgrenze erstellt werden.

Um dieses Problem zu umgehen, verwenden Sie einen Skalierungsplan, um ein Netzwerkkontingent zu erhöhen, wenn der Plan bereits einem Abonnement zugeordnet ist. Weitere Informationen finden Sie in der Beschreibung der Vorgehensweise zum Bereitstellen eines Skalierungsplans.

Ein Abonnement, dem DNS-Zonen- oder Routingtabellenressourcen zugeordnet wurden, kann nicht gelöscht werden. Um das Abonnement erfolgreich zu löschen, müssen Sie zuerst die DNS-Zonen- und Routingtabellenressourcen aus dem Mandantenabonnement löschen.

Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse blockiert.

In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.

Azure Stack unterstützt nicht das Hinzufügen zusätzlicher Netzwerkschnittstellen zu einer VM-Instanz, nachdem die VM bereitgestellt wurde. Wenn die VM mehr als eine Netzwerkschnittstelle benötigt, müssen diese zum Zeitpunkt der Bereitstellung definiert werden.

Sie können das Verwaltungsportal nicht verwenden, um Regeln für eine Netzwerksicherheitsgruppe zu aktualisieren.

Problemumgehung für App Service: Wenn Sie eine Remotedesktopverbindung mit den Controllerinstanzen herstellen müssen, ändern Sie mit PowerShell die Sicherheitsregeln innerhalb der Netzwerksicherheitsgruppen. Im Folgenden werden Beispiele zum Zulassen und anschließenden Wiederherstellen der Konfiguration mit Verweigern vorgestellt:

Zulassen:

Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Verweigern:


Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL und MySQL

Auf Servern, die SQL oder MySQL hosten, kann nur der Ressourcenanbieter Elemente erstellen. Die auf einem Hostserver erstellten Elemente, die nicht vom Ressourcenanbieter erstellt wurden, könnten zu einem Zustand ohne Entsprechung führen.

Sonderzeichen, einschließlich Leerzeichen und Interpunktion, werden in den Namen für die Familie oder Ebene nicht unterstützt, wenn Sie die SKU für die SQL- und MySQL-Ressourcenanbieter erstellen.

Hinweis

Nachdem Sie ein Update auf Azure Stack 1805 ausgeführt haben, können Sie die zuvor bereitgestellten Ressourcenanbieter SQL und MySQL weiterhin verwenden. Es wird empfohlen, SQL und MySQL zu aktualisieren, sobald ein neues Release verfügbar ist. Wenden Sie Updates wie bei Azure Stack sequenziell auf die Ressourcenanbieter SQL und MySQL an. Wenn Sie z.B. Version 1803 verwenden, wenden Sie zuerst Version 1804 an, und aktualisieren Sie dann auf 1805.

Die Installation des Updates 1805 wirkt sich nicht auf die aktuelle Verwendung der von Ihren Benutzern verwendeten Ressourcenanbieter SQL oder MySQL aus. Unabhängig von der Version der Ressourcenanbieter, die Sie verwenden, bleiben Ihre Benutzerdaten in deren Datenbanken davon unberührt und stehen weiterhin für den Zugriff zur Verfügung.

App Service

Benutzer müssen den Speicherressourcenanbieter vor dem Erstellen seiner ersten Azure-Funktion im Abonnement registrieren.

Um die Infrastruktur (Worker-, Verwaltungs-, Front-End-Rollen) aufzuskalieren, müssen Sie PowerShell verwenden, wie in den Anmerkungen zu dieser Version für die Berechnung beschrieben.

App Service kann zurzeit nur im Abonnement für Standardanbieter bereitgestellt werden.

Verbrauch

Die Ansicht „Verwendung“ für die Nutzungsdaten öffentlicher IP-Adressen zeigt den gleichen EventDateTime-Wert für jeden Datensatz anstatt des TimeDate-Stempels, der anzeigt, wann dieser jeweils erstellt wurde. Derzeit können Sie diese Daten nicht nutzen, um eine genaue Buchhaltung über die Nutzung öffentlicher IP-Adressen durchzuführen.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1805 hier herunterladen.

Siehe auch

Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.
Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

1804 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

In diesem Artikel wird beschrieben, welche Verbesserungen und Fehlerbehebungen in diesem Updatepaket 1804 enthalten sind, welche bekannten Probleme es für dieses Release gibt und wo das Update heruntergeladen werden kann. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1804 ist 20180513.1.

Neue Funktionen

Dieses Update enthält die folgenden Verbesserungen für Azure Stack.

Visual Studio-Unterstützung für getrennte Azure Stack-Bereitstellungen mithilfe von AD FS. In Visual Studio können Sie ab sofort Abonnements hinzufügen und sich mithilfe von AD FS-Anmeldeinformationen für Verbundbenutzer authentifizieren.

Möglichkeit zum Einsatz virtueller Computer der Av2- und F-Serie. In Azure Stack können ab sofort virtuelle Computer basierend auf den Größen virtueller Computer der Av2- und F-Serie eingesetzt werden. Weitere Informationen finden Sie unter In Azure Stack unterstützte VM-Größen.

Neue Verwaltungsabonnements. Mit 1804 gibt es im Portal zwei neue Abonnementtypen. Diese neuen Abonnementtypen sind zusätzlich zum Standardabonnement des Anbieters verfügbar und werden in neuen Azure Stack-Installationen ab Version 1804 angezeigt. Verwenden Sie diese neuen Abonnementtypen nicht mit dieser Azure Stack-Version. Die Verfügbarkeit dieser Abonnementtypen wird in einem zukünftigen Update bekanntgegeben.

Wenn Sie Azure Stack auf Version 1804 aktualisieren, sind die zwei neuen Abonnementtypen nicht sichtbar. Neue Bereitstellungen von integrierten Azure Stack-Systemen und -Installationen des Azure Stack Development Kit ab Version 1804 haben jedoch Zugriff auf alle drei Abonnementtypen.

Diese neuen Abonnementtypen sind Bestandteil einer größeren Änderung, um das Abonnement für Standardanbieter zu sichern und die Bereitstellung von freigegebenen Ressourcen wie SQL-Hostserver zu vereinfachen. Da Azure Stack in zukünftigen Updates weitere Bestandteile dieser größeren Änderung enthalten wird, gehen möglicherweise die unter diesen neuen Abonnementtypen bereitgestellten Ressourcen verloren.

Derzeit sind drei Abonnementtypen sichtbar:
- Abonnement für Standardanbieter: Diesen Abonnementtyp können Sie weiterhin verwenden.
- Abonnement für Messungen: Verwenden Sie diesen Abonnementtyp nicht.
- Abonnement für die Nutzung: Verwenden Sie diesen Abonnementtyp nicht.

Behobene Probleme

Im Verwaltungsportal müssen Sie die Kachel "Aktualisieren" nicht mehr aktualisieren, bevor Die Informationen angezeigt werden.

Sie können jetzt das Verwaltungsportal verwenden, um Speichermetriken für Blob-Dienst, Tabellendienst und Warteschlangendienst zu bearbeiten.

Wenn Sie unter "Netzwerk" auf "Verbindung" klicken, um eine VPN-Verbindung einzurichten, ist site-to-site (IPsec) jetzt die einzige verfügbare Option.
Es wurden verschiedene Fehlerbehebungen hinsichtlich der Leistung, Stabilität, Sicherheit und des von Azure Stack eingesetzten Betriebssystems vorgenommen.

Zusätzliche, zeitlich auf dieses Update abgestimmte Releases

Die folgenden Updates sind jetzt verfügbar, benötigen jedoch nicht Azure Stack Update 1804.

Update für das Microsoft Azure Stack System Center Operations Manager-Überwachungspaket. Eine neue Version (1.0.3.0) des Microsoft System Center Operations Manager-Überwachungspakets für Azure Stack steht zum Herunterladen zur Verfügung. Mit dieser Version können Sie Dienstprinzipale verwenden, wenn Sie eine verbundene Azure Stack-Bereitstellung hinzufügen. Diese Version bietet auch eine Updateverwaltungsoberfläche, mit der Sie die Wartungsaktion direkt in Operations Manager ausführen können. Es gibt auch neue Dashboards, die Ressourcenanbieter, Skalierungseinheiten und Skalierungseinheitenknoten anzeigen.
Neue Azure Stack Admin PowerShell Version 1.3.0. Azure Stack PowerShell 1.3.0 ist jetzt für die Installation verfügbar. Diese Version stellt Befehle für alle Administratorressourcenanbieter zum Verwalten von Azure Stack zur Verfügung. Bei diesem Release werden manche Inhalte aus dem GitHub-Repository für Azure Stack-Tools eingestellt.

Um ausführliche Informationen zur Installation zu erhalten, beachten Sie die Anweisungen oder den Hilfeinhalt für das Azure Stack-Modul 1.3.0.
Erstes Release der Azure Stack-REST-API-Referenz. Die API-Referenz für alle Azure Stack-Administratorressourcenanbieter ist jetzt veröffentlicht.

Voraussetzungen

Installieren Sie das Azure Stack 1803-Update, bevor Sie das Azure Stack 1804-Update anwenden.
Installieren Sie das neueste verfügbare Update oder Hotfix für Version 1803.

Bekannte Probleme mit dem Updateprozess

Während der Installation des Updates 1804 werden unter Umständen Warnungen mit folgender Meldung angezeigt: Fehler: Die Vorlage für FaultType UserAccounts.New fehlt. Sie können diese Warnungen problemlos ignorieren. Diese Warnungen werden automatisch geschlossen, nachdem das Update 1804 durchgeführt wurde.

Versuchen Sie nicht, während der Installation dieses Updates virtuelle Computer zu erstellen. Weitere Informationen zum Verwalten von Updates finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.

Schritte nach dem Update

Installieren Sie nach der Installation von 1804 alle entsprechenden Hotfixes. Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln sowie in unserer Wartungsrichtlinie.

KB 4344114 – Azure Stack-Hotfix 1.0.180527.15.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zum Build 20180513.1 vorgestellt.

Portal

Die technische Dokumentation für Azure Stack konzentriert sich auf das neueste Release. Aufgrund von Portaländerungen zwischen den Releases kann das, was bei der Verwendung der Azure Stack-Portale angezeigt wird, von dem abweichen, was in der Dokumentation angezeigt wird.

Sie können mit dieser Version von Azure Stack keine Treiberupdates mit einem OEM-Erweiterungspaket durchführen. Dafür gibt es keine Problemumgehung.

Nachdem Sie diese Version von Azure Stack installiert oder aktualisiert haben, können Sie möglicherweise keine Azure Stack-Skalierungseinheiten im Verwaltungsportal anzeigen.
Problemumgehung: Verwenden Sie PowerShell zum Anzeigen von Informationen zu Skalierungseinheiten. Weitere Informationen finden Sie in der Hilfe zum Azure Stack-Modul 1.3.0.

Wenn Sie AD FS für Ihr Azure Stack-Identitätssystem verwenden und auf diese Version von Azure Stack aktualisieren, wird der Standardbesitzer des Abonnements für Standardanbieter auf den integrierten CloudAdmin-Benutzer zurückgesetzt.
Problemumgehung: Um dieses Problem nach der Installation dieses Updates zu beheben, führen Sie Schritt 3 unter Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbieter-Vertrauensstellung in Azure Stack aus, um den Besitzer des Abonnements für Standardanbieter zurückzusetzen.

Einige administrative Abonnementtypen sind nicht verfügbar. Wenn Sie Azure Stack auf diese Version aktualisieren, werden die zwei Abonnementtypen, die mit Version 1804 eingeführt wurden, nicht in der Konsole angezeigt. Dies entspricht dem erwarteten Verhalten. Die nicht verfügbaren Abonnementtypen sind Messungsabonnement und Verbrauchsabonnement. Diese Abonnementtypen sind in neuen Azure Stack-Umgebungen ab Version 1804 sichtbar, aber noch nicht zur Verwendung bereit. Sie sollten weiterhin den Typ Standardabonnement des Anbieters verwenden.

Die Funktion, mit der innerhalb des Administratorportals eine neue Supportanfrage über die Dropdownliste geöffnet wird, ist nicht verfügbar. Verwenden Sie stattdessen den folgenden Link:
- Für integrierte Azure Stack-Systeme muss https://aka.ms/newsupportrequest verwendet werden.

Möglicherweise haben Sie die horizontale Scrollleiste am unteren Rand des Verwaltungs- und Benutzerportals nicht verwendet. Wenn Sie nicht auf die horizontale Bildlaufleiste zugreifen können, verwenden Sie die Breadcrumb-Leiste, um zu einem vorherigen Blatt im Portal zu navigieren. Wählen Sie hierzu den Namen des Blattes, das Sie anzeigen möchten, aus der Breadcrumb-Liste oben links im Portal aus.

Es ist es u.U. nicht möglich, Compute- oder Speicherressourcen im Administratorportal anzuzeigen. Grund für dieses Problem ist ein Fehler bei der Installation des Updates, der dazu führt, dass das Update fälschlicherweise als erfolgreich gemeldet wird. Wenn dieses Problem auftritt, wenden Sie sich an Microsoft Customer Support Services, um Unterstützung zu erhalten.

Es kann sein, dass im Portal ein leeres Dashboard angezeigt wird. Wählen Sie zum Wiederherstellen des Dashboards oben rechts im Portal das Zahnradsymbol und dann die Option Standardeinstellungen wiederherstellen.

Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.

Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.

Im Verwaltungsportal wird unter Umständen eine kritische Warnung für die Komponente Microsoft.Update.Admin angezeigt. Name, Beschreibung und Behebung der Warnung werden wie folgt angezeigt:
- FEHLER: Vorlage für FaultType ResourceProviderTimeout fehlt.
Diese Warnung kann ignoriert werden.

Integrität und Überwachung

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:

Warnung 1:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Warnung 2:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Beide Warnungen können ignoriert werden. Sie werden nach einem bestimmten Zeitraum automatisch geschlossen.

Compute

Bei der Auswahl der Größe des virtuellen Computers für die Bereitstellung eines virtuellen Computers sind einige VM-Größen der Serie F beim Erstellen einer VM nicht als Teil der Größenauswahl sichtbar. Folgende VM-Größen werden im Selektor nicht angezeigt: F8s_v2, F16s_v2, F32s_v2 und F64s_v2.
Um das Problem zu umgehen, verwenden Sie eine der folgenden Methoden zum Bereitstellen einer VM. Bei jeder Methode müssen Sie die gewünschte VM-Größe angeben.
- Azure Resource Manager-Vorlage: Wenn Sie eine Vorlage verwenden, legen Sie vmSize in der Vorlage entsprechend der gewünschten VM-Größe fest. Der folgende Inhalt z.B. wird zum Bereitstellen einer VM mit der Größe F32s_v2 verwendet:
```
    "properties": {
    "hardwareProfile": {
            "vmSize": "Standard_F32s_v2"
    },
```
- Azure CLI: Sie können den Befehl az vm create verwenden und die VM-Größe als Parameter angeben, ähnlich wie --size "Standard_F32s_v2".
- PowerShell: Mit PowerShell können Sie New-AzureRMVMConfig mit dem Parameter verwenden, der die VM-Größe angibt, ähnlich wie -VMSize "Standard_F32s_v2".

Die Skalierungseinstellungen für Skalierungsgruppen für virtuelle Computer sind im Portal nicht verfügbar. Dieses Problem können Sie umgehen, indem Sie Azure PowerShell verwenden. Aufgrund der Versionsunterschiede bei PowerShell müssen Sie den -Name-Parameter statt des -VMScaleSetName-Parameters verwenden.

Wenn Sie im Portal unter Neu>Berechnen>Verfügbarkeitsgruppe eine Verfügbarkeitsgruppe erstellen, können Sie nur eine Verfügbarkeitsgruppe mit einer Fehlerdomäne und einer Updatedomäne erstellen. Erstellen Sie bei der Erstellung eines neuen virtuellen Computers zur Problemumgehung die Verfügbarkeitsgruppe mithilfe von PowerShell, der CLI oder im Portal.

Beim Erstellen von virtuellen Computern im Azure Stack-Benutzerportal zeigt das Portal eine falsche Anzahl von Datenträgern an, die an eine VM der Serie D angefügt werden können. Alle unterstützten virtuellen Computer der Serie D können so viele Datenträger wie bei der Azure-Konfiguration aufnehmen.

Falls bei der Erstellung eines VM-Images ein Fehler auftritt, wird dem Blatt „Berechnung der VM-Images“ ggf. ein fehlerhaftes Element hinzugefügt, das nicht gelöscht werden kann.

Erstellen Sie zur Problemumgehung ein neues VM-Image mit einer Dummy-VHD, die per Hyper-V erstellt werden kann (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Das Problem, mit dem das Löschen des fehlerhaften Elements verhindert wird, sollte durch diesen Vorgang behoben werden. Anschließend können Sie das Element 15 Minuten nach der Erstellung des Dummy-Images erfolgreich löschen.

Danach können Sie versuchen, das VM-Image, bei dem zuvor ein Fehler aufgetreten ist, erneut herunterzuladen.

Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Benutzer eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Netzwerk

Wenn Sie unter Netzwerk auf VPN Gateway erstellen klicken, um eine VPN-Verbindung einzurichten, wird als VPN-Typ Richtlinienbasiert aufgeführt. Wählen Sie diese Option nicht aus. Nur die Option Routenbasiert wird in Azure Stack unterstützt.

Nachdem Sie eine VM erstellt und einer öffentlichen IP-Adresse zugeordnet haben, können Sie die Zuordnung dieser VM zu dieser IP-Adresse nicht mehr aufheben. Die Aufhebung der Zuordnung war scheinbar erfolgreich, aber die zuvor zugewiesene öffentliche IP-Adresse bleibt der ursprünglichen VM zugeordnet.

Derzeit müssen Sie ausschließlich neue öffentliche IP-Adressen für die Erstellung neuer VMs verwenden.

Dieses Verhalten tritt auch dann auf, wenn Sie die IP-Adresse einem neuen virtuellen Computer neu zuordnen (gewöhnlich als VIP-Austausch bezeichnet). Alle künftigen Versuche, eine Verbindung über diese IP-Adresse herzustellen, führen dazu, dass eine Verbindung mit dem ursprünglich zugeordneten virtuellen Computer (und nicht mit dem neuen) hergestellt wird.

Wenn Sie eine Kontingentgrenze für eine Netzwerkressource heraufsetzen, die Teil eines Angebots und eines Plans ist, das bzw. der mit einem Mandantenabonnement verbunden ist, wird die neue Grenze nicht auf dieses Abonnement angewendet. Der neue Grenzwert gilt jedoch für neue Abonnements, die nach Heraufsetzen der Kontingentgrenze erstellt werden.

Um dieses Problem zu umgehen, verwenden Sie einen Skalierungsplan, um ein Netzwerkkontingent zu erhöhen, wenn der Plan bereits einem Abonnement zugeordnet ist. Weitere Informationen finden Sie in der Beschreibung der Vorgehensweise zum Bereitstellen eines Skalierungsplans.

Ein Abonnement, dem DNS-Zonen- oder Routingtabellenressourcen zugeordnet wurden, kann nicht gelöscht werden. Um das Abonnement erfolgreich zu löschen, müssen Sie zuerst die DNS-Zonen- und Routingtabellenressourcen aus dem Mandantenabonnement löschen.

Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse blockiert.

In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.

Azure Stack unterstützt nicht das Hinzufügen zusätzlicher Netzwerkschnittstellen zu einer VM-Instanz, nachdem die VM bereitgestellt wurde. Wenn die VM mehr als eine Netzwerkschnittstelle benötigt, müssen diese zum Zeitpunkt der Bereitstellung definiert werden.

Sie können das Verwaltungsportal nicht verwenden, um Regeln für eine Netzwerksicherheitsgruppe zu aktualisieren.

Zulassen:

Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Verweigern:


Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL und MySQL

Auf Servern, die SQL oder MySQL hosten, kann nur der Ressourcenanbieter Elemente erstellen. Die auf einem Hostserver erstellten Elemente, die nicht vom Ressourcenanbieter erstellt wurden, könnten zu einem Zustand ohne Entsprechung führen.

Sonderzeichen, einschließlich Leerzeichen und Interpunktion, werden in den Namen für die Familie oder Ebene nicht unterstützt, wenn Sie die SKU für die SQL- und MySQL-Ressourcenanbieter erstellen.

Hinweis

Nach dem Update auf Azure Stack 1804 können Sie weiterhin die zuvor bereitgestellten SQL- und MySQL-Ressourcenanbieter verwenden. Es wird empfohlen, SQL und MySQL zu aktualisieren, sobald ein neues Release verfügbar ist. Wenden Sie Updates wie bei Azure Stack sequenziell auf die Ressourcenanbieter SQL und MySQL an. Wenn Sie z.B. Version 1802 verwenden, wenden Sie zuerst Version 1803 an, und aktualisieren Sie sie dann auf 1804.

Die Installation des Updates 1804 wirkt sich nicht auf die aktuelle Verwendung der von Ihren Benutzern verwendeten Ressourcenanbieter SQL oder MySQL aus. Unabhängig von der Version der Ressourcenanbieter, die Sie verwenden, bleiben Ihre Benutzerdaten in deren Datenbanken davon unberührt und stehen weiterhin für den Zugriff zur Verfügung.

App Service

Benutzer müssen den Speicherressourcenanbieter vor dem Erstellen seiner ersten Azure-Funktion im Abonnement registrieren.

Um die Infrastruktur (Worker-, Verwaltungs-, Front-End-Rollen) aufzuskalieren, müssen Sie PowerShell verwenden, wie in den Anmerkungen zu dieser Version für die Berechnung beschrieben.

App Service kann derzeit nur im Abonnement für Standardanbieter bereitgestellt werden. In einem zukünftigen Update wird App Service im neuen in Azure Stack 1804 eingeführten Abonnement für Messungen bereitgestellt, auch werden alle vorhandenen Bereitstellungen zu diesem neuen Abonnement migriert.

Verbrauch

Die Ansicht „Verwendung“ für die Nutzungsdaten öffentlicher IP-Adressen zeigt den gleichen EventDateTime-Wert für jeden Datensatz anstatt des TimeDate-Stempels, der anzeigt, wann dieser jeweils erstellt wurde. Derzeit können Sie diese Daten nicht nutzen, um eine genaue Buchhaltung über die Nutzung öffentlicher IP-Adressen durchzuführen.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1804 hier herunterladen.

Siehe auch

Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.
Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

1803 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

In diesem Artikel wird beschrieben, welche Verbesserungen und Fehlerbehebungen in diesem Updatepaket 1803 enthalten sind, welche bekannten Probleme es für dieses Release gibt und wo das Update heruntergeladen werden kann. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1803 ist 20180329.1.

Voraussetzungen

Wichtig

Versuchen Sie nicht, während der Installation dieses Updates virtuelle Computer zu erstellen. Weitere Informationen zum Verwalten von Updates finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.

Voraussetzungen

Installieren Sie das Azure Stack 1802-Update, bevor Sie das Azure Stack 1803-Update anwenden.
Installieren Sie AzS Hotfix 1.0.180312.1 – Build 20180222.2, bevor Sie das Azure Stack 1803-Update anwenden. Durch diesen Hotfix wird Windows Defender aktualisiert. Dieser ist beim Herunterladen von Updates für Azure Stack verfügbar.

Um den Hotfix zu installieren, führen Sie die üblichen Verfahren zum Installieren von Updates für Azure Stack durch. Der Name des Updates wird als AzS Hotfix 1.0.180312.1 angezeigt und enthält die folgenden Dateien:
- PUPackageHotFix_20180222.2-1.exe
- PUPackageHotFix_20180222.2-1.bin
- Metadata.xml
Nachdem Sie diese Dateien in ein Speicherkonto und in einen Container hochgeladen haben, führen Sie die Installation im Verwaltungsportal über die Kachel „Aktualisieren“ aus.

Im Gegensatz zu Updates für Azure Stack wird die Version von Azure Stack nicht durch die Installation dieses Updates geändert. Um zu überprüfen, ob dieses Update installiert wurde, sehen Sie sich die Liste Installierte Updates an.

Neue Funktionen

Dieses Update enthält die folgenden Verbesserungen und Fehlerbehebungen für Azure Stack.

Aktualisieren von Azure Stack-Geheimnissen – (Konten und Zertifikate). Weitere Informationen zum Verwalten von Geheimnissen finden Sie unter Rotieren von Geheimnissen in Azure Stack.

Automatische Umleitung an HTTPS beim Zugriff auf die Administrator- und Benutzerportale über HTTP. Diese Verbesserung wurde basierend auf dem UserVoice-Feedback für Azure Stack vorgenommen.

Zugriff auf den Marketplace: Sie können nun den Azure Stack Marketplace öffnen, indem Sie die Option +Neu in den Admin- und Benutzerportalen wie die in den Azure-Portalen verwenden.

Azure Monitor – Azure Stack fügt Azure Monitor zu den Administrator- und Benutzerportalen hinzu. Dazu gehören neue Explorer für Metriken und Aktivitätsprotokolle. Um von externen Netzwerken auf Azure Monitor zugreifen zu können, muss der Port 13012 in Firewallkonfigurationen geöffnet sein. Weitere Informationen zu Ports, die von Azure Stack benötigt werden, finden Sie unter Azure Stack-Rechenzentrumsintegration – Veröffentlichen von Endpunkten.

Im Rahmen dieser Änderung wird die Option Überwachungsprotokolle unter Weitere Dienste zudem jetzt als Aktivitätsprotokolle angezeigt. Die Funktionalität entspricht jetzt dem Azure-Portal.

Sparsedateien – Wenn Sie ein neues Image zu Azure Stack hinzufügen oder ein Image über die Marketplace-Syndikation hinzufügen, wird das Image in eine Sparsedatei konvertiert. Images, die vor der Verwendung von Azure Stack Version 1803 hinzugefügt wurden, können nicht konvertiert werden. Stattdessen müssen Sie diese Images über die Marketplace-Syndikation erneut übermitteln, um dieses Feature nutzen zu können.

Sparsedateien stellen ein effizientes Dateiformat dar, das zur Verringerung der Speicherplatznutzung und Verbesserung von E/A-Vorgängen verwendet wird. Weitere Informationen zu Windows Server finden Sie unter Fsutil-Sparsedatei.

Behobene Probleme

Interner Lastenausgleich (Internal Load Balancing, ILB) behandelt jetzt ordnungsgemäß MAC-Adressen für Back-End-VMs, was bewirkt, dass ILB Pakete in das Back-End-Netzwerk abgibt, wenn Linux-Instanzen im Back-End-Netzwerk verwendet werden. Der ILB funktioniert gut mit Windows-Instanzen im Back-End-Netzwerk.

Ein Problem, bei dem VPN-Verbindungen zwischen Azure Stack aufgrund von Azure Stack mit unterschiedlichen Einstellungen für die IKE-Richtlinie als Azure getrennt wurden. Die Werte für SALifetime (Zeit) und SALiftetime (Bytes) waren nicht mit Azure kompatibel und wurden in 1803 an die Azure-Einstellungen angepasst. Der Wert für SALifetime (Sekunden) vor 1803 betrug 14.400 und wurde nun in Version 1803 in 27.000 geändert. Der Wert für SALifetime (Bytes) vor 1803 betrug 819.200 und wurde nun in Version 1803 in 33.553.408 geändert.

Das IP-Problem, bei dem VPN-Verbindungen zuvor im Portal sichtbar waren; Das Aktivieren oder Umschalten der IP-Weiterleitung hat jedoch keine Auswirkung. Das Feature ist standardmäßig aktiviert, und es besteht noch keine Möglichkeit, dies zu ändern. Das Steuerelement wurde aus dem Portal entfernt.

Azure Stack unterstützt keine richtlinienbasierten VPN-Gateways, obwohl die Option im Portal angezeigt wird. Die Option wurde aus dem Portal entfernt.

Azure Stack verhindert jetzt die Größenänderung eines virtuellen Computers, der mit dynamischen Datenträgern erstellt wird.

Nutzungsdaten für virtuelle Computer werden jetzt stündlich getrennt. Dies steht im Einklang mit Azure.

Das Problem, bei dem das Blatt "Einstellungen" für vNet-Subnetze im Administrator- und Benutzerportal nicht geladen werden kann. Verwenden Sie zur Problemumgehung PowerShell und das Cmdlet Get-AzureRmVirtualNetworkSubnetConfig, um diese Informationen anzuzeigen und zu verwalten.
Bei der Erstellung eines virtuellen Computers wird die Meldung Preise können nicht angezeigt werden nicht mehr angezeigt, wenn Sie eine VM-Größe auswählen.
Es wurden verschiedene Fehlerbehebungen hinsichtlich der Leistung, Stabilität, Sicherheit und des von Azure Stack eingesetzten Betriebssystems vorgenommen.

Änderungen

Die Methode der Änderung des Zustands eines neu erstellten Angebots von Privat in Öffentlich oder Außer Betrieb hat sich geändert. Weitere Informationen finden Sie unter Erstellen von Angeboten in Azure Stack.

Bekannte Probleme mit dem Updateprozess

Während der Installation des 1803-Updates kann es zu Ausfallzeiten des BLOB-Diensts und interner Dienste kommen, die blob-Dienst verwenden. Betroffen sind auch einige Vorgänge in virtuellen Computern. Durch diese Ausfallzeit können Fehler bei Mandantenvorgängen oder Warnungen von Diensten verursacht werden, die nicht auf Daten zugreifen können. Dieses Problem löst sich nach der Installation des Updates von selbst.

Schritte nach dem Update

Installieren Sie nach der Installation von 1803 alle entsprechenden Hotfixes. Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln sowie in unserer Wartungsrichtlinie.
- KB 4344115 – Azure Stack-Hotfix 1.0.180427.15.
Überprüfen Sie nach der Installation dieses Updates die Firewallkonfiguration, um sicherzustellen, dass die erforderlichen Ports offen sind. Mit diesem Update beispielsweise wird der Dienst Azure Monitor eingeführt, der einen Wechsel von Überwachungsprotokollen zu Aktivitätsprotokollen beinhaltet. Durch diese Änderung wird jetzt Port 13012 verwendet, der ebenfalls offen sein muss.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zum Build 20180323.2 vorgestellt.

Portal

Wenn Sie AD FS für Ihr Azure Stack-Identitätssystem verwenden und auf diese Version von Azure Stack aktualisieren, wird der Standardbesitzer des Abonnements für Standardanbieter auf den integrierten CloudAdmin-Benutzer zurückgesetzt.
Problemumgehung: Um dieses Problem nach der Installation dieses Updates zu beheben, führen Sie Schritt 3 unter Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbieter-Vertrauensstellung in Azure Stack aus, um den Besitzer des Abonnements für Standardanbieter zurückzusetzen.
Die Funktion, mit der innerhalb des Administratorportals eine neue Supportanfrage über die Dropdownliste geöffnet wird, ist nicht verfügbar. Verwenden Sie stattdessen den folgenden Link:
- Für integrierte Azure Stack-Systeme muss https://aka.ms/newsupportrequest verwendet werden.

Im Verwaltungsportal ist es nicht möglich, Speichermetriken für Blob-Dienst, Tabellendienst oder Warteschlangendienst zu bearbeiten. Wenn Sie zum Speicher navigieren und dann die Kachel für Blob-Dienst, Tabellenspeicherdienst oder Warteschlangendienst auswählen, wird ein neues Blatt mit dem Metrikdiagramm für diesen Dienst geöffnet. Wenn Sie anschließend oben in der Kachel „Metrikdiagramm“ die Option „Bearbeiten“ auswählen, wird das Blatt "Diagramm bearbeiten" geöffnet, welches jedoch keine Optionen zum Bearbeiten von Metriken anzeigt.
Es ist es u.U. nicht möglich, Compute- oder Speicherressourcen im Administratorportal anzuzeigen. Grund für dieses Problem ist ein Fehler bei der Installation des Updates, der dazu führt, dass das Update fälschlicherweise als erfolgreich gemeldet wird. Wenn dieses Problem auftritt, wenden Sie sich an Microsoft Customer Support Services, um Unterstützung zu erhalten.
Es kann sein, dass im Portal ein leeres Dashboard angezeigt wird. Wählen Sie zum Wiederherstellen des Dashboards oben rechts im Portal das Zahnradsymbol und dann die Option Standardeinstellungen wiederherstellen.
Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.
Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.
Im Dashboard des Verwaltungsportals tritt beim Anzeigen von Informationen zu Updates über die Kachel „Aktualisieren“ ein Fehler auf. Klicken Sie zur Behebung dieses Problems auf die Kachel, um sie zu aktualisieren.
Im Verwaltungsportal wird unter Umständen eine kritische Warnung für die Komponente Microsoft.Update.Admin angezeigt. Name, Beschreibung und Behebung der Warnung werden wie folgt angezeigt:
- FEHLER: Vorlage für FaultType ResourceProviderTimeout fehlt.
Diese Warnung kann ignoriert werden.

Integrität und Überwachung

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:

Warnung 1:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Warnung 2:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Beide Warnungen können ignoriert werden. Sie werden nach einem bestimmten Zeitraum automatisch geschlossen.

Marketplace

Benutzer können den gesamten Marketplace ohne Abonnement durchsuchen, und es werden administrative Elemente wie Pläne und Angebote angezeigt. Diese Elemente sind für Benutzer nicht funktional.

Compute

Die Skalierungseinstellungen für Skalierungsgruppen für virtuelle Computer sind im Portal nicht verfügbar. Dieses Problem können Sie umgehen, indem Sie Azure PowerShell verwenden. Aufgrund der Versionsunterschiede bei PowerShell müssen Sie den -Name-Parameter statt des -VMScaleSetName-Parameters verwenden.
Wenn Sie im Portal unter Neu>Berechnen>Verfügbarkeitsgruppe eine Verfügbarkeitsgruppe erstellen, können Sie nur eine Verfügbarkeitsgruppe mit einer Fehlerdomäne und einer Updatedomäne erstellen. Erstellen Sie bei der Erstellung eines neuen virtuellen Computers zur Problemumgehung die Verfügbarkeitsgruppe mithilfe von PowerShell, der CLI oder im Portal.
Beim Erstellen von virtuellen Computern im Azure Stack-Benutzerportal zeigt das Portal eine falsche Anzahl von Datenträgern an, die an eine VM der Serie D angefügt werden können. Alle unterstützten virtuellen Computer der Serie D können so viele Datenträger wie bei der Azure-Konfiguration aufnehmen.
Falls bei der Erstellung eines VM-Images ein Fehler auftritt, wird dem Blatt „Berechnung der VM-Images“ ggf. ein fehlerhaftes Element hinzugefügt, das nicht gelöscht werden kann.

Erstellen Sie zur Problemumgehung ein neues VM-Image mit einer Dummy-VHD, die per Hyper-V erstellt werden kann (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Das Problem, mit dem das Löschen des fehlerhaften Elements verhindert wird, sollte durch diesen Vorgang behoben werden. Anschließend können Sie das Element 15 Minuten nach der Erstellung des Dummy-Images erfolgreich löschen.

Danach können Sie versuchen, das VM-Image, bei dem zuvor ein Fehler aufgetreten ist, erneut herunterzuladen.
Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Benutzer eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Netzwerk

Nachdem Sie eine VM erstellt und einer öffentlichen IP-Adresse zugeordnet haben, können Sie die Zuordnung dieser VM zu dieser IP-Adresse nicht mehr aufheben. Die Aufhebung der Zuordnung war scheinbar erfolgreich, aber die zuvor zugewiesene öffentliche IP-Adresse bleibt der ursprünglichen VM zugeordnet.

Derzeit müssen Sie ausschließlich neue öffentliche IP-Adressen für die Erstellung neuer VMs verwenden.

Dieses Verhalten tritt auch dann auf, wenn Sie die IP-Adresse einem neuen virtuellen Computer neu zuordnen (gewöhnlich als VIP-Austausch bezeichnet). Alle künftigen Versuche, eine Verbindung über diese IP-Adresse herzustellen, führen dazu, dass eine Verbindung mit dem ursprünglich zugeordneten virtuellen Computer (und nicht mit dem neuen) hergestellt wird.
Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse blockiert.
In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.
Azure Stack unterstützt nicht das Hinzufügen zusätzlicher Netzwerkschnittstellen zu einer VM-Instanz, nachdem die VM bereitgestellt wurde. Wenn die VM mehr als eine Netzwerkschnittstelle benötigt, müssen diese zum Zeitpunkt der Bereitstellung definiert werden.

Sie können das Verwaltungsportal nicht verwenden, um Regeln für eine Netzwerksicherheitsgruppe zu aktualisieren.

Zulassen:

Add-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Verweigern:


Add-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL und MySQL

Bevor Sie fortfahren, überprüfen Sie den wichtigen Hinweis unter Bevor Sie beginnen bei den Anmerkungen zu dieser Version.
Es kann bis zu einer Stunde dauern, bis Benutzer Datenbanken in einer neuen SQL- oder MySQL-Bereitstellung erstellen können.
Auf Servern, die SQL oder MySQL hosten, kann nur der Ressourcenanbieter Elemente erstellen. Die auf einem Hostserver erstellten Elemente, die nicht vom Ressourcenanbieter erstellt wurden, könnten zu einem Zustand ohne Entsprechung führen.

Sonderzeichen, einschließlich Leerzeichen und Interpunktion, werden im Namen für die Familie nicht unterstützt, wenn Sie die SKU für die SQL- und MySQL-Ressourcenanbieter erstellen.

Hinweis

Nachdem Sie ein Update auf Azure Stack 1803 ausgeführt haben, können Sie die zuvor bereitgestellten Ressourcenanbieter SQL und MySQL weiterhin verwenden. Es wird empfohlen, SQL und MySQL zu aktualisieren, sobald ein neues Release verfügbar ist. Wenden Sie Updates wie bei Azure Stack sequenziell auf die Ressourcenanbieter SQL und MySQL an. Wenn Sie z.B. Version 1711 verwenden, wenden Sie zuerst Version 1712, dann 1802 und schließlich 1803 an.

Die Installation des Updates 1803 wirkt sich nicht auf die aktuelle Verwendung der von Ihren Benutzern verwendeten Ressourcenanbieter SQL oder MySQL aus. Unabhängig von der Version der Ressourcenanbieter, die Sie verwenden, bleiben Ihre Benutzerdaten in deren Datenbanken davon unberührt und stehen weiterhin für den Zugriff zur Verfügung.

App Service

Benutzer müssen den Speicherressourcenanbieter vor dem Erstellen seiner ersten Azure-Funktion im Abonnement registrieren.
Um die Infrastruktur (Worker-, Verwaltungs-, Front-End-Rollen) aufzuskalieren, müssen Sie PowerShell verwenden, wie in den Anmerkungen zu dieser Version für die Berechnung beschrieben.

Verbrauch

Die Ansicht „Verwendung“ für die Nutzungsdaten öffentlicher IP-Adressen zeigt den gleichen EventDateTime-Wert für jeden Datensatz anstatt des TimeDate-Stempels, der anzeigt, wann dieser jeweils erstellt wurde. Derzeit können Sie diese Daten nicht nutzen, um eine genaue Buchhaltung über die Nutzung öffentlicher IP-Adressen durchzuführen.

Herunterladen von Azure Stack-Tools von GitHub

Beim Herunterladen der Azure Stack-Tools über GitHub mit dem PowerShell-Cmdlet invoke-webrequest ist ein Fehler aufgetreten:
- invoke-webrequest: Die Anforderung wurde abgebrochen: Es konnte kein sicherer SSL/TLS-Kanal erstellt werden.
Dieser Fehler tritt aufgrund der zurzeit veralteten GitHub-Unterstützung für die kryptografischen Standards TLS v1 und TLS v1.1 auf (der Standardwert für PowerShell). Weitere Informationen finden Sie unter Weak cryptographic standards removal notice (Hinweis zur Abschaffung unsicherer kryptografischer Standards).

Fügen Sie zur Behebung dieses Problems [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 am Anfang des Skripts hinzu, um bei Downloads aus GitHub-Repositorys die Verwendung von TLS v1.2 in der PowerShell-Konsole zu erzwingen.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1803 hier herunterladen.

Siehe auch

Informationen zum Überwachen und Fortsetzen von Updates mithilfe des privilegierten Endpunkts (PEP) finden Sie unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.
Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

1802 – archivierte Versionshinweise

Gilt für: Integrierte Azure Stack-Systeme

In diesem Artikel wird beschrieben, welche Verbesserungen und Fehlerbehebungen in diesem Updatepaket 1802 enthalten sind, welche bekannten Probleme es für dieses Release gibt und wo das Update heruntergeladen werden kann. Die bekannten Probleme sind in Probleme unterteilt, die sich direkt auf den Updateprozess beziehen, und in Probleme mit dem Build (nach der Installation).

Wichtig

Dieses Updatepaket gilt nur für integrierte Azure Stack-Systeme. Wenden Sie dieses Updatepaket nicht auf das Azure Stack Development Kit an.

Buildreferenz

Die Buildnummer des Azure Stack-Updates 1802 ist 20180302.1.

Voraussetzungen

Wichtig

Voraussetzungen

Installieren Sie das Azure Stack 1712-Update, bevor Sie das Azure Stack 1802-Update anwenden.
Installieren Sie AzS-Hotfix 1.0.180312.1 – Build 20180222.2, bevor Sie das Azure Stack 1802-Update anwenden. Durch diesen Hotfix wird Windows Defender aktualisiert. Dieser ist beim Herunterladen von Updates für Azure Stack verfügbar.

Um den Hotfix zu installieren, führen Sie die üblichen Verfahren zum Installieren von Updates für Azure Stack durch. Der Name des Updates wird als AzS Hotfix 1.0.180312.1 angezeigt und enthält die folgenden Dateien:
- PUPackageHotFix_20180222.2-1.exe
- PUPackageHotFix_20180222.2-1.bin
- Metadata.xml
Nachdem Sie diese Dateien in ein Speicherkonto und in einen Container hochgeladen haben, führen Sie die Installation im Verwaltungsportal über die Kachel „Aktualisieren“ aus.

Im Gegensatz zu Updates für Azure Stack wird die Version von Azure Stack nicht durch die Installation dieses Updates geändert. Um zu überprüfen, ob dieses Update installiert wurde, sehen Sie sich die Liste Installierte Updates an.

Schritte nach dem Update

Installieren Sie nach der Installation von 1802 alle entsprechenden Hotfixes. Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln sowie in unserer Wartungsrichtlinie.

Azure Stack-Hotfix 1.0.180302.4. KB 4131152: Vorhandene Virtual Machine Scale Sets-Instanzen werden möglicherweise unbrauchbar.

Mit diesem Hotfix werden auch die unter KB 4103348 – Netzwerkcontroller-API-Dienst stürzt ab, wenn versucht wird, ein Azure Stack-Update zu installieren beschriebenen Probleme behoben.

Neue Features und Fehlerbehebungen

Dieses Update enthält die folgenden Verbesserungen und Fehlerbehebungen für Azure Stack.

Die Unterstützung wurde auf die folgenden Versionen der Azure Storage-Dienst-API erweitert:
- 2017-04-17
- 2016-05-31
- 2015-12-11
- 2015-07-08
Weitere Informationen finden Sie unter Azure Stack-Speicher: Unterschiede und Überlegungen.
Unterstützung für größere Blockblobs:
- Die maximal zulässige Blockgröße wurde von 4 MB auf 100 MB erhöht.
- Die maximale Blobgröße wurde von 195 GB auf 4,75 TB erhöht.
Die Infrastruktursicherung wird ab sofort in der Kachel „Ressourcenanbieter“ angezeigt, und Benachrichtigungen in Bezug auf Sicherungen sind aktiviert. Weitere Informationen zum Infrastructure Backup-Dienst finden Sie unter Sicherung und Datenwiederherstellung für Azure Stack mit dem Infrastructure Backup-Dienst.
Führen Sie ein Update auf das Cmdlet Test-AzureStack durch, um die Diagnose für den Speicher zu verbessern. Weitere Informationen zu diesem Cmdlet finden Sie unter Ausführen eines Validierungstests für Azure Stack.
Verbesserungen an der rollenbasierten Zugriffssteuerung (RBAC) – Ab sofort können Sie mithilfe der RBAC Berechtigungen an universellen Benutzergruppen delegieren, wenn Azure Stack mit AD FS bereitgestellt wird. Weitere Informationen zur RBAC finden Sie unter Verwalten der rollenbasierten Zugriffssteuerung.
Es wurde Unterstützung für mehrere Fehlerdomänen hinzugefügt. Weitere Informationen finden Sie unter Hochverfügbarkeit für Azure Stack.
Unterstützung von Upgrades für den physischen Speicher: Sie können jetzt die Speicherkapazität des integrierten Azure Stack-Systems nach der Erstbereitstellung erweitern. Weitere Informationen finden Sie unter Verwalten der Kapazität des physischen Speichers für Azure Stack.
Es wurden verschiedene Fehlerbehebungen hinsichtlich der Leistung, Stabilität, Sicherheit und des von Azure Stack eingesetzten Betriebssystems vorgenommen.

Bekannte Probleme mit dem Updateprozess

Es liegen keine bekannten Probleme für die Installation des Updates 1802 vor.

Bekannte Probleme (nach der Installation)

Im Folgenden werden bekannte Probleme nach der Installation zum Build 20180302.1 vorgestellt.

Portal

Wenn Sie AD FS für Ihr Azure Stack-Identitätssystem verwenden und auf diese Version von Azure Stack aktualisieren, wird der Standardbesitzer des Abonnements für Standardanbieter auf den integrierten CloudAdmin-Benutzer zurückgesetzt.
Problemumgehung: Um dieses Problem nach der Installation dieses Updates zu beheben, führen Sie Schritt 3 unter Auslösen der Automatisierung zum Konfigurieren der Anspruchsanbieter-Vertrauensstellung in Azure Stack aus, um den Besitzer des Abonnements für Standardanbieter zurückzusetzen.
Die Funktion, mit der innerhalb des Administratorportals eine neue Supportanfrage über die Dropdownliste geöffnet wird, ist nicht verfügbar. Verwenden Sie stattdessen den folgenden Link:
- Für integrierte Azure Stack-Systeme muss https://aka.ms/newsupportrequest verwendet werden.

Im Verwaltungsportal ist es nicht möglich, Speichermetriken für Blob-Dienst, Tabellendienst oder Warteschlangendienst zu bearbeiten. Wenn Sie zum Speicher navigieren und dann die Kachel für Blob-Dienst, Tabellenspeicherdienst oder Warteschlangendienst auswählen, wird ein neues Blatt mit dem Metrikdiagramm für diesen Dienst geöffnet. Wenn Sie anschließend oben in der Kachel „Metrikdiagramm“ die Option „Bearbeiten“ auswählen, wird das Blatt "Diagramm bearbeiten" geöffnet, welches jedoch keine Optionen zum Bearbeiten von Metriken anzeigt.
Es ist es u.U. nicht möglich, Compute- oder Speicherressourcen im Administratorportal anzuzeigen. Grund für dieses Problem ist ein Fehler bei der Installation des Updates, der dazu führt, dass das Update fälschlicherweise als erfolgreich gemeldet wird. Wenn dieses Problem auftritt, wenden Sie sich an Microsoft Customer Support Services, um Unterstützung zu erhalten.
Es kann sein, dass im Portal ein leeres Dashboard angezeigt wird. Wählen Sie zum Wiederherstellen des Dashboards oben rechts im Portal das Zahnradsymbol und dann die Option Standardeinstellungen wiederherstellen.
Das Löschen von Benutzerabonnements führt zu verwaisten Ressourcen. Eine Problemumgehung besteht darin, zuerst Benutzerressourcen oder die gesamte Ressourcengruppe zu löschen und anschließend Benutzerabonnements zu löschen.
Sie können mit den Azure Stack-Portalen keine Berechtigungen für Ihr Abonnement anzeigen. Verwenden Sie für die Problemumgehung PowerShell, um Berechtigungen zu überprüfen.
Im Dashboard des Verwaltungsportals tritt beim Anzeigen von Informationen zu Updates über die Kachel „Aktualisieren“ ein Fehler auf. Klicken Sie zur Behebung dieses Problems auf die Kachel, um sie zu aktualisieren.
Im Verwaltungsportal wird möglicherweise eine kritische Benachrichtigung für die Komponente „Microsoft.Update.Admin“ angezeigt. Name, Beschreibung und Behebung der Warnung werden wie folgt angezeigt:

FEHLER: Vorlage für FaultType ResourceProviderTimeout fehlt.

Diese Warnung kann ignoriert werden.

In den Administrator- und Benutzerportalen kann das Blatt „Einstellungen“ für VNET-Subnetze nicht geladen werden. Verwenden Sie zur Problemumgehung PowerShell und das Cmdlet Get-AzureRmVirtualNetworkSubnetConfig, um diese Informationen anzuzeigen und zu verwalten.
Sowohl im Administrator- als auch im Benutzerportal wird das Blatt „Übersicht“ nicht geladen, wenn Sie auf das Übersichtsblatt für Speicherkonten klicken, die mit einer älteren API-Version (beispielsweise 2015-06-15) erstellt wurden. Das gilt auch für Systemspeicherkonten wie updateadminaccount, das im Rahmen von Patch- und Updatevorgängen verwendet wird.

Führen Sie zur Umgehung dieses Problems mithilfe von PowerShell das Skript Start-ResourceSynchronization.ps1 aus, um den Zugriff auf die Speicherkontodetails wiederherzustellen. Das Skript steht auf GitHub zur Verfügung und muss mit Dienstadministrator-Anmeldeinformationen auf dem privilegierten Endpunkt ausgeführt werden.
Das Blatt Service Health wird nicht geladen. Beim Öffnen des Blatts „Service Health“ im Verwaltungs- oder Benutzerportal zeigt Azure Stack eine Fehlermeldung an, und Informationen werden nicht geladen. Dieses Verhalten wird erwartet. Sie können Service Health zwar auswählen und öffnen, dieses Feature ist jedoch noch nicht verfügbar, sondern wird in einer zukünftigen Version von Azure Stack implementiert.

Integrität und Überwachung

Möglicherweise werden Warnungen für die Health Controller-Komponente mit folgenden Details angezeigt:

Warnung 1:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Heartbeat Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Warnung 2:
- NAME: Infrastrukturrolle fehlerhaft
- SCHWEREGRAD: Warnung
- KOMPONENTE: Health Controller
- BESCHREIBUNG: Fault Scanner von Health Controller ist nicht verfügbar. Dies kann sich auf Integritätsberichte und Metriken auswirken.
Beide Warnungen können ignoriert werden. Sie werden nach einem bestimmten Zeitraum automatisch geschlossen.

Marketplace

Benutzer können den gesamten Marketplace ohne Abonnement durchsuchen, und es werden administrative Elemente wie Pläne und Angebote angezeigt. Diese Elemente sind für Benutzer nicht funktional.

Compute

Die Skalierungseinstellungen für Skalierungsgruppen für virtuelle Computer sind im Portal nicht verfügbar. Dieses Problem können Sie umgehen, indem Sie Azure PowerShell verwenden. Aufgrund der Versionsunterschiede bei PowerShell müssen Sie den -Name-Parameter statt des -VMScaleSetName-Parameters verwenden.

Es ist für Sie nicht möglich, eine VM-Skalierungsgruppe (VMSS) hochzuskalieren, die mit einer älteren Version als Azure Stack 1802 erstellt wurde. Der Grund ist eine Änderung bei der Unterstützung der Nutzung von Verfügbarkeitsgruppen mit VM-Skalierungsgruppen. Diese Unterstützung wurde mit Version 1802 hinzugefügt. Wenn Sie zusätzliche Instanzen zur Skalierung einer VM-Skalierungsgruppe hinzufügen möchten, die vor dem Vorhandensein dieser Unterstützung erstellt wurde, tritt für den Vorgang ein Fehler mit der Meldung Bereitstellungsstatus „Fehler“ auf.

Dieses Problem wurde in Version 1803 behoben. Installieren Sie zum Beheben dieses Problems für Version 1802 das Azure Stack-Hotfix 1.0.180302.4. Weitere Informationen finden Sie unter KB 4131152: Vorhandene Virtual Machine Scale Sets-Instanzen werden möglicherweise unbrauchbar.
Azure Stack unterstützt nur die Verwendung von VHDs mit fester Größe. Einige über den Marketplace in Azure Stack angebotenen Images verwenden dynamische VHDs, die aber entfernt wurden. Größenänderungen an virtuellen Computern (VMs), bei denen ein dynamischer Datenträger angefügt ist, führen dazu, dass die VM in den Zustand „Fehlerhaft“ wechselt.

Löschen Sie in diesem Fall den virtuellen Computer, ohne jedoch seinen Datenträger (ein VHD-Blob in einem Speicherkonto) zu löschen. Konvertieren Sie die VHD anschließend von einem dynamischen Datenträger in einen Datenträger mit fester Größe, und erstellen Sie den virtuellen Computer neu.
Wenn Sie im Portal unter Neu>Berechnen>Verfügbarkeitsgruppe eine Verfügbarkeitsgruppe erstellen, können Sie nur eine Verfügbarkeitsgruppe mit einer Fehlerdomäne und einer Updatedomäne erstellen. Erstellen Sie bei der Erstellung eines neuen virtuellen Computers zur Problemumgehung die Verfügbarkeitsgruppe mithilfe von PowerShell, der CLI oder im Portal.
Beim Erstellen von virtuellen Computern im Azure Stack-Benutzerportal zeigt das Portal eine falsche Anzahl von Datenträgern an, die an eine VM der Serie D angefügt werden können. Alle unterstützten virtuellen Computer der Serie D können so viele Datenträger wie bei der Azure-Konfiguration aufnehmen.
Falls bei der Erstellung eines VM-Images ein Fehler auftritt, wird dem Blatt „Berechnung der VM-Images“ ggf. ein fehlerhaftes Element hinzugefügt, das nicht gelöscht werden kann.

Erstellen Sie zur Problemumgehung ein neues VM-Image mit einer Dummy-VHD, die per Hyper-V erstellt werden kann (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Das Problem, mit dem das Löschen des fehlerhaften Elements verhindert wird, sollte durch diesen Vorgang behoben werden. Anschließend können Sie das Element 15 Minuten nach der Erstellung des Dummy-Images erfolgreich löschen.

Danach können Sie versuchen, das VM-Image, bei dem zuvor ein Fehler aufgetreten ist, erneut herunterzuladen.
Wenn die Bereitstellung einer Erweiterung für eine VM-Bereitstellung zu lange dauert, sollten Benutzer eine Zeitüberschreitung der Bereitstellung zulassen und nicht versuchen, den Vorgang zum Aufheben der Zuordnung oder Löschen der VMs zu beenden.

Die Linux-VM-Diagnose wird in Azure Stack nicht unterstützt. Wenn Sie eine Linux-VM mit aktivierter VM-Diagnose bereitstellen, schlägt die Bereitstellung fehl. Die Bereitstellung schlägt auch fehl, wenn Sie die grundlegenden Linux-VM-Metriken über die Diagnoseeinstellungen aktivieren.

Netzwerk

Nachdem Sie eine VM erstellt und einer öffentlichen IP-Adresse zugeordnet haben, können Sie die Zuordnung dieser VM zu dieser IP-Adresse nicht mehr aufheben. Die Aufhebung der Zuordnung war scheinbar erfolgreich, aber die zuvor zugewiesene öffentliche IP-Adresse bleibt der ursprünglichen VM zugeordnet.

Derzeit müssen Sie ausschließlich neue öffentliche IP-Adressen für die Erstellung neuer VMs verwenden.

Dieses Verhalten tritt auch dann auf, wenn Sie die IP-Adresse einem neuen virtuellen Computer neu zuordnen (gewöhnlich als VIP-Austausch bezeichnet). Alle künftigen Versuche, eine Verbindung über diese IP-Adresse herzustellen, führen dazu, dass eine Verbindung mit dem ursprünglich zugeordneten virtuellen Computer (und nicht mit dem neuen) hergestellt wird.
Der interne Lastenausgleich (ILB) behandelt MAC-Adressen für Back-End-VMs nicht korrekt, wodurch der ILB bei der Verwendung von Linux-Instanzen im Back-End-Netzwerk abstürzt. Der ILB funktioniert gut mit Windows-Instanzen im Back-End-Netzwerk.
Das Feature zur IP-Weiterleitung wird im Portal angezeigt, aber die Aktivierung der IP-Weiterleitung hat keine Auswirkungen. Dieses Feature wird noch nicht unterstützt.
Azure Stack unterstützt ein einzelnes Gateway eines lokalen Netzwerks pro IP-Adresse. Dies gilt für alle Mandantenabonnements. Nach der Herstellung der Verbindung mit dem ersten Gateway eines lokalen Netzwerks werden nachfolgende Versuche zum Erstellen einer Ressource für Gateways lokaler Netzwerke mit der gleichen IP-Adresse blockiert.
In einem virtuellen Netzwerk, das mit der DNS-Servereinstellung Automatisch erstellt wurde, tritt bei der Änderung eines benutzerdefinierten DNS-Servers ein Fehler auf. Die aktualisierten Einstellungen werden nicht per Pushvorgang auf VMs in diesem VNET übertragen.
Azure Stack unterstützt nicht das Hinzufügen zusätzlicher Netzwerkschnittstellen zu einer VM-Instanz, nachdem die VM bereitgestellt wurde. Wenn die VM mehr als eine Netzwerkschnittstelle benötigt, müssen diese zum Zeitpunkt der Bereitstellung definiert werden.

Sie können das Verwaltungsportal nicht verwenden, um Regeln für eine Netzwerksicherheitsgruppe zu aktualisieren.

Zulassen:

Login-AzureRMAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Verweigern:


Login-AzureRMAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL und MySQL

Bevor Sie fortfahren, überprüfen Sie den wichtigen Hinweis unter Bevor Sie beginnen bei den Anmerkungen zu dieser Version.
Es kann bis zu einer Stunde dauern, bis Benutzer Datenbanken in einer neuen SQL- oder MySQL-Bereitstellung erstellen können.
Auf Servern, die SQL oder MySQL hosten, kann nur der Ressourcenanbieter Elemente erstellen. Die auf einem Hostserver erstellten Elemente, die nicht vom Ressourcenanbieter erstellt wurden, könnten zu einem Zustand ohne Entsprechung führen.

Sonderzeichen, einschließlich Leerzeichen und Interpunktion, werden im Namen für die Familie nicht unterstützt, wenn Sie die SKU für die SQL- und MySQL-Ressourcenanbieter erstellen.

Hinweis

Nachdem Sie ein Update auf Azure Stack 1802 ausgeführt haben, können Sie die zuvor bereitgestellten Ressourcenanbieter SQL und MySQL weiterhin verwenden. Es wird empfohlen, SQL und MySQL zu aktualisieren, sobald ein neues Release verfügbar ist. Wenden Sie Updates wie bei Azure Stack sequenziell auf die Ressourcenanbieter SQL und MySQL an. Wenn Sie z.B. Version 1710 verwenden, wenden Sie zuerst Version 1711, dann 1712 und schließlich 1802 an.

Die Installation des Updates 1802 wirkt sich nicht auf die aktuelle Verwendung der von Ihren Benutzern verwendeten Ressourcenanbieter SQL oder MySQL aus. Unabhängig von der Version der Ressourcenanbieter, die Sie verwenden, bleiben Ihre Benutzerdaten in deren Datenbanken davon unberührt und stehen weiterhin für den Zugriff zur Verfügung.

App Service

Benutzer müssen den Speicherressourcenanbieter vor dem Erstellen seiner ersten Azure-Funktion im Abonnement registrieren.
Um die Infrastruktur (Worker-, Verwaltungs-, Front-End-Rollen) aufzuskalieren, müssen Sie PowerShell verwenden, wie in den Anmerkungen zu dieser Version für die Berechnung beschrieben.

Herunterladen von Azure Stack-Tools von GitHub

Beim Herunterladen der Azure Stack-Tools über GitHub mit dem PowerShell-Cmdlet invoke-webrequest ist ein Fehler aufgetreten:
- invoke-webrequest: Die Anforderung wurde abgebrochen: Es konnte kein sicherer SSL/TLS-Kanal erstellt werden.
Dieser Fehler tritt aufgrund der zurzeit veralteten GitHub-Unterstützung für die kryptografischen Standards TLS v1 und TLS v1.1 auf (der Standardwert für PowerShell). Weitere Informationen finden Sie unter Weak cryptographic standards removal notice (Hinweis zur Abschaffung unsicherer kryptografischer Standards).

Fügen Sie zur Behebung dieses Problems [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 am Anfang des Skripts hinzu, um bei Downloads aus GitHub-Repositorys die Verwendung von TLS v1.2 in der PowerShell-Konsole zu erzwingen.

Herunterladen des Updates

Sie können das Paket für das Azure Stack-Update 1802 hier herunterladen.

Weitere Informationen

Microsoft stellt mithilfe des privilegierten Endpunkts (Privileged End Point, PEP), der mit Update 1710 installiert wird, eine Möglichkeit zum Überwachen und Fortsetzen von Updates bereit.

Weitere Informationen finden Sie in der Dokumentation unter Überwachen von Änderungen in Azure Stack mithilfe des privilegierten Endpunkts.

Siehe auch

Eine Übersicht über die Updateverwaltung in Azure Stack finden Sie unter Übersicht zum Verwalten von Updates in Azure Stack.
Informationen zur Anwendung von Updates mit Azure Stack finden Sie unter Anwenden von Updates in Azure Stack.

Freigeben über

Azure Stack Hub: Archivierte Versionshinweise

Buildreferenz 2311

Updatetyp

Neues

Änderungen

Sicherheitsupdates

Hotfixes

Hotfixvoraussetzungen: vor dem Anwenden des 2311-Updates

Nach erfolgreicher Anwendung des 2311-Updates

Buildreferenz 2306

Updatetyp

Neues

Änderungen

Sicherheitsupdates

Hotfixes

Hotfixvoraussetzungen: vor dem Anwenden des 2306-Updates

Nach erfolgreicher Anwendung des 2306-Updates

Buildreferenz 2301

Updatetyp

Neues

Änderungen

Sicherheitsupdates

Hotfixes

Hotfixvoraussetzungen: vor dem Anwenden des 2301-Updates

Nach erfolgreicher Anwendung des 2301-Updates

Buildreferenz zu 2206

Updatetyp

Neues

Änderungen

Korrekturen

Sicherheitsupdates

Hotfixes

Hotfixvoraussetzungen: Vor dem Anwenden des Updates 2206

Nach erfolgreicher Anwendung des Updates 2206

Buildreferenz zu 2102

Updatetyp

Neues

Verbesserungen

Änderungen

Korrekturen

Sicherheitsupdates

Hotfixes

Hotfixvoraussetzungen: vor dem Anwenden des Updates 2102

Nach erfolgreicher Anwendung des Updates 2102

Versionshinweise für unterstützte Versionen

Buildreferenz zu 2108

Updatetyp

Neues

Verbesserungen

Änderungen

Korrekturen

Sicherheitsupdates

Hotfixes

Hotfixvoraussetzungen: vor dem Anwenden des Updates 2108

Nach erfolgreicher Anwendung des Updates 2108

2008 – Buildreferenz

Updatetyp

Neues

Verbesserungen

Änderungen

Korrekturen

Sicherheitsupdates

Hotfixes

Nach erfolgreicher Anwendung des Updates 2008

2005 – archivierte Versionshinweise

Updatetyp

Neues

Verbesserungen

Änderungen

Korrekturen

Sicherheitsupdates

Hotfixes

Voraussetzungen: Vor dem Anwenden des Updates 2005

Nach erfolgreicher Anwendung des Updates 2005

2002: Archivierte Versionshinweise

Updateplanung

Herunterladen des Updates

2002 – Buildreferenz

Updatetyp