Konfigurations- och hanteringsproblem för Azure Cloud Services (klassisk): Vanliga frågor och svar

Vi rekommenderar att kunderna installerar den fullständiga certifikatkedjan (lövcertifikat, mellanliggande certifikat och rotcertifikat) i stället för bara lövcertifikatet. När du installerar bara lövcertifikatet förlitar du dig på att Windows skapar certifikatkedjan genom att gå till listan över betrodda certifikat (CTL). Om det uppstår tillfälliga problem med nätverket eller DNS(Domain Name System) i Azure eller Windows Update när Windows försöker verifiera certifikatet kan certifikatet anses vara ogiltigt. När du installerar den fullständiga certifikatkedjan kan du undvika det här problemet. Bloggen på How to install a chained SSL certificate (Installera ett länkat SSL-certifikat ) visar hur du installerar den fullständiga certifikatkedjan.

Dessa certifikat skapas automatiskt när ett tillägg läggs till i molntjänsten. Det här tillägget är oftast WAD-tillägget eller RDP-tillägget, men det kan vara andra, till exempel tillägget Program mot skadlig kod eller Logginsamlare. Dessa certifikat används endast för att kryptera och dekryptera den privata konfigurationen för tillägget. Förfallodatumet kontrolleras aldrig, så det spelar ingen roll om certifikatet har upphört att gälla. 

Du kan ignorera dessa certifikat. Om du vill rensa certifikaten kan du prova att ta bort alla. Azure utlöser ett fel om du försöker ta bort ett certifikat som används.

Se följande vägledningsdokument:

Skaffa ett certifikat för användning med Microsoft Azure-webbplatser (WAWS)

CSR är bara en textfil. Den behöver inte skapas från den dator som är avsedd att använda certifikatet. Även om det här dokumentet är skrivet för en App Service är csr-skapandet allmänt och gäller även för Cloud Services.

Du kan använda följande PowerShell-kommandon för att förnya dina hanteringscertifikat:

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

Get-AzurePublishSettingsFile skapar ett nytt hanteringscertifikat i Prenumerationshanteringscertifikat> i Azure Portal. Namnet på det nya certifikatet ser ut som "YourSubscriptionNam]-[CurrentDate]-credentials".

Du kan automatisera den här uppgiften med hjälp av ett startskript (batch/cmd/PowerShell) och registrera startskriptet i tjänstdefinitionsfilen. Lägg till både startskriptet och certifikatet (.p7b-filen) i projektmappen i samma katalog i startskriptet.

Det här certifikatet används för att kryptera datornycklar på Azure-webbroller. Mer information finns i den här rådgivningen.

Mer information finns i följande artiklar:

• Så här konfigurerar och kör du startuppgifter för en molntjänst
• Vanliga startuppgifter för Cloud Service

Möjligheten att generera ett nytt certifikat för RDP (Remote Desktop Protocol) kommer snart. Du kan också köra det här skriptet:

$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

Möjligheten att välja blob eller lokal för din csdef- och cscfg-uppladdningsplats kommer snart. Med New-AzureDeployment kan du ange varje platsvärde.

Möjlighet att övervaka mått på instansnivå. Fler övervakningsfunktioner finns i Övervaka molntjänster.

Du har förbrukat den lokala lagringskvoten för att skriva till loggkatalogen. Du kan åtgärda det här problemet genom att göra något av tre:

• Aktivera diagnostik för IIS och låt diagnostiken regelbundet flyttas till bloblagring.
• Ta bort loggfiler manuellt från loggningskatalogen.
• Öka kvotgränsen för lokala resurser.

Mer information finns i följande dokument.

• Lagra och visa diagnostikdata i Azure Storage
• IIS-loggar slutar skriva i Cloud Service

Du kan aktivera loggning av Microsoft Azure Diagnostics (WAD) genom följande alternativ:

1. Aktivera från Visual Studio
2. Aktivera via .NET-kod
3. Aktivera via PowerShell

För att hämta de aktuella WAD-inställningarna för din molntjänst kan du använda Get-AzureServiceDiagnosticsExtensions PowerShell-cmd eller så kan du visa den via portalen från bladet "Cloud Services --> Extensions".

Du kan ange tidsgränsen i tjänstdefinitionsfilen (csdef) så här:

<?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>

Mer information finns i Ny: Konfigurerbar tidsgräns för inaktivitet för Azure Load Balancer .

Om du vill konfigurera en statisk IP-adress måste du skapa en reserverad IP-adress. Den här reserverade IP-adressen kan associeras till en ny molntjänst eller till en befintlig distribution. Mer information finns i följande dokument:

• Så här skapar du en reserverad IP-adress
• Reservera IP-adressen för en befintlig molntjänst
• Associera en reserverad IP-adress till en ny molntjänst
• Associera en reserverad IP-adress till en distribution som körs
• Associera en reserverad IP-adress till en molntjänst med hjälp av en tjänstkonfigurationsfil

Azure har IPS/IDS på fysiska datacenterservrar för att skydda mot hot. Dessutom kan kunder distribuera säkerhetslösningar som inte kommer från Microsoft, till exempel brandväggar för webbprogram, nätverksbrandväggar, program mot skadlig kod, intrångsidentifiering, skyddssystem (IDS/IPS) med mera. Mer information finns i Skydda dina data och tillgångar och följ globala säkerhetsstandarder.

Microsoft övervakar kontinuerligt servrar, nätverk och program för att identifiera hot. Azures multipronged hothanteringsmetod använder intrångsidentifiering, distribuerad överbelastningsattack (DDoS), intrångstestning, beteendeanalys, avvikelseidentifiering och maskininlärning för att ständigt stärka skyddet och minska riskerna. Microsoft Antimalware för Azure skyddar Azure Cloud Services och virtuella datorer. Du kan dessutom distribuera säkerhetslösningar som inte kommer från Microsoft, till exempel brandväggar för brandväggar för webbprogram, nätverksbrandväggar, program mot skadlig kod, intrångsidentifiering och förebyggande system (IDS/IPS) med mera.

Windows 10 och Windows Server 2016 har stöd för HTTP/2 på både klient- och serversidan. Om klienten (webbläsaren) ansluter till IIS-servern via TLS (Transport Layer Security) som förhandlar om HTTP/2 via TLS-tillägg behöver du inte göra några ändringar på serversidan. Du behöver inte göra ändringar eftersom h2-14-huvudet som anger användningen av HTTP/2 skickas som standard via TLS. Om klienten å andra sidan skickar ett uppgraderingshuvud för att uppgradera till HTTP/2 måste du göra följande ändring på serversidan för att säkerställa att uppgraderingen fungerar och att du får en HTTP/2-anslutning.

1. Kör regedit.exe.
2. Bläddra till registernyckel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
3. Skapa ett nytt DWORD-värde med namnet DuoEnabled.
4. Ange värdet till 1.
5. Starta om servern.
6. Gå till Bindningar på standardwebbplatsen och skapa en ny TLS-bindning med det självsignerade certifikatet som du skapade.

Mer information finns i:

• HTTP/2 på IIS
• Video: HTTP/2 i Windows 10: Webbläsare, appar och webbserver

De här stegen kan automatiseras via en startuppgift, så att när en ny PaaS-instans skapas kan den göra de tidigare ändringarna i systemregistret. Mer information finns i Konfigurera och köra startuppgifter för en molntjänst.

När du är klar kan du kontrollera om HTTP/2 är aktiverat eller inte med någon av följande metoder:

• Aktivera Protokollversion i IIS-loggar och titta på IIS-loggarna. Den visar HTTP/2 i loggarna.
• Aktivera F12 Developer Tool i Internet Explorer eller Microsoft Edge och växla till fliken Nätverk. Här kan du verifiera protokollet.

Mer information finns i HTTP/2 på IIS.

Cloud Services stöder inte den rollbaserade azure-åtkomstkontrollmodellen eftersom den inte är en Azure Resource Manager-baserad tjänst.

Se Förstå de olika rollerna i Azure.

Microsoft följer en strikt process som inte tillåter interna tekniker att fjärrskrivbord till din molntjänst utan skriftligt tillstånd (e-post eller annan skriftlig kommunikation) från ägaren eller deras designobjekt.

Det här felet kan inträffa om du använder RDP-filen från en dator som är ansluten till Microsoft Entra-ID. Följ dessa anvisningar för att lösa problemet:

1. Högerklicka på RDP-filen som du laddade ned och välj sedan Redigera.
2. Lägg till "\" som prefix före användarnamnet. Använd till exempel .\username i stället för användarnamn.

Din Azure-prenumeration har en gräns för hur många kärnor du kan använda. Skalning fungerar inte om du använde alla tillgängliga kärnor. Om du till exempel har en gräns på 100 kärnor innebär det att du kan ha 100 virtuella datorinstanser i A1-storlek för din molntjänst eller 50 instanser med A2-storlek för virtuella datorer.

Autoskalning baserat på minnesmått för molntjänster stöds inte för närvarande.

Om du vill undvika det här problemet kan du använda Application Insights. Automatisk skalning stöder Application Insights som måttkälla och kan skala antalet rollinstanser baserat på gästmått som "Minne". Du måste konfigurera Application Insights i molntjänstprojektets paketfil (*.cspkg) och aktivera Azure Diagnostics-tillägget på tjänsten för att implementera den här bedriften.

Mer information om hur du använder ett anpassat mått via Application Insights för att konfigurera automatisk skalning i Cloud Services finns i Kom igång med automatisk skalning efter anpassat mått i Azure

Mer information om hur du integrerar Azure Diagnostics med Application Insights för Cloud Services finns i Skicka molntjänst, virtuell dator eller Service Fabric-diagnostikdata till Application Insights

Mer information om hur du aktiverar Application Insights för Cloud Services finns i Application Insights för Azure Cloud Services

Mer information om hur du aktiverar Azure Diagnostics-loggning för Cloud Services finns i Konfigurera diagnostik för Azure Cloud Services och virtuella datorer

Om du vill förhindra klienter från att sniffa MIME-typerna lägger du till en inställning i filen web.config .

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

Du kan också lägga till detta som en inställning i IIS. Använd följande kommando med artikeln vanliga startuppgifter .

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

Använd IIS-startskriptet från artikeln vanliga startuppgifter .

Se Tjänstspecifika gränser.

Det här beteendet förväntas och bör inte orsaka något problem för ditt program. Journaler aktiveras för enheten %approot% i virtuella Azure PaaS-datorer, vilket i princip förbrukar dubbelt så mycket utrymme som filer normalt tar upp. Det finns dock flera saker att vara medveten om som gör den här händelsen till en icke-fråga.

Enhetsstorleken %approot% beräknas som <storleken på .cspkg + max journalstorlek + en marginal med ledigt utrymme>, eller 1,5 GB, beroende på vilket som är större. Storleken på den virtuella datorn har ingen betydelse för den här beräkningen. (Storleken på den virtuella datorn påverkar bara storleken på den tillfälliga C:-enheten.)

Det går inte att skriva till enheten %approot%. Om du skriver till den virtuella Azure-datorn måste du göra det i en tillfällig LocalStorage-resurs (eller något annat alternativ, till exempel Blob Storage, Azure Files osv.). Därför är mängden ledigt utrymme i mappen %approot% inte meningsfullt. Om du inte är säker på om programmet skriver till %approot%-enheten kan du alltid låta tjänsten köras i några dagar och sedan jämföra storlekarna "före" och "efter". 

Azure skriver ingenting till %approot%-enheten. När den virtuella hårddisken (VHD) har skapats från din .cspkg och monterats på den virtuella Azure-datorn är det enda som kan skriva till den här enheten ditt program. 

Journalinställningarna är inte konfigurerbara, så du kan inte inaktivera det.

Du kan aktivera tillägget Program mot skadlig kod med hjälp av PowerShell-skript i startuppgiften. Följ stegen i de här artiklarna för att implementera det:

• Skapa en PowerShell-startuppgift
• Set-AzureServiceAntimalwareExtension

Mer information om distributionsscenarier för program mot skadlig kod och hur du aktiverar det från portalen finns i Distributionsscenarier för program mot skadlig kod.

Du kan aktivera SNI i Cloud Services med någon av följande metoder:

Metod 1: Använda PowerShell

SNI-bindningen kan konfigureras med hjälp av följande PowerShell-cmdlet New-WebBinding i en startuppgift för en molntjänstrollinstans:

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

Som beskrivs här kan $sslFlags vara något av följande värden:

Metod 2: Använd kod

SNI-bindningen kan också konfigureras via kod i rollstarten enligt beskrivningen i det här blogginlägget:

//<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>

Med någon av ovanstående metoder måste respektive certifikat (*.pfx) för de specifika värdnamnen först installeras på rollinstanserna med hjälp av en startaktivitet eller via kod för att SNI-bindningen ska vara effektiv.

Cloud Service är en klassisk resurs. Endast resurser som skapats via Azure Resource Manager stöder taggar. Du kan inte använda taggar för klassiska resurser, till exempel Cloud Service.

Vi arbetar med att ta med den här funktionen på Azure Portal. Under tiden kan du använda följande PowerShell-kommandon för att hämta SDK-versionen:

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

En redan distribuerad molntjänst debiteras för den beräkning och lagring som den använder. Så även om du stänger av den virtuella Azure-datorn debiteras du fortfarande för lagringen.

Här är vad du kan göra för att minska din fakturering utan att förlora IP-adressen för din tjänst:

1. Reservera IP-adressen innan du tar bort distributionerna. Azure debiterar dig endast för den här IP-adressen. Mer information om IP-adressfakturering finns i Prissättning för IP-adresser.
2. Ta bort distributionerna. Ta inte bort xxx.cloudapp.net så att du kan använda den i framtiden.
3. Om du vill distribuera om molntjänsten med samma reserverade IP-adress som du reserverade i din prenumeration kan du läsa Reserverade IP-adresser för Molntjänster och Virtuella datorer.