Freigeben über


Problembehandlung bei der Zertifizierung von virtuellen Computern

Beim Veröffentlichen Ihres Images des virtuellen Computers (VM) in Azure Marketplace wird es vom Azure-Team überprüft, um dafür die Startfähigkeit, Sicherheit und Kompatibilität mit Azure sicherzustellen. Falls Ihr VM-Image einen der Tests zur Überprüfung der hohen Qualitätsanforderungen nicht besteht, wird es nicht veröffentlicht. Sie erhalten eine Fehlermeldung, in der das Problem beschrieben ist.

In diesem Artikel werden Fehlermeldungen, die häufig bei der Veröffentlichung von VM-Images angezeigt werden, sowie die zugehörigen Lösungen erläutert.

Hinweis

Wenden Sie sich an den Partner Center-Support, falls Sie Fragen zu diesem Artikel oder Verbesserungsvorschläge haben.

Fehler bei der VM-Erweiterung

Überprüfen Sie, ob Ihr Image VM-Erweiterungen unterstützt.

Aktivieren Sie VM-Erweiterungen wie folgt:

  1. Wählen Sie Ihren virtuellen Linux-Computer aus.

  2. Navigieren Sie zu Diagnoseeinstellungen.

  3. Aktivieren Sie Basismatrizen, indem Sie das Speicherkonto aktualisieren.

  4. Wählen Sie Speichern.

    Screenshot: Aktivieren der Überwachung auf Gastebene

Überprüfen Sie wie folgt, ob die VM-Erweiterungen richtig aktiviert wurden:

  1. Wählen Sie auf dem virtuellen Computer die Registerkarte VM-Erweiterungen aus, und überprüfen Sie den Status der Linux-Diagnoseerweiterung.

  2. Überprüfen Sie den Bereitstellungsstatus.

    • Wenn der Status "Bereitstellung erfolgreich" ist, wurde der Testfall der Erweiterungen bestanden.
    • Wenn der Status "Bereitstellung fehlgeschlagen" ist, ist der Testfall für Erweiterungen fehlgeschlagen, und Sie müssen das flag "Hartened" festlegen.

    Screenshot, der zeigt, dass die Bereitstellung erfolgreich war.

    Liegt ein Fehler bei der VM-Erweiterung vor, lesen Sie die Informationen unter Verwenden der Linux-Diagnoseerweiterung zum Überwachen von Metriken und Protokollen, um sie zu aktivieren. Wenn die VM-Erweiterung nicht aktiviert sein soll, wenden Sie sich an das Supportteam, und lassen Sie die Erweiterung deaktivieren.

Problem bei der VM-Bereitstellung

Vergewissern Sie sich vor der Übermittlung Ihres Angebots, dass Sie den VM-Bereitstellungsprozess strikt befolgt haben. Unter dem Thema zum Testen von VM-Images finden Sie das JSON-Format zum Bereitstellen der VM.

Bereitstellungsprobleme können auf folgende Fehler zurückzuführen sein:

Szenario Fehler `Reason` Lösung
1 Ungültige virtuelle Festplatte (VHD) Wenn der angegebene Cookiewert in der VHD-Fußzeile falsch ist, wird die VHD als ungültig angesehen. Erstellen Sie das Image neu, und senden Sie die Anforderung.
2 Ungültiger Blobtyp Fehler bei der VM-Bereitstellung, weil der verwendete Block ein Blocktyp und kein Seitentyp ist. Erstellen Sie das Image als Seitentyp neu, und senden Sie die Anforderung.
3 Timeout bei der Bereitstellung oder nicht ordnungsgemäß generalisiert Es liegt ein Problem mit der VM-Generalisierung vor. Erstellen Sie das Image mit Generalisierung neu, und senden Sie die Anforderung.

Hinweis

Weitere Informationen zur VM-Generalisierung finden Sie in den folgenden Ressourcen:

Hinweis

Wenn bei der Bereitstellung ein Fehler auftritt, da für das VM-Image eine benutzerdefinierte ARM-Vorlage bereitgestellt werden muss, aktivieren Sie in Partner Center auf der Seite „Technische Konfiguration“ das Kontrollkästchen „Erfordert eine benutzerdefinierte ARM-Vorlage für die Bereitstellung“. Dies hilft dem Zertifizierungsteam, die richtige Aktion für diese Anforderung zu ergreifen, ohne dass es für das Bereitstellungsproblem fehlschlägt.

Kontrollkästchen „Erfordert eine benutzerdefinierte ARM-Vorlage für die Bereitstellung“

VHD-Spezifikationen

Die Zeichenfolge „conectix“ ist Teil der VHD-Spezifikation. Sie wird als 8-Byte-Cookie in der VHD-Fußzeile für die Identifizierung des Dateierstellers definiert. Alle von Microsoft erstellten VHD-Dateien verfügen über dieses Cookie.

Ein Blob mit VHD-Formatierung sollte eine 512-Byte-Fußzeile mit dem folgenden Format aufweisen:

Felder in Festplatten-Fußzeilen Größe (Byte)
Cookie 8
Features 4
Dateiformatversion 4
Datenoffset 8
Zeitstempel 4
Anwendung des Erstellers 4
Version des Erstellers 4
Hostbetriebssystem des Erstellers 4
Originalgröße 8
Aktuelle Größe 8
Datenträgergeometrie 4
Datenträgertyp 4
Checksum 4
Eindeutige ID 16
Gespeicherter Zustand 1
Reserved 427

VHD-Spezifikationen

Stellen Sie sicher, dass Ihre VHD die folgenden Kriterien erfüllt, um eine reibungslose Veröffentlichung zu ermöglichen:

  • Das Cookie enthält die Zeichenfolge "conectix".
  • Der Datenträgertyp lautet „Fixed“ (Feststehend).
  • Die virtuelle Größe der VHD beträgt mindestens 20 MB.
  • Die VHD wurde ausgerichtet. Die virtuelle Größe muss ein Vielfaches von 1 MB sein.
  • Die Länge des VHD-Blobs entspricht der virtuellen Größe plus der Länge der VHD-Fußzeile (512).

Laden Sie die VHD-Spezifikation herunter.

Softwarecompliance für Windows

Wenn Ihre Windows-Imageanforderung aufgrund eines Softwarecomplianceproblems abgelehnt wird, besteht dies möglicherweise darin, dass Sie ein Windows-Image mit einer installierten SQL Server-Instanz erstellt haben. Stattdessen müssen Sie das entsprechende SQL Server-Versionsbasisimage aus Azure Marketplace verwenden.

Erstellen Sie kein eigenes Windows-Image, auf dem SQL Server installiert ist. Verwenden Sie die genehmigten SQL Server-Basisimages (Enterprise/Standard/Web) aus dem Azure Marketplace.

Wenn Sie Visual Studio oder ein lizenziertes Office-Produkt installieren möchten, holen Sie vorab die Genehmigung des Supportteams ein.

Weitere Informationen zum Auswählen einer genehmigten Basis finden Sie im Thema zum Erstellen eines virtuellen Computers aus einer genehmigten Basis.

Fehler bei der Testfallausführung des Toolkits.

Mit dem Microsoft Certification-Toolkit können Sie Testfälle ausführen und überprüfen, ob Ihre VHD oder Ihr Image mit der Azure-Umgebung kompatibel ist.

Laden Sie das Microsoft Certification-Toolkit herunter.

Linux-Testfälle

In der folgenden Tabelle sind die Linux-Testfälle aufgeführt, in denen das Toolkit ausgeführt wird. Die Testvalidierung wird in der Beschreibung angegeben.

Szenario Testfall Beschreibung
1 Bashverlauf Bashverlaufsdateien sollten vor dem Erstellen des VM-Images gelöscht werden.
2 Linux-Agent-Version Die mindestens unterstützte Version des Azure Linux-Agents muss installiert sein.
3 Erforderliche Kernelparameter Überprüft, ob die folgenden Kernelparameter festgelegt sind:
console=ttyS0
earlyprintk=ttyS0
4 Swap-Partition auf dem Betriebssystemdatenträger Stellt sicher, dass Swap-Partitionen nicht auf dem Betriebssystemdatenträger erstellt werden.
5 Stammpartition auf dem Betriebssystemdatenträger Erstellen Sie eine einzelne Stammpartition für den Betriebssystemdatenträger.
6 OpenSSL-Version Sie müssen mindestens Version v0.9.8 von OpenSSL verwenden.
7 Python-Version Dringend empfohlen wird Python-Version 2.6 oder höher.
8 Client-Alive-Intervall Legen Sie das ClientAliveInterval auf 180 fest. Je nach Anforderung der Anwendung kann es auf einen Wert zwischen 30 und 235 festgelegt werden. Wenn Sie SSH für Ihre Endbenutzer aktivieren, muss dieser Wert gemäß der Beschreibung festgelegt werden.
9 Betriebssystemarchitektur Es werden nur 64-Bit-Betriebssysteme unterstützt.
10 Automatische Aktualisierung Gibt an, ob die automatische Aktualisierung des Linux-Agents aktiviert ist.

Häufige Testfallfehler

In der folgenden Tabelle sind die häufigen Fehler angegeben, die beim Ausführen von Testfällen auftreten können:

Szenario Testfall Fehler Lösung
1 Testfall zur Überprüfung der Linux-Agent-Version Die mindestens unterstützte Version des Azure Linux-Agents muss installiert sein.] (https://learn.microsoft.com/troubleshoot/azure/virtual-machines/support-extensions-agent-version) Aktualisieren Sie die Version des Linux-Agents. Weitere Informationen finden Sie auf der Seite mit Updates für die Linux-Agent-Version.
2 Bashverlauf-Testfall Es tritt ein Fehler auf, wenn die Größe des Bashverlaufs in Ihrem gesendeten Image 1 Kilobyte (KB) überschreitet. Die Größe ist auf 1 KB beschränkt, um sicherzustellen, dass in Ihrer Datei mit dem Bashverlauf keine potenziell vertraulichen Informationen erfasst werden. Stellen Sie die VHD hierfür auf einer anderen funktionierenden VM bereit, und nehmen Sie Änderungen vor, um die Größe auf maximal 1 KB zu reduzieren. Löschen Sie beispielsweise die .bash_history-Dateien.
3 Testfall für erforderliche Kernelparameter Dieser Fehler wird angezeigt, wenn der Wert für console diesen Wert nicht festgelegt ttyS0ist. Überprüfen Sie, indem Sie den folgenden Befehl ausführen:
cat /proc/cmdline
Legen Sie den Wert für console die ttyS0Anforderung fest, und übermitteln Sie die Anforderung erneut.
4 Testfall für das Client-Alive-Intervall Falls im Toolkit-Ergebnis für diesen Testfall ein Fehler zurückgegeben wird, ist für ClientAliveInterval ein unzulässiger Wert vorhanden. Legen Sie den Wert auf ClientAliveInterval kleiner oder gleich 235 fest, und übermitteln Sie die Anforderung erneut.
5 smoke_test Sie erhalten eine Fehlermeldung, wenn das Image aufgrund einer Kernel-Panik nicht gestartet oder neu gestartet werden kann. Sie können einige Informationen zur Anrufablaufverfolgung des Kernels aus der "Fehlerbeschreibung" abrufen. Wenn Sie die gesamte Anrufablaufverfolgung und das serielle Protokoll anzeigen möchten, können Sie einen virtuellen Computer in Azure mit Ihrem Image bereitstellen und die serielle Konsole in Ihrer VM-Ressource in der Azure-Portal überprüfen. Wenn Sie einen virtuellen Computer in Azure erstellen, können Sie das serielle Konsolenprotokoll aus dem Azure-Portal herunterladen (Weitere Informationen zur seriellen Konsole finden Sie unter https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-linux
6 verify_dns_name_resolution Dieser Testfall überprüft die DNS-Namensauflösung durch Ausführen von Befehl:Ping bing.com -c 5 -i 0.5 -O. Wenn eine öffentliche Webadresse "bing.com" nicht anpingt, tritt ein Fehler auf. Informationen zum https://learn.microsoft.com/en-us/azure/virtual-machines/linux/azure-dns Hinzufügen der richtigen Einstellungen finden Sie unter
7 verify_no_pre_exist_users Sie erhalten die Fehlermeldung "Kennwort des Benutzers XXXX wurde erkannt", wenn das Kennwort eines Benutzers erkannt wurde oder wenn der Schlüssel eines Benutzers erkannt wurde. überprüfen Sie /etc/shadow-Datei, um festzustellen, ob sie über ein Kennwort eines Benutzers verfügt, falls ja, müssen Sie das Kennwort löschen und das Startverzeichnis des {Benutzers}/.ssh/authorized_keys datei nach der Fehlermeldung löschen.
8 validate_netvsc_reload Sie erhalten den Fehler "failed". SSHException: SSH-Sitzung nicht aktiv.' wenn der virtuelle Computer nach ausführung unter dem Befehl nicht verbunden werden kann. Sie erhalten die Fehlermeldung "Kernel-Panik vom Knoten xx gefunden". wenn Kernel-Panik von der VM gefunden wird, nachdem der Befehl ausgeführt wurde: "modprobe -r hv_netvsc; modprobe hv_netvsc; ip link set eth0 down; ip link set eth0 up; dhclient -r eth0; dhclient eth0 ' Überprüfen Sie die serielle Konsole, um festzustellen, ob während des Zeitraums der Ausführung über dem Befehl ein Fehler aufgetreten ist. Weitere Informationen zum Network Virtual Service Client (NetVSC) finden Sie unter.You can visit https://learn.microsoft.com/en-us/windows-hardware/drivers/network/sr-iov-synthetic-data-path for more details about Network Virtual Service Client (NetVSC).

Windows-Testfälle

In der folgenden Tabelle sind die Windows-Testfälle aufgeführt, die vom Toolkit ausgeführt werden, sowie eine Beschreibung der Testüberprüfung:

Szenario Testfälle Beschreibung
1 Betriebssystemarchitektur Azure unterstützt nur 64-Bit-Betriebssysteme.
2 Abhängigkeit von Benutzerkonten Die Ausführung der Anwendung sollte nicht vom Administratorkonto abhängen.
3 Failovercluster Das Feature „Windows Server-Failoverclustering“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
4 IPV6 IPv6 wird in der Azure-Umgebung noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
5 DHCP Die Serverrolle „Dynamic Host Configuration-Protokoll“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
6 Remotezugriff Die Serverrolle „Remotezugriff (Direktzugriff)“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
7 Rights Management Services Rights Management Services. Die Serverrolle wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
8 Windows-Bereitstellungsdienste Windows-Bereitstellungsdienste. Die Serverrolle wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
9 BitLocker-Laufwerkverschlüsselung Die BitLocker-Laufwerkverschlüsselung wird auf der Betriebssystem-Festplatte nicht unterstützt, aber möglicherweise auf Datenträgern verwendet.
10 Internet Storage Name Server Das Feature „Internet Storage Name Server“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
11 Multipfad-E/A Multipfad-E/A. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
12 Netzwerklastenausgleich Netzwerklastenausgleich. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
13 Peer Name Resolution-Protokoll Peer Name Resolution-Protokoll. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
14 SNMP-Dienste Das Feature „SNMP-Dienste“ (Simple Network Management-Protokoll) wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
15 WINS (Windows Internet Name Service) WINS (Windows Internet Name Service). Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.
16 WLAN-Dienst WLAN-Dienst. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen.

Wenn im Zusammenhang mit den obigen Testfällen Fehler auftreten, finden Sie in der Tabelle in der Spalte Beschreibung Hinweise zur Fehlerbehebung. Wenden Sie sich an das Supportteam, falls Sie weitere Informationen benötigen.

Überprüfung der Datenträgergröße

Datenträgeranforderungen mit einer Größe von mehr als 1.023 Gigabyte (GB) werden nicht genehmigt. Diese Regel gilt sowohl für Linux als auch für Windows.

Senden Sie die Anforderung mit einer Größe von maximal 1.023 GB noch einmal.

Überprüfung der Betriebssystemdatenträgergröße

In den folgenden Regeln finden Sie Einschränkungen hinsichtlich der Betriebssystem-Datenträgergröße. Überprüfen Sie beim Senden von Anforderungen, ob die Betriebssystem-Datenträgergröße innerhalb der Grenzen für Linux bzw. Windows liegt.

OS Empfohlene VHD-Größe
Linux 1 GB bis 1.023 GB
Windows 30 GB bis 250 GB

Da VMs den Zugriff auf das zugrunde liegende Betriebssystem zulassen, sollten Sie sich vergewissern, dass die Größe der VHD ausreicht. Datenträger können erweitert werden, ohne dass es zu Ausfallzeiten kommt. Verwenden Sie eine Datenträgergröße zwischen 30 und 50 GB.

VHD-Größe Tatsächlich belegte Größe Lösung
>500 Tebibyte (TiB) Nicht zutreffend Wenden Sie sich wegen einer Ausnahmegenehmigung an das Supportteam.
250-500 TiB Differenz von >200 Gibibyte (GiB) zur Blobgröße Wenden Sie sich wegen einer Ausnahmegenehmigung an das Supportteam.

Hinweis

Größere Datenträgergrößen verursachen höhere Kosten und führen zu einer Verzögerung während des Setup- und Replikationsprozesses. Aufgrund dieser Verzögerung und Kosten kann das Supportteam eine begründete Ausnahmegenehmigung erteilen.

Überprüfungstest für WannaCry-Patches für Windows

Um einen potenziellen Angriff im Zusammenhang mit dem WannaCry-Virus zu verhindern, stellen Sie sicher, dass alle Windows-Image-Anforderungen mit dem neuesten Patch aktualisiert sind.

Sie können die Version der Imagedatei unter C:\windows\system32\drivers\srv.sys oder srv2.sys überprüfen.

In der folgenden Tabelle ist die gepatchte Mindestversion von Windows Server angegeben:

OS Version
Windows Server 2008 R2 6.1.7601.23689
Windows Server 2012 6.2.9200.22099
Windows Server 2012 R2 6.3.9600.18604
Windows Server 2016 10.0.14393.953
Windows Server 2019 NV

Hinweis

Für WindowsServer2019 gelten keine obligatorischen Versionsanforderungen.

Überprüfung des SACK-Sicherheitsrisikopatches

Wenn Sie ein Linux-Image senden, wird Ihre Anforderung möglicherweise aufgrund von Problemen mit der Kernelversion abgelehnt.

Aktualisieren Sie den Kernel mit einer genehmigten Version, und senden Sie die Anforderung noch einmal. Die genehmigte Kernelversion finden Sie in der folgenden Tabelle. Die Versionsnummer muss mindestens der hier aufgeführten entsprechen.

Wenn das Image nicht mit einer der folgenden Kernelversionen installiert ist, aktualisieren Sie es mit den richtigen Patches. Fordern Sie die nötige Genehmigung vom Supportteam an, nachdem das Image mit diesen erforderlichen Patches aktualisiert wurde:

  • CVE-2019-11477
  • CVE-2019-11478
  • CVE-2019-11479
Betriebssystemfamilie Version Kernel
Ubuntu 14.04 LTS 4.4.0-151
14.04 LTS 4.15.0-1049-*-azure
16.04 LTS 4.15.0-1049
18.04 LTS 4.18.0-1023
18.04 LTS 5.0.0-1025
18.10 4.18.0-1023
19.04 5.0.0-1010
19.04 5.3.0-1004
RHEL und CentOS 6.10 2.6.32-754.15.3
7.2 3.10.0-327.79.2
7.3 3.10.0-514.66.2
7.4 3.10.0-693.50.3
7,5 3.10.0-862.34.2
7.6 3.10.0-957.21.3
7.7 3.10.0-1062.1.1
8.0 4.18.0-80.4.2
8.1 4.18.0-147
„7-RAW“ (7.6)
„7-LVM“ (7.6) 3.10.0-957.21.3
RHEL-SAP 7.4 TBD
RHEL-SAP 7.5 TBD
SLES SLES11SP4 (einschließlich SAP) 3.0.101-108.95.2
SLES12SP1 für SAP 3.12.74-60.64.115.1
SLES12SP2 für SAP 4.4.121-92.114.1
SLES12SP3 4.4180-4.31.1 (Kernel-Azure)
SLES12SP3 für SAP 4.4.180-94.97.1
SLES12SP4 4.12.14-6.15.2 (Kernel-Azure)
SLES12SP4 für SAP 4.12.14-95.19.1
SLES15 4.12.14-5.30.1 (Kernel-Azure)
SLES15 für SAP 4.12.14-5.30.1 (Kernel-Azure)
SLES15SP1 4.12.14-5.30.1 (Kernel-Azure)
Oracle 6.10 UEK2 2.6.39-400.312.2
UEK3 3.8.13-118.35.2
RHCK 2.6.32-754.15.3
7.0-7.5 UEK3 3.8.13-118.35.2
UEK4 4.1.12-124.28.3
RHCK folgt auf obiges RHEL
7.6 RHCK 3.10.0-957.21.3
UEK5 4.14.35-1902.2.0
CoreOS Stable 2079.6.0 4.19.43*
Beta 2135.3.1 4.19.50*
Alpha 2163.2.1 4.19.50*
Debian Jessie (Sicherheit) 3.16.68-2
Jessie-Backports 4.9.168-1+deb9u3
Stretch (Sicherheit) 4.9.168-1+deb9u3
Debian GNU/Linux 10 (Buster) Debian 6.3.0-18+deb9u1
Buster, SID (Stretch-Backports) 4.19.37-5

Bildgröße sollte sich in Vielfachen von Megabytes

Alle VHDs in Azure müssen eine virtuelle Größe aufweisen, die sich an einem Vielfachen von 1 Megabyte (MB) orientiert. Wenn Ihre VHD nicht empfohlene virtuelle Größe aufweist, wird Ihre Anforderung möglicherweise zurückgewiesen.

Halten Sie sich beim Konvertieren von einem Rohdatenträger in eine VHD an die Richtlinien. Stellen Sie sicher, dass die Größe des Rohdatenträgers ein Vielfaches von 1 MB ist. Weitere Informationen finden Sie unter Informationen zu nichtdornierten Verteilungen.

VM-Zugriff verweigert

Ein Problem vom Typ Zugriff verweigert beim Ausführen eines Testfalls auf der VM wird ggf. durch unzureichende Berechtigungen verursacht.

Überprüfen Sie, ob Sie für das Konto, unter dem die Testfälle ausgeführt werden, den richtigen Zugriff aktiviert haben. Aktivieren Sie den Zugriff zum Ausführen von Testfällen, falls dies noch nicht durchgeführt wurde. Wenn Sie den Zugriff nicht aktivieren möchten, können Sie die Ergebnisse des Selbsttestfalls mit dem Supportteam teilen.

Übermitteln Sie Ihre Anforderung mit einem Image mit deaktiviertem SSH für den Zertifizierungsprozess wie folgt:

  1. Führen Sie das aktuelle Tool zum Testen der Zertifizierung für Azure-VMs für Ihr Image aus.

  2. Erstellen Sie ein Supportticket. Achten Sie darauf, dass Sie den Toolkit-Bericht anfügen und die Angebotsdetails angeben:

    • Angebotsname
    • Herausgebername
    • Plan-ID/SKU und Version
  3. Übermitteln Sie Ihre Zertifizierungsanforderung erneut.

Hinweis

Wenn Sie ein gesperrtes VM-Image veröffentlichen, das ssh deaktiviert oder eingeschränkt hat, aktivieren Sie das Kontrollkästchen "Remotedesktop oder SSH deaktiviert" auf der Seite "Technische Konfiguration" des Partner Centers. Dadurch wird das Zertifizierungsteam darüber informiert, dass dies beabsichtigt ist, und die richtigen Überprüfungen für das Bild durchführen, ohne dass es für eingeschränkten Zugriff fehlschlägt.

Kontrollkästchen für gesperrtes Image

Downloadfehler

In der Tabelle unten finden Sie alle Probleme, die auftreten können, wenn Sie das VM-Image mit einer SAS-URL (Shared Access Signature) herunterladen.

Fehler `Reason` Lösung
Nicht gefundenes Blob Die VHD wurde entweder gelöscht oder vom angegebenen Speicherort verschoben.
Blob wird verwendet Die VHD wird von einem anderen internen Prozess verwendet. Der Quellblobspeicher der VHD wird während der Veröffentlichung geändert. Die VHD sollte sich nicht in einem verwendeten Zustand befinden, wenn Sie sie mit einer SAS-URL herunterladen. Verwenden/ändern Sie die VHD auch nicht, wenn die Veröffentlichung ausgeführt wird.
Ungültige SAS-URL Die zugehörige SAS-URL für die VHD ist falsch. Rufen Sie die richtige SAS-URL ab.
Ungültige Signatur Die zugehörige SAS-URL für die VHD ist falsch. Rufen Sie die richtige SAS-URL ab.
Bedingter HTTP-Header Die SAS-URL ist ungültig. Rufen Sie die richtige SAS-URL ab.
Ungültiger VHD-Name Überprüfen Sie, ob Sonderzeichen wie das Prozentzeichen (%) oder Anführungszeichen (") im VHD-Namen enthalten sind. Benennen Sie die VHD-Datei um, und entfernen Sie die Sonderzeichen.

VM-Images müssen 1 MB freien Speicherplatz haben

Wenn Sie Ihr Image in Azure (mit GPT-Partition) veröffentlichen, wird dringend empfohlen , die ersten 2.048 Sektoren (1 MB) des Betriebssystemdatenträgers leer zu halten. Diese Anforderung dient dazu, Azure das Hinzufügen wichtiger Metadaten zum Image zu ermöglichen (z. B. Metadaten zur Verbesserung der Startzeit für Kunden, Abrechnung und andere Details). Dies ist eine Empfehlung für bewährte Methoden, wenn Sie bereits ein genehmigtes Basisimage verwenden und Ihr Bild über ein gültiges Abrechnungstag verfügt. Wenn Ihr Image jedoch nicht über ein gültiges Abrechnungstag verfügt, schlägt die Veröffentlichung möglicherweise fehl, wenn die ersten 1 MB des Betriebssystemdatenträgers nicht leer sind.

Wenn Sie ein eigenes Image erstellen, das über kein gültiges Abrechnungstag verfügt, stellen Sie sicher, dass die ersten 2.048 Sektoren (1 MB) des Betriebssystemdatenträgers leer sind. Andernfalls tritt bei der Veröffentlichung ein Fehler auf. Diese Anforderung gilt nur für den Betriebssystemdatenträger (nicht für andere Datenträger). Wenn Sie Ihr Image aus einer genehmigten Basis erstellen, ist es bereits über 1 MB leer. Sie müssen es also nicht separat bearbeiten.

Damit die ersten 1 MB auf Ihrem Betriebssystemdatenträger frei bleiben, führen Sie die Schritte im nächsten Abschnitt aus.

Beibehalten von 1 MB freien Speicherplatz am Anfang einer leeren VHD (2.048 Sektoren mit jeweils 512 Byte)

Diese Schritte gelten nur für Linux.

  1. Erstellen Sie eine beliebige Art von Linux-VM, z. B. Ubuntu, CentOS usw. Füllen Sie die erforderlichen Felder aus, und wählen Sie dann Weiter: Datenträger aus.

    Screenshot der Seite „Virtuellen Computer erstellen“ mit hervorgehobener Schaltfläche „Weiter: Datenträger“

  2. Erstellen Sie einen nicht verwalteten Datenträger für Ihren virtuellen Computer. Verwenden Sie entweder die Standardwerte, oder geben Sie einen beliebigen Wert für Felder wie Größe des Betriebssystemdatenträgers, Typ des Betriebssystemdatenträgers und Verschlüsselungstyp an.

    Screenshot der Seite „Datenträger“ unter „Virtuellen Computer erstellen“

  3. Wählen Sie nach dem Erstellen der VM im linken Bereich die Option Datenträger aus.

    Screenshot der Auswahl von Datenträgern für eine VM

  4. Fügen Sie Ihre VHD als Datenträger an Ihre VM an, um eine Partitionstabelle zu erstellen.

    1. Wählen Sie Vorhandene Datenträger anfügen aus:

      Screenshot des Hinzufügens eines Datenträgers zu Ihrer VHD

      Screenshot der Auswahl des Datenträgers für Ihre VHD

    2. Suchen Sie nach Ihrem VHD-Speicherkonto.

    3. Wählen Sie die Option Container und dann Ihre VHD aus.

    4. Wählen Sie OK aus.

      Screenshot: Seite „Nicht verwalteten Datenträger anfügen“

      Ihre VHD wird als Datenträger „LUN 0“ hinzugefügt.

  5. Starten Sie den virtuellen Computer neu.

  6. Melden Sie sich nach dem Neustart der VM bei der VM an, indem Sie PuTTY oder einen anderen Client verwenden, und führen Sie den Befehl sudo -i aus, um root-Zugriff zu erhalten.

    Screenshot der Befehlszeile im PuTTY-Client mit dem Befehl „sudo -i“

  7. Erstellen Sie auf Ihrer VHD eine Partition.

    1. Geben Sie den Befehl fdisk /dev/sdb ein.

    2. Geben Sie p ein, um die vorhandene Partitionsliste Ihrer VHD anzuzeigen.

    3. Geben Sie d ein, um alle vorhandenen Partitionen zu löschen, die auf Ihrer VHD verfügbar sind. Sie können diesen Schritt überspringen, falls er für Sie nicht erforderlich ist.

      Screenshot der Befehlszeile im PuTTY-Client mit den Befehlen zum Löschen vorhandener Partitionen

    4. Geben Sie n ein, um eine neue Partition zu erstellen, und wählen Sie als Typ p (primäre Partition) aus.

    5. Geben Sie „2048“ als Wert für den ersten Sektor (First sector) ein. Sie können Last sector (Letzter Sektor) als Standardwert beibehalten.

      Wichtig

      Alle vorhandenen Daten werden gelöscht, bis 2048 Sektoren (mit jeweils 512 Bytes) frei sind. Erstellen Sie eine Sicherung der VHD, bevor Sie eine neue Partition erstellen.

      Screenshot der Befehlszeile im PuTTY-Client mit den Befehlen und der Ausgabe für gelöschte Daten

    6. Geben Sie w ein, um die Erstellung der Partition zu bestätigen.

      Screenshot der Befehlszeile im PuTTY-Client mit den Befehlen zum Erstellen einer Partition

    7. Sie können die Partitionstabelle überprüfen, indem Sie den Befehl n fdisk /dev/sdb ausführen und p eingeben. Sie sehen, dass die Partition mit dem Offsetwert „2048“ erstellt wurde.

      Screenshot der Befehlszeile im PuTTY-Client mit den Befehlen zum Erstellen des Offsets von 2048

  8. Trennen Sie die VHD vom virtuellen Computer, und löschen Sie den virtuellen Computer.

Standardanmeldeinformationen

Senden Sie zusammen mit der übermittelten VHD niemals Standardanmeldeinformationen. Das Hinzufügen von Standardanmeldeinformationen macht die VHD anfälliger gegenüber Sicherheitsbedrohungen. Erstellen Sie stattdessen beim Senden der VHD eigene Anmeldeinformationen.

DataDisk wurde falsch zugeordnet

Ein Zuordnungsproblem kann auftreten, wenn eine Anforderung mit mehreren Datenträgern übermittelt wird, die nicht als entsprechende Sequenz vorliegen. Die Nummerierungsreihenfolge für die drei Datenträger muss beispielsweise 0, 1, 2 lauten. Alle anderen Reihenfolgen werden als Zuordnungsproblem behandelt.

Senden Sie die Anforderung mit ordnungsgemäßer Sequenzierung der Datenträger noch einmal.

Falsche Betriebssystemzuordnung

Beim Erstellen eines Images kann dieses der falschen Betriebssystembezeichnung zugeordnet oder zugewiesen werden. Wenn Sie beim Erstellen des Images beispielsweise Windows als Teil des Betriebssystemnamens auswählen, darf der Betriebssystem-Datenträger nur mit Windows installiert werden. Die gleiche Anforderung gilt für Linux.

VM nicht generalisiert

Wenn alle Images aus Azure Marketplace wiederverwendet werden sollen, muss die Betriebssystem-VHD generalisiert werden.

  • Unter Linux wird mit dem folgenden Prozess eine Linux-VM generalisiert und als separate VM erneut bereitgestellt.

    Geben Sie im SSH-Fenster den folgenden Befehl ein: sudo waagent -deprovision+user

  • Unter Windows generalisieren Sie Windows-Images mithilfe von sysreptool.

    Weitere Informationen zum Tool sysreptool finden Sie unter Übersicht über Sysprep (Systemvorbereitung).

DataDisk-Fehler

In der folgenden Tabelle sind Fehlerbehebungsoptionen für Fehler in Verbindung mit dem Datenträger aufgeführt:

Fehler `Reason` Lösung
DataDisk- InvalidUrl: Dieser Fehler kann darauf zurückzuführen sein, dass beim Übermitteln des Angebots eine ungültige logische Gerätenummer (Logical Unit Number, LUN) angegeben wurde. Vergewissern Sie sich, dass sich die Sequenz der LUN-Nummern für den Datenträger in Partner Center befindet.
DataDisk- NotFound: Dieser Fehler kann darauf zurückzuführen sein, dass sich ein Datenträger nicht unter einer angegebenen SAS-URL befindet. Vergewissern Sie sich, dass der Datenträger unter der angegebenen SAS-URL vorhanden ist.

Problem beim Remotezugriff

Sie erhalten diesen Fehler, wenn für das Windows-Image nicht die Remotedesktopprotokoll-Option (RDP) aktiviert ist.

Aktivieren Sie vor dem Senden den RDP-Zugriff für Windows-Images.

Bash-Verlauf fehlgeschlagen

Dieser Fehler tritt auf, wenn die Größe des Bashverlaufs in Ihrem gesendeten Image 1 Kilobyte (KB) überschreitet. Die Größe ist auf 1 KB beschränkt, um zu verhindern, dass die Datei potenziell vertrauliche Informationen enthält.

Löschen Sie den Bashverlauf wie folgt:

  1. Stellen Sie den virtuellen Computer bereit, und wählen Sie im Azure-Portal die Option Befehl ausführen aus.

    Screenshot: Option „Befehl ausführen“ im linken Bereich des Azure-Portals

  2. Wählen Sie die erste Option RunShellScript aus, und führen Sie dann den folgenden Befehl aus: cat /dev/null > ~/.bash_history && history -c.

    Screenshot: Seite für Ausführung des Befehlsskripts im Azure-Portal

  3. Starten Sie den virtuellen Computer neu, nachdem der Befehl erfolgreich ausgeführt wurde.

  4. Generalisieren Sie den virtuellen Computer, erstellen Sie die Image-VHD, und beenden Sie den virtuellen Computer.

  5. Übermitteln Sie das generalisierte Image erneut.

Überprüfungen der virtuellen Netzwerkanwendung

Während der Marketplace-Imagezertifizierung wird ein VM-Angebot, das eine Network Virtual Appliance (NVA) ist, mithilfe von Tests überprüft, die generisch für jedes VM-Angebot sind, und NVA-Testfälle, die in der folgenden Tabelle aufgeführt sind. Als Ziel dieser NVA-spezifischen Überprüfungen soll ermittelt werden, wie gut das NVA-Image mit dem SDN-Stapel orchestriert wird.

Testfall Schritte zum Ausführen des Testfalls Lösung
VHD-Zugriff Vergewissern Sie sich, dass die richtige SAS-URL für die VHD angegeben ist, die Berechtigungen so festgelegt sind, dass der Zugriff gestattet wird, und das NVA-Image generalisiert ist. Überprüfen Sie das NVA-Image und die angegebene URL.
NVA-Bereitstellung Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Vergewissern Sie sich, dass die Bereitstellung in 20 Minuten abgeschlossen ist. Wenn die Bereitstellung nicht innerhalb von 20 Minuten abgeschlossen ist, überprüfen Sie das NVA-Image.
NVA-Neustart Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Wechseln Sie dann in Azure-Portal zum virtuellen Computer, und wählen Sie im linken Bereich "Support + Problembehandlung" die Option "Erneut bereitstellen+ Erneut anwenden" aus, und stellen Sie den virtuellen Computer erneut bereit. Überprüfen Sie nach Abschluss der erneuten Bereitstellung, ob der Status der VM Wird ausgeführt lautet und der NIC-Port 22 mit dem Netcat-Befehl erreichbar ist. Wenn der virtuelle Computer nach dem Neustart nicht angezeigt wird, liegt möglicherweise ein Problem mit dem NVA-Image vor.

Ein Fehler beim Netcat-Test kann auftreten, wenn die NIC nach dem Neustart nicht gestartet werden konnte, obwohl die VM ausgeführt wurde. Warten Sie einige Minuten, und versuchen Sie es erneut. Wenn es nach 20 Minuten immer noch fehlschlägt, liegt möglicherweise ein Problem mit dem NVA-Bild vor.
Erneute NVA-Bereitstellung Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Stellen Sie dann die VM erneut bereit. Überprüfen Sie, ob der Status der VM Wird ausgeführt lautet und der NIC-Port 22 mit dem Netcat-Befehl erreichbar ist. Wenn die erneute Bereitstellung nicht innerhalb von 15 Minuten abgeschlossen ist, liegt möglicherweise ein Problem mit dem NVA-Image vor.

Ein Fehler beim Netcat-Test kann auftreten, wenn die NIC nach dem Neustart nicht gestartet werden konnte, obwohl die VM ausgeführt wurde. Warten Sie einige Minuten, und versuchen Sie es erneut. Wenn es nach 20 Minuten immer noch fehlschlägt, liegt möglicherweise ein Problem mit dem NVA-Bild vor.
Hochverfügbarkeit Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Es sollte entweder keine öffentliche IP-Adresse an die NIC angefügt sein, oder wenn eine öffentliche IP-Adresse angefügt ist, sollte die SKU eine Standard-SKU und die IP-Zuordnungsmethode statisch sein. Richten Sie im selben virtuellen Netzwerk einen Azure Internal Load Balancer mit der nachstehenden Konfiguration ein.
– Lastenausgleich mit Standard-SKU
– Front-End-IP-Adresse mit dynamischer Zuordnungsmethode für private IP-Adressen
– Integritätstests mit TCP, Port 22 mit einem Wiederholungsintervall von 15 Sekunden
– Eine Lastenausgleichsregel, bei der das Protokoll auf alle und „Floating IP-Adresse aktivieren“ auf FALSE festgelegt ist
– Back-End-Pool, der auf NVA-VM verweist

Sobald die Einrichtung abgeschlossen ist, überprüfen Sie mithilfe des Netcat-Befehls, ob die NVA-VM über den Lastenausgleich erreichbar ist.
Ist das NVA nicht über den Lastenausgleich erreichbar, überprüfen Sie die Einrichtung der VM, des Lastenausgleichs und des Features für Hochverfügbarkeitsports. Wenn alles korrekt ist, liegt möglicherweise ein Problem mit dem NVA-Bild vor.
VNET-Peering Stellen Sie einen virtuellen Computer VM1 mithilfe des NVA-Images mit einer NIC in einem virtuellen Netzwerk-VNET1 bereit. Stellen Sie in einem anderen virtuellen Netzwerk VNET2 einen virtuellen Computer VM2 mit jedem Linux-Image bereit, z. B. Ubuntu, mit einer NIC und VM-Einstellungen als Dynamische IP-Zuordnungsmethode und einfache SKU. Erstellen Sie ein VNET-Peering zwischen VNET1 und VNET2, und konfigurieren Sie Datenverkehr zum virtuellen Remotenetzwerk als Zulassen (Standard).

Sobald die Einrichtung abgeschlossen ist, überprüfen Sie mithilfe des Netcat-Befehls, ob von VM2 aus die private IP-Adresse der NIC auf der NVA-VM1 erreicht werden kann.
Wenn die NVA-VM1 von VM2 aus nicht erreichbar ist, überprüfen Sie, ob das VNET-Peering ordnungsgemäß konfiguriert ist, und versuchen Sie es erneut. Wenn es immer noch nicht funktioniert, liegt möglicherweise ein Problem mit dem NVA-Bild vor.
Beschleunigter Netzwerkbetrieb (Accelerated Networking, AN) Stellen Sie eine VM mit dem NVA und einer NIC mit aktiviertem beschleunigtem Netzwerkbetrieb bereit. Sie können den beschleunigten Netzwerkbetrieb für eine NIC beim Erstellen der VM oder nach dem Erstellen der VM in den NIC-Eigenschaften aktivieren. Vergewissern Sie sich, dass die VM aktiv ist und ausgeführt wird. Wenn die Bereitstellung fehlschlägt, überprüfen Sie, ob das NVA-Image beschleunigte Netzwerke unterstützt.
Multi-NIC – Basic Stellen Sie eine VM mithilfe des NVA mit drei NICs mit dynamischer IP-Zuordnungsmethode und Basic-SKU bereit. Rufen Sie die privaten IP- und MAC-Adressen für alle NICs ab (Anweisungen dazu finden Sie unter Anzeigen der Einstellungen von Netzwerkschnittstellen). Stellen Sie dann die VM erneut bereit, und vergewissern Sie sich, dass die privaten IP- und MAC-Adressen für alle NICs die gleichen sind wie vor der erneuten Bereitstellung. Wenn sich die private IP- und MAC-Adresse für alle NICs nach der erneuten Bereitstellung ändern, liegt möglicherweise ein Problem mit dem NVA-Image vor.
Netzwerkunterbrechung Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Erstellen Sie anschließend eine Netzwerksicherheitsgruppe (NSG), und wenden Sie diese an, um den gesamten Datenverkehr an die NVA-VM zu blockieren. Vergewissern Sie sich dann, dass der Status der VM Wird ausgeführt lautet. Wenn nach dem Anwenden von NSG der virtuelle Computer heruntergeht, liegt möglicherweise ein Problem mit dem NVA-Image vor.

Für weitere Informationen oder Fragen öffnen Sie einen Azure-Supportfall.

Netcat-Übersicht:

Netcat ist ein Befehl, der eine TCP- oder UDP-Verbindung zwischen zwei Computern herstellen kann. Das bedeutet, dass er über einen offenen Port schreiben und lesen kann. Während der NVA-Überprüfungen führen wir den Netcat-Befehl von einer VM aus, die sich im gleichen virtuellen Netzwerk wie der NVA-VM befindet, um zu testen, ob TCP-Port 22 erreichbar ist. Die Befehlssyntax lautet nc <destination_ip_address> <destination_port>. Dabei gilt Folgendes:

  • destination_ip_address ist die private IP-Adresse, die der VM-NIC zugewiesen ist.
  • destination_port ist die Portnummer des NVA. In NVA-Testfällen wird 22 verwendet.

Beispiel: nc 192.168.1.1 22

Anfordern einer Ausnahme für VM-Images für ausgewählte Tests

Herausgeber können für einige Tests, die während der VM-Zertifizierung durchgeführt werden, Ausnahmen anfordern. Ausnahmen werden in seltenen Fällen gewährt, wenn der Herausgeber die Anforderung fundiert begründet. Das Zertifizierungsteam behält sich das Recht vor, Ausnahmen jederzeit abzulehnen oder zu genehmigen.

In diesem Abschnitt werden allgemeine Szenarien, in denen Herausgeber eine Ausnahme anfordern, und die entsprechenden Vorgehensweisen beschrieben.

Szenarien für eine Ausnahme

Herausgeber fordern Ausnahmen normalerweise in den folgenden Fällen an:

  • Ausnahme für einen oder mehrere Testfälle: Wenden Sie sich an den Partner Center-Support, um Ausnahmen für Testfälle anzufordern.

  • Gesperrte VMs/kein Root-Zugriff: Bei einigen Herausgebern müssen VMs gesperrt werden, weil Software (z. B. Firewalls) auf der VM installiert ist. Laden Sie in diesem Fall das Certified-Testtool herunter, und übermitteln Sie den Bericht an den Partner Center-Support.

  • Benutzerdefinierte Vorlagen: Einige Herausgeber veröffentlichen VM-Images, für die eine benutzerdefinierte ARM-Vorlage (Azure Resource Manager) zum Bereitstellen der VMs erforderlich ist. Übermitteln Sie in diesem Fall die benutzerdefinierten Vorlagen im Partner Center-Support , die vom Zertifizierungsteam zur Überprüfung verwendet werden sollen.

Zu übermittelnde Informationen für Ausnahmeszenarien

Wenden Sie sich an den Partner Center-Support, um eine Ausnahme für eines der Szenarien anzufordern, und geben Sie die folgenden Informationen an:

  • Herausgeber-ID: Geben Sie die Herausgeber-ID aus Ihrem Partner Center-Portal ein.

  • Angebots-ID/Name: Geben Sie die Angebots-ID oder den Namen ein.

  • SKU/Plan-ID: Geben Sie die Plan-ID oder SKU des VM-Angebots ein.

  • Version: Geben Sie die Version des VM-Angebots ein, für das eine Ausnahme erforderlich ist.

  • Ausnahmetyp: Wählen Sie zwischen Tests, gesperrten virtuellen Computern und benutzerdefinierten Vorlagen.

  • Grund für die Anforderung: Geben Sie den Grund für die Ausnahmeanforderung sowie Informationen zu den auszuschließenden Tests an.

  • Zeitachse: Geben Sie das Enddatum für Ihre Ausnahme ein.

  • Anhang. Angefügte Dokumente mit wichtigen Nachweisinformationen:

    • Fügen Sie für gesperrte virtuelle Computer den Testbericht an.
    • Fügen Sie für benutzerdefinierte Vorlagen die benutzerdefinierte ARM-Vorlage als Anlage an.

    Wenn Sie diese Anlagen nicht anfügen, wird die Anforderung abgelehnt.

Beheben einer Sicherheitsanfälligkeit oder eines Exploits in einem VM-Angebot

In diesem Abschnitt wird beschrieben, wie Sie ein neues VM-Image bereitstellen, wenn ein Sicherheitsrisiko oder Exploit bei einem Ihrer VM-Images erkannt wird. Dies gilt nur für Azure-VM-Angebote, die auf Azure Marketplace veröffentlicht werden.

Hinweis

Sie können weder das letzte VM-Image aus einem Plan entfernen noch den Verkauf des letzten Plans für ein Angebot einstellen.

Führen Sie eine der folgenden Aktionen aus:

Bereitstellen eines korrigierten VM-Images

Gehen Sie wie folgt vor, um ein korrigiertes VM-Image als Ersatz für ein VM-Image mit Sicherheitsrisiko oder Exploit bereitzustellen:

  1. Stellen Sie ein neues VM-Image bereit, um das Sicherheitsrisiko oder Exploit zu beheben.
  2. Entfernen Sie das VM-Image mit dem Sicherheitsrisiko oder Exploit.
  3. Veröffentlichen Sie das Angebot erneut.

Bereitstellen eines neuen VM-Images zur Behebung des Sicherheitsrisikos oder Exploits

Bereiten Sie die technischen Ressourcen für das hinzuzufügende VM-Image vor, um diese Schritte ausführen zu können. Weitere Informationen finden Sie unter Erstellen eines virtuellen Computers mit einer genehmigten Basis oder Erstellen eines virtuellen Computers mit einem eigenen Image und Generieren eines SAS-URIs für Ihr VM-Image.

  1. Melden Sie sich bei Partner Center an.

  2. Wählen Sie auf der Startseite die Kachel Marketplace-Angebote aus.

  3. Wählen Sie in der Spalte Angebotsalias das Angebot aus.

  4. Wählen Sie die Registerkarte Planübersicht und dann den entsprechenden Plan aus.

  5. Wählen Sie auf der Registerkarte Technische Konfiguration unter VM-Images die Option + VM-Image hinzufügen aus.

    Hinweis

    Sie können einem Plan jeweils nur ein VM-Image hinzufügen. Wenn Sie mehrere VM-Images hinzufügen möchten, sollten Sie das erste VM-Image veröffentlichen, bevor Sie das nächste hinzufügen.

  6. Geben Sie in den angezeigten Feldern eine neue Datenträgerversion und das VM-Image an.

  7. Wähen Sie Entwurf speichern aus.

Entfernen Sie als Nächstes das VM-Image mit dem Sicherheitsrisiko.

Entfernen des VM-Images mit dem Sicherheitsrisiko oder Exploit

  1. Melden Sie sich bei Partner Center an.
  2. Wählen Sie auf der Startseite die Kachel Marketplace-Angebote aus.
  3. Wählen Sie in der Spalte Angebotsalias das Angebot aus.
  4. Wählen Sie die Registerkarte Planübersicht und dann den entsprechenden Plan aus.
  5. Wählen Sie auf der Registerkarte Technische Konfiguration unter VM-Images die Option VM-Image entfernen neben dem zu entfernenden VM-Image aus.
  6. Wählen Sie im Dialogfeld die Option Weiter aus.
  7. Wähen Sie Entwurf speichern aus.

Veröffentlichen Sie das Angebot anschließend erneut.

Erneutes Veröffentlichen des Angebots

  1. Wählen Sie Überprüfen und veröffentlichen aus.
  2. Wenn Sie Informationen für das Zertifizierungsteam bereitstellen müssen, fügen Sie diese dem Feld Hinweise zur Zertifizierung hinzu.
  3. Wählen Sie Veröffentlichen aus.

Unter Überprüfen und Veröffentlichen von Angeboten erfahren Sie, wie Sie die Veröffentlichung abschließen.

VM-Images mit beschränktem Zugriff oder erforderlichen benutzerdefinierten Vorlagen

Gesperrtes (oder) deaktiviertes SSH-Angebot

Images, die entweder mit deaktiviertem SSH (für Linux) oder deaktiviertem RDP (für Windows) veröffentlicht werden, werden als gesperrte VMs behandelt. Es gibt spezielle Geschäftsszenarios, in denen Herausgeber nur wenigen oder keinen Benutzern den beschränkten Zugriff gewähren.

Gesperrte VMs lassen die Ausführung bestimmter Zertifizierungsbefehle möglicherweise während Validierungsüberprüfungen nicht zu.

Benutzerdefinierte Vorlagen

Im Allgemeinen folgen alle unter einem virtuellen Computer veröffentlichten Images der Standard-ARM-Vorlage für die Bereitstellung. Es gibt jedoch Szenarien, in denen der Herausgeber erfordert, dass während der Bereitstellung von VMs Anpassungen vorgenommen werden (z. B. die Konfiguration mehrerer Netzwerkschnittstellen).

Je nach den folgenden Szenarien (nichtexextive) verwenden Herausgeber benutzerdefinierte Vorlagen für die Bereitstellung der VM:

  • VM erfordert zusätzliche Netzwerksubnetze.
  • Weitere Metadaten, die in arm-Vorlage eingefügt werden sollen.
  • Es sind Befehle für die Ausführung der ARM-Vorlage erforderlich.

VM-Erweiterungen

Erweiterungen für virtuelle Azure-Computer sind kleine Anwendungen, die Konfigurations- und Automatisierungsaufgaben auf Azure-VMs nach der Bereitstellung ermöglichen. Wenn z.B. Software auf einem virtuellen Computer (virtual machine, VM) installiert werden muss, Virenschutz oder die Ausführung eines Skripts erforderlich ist, kann eine VM-Erweiterung verwendet werden.

Folgendes muss für Überprüfungen der Linux-VM-Erweiterung im Image enthalten sein:

Weitere Informationen finden Sie unter VM-Erweiterung.

Überprüfung der Integrität des Bilds

Wenn Sie ein Image erstellen und Datenträger aus dem Image erstellen, um die Integrität des Bilds zu überprüfen, beachten Sie, dass die ersten 1 MB für eine optimierte Leistung reserviert sind und die letzten 512 Bytes für die VHD-Fußzeile reserviert sind. Ignorieren Sie sie also, während Sie die Integrität des Bilds überprüfen.