Probleme mit der Konfiguration und Verwaltung für Azure Cloud Services (klassisch): Häufig gestellte Fragen (FAQs)

Wir empfehlen, dass Kunden die vollständige Zertifikatskette (untergeordnetes Zertifikat, Zwischenzertifikate und Stammzertifikate) installieren und nicht nur das untergeordnete Zertifikat. Wenn Sie nur das untergeordnete Zertifikat installieren, sind Sie davon abhängig, dass Windows die Zertifikatskette durch durchlaufen der CTL erstellt. Wenn zeitweilige Netzwerk- oder DNS-Probleme in Azure oder Windows Update auftreten, während Windows das Zertifikat überprüft, wird das Zertifikat möglicherweise als ungültig behandelt. Durch Installation der vollständigen Zertifikatskette kann dieses Problem vermieden werden. Der Blogbeitrag How to install a chained SSL certificate (Installieren eines SSL-Kettenzertifikats) veranschaulicht diese Vorgehensweise.

Diese Zertifikate werden automatisch erstellt, wenn dem Clouddienst eine Erweiterung hinzugefügt wird. In den meisten Fällen handelt es sich hierbei um die WAD- oder RDP-Erweiterung. Es kann sich aber auch um die Antimalware- oder Log Collector-Erweiterung handeln. Diese Zertifikate werden nur zum Verschlüsseln und Entschlüsseln der privaten Konfiguration der Erweiterung verwendet. Das Ablaufdatum wird nicht überprüft, sodass es keine Rolle spielt, wenn das Zertifikat abgelaufen ist. 

Sie können diese Zertifikate ignorieren. Wenn Sie die Zertifikate bereinigen möchten, können Sie versuchen, sie alle zu löschen. Azure löst einen Fehler aus, wenn Sie versuchen ein Zertifikat zu löschen, das verwendet wird.

Weitere Informationen finden Sie im folgenden Richtliniendokument:

Obtaining a certificate for use with Windows Azure Web Sites (WAWS) (Abrufen eines Zertifikats für die Verwendung in Windows Azure-Websites (WAWS))

Die CSR-Datei ist nur eine Textdatei. Sie muss nicht von dem Computer aus erstellt werden, auf dem das Zertifikat letztlich verwendet wird. Obwohl dieses Dokument für App Service geschrieben ist, ist das Erstellen einer CSR generisch und gilt auch für Cloud Services.

Sie können Ihre Verwaltungszertifikate mit folgenden PowerShell-Befehlen verlängern:

Add-AzureAccount
Select-AzureSubscription -Current -SubscriptionName <your subscription name>
Get-AzurePublishSettingsFile

Mit Get-AzurePublishSettingsFile wird im Azure-Portal unter Abonnement>Verwaltungszertifikate ein neues Verwaltungszertifikat erstellt. Der Name des neuen Zertifikats sieht wie folgt aus: YourSubscriptionNam]-[CurrentDate]-Anmeldeinformationen

Sie können diese Aufgabe mithilfe eines Startskripts („batch/cmd/PowerShell“) automatisieren und das Startskript in der Dienstdefinitionsdatei registrieren. Fügen Sie sowohl das Startskript als auch das Zertifikat (P7B-Datei) dem Projektordner im selben Verzeichnis wie das Startskript hinzu.

Dieses Zertifikat dient zum Verschlüsseln von Computerschlüsseln für Azure-Webrollen. Weitere Informationen finden Sie in dieser Empfehlung.

Weitere Informationen finden Sie in den folgenden Artikeln:

• Konfigurieren und Ausführen von Startaufgaben für einen Clouddienst
• Allgemeine Starttasks für Clouddienste

Die Option zum Generieren eines neuen Zertifikats für Remotedesktopprotokoll (RDP) ist bald verfügbar. Alternativ können Sie das folgende Skript ausführen:

$cert = New-SelfSignedCertificate -DnsName yourdomain.cloudapp.net -CertStoreLocation "cert:\LocalMachine\My" -KeyLength 20 48 -KeySpec "KeyExchange"
$password = ConvertTo-SecureString -String "your-password" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath ".\my-cert-file.pfx" -Password $password

Die Option zum Auswählen eines Blobs oder eines lokalen Speicherorts als CSDEF- und CSCFG-Uploadspeicherort ist in Kürze verfügbar. Mit New-AzureDeployment können Sie jeden Speicherortwert festlegen.

Option zum Überwachen von Metriken auf Instanzebene. Weitere Überwachungsfunktionen stehen unter Überwachung von Clouddiensten zur Verfügung.

Sie haben das lokale Speicherkontingent für das Schreiben in das Protokollverzeichnis ausgeschöpft. Es gibt drei Möglichkeiten, dies zu korrigieren:

• Aktivieren Sie die Diagnose für IIS und lassen Sie die Diagnose regelmäßig in einen Blob-Speicher verschieben.
• Entfernen Sie Protokolldateien manuell aus dem Protokollierungsverzeichnis.
• Erhöhen Sie die Kontingentgrenze für lokale Ressourcen.

Weitere Informationen finden Sie in den folgenden Dokumenten:

• Speichern und Anzeigen von Diagnosedaten in Azure Storage
• Im Clouddienst werden keine IIS-Protokolle mehr geschrieben.

Sie können die Protokollierung durch die Windows Azure-Diagnose (WAD) über folgende Optionen aktivieren:

1. Aktivieren über Visual Studio
2. Aktivieren über .NET-Code
3. Aktivieren über PowerShell

Um die aktuellen WAD-Einstellungen Ihres Clouddiensts abzurufen, können Sie den PowerShell-Befehl Get-AzureServiceDiagnosticsExtensions verwenden oder im Portal über das Blatt „Clouddienste“ --> „Erweiterungen“ darauf zugreifen.

Sie können das Timeout in der Dienstdefinitionsdatei (CSDEF) wie folgt angeben:

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="mgVS2015Worker" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6">
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" />
    </ConfigurationSettings>
    <Imports>
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="10100"   idleTimeoutInMinutes="30" />
    </Endpoints>
  </WorkerRole>

Weitere Informationen finden Sie unter New: Configurable Idle Timeout for Azure Load Balancer (Neu: Konfigurierbares Leerlauftimeout für Azure Load Balancer).

Sie müssen für das Erstellen einer reservierten IP-Adresse eine statische IP-Adresse festlegen. Diese reservierte IP-Adresse kann einem neuen Clouddienst oder einer vorhandenen Bereitstellung zugeordnet werden. Weitere Informationen finden Sie in den folgenden Dokumenten:

• Verwalten von reservierten IPs
• Reservieren der IP-Adresse eines vorhandenen Clouddiensts
• Zuordnen einer reservierten IP zu einem neuen Clouddienst
• Zuordnen einer reservierten IP zu einer aktiven Bereitstellung
• Zuordnen einer reservierten IP zu einem Clouddienst mit einer Dienstkonfigurationsdatei

Azure verfügt über IPS/IDS in physischen Servern des Datencenters, um Bedrohungen abzuwehren. Darüber hinaus können Kunden Sicherheitslösungen von Drittanbietern bereitstellen, z.B. Web Application Firewalls, Netzwerkfirewalls, Antischadsoftware, Angriffserkennungs- und Eindringschutzsysteme (IDS/IPS) und weitere. Weitere Informationen finden Sie unter Protect your data and assets and comply with global security standards (Schutz Ihrer Daten und Objekte in Übereinstimmung mit globalen Sicherheitsstandards).

Microsoft überwacht durchgehend Server, Netzwerke und Anwendungen, um Bedrohungen zu erkennen. Azure's mehrgleisiger Ansatz zur Verwaltung von Bedrohungen verwendet Angriffserkennung, Verhinderung von verteilten Denial-of-Service-Angriffen (DDoS), Penetrationstests, Verhaltensanalyse, Anomalieerkennung und Machine Learning, um den Schutz stetig zu verbessern und Risiken zu reduzieren. Microsoft Antimalware für Azure schützt Azure Cloud Services und virtuelle Computer. Darüber hinaus können Sie zusätzlich Sicherheitslösungen von Drittanbietern bereitstellen, z.B. Web Application Firewalls, Netzwerkfirewalls, Antischadsoftware, Angriffserkennungs- und Eindringschutzsysteme (IDS/IPS) und weitere.

Windows 10 und Windows Server 2016 unterstützen HTTP/2 auf Client- und Serverseite. Wenn Ihr Client (Browser) über TLS eine Verbindung mit dem IIS-Server herstellt, wobei HTTP/2 über TLS-Erweiterungen ausgehandelt wird, müssen Sie keine Änderungen auf der Serverseite vornehmen. Dies liegt daran, weil über TLS standardmäßig der h2-14-Header gesendet wird, der die Verwendung von HTTP/2 festlegt. Wenn andererseits der Client einen Upgradeheader zum Upgrade auf HTTP/2 sendet, müssen Sie die folgende Änderung auf der Serverseite vornehmen, um sicherzustellen, dass das Upgrade funktioniert, und Sie eine HTTP/2-Verbindung erhalten.

1. Führen Sie „regedit.exe“ aus.
2. Navigieren Sie zu folgendem Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
3. Erstellen Sie einen neuen DWORD-Wert namens DuoEnabled.
4. Legen Sie hierfür den Wert 1 fest.
5. Starten Sie den Server neu.
6. Wechseln Sie zu Ihrer Standardwebsite, und erstellen Sie unter Bindungen eine neue TLS-Bindung mit dem selbstsignierten Zertifikat, das Sie gerade erstellt haben.

Weitere Informationen finden Sie unter

• HTTP/2 on IIS (HTTP/2 auf IIS)
• Video: HTTP/2 in Windows 10: Browser, Apps and Web Server (HTTP/2 in Windows 10: Browser, Apps und Webserver)

Diese Schritte könnten über einen Starttask automatisiert werden, sodass immer dann, wenn eine neue PaaS-Instanz erstellt wird, die obigen Änderungen in der Systemregistrierung vorgenommen werden könnten. Weitere Informationen finden Sie unter Konfigurieren und Ausführen von Startaufgaben für einen Clouddienst.

Sobald dies geschehen ist, können Sie mit einer der folgenden Methoden überprüfen, ob HTTP/2 aktiviert wurde:

• Aktivieren Sie die Protokollversion in IIS-Protokollen, und schauen Sie in die IIS-Protokolle. HTTP/2 wird in den Protokollen angezeigt.
• Aktivieren Sie „F12 Developer Tool“ in Internet Explorer oder Microsoft Edge, und wechseln Sie zur Registerkarte „Netzwerk“, um das Protokoll zu überprüfen.

Weitere Informationen finden Sie unter HTTP/2 on IIS (HTTP/2 auf IIS).

Das Azure RBAC-Modell (Azure Role-Based Access Control, rollenbasierter Zugriff von Azure) wird von Cloud Services nicht unterstützt, da es sich nicht um einen Azure Resource Manager-basierten Dienst handelt.

Weitere Informationen finden Sie unter Grundlegendes zu den verschiedenen Rollen in Azure.

Bei Microsoft gilt ein strenger Verhaltenskodex, der es internen Technikern nicht erlaubt, eine Remotedesktopverbindung mit einem Clouddienst herzustellen, ohne dass eine schriftliche Genehmigung (in Form einer E-Mail oder schriftlichen Mitteilung) des Besitzers oder Bevollmächtigten vorliegt.

Dieser Fehler kann auftreten, wenn Sie die RDP-Datei eines Computers verwenden, der in Microsoft Entra ID eingebunden ist. Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Klicken Sie mit der rechten Maustaste auf die heruntergeladene RDP-Datei, und wählen Sie Bearbeiten aus.
2. Fügen Sie vor dem Benutzernamen das Präfix „\“ hinzu. Verwenden Sie z. B. .\username anstelle von username.

Für Ihr Azure-Abonnement gilt ein Limit hinsichtlich der Anzahl von Kernen, die Sie verwenden können. Wenn Sie alle verfügbaren Kerne verwendet haben, können Sie nicht skalieren. Beispiel: Wenn Ihr Limit bei 100 Kernen liegt, können Sie für Ihren Clouddienst 100 virtuelle Computerinstanzen der Größe A1 oder 50 virtuelle Computerinstanzen der Größe A2 einrichten.

Die automatische Skalierung auf Grundlage von Speichermetriken für Cloud Services wird derzeit nicht unterstützt.

Um dieses Problem zu umgehen, können Sie Application Insights verwenden. Die automatische Skalierung unterstützt Application Insights als Quelle für Metriken und kann die Anzahl der Rolleninstanzen anhand einer Gastmetrik wie „Speicher“ skalieren. Sie müssen Application Insights in der Paketdatei Ihres Clouddienstprojekts (*.cspkg) konfigurieren und die Azure-Diagnoseerweiterung für den Dienst aktivieren, um dieses Feature zu implementieren.

Weitere Informationen dazu, wie Sie über Application Insights eine benutzerdefinierte Metrik verwenden, um die automatische Skalierung für Cloud Services zu konfigurieren, finden Sie unter Erste Schritte mit der automatischen Skalierung durch eine benutzerdefinierte Metrik in Azure.

Weitere Informationen zur Integration der Azure-Diagnose in Application Insights für Cloud Services finden Sie unter Senden von Cloud Services-, Virtual Machines- oder Service Fabric-Diagnosedaten an Application Insights.

Weitere Informationen dazu, wie Sie Application Insights für Cloud Services aktivieren, finden Sie unter Application Insights für Azure Cloud Services.

Weitere Informationen dazu, wie Sie die Azure-Diagnoseprotokollierung für Cloud Services aktivieren, finden Sie unter Einrichten der Diagnose für Azure Cloud Services und virtuelle Azure-Computer.

Um zu verhindern, dass Clients die MIME-Typen abfangen, fügen Sie eine Einstellung in Ihre Datei web.config ein.

<configuration>
   <system.webServer>
      <httpProtocol>
         <customHeaders>
            <add name="X-Content-Type-Options" value="nosniff" />
         </customHeaders>
      </httpProtocol>
   </system.webServer>
</configuration>

Sie können dies auch als Einstellung in IIS hinzufügen. Verwenden Sie den folgenden Befehl und den Artikel Gängige Starttasks.

%windir%\system32\inetsrv\appcmd set config /section:httpProtocol /+customHeaders.[name='X-Content-Type-Options',value='nosniff']

Verwenden Sie das IIS-Startskript aus dem Artikel Gängige Starttasks.

Weitere Informationen finden Sie unter Dienstspezifische Grenzwerte.

Hierbei handelt es sich um erwartetes Verhalten, das kein Problem bei Ihrer Anwendung verursachen sollte. Für das Laufwerk %approot% auf virtuellen Azure PaaS-Computern ist das Journaling aktiviert, was praktisch doppelt so viel Speicherplatz verbraucht, wie Dateien normalerweise belegen. Es gibt jedoch einige Punkte zu beachten, durch die dieses Verhalten nicht zu einem Problem wird.

Die Größe des Laufwerks %aproot% beträgt 1,5 GB oder wird als <Größe von CSPKG + max. Journalgröße + Rand mit freiem Speicherplatz> berechnet, je nachdem, welcher Wert größer ist. Die Größe Ihres virtuellen Computers hat keinen Einfluss auf diese Berechnung. (Die Größe des virtuellen Computers betrifft nur die Größe des temporären Laufwerks „C:“)

Schreibvorgänge in das Laufwerk „%aproot%“ werden nicht unterstützt. Wenn Sie einen Schreibvorgang auf dem virtuellen Azure-Computer vornehmen, müssen Sie diesen in einer temporären LocalStorage-Ressource (oder einer anderen Option, z. B. Blobspeicher, Azure Files usw.) ausführen. Der freie Speicherplatz im Ordner %approot% ist also nicht von Bedeutung. Wenn Sie sich unsicher sind, ob Ihre Anwendung in das Laufwerk „%aproot%“ schreibt, können Sie Ihren Dienst einige Tage lang ausführen und anschließend die „Vorher/Nachher“-Größe vergleichen. 

Azure wird nichts in das Laufwerk %approot% schreiben. Nachdem die VHD-Datei aus Ihrer .cspkg-Datei erstellt und in den virtuellen Azure-Computer eingebunden wurde, kann nur noch die Anwendung auf dieses Laufwerk schreiben. 

Die Einstellungen für Journaling sind nicht konfigurierbar, also lässt es sich nicht deaktiveren.

Sie können mithilfe des PowerShell-Skripts im Starttask die Antischadsoftware-Erweiterung aktivieren. Führen Sie die Schritte in den folgenden Artikeln aus, um sie zu implementieren:

• Erstellen eines PowerShell-Starttasks
• Set-AzureServiceAntimalwareExtension

Weitere Informationen zu den Antimalware-Bereitstellungsszenarien, und wie sie vom Portal aus aktiviert werden, finden Sie unter Antimalware-Bereitstellungsszenarien.

Sie können SNI in Cloud Services mit einer der folgenden Methoden aktivieren:

Methode 1: Verwenden von PowerShell

Die SNI-Bindung kann mithilfe des PowerShell-Cmdlets New-WebBinding in einem Starttask für eine Rolleninstanz des Clouddiensts wie unten beschrieben konfiguriert werden:

New-WebBinding -Name $WebsiteName -Protocol "https" -Port 443 -IPAddress $IPAddress -HostHeader $HostHeader -SslFlags $sslFlags

Wie hier beschrieben, können die $sslFlags einen der folgenden Werte haben:

Methode 2: Verwenden von Code

Die SNI-Bindung könnte auch über den Code im Rollenstart konfiguriert werden, wie in diesem Blogbeitrag beschrieben:

//<code snip> 
                var serverManager = new ServerManager(); 
                var site = serverManager.Sites[0]; 
                var binding = site.Bindings.Add(":443:www.test1.com", newCert.GetCertHash(), "My"); 
                binding.SetAttributeValue("sslFlags", 1); //enables the SNI 
                serverManager.CommitChanges(); 
    //</code snip>

Bei jedem der obigen Ansätze müssen die entsprechenden Zertifikate (*.pfx) für den spezifischen Hostnamen zuerst mit einem Starttask oder über den Code in der Rolleninstanz installiert werden, damit die SNI-Bindung wirksam wird.

Der Clouddienst ist eine klassische Ressource. Nur Ressourcen, die mit dem Azure Resource Manager erstellt wurden, unterstützen Tags. Sie können keine Tags auf klassische Ressourcen wie den Clouddienst anwenden.

Wir arbeiten an der Implementierung dieses Features im Azure-Portal. In der Zwischenzeit können Sie die SDK-Version mithilfe folgender PowerShell-Befehle abrufen:

Get-AzureService -ServiceName "<Cloud Service name>" | Get-AzureDeployment | Where-Object -Property SdkVersion -NE -Value "" | select ServiceName,SdkVersion,OSVersion,Slot

Bei einem bereits bereitgestellten Clouddienst wird die Compute- und Speichernutzung in Rechnung gestellt. Daher wird die Speichernutzung selbst dann abgerechnet, wenn Sie die Azure-VM deaktivieren.

Hier erfahren Sie, wie Sie Ihre Kosten reduzieren können, ohne die IP-Adresse für Ihren Dienst zu verlieren:

1. Reservieren Sie die IP-Adresse, bevor Sie die Bereitstellungen löschen. Es fallen nur Gebühren für diese IP-Adresse an. Weitere Informationen zur Abrechnung von IP-Adressen finden Sie unter IP-Adressen – Preise.
2. Löschen Sie die Bereitstellungen. „xxx.cloudapp.net“ darf nicht gelöscht werden, damit Sie sie künftig weiter verwenden können.
3. Wenn Sie den Clouddienst mit derselben IP-Adresse erneut bereitstellen möchten, die Sie in Ihrem Abonnement reserviert haben, informieren Sie sich im Thema zu Reservierten IP-Adressen für Cloud Services und Virtual Machines.