Problemi di configurazione e gestione per Servizi cloud di Azure (versione classica): domande frequenti

È consigliabile installare la catena di certificati completa (certificato foglia, certificati intermedi e certificato radice) invece che solo il certificato foglia. Quando si installa solo il certificato foglia, ci si basa su Windows per creare la catena di certificati scorrendo l'elenco di scopi consentiti. In caso di problemi intermittenti di rete o DNS in Azure o Windows Update quando Windows tenta di convalidare il certificato, il certificato potrebbe essere considerato non valido. Installando la catena di certificati completa, è possibile evitare questo problema. Il post di blog How to install a chained SSL Certificate (Come installare un certificato SSL incluso in una catena) spiega come fare.

Questi certificati vengono creati automaticamente ogni volta che si aggiunge un'estensione al servizio cloud. In genere, si tratta dell'estensione WAD o RDP, ma può trattarsi anche di altre estensioni, ad esempio l'estensione antimalware o dell'agente di raccolta log. Questi certificati vengono usati unicamente per crittografare e decrittografare la configurazione privata dell'estensione. La data di scadenza non viene mai controllata, quindi non è importante se il certificato è scaduto. 

È possibile ignorare questi certificati. Per eseguire la pulizia dei certificati, provare a eliminarli tutti. Se si tenta di eliminare un certificato in uso, Azure genera un errore.

Per indicazioni, vedere il documento seguente:

Obtaining a certificate for use with Windows Azure Web Sites (WAWS) (Ottenere un certificato per l'uso con Siti Web di Azure)

La richiesta di firma del certificato è semplicemente un file di testo. Non è necessario che tale file venga creato dal computer in cui il certificato verrà usato. Anche se questo documento è scritto per un servizio app, la creazione della richiesta di firma del certificato è generica e si applica anche a Servizi cloud.

È possibile usare i comandi seguenti di PowerShell per il rinnovo dei certificati di gestione:

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

Get-AzurePublishSettingsFile creerà un nuovo certificato di gestione in Sottoscrizione>Certificati di gestione nel portale di Azure. Il nome del nuovo certificato è simile a "[NomeSottoscrizione]-[DataCorrente] - credenziali".

È possibile automatizzare questa attività usando uno script di avvio (batch/cmd/PowerShell) e registrare lo script di avvio nel file di definizione del servizio. Aggiungere sia lo script di avvio sia il certificato (file con estensione p7b) nella cartella del progetto nella stessa directory dello script di avvio.

Questo certificato viene usato per crittografare le chiavi computer nei ruoli Web di Azure. Per altre informazioni, consultare questo advisory.

Per altre informazioni, vedere gli articoli seguenti:

• Come configurare ed eseguire attività di avvio per un servizio cloud
• Attività di avvio comuni del servizio cloud

Sarà presto disponibile la possibilità di generare un nuovo certificato per Remote Desktop Protocol (RDP). In alternativa, è possibile eseguire lo script seguente:

$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

Sarà disponibile a breve la possibilità di scegliere BLOB o locale come percorso di caricamento dei file con estensione csdef e cscfg. Usare New-AzureDeployment per impostare il valore di ciascuna posizione.

Possibilità di monitorare le metriche a livello di istanza. In Come monitorare i servizi cloud sono disponibili funzionalità di monitoraggio aggiuntive.

È stata superata la quota di archiviazione locale per la scrittura nella directory dei log. Per risolvere il problema, è possibile eseguire una delle tre operazioni seguenti:

• Abilitare la diagnostica per IIS e spostare periodicamente la diagnostica nell'archiviazione BLOB.
• Rimuovere manualmente i file di log dalla directory di registrazione.
• Aumentare il limite di quota per le risorse locali.

Per altre informazioni, vedere i documenti seguenti:

• Archiviare e visualizzare i dati di diagnostica in Archiviazione di Azure
• IIS Logs stop writing in Cloud Service (I log di IIS non vengono più scritti nel servizio cloud)

È possibile abilitare la registrazione di Diagnostica di Microsoft Azure tramite le opzioni seguenti:

1. Abilitare da Visual Studio
2. Abilitare tramite codice .NET
3. Abilitare tramite PowerShell

Per ottenere le impostazioni di Diagnostica di Microsoft Azure corrente del servizio cloud, è possibile usare il comando Get-AzureServiceDiagnosticsExtensions di PowerShell oppure è possibile visualizzarle tramite il portale dal pannello "Servizi cloud --> Estensioni".

È possibile specificare il timeout nel file di definizione del servizio (con estensione csdef) analogo al seguente:

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

Per altre informazioni, vedere New: Configurable Idle Timeout for Azure Load Balancer (Novità: Timeout di inattività configurabile per Azure Load Balancer).

Per configurare un indirizzo IP statico, è necessario creare un IP riservato. Questo indirizzo IP riservato può essere associato a un nuovo servizio cloud o a una distribuzione esistente. Vedere i documenti seguenti per informazioni dettagliate:

• Come creare un indirizzo IP riservato
• Riservare l'indirizzo IP di un servizio cloud esistente
• Associare un indirizzo IP riservato a un nuovo servizio cloud
• Associare un indirizzo IP riservato a una distribuzione in esecuzione
• Associare un indirizzo IP riservato a un servizio cloud usando un file cscfg

Azure offre sistemi di rilevamento e prevenzione delle intrusioni nei server fisici dei data center per consentire la difesa dalle minacce. I clienti possono anche distribuire soluzioni di sicurezza di terze parti, ad esempio web application firewall, firewall di rete, antimalware, sistemi di rilevamento delle intrusioni, sistemi di prevenzione e altro ancora. Per altre informazioni, vedere Protect your data and assets and comply with global security standards (Proteggere dati e asset e rispettare gli standard di sicurezza globali).

Microsoft esegue un monitoraggio continuo di server, reti e applicazioni per rilevare le minacce. L'approccio di gestione delle minacce su più fronti adottato in Azure prevede l'uso di funzionalità di rilevamento delle intrusioni, prevenzione contro attacchi Distributed Denial of Service (DDoS), test di penetrazione, analisi comportamentali, rilevamento di anomalie e apprendimento automatico al fine di rafforzare continuamente le difese e ridurre i rischi. Microsoft Antimalware per Azure protegge i servizi cloud e le macchine virtuali di Azure. In aggiunta è possibile distribuire soluzioni di terze parti, come web application firewall, firewall di rete, antimalware, sistemi di rilevamento e prevenzione delle intrusioni e altro ancora.

Windows 10 e Windows Server 2016 includono il supporto per HTTP/2 sia sul lato client sia sul lato server. Se il client (browser) si connette al server IIS mediante il protocollo TLS che negozia HTTP/2 tramite le estensioni TLS, non è necessario apportare modifiche sul lato server. Con il protocollo TLS infatti come impostazione predefinita viene inviata l'intestazione h2-14 che specifica l'utilizzo di HTTP/2. Se invece il client invia un'intestazione di aggiornamento per eseguire l'aggiornamento a HTTP/2, è necessario apportare la modifica di seguito sul lato server per garantire il funzionamento dell'aggiornamento e la disponibilità di una connessione HTTP/2.

1. Eseguire regedit.exe.
2. Individuare la chiave del Registro di sistema: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
3. Creare un nuovo valore DWORD denominato DuoEnabled.
4. Impostare il relativo valore su 1.
5. Riavviare il server.
6. Passare al sito Web predefinito e in Associazioni creare una nuova associazione TLS con il certificato autofirmato appena creato.

Per altre informazioni, vedi:

• HTTP/2 on IIS (HTTP/2 in IIS)
• Video: HTTP/2 in Windows 10: Browser, Apps and Web Server (Video: HTTP/2 in Windows 10: Browser, app e server Web)

È possibile automatizzare i passaggi precedenti tramite un'attività di avvio in modo che ogni volta che viene creata una nuova istanza PaaS, l'attività possa eseguire le modifiche indicate in precedenza nel Registro di sistema. Per altre informazioni, vedere Come configurare ed eseguire attività di avvio per un servizio cloud.

Dopo questa operazione è possibile verificare l'abilitazione del protocollo HTTP/2 usando uno dei metodi seguenti:

• Abilitare la versione del protocollo nei log di IIS ed esaminare i log di IIS. HTTP/2 verrà indicato nei log.
• Abilitare lo strumento di sviluppo F12 in Internet Explorer o Microsoft Edge e passare alla scheda Rete per controllare il protocollo.

Per altre informazioni, vedere HTTP/2 on IIS (HTTP/2 in IIS).

Servizi cloud non supporta il modello di controllo degli accessi in base al ruolo di Azure, perché non è un servizio basato su Azure Resource Manager.

Vedere Comprendere i diversi ruoli in Azure.

Microsoft segue un processo rigoroso che non consente ai tecnici interni di usare desktop remoto nel servizio cloud di un cliente senza autorizzazione scritta (tramite posta elettronica o altro tipo di comunicazione scritta) del proprietario o di un suo rappresentante.

Questo errore può verificarsi se si usa il file RDP da un computer aggiunto a Microsoft Entra ID. Per risolvere il problema, seguire questa procedura:

1. Fare clic con il pulsante destro del mouse sul file RDP scaricato e quindi scegliere Modifica.
2. Aggiungere "\" come prefisso prima del nome utente. Ad esempio, usare .\nomeutente invece di nomeutente.

La sottoscrizione di Azure presenta un limite al numero di memorie centrali che è possibile usare. Se vengono usate tutte le memorie centrali disponibili, la scalabilità non funziona. Ad esempio, se si dispone di un limite di 100 memorie centrali, vuol dire che è possibile avere 100 istanze di macchina virtuale con dimensioni A1 per il servizio cloud o 50 istanze di macchine virtuali con dimensioni A2.

La scalabilità automatica in base alle metriche di memoria per i servizi cloud non è attualmente supportata.

Per ovviare a questo problema, è possibile usare Application Insights. La scalabilità automatica supporta Application Insights come origine delle metriche e supporta l'aumento o la riduzione del numero di istanze del ruolo in base a metriche guest come la memoria. Per implementare questa funzionalità, è necessario configurare Application Insights nel file di pacchetto del progetto del servizio cloud (*.cspkg) e abilitare l'estensione Diagnostica di Azure per il servizio.

Per altri dettagli su come usare una metrica personalizzata tramite Application Insights per configurare la scalabilità automatica per i servizi cloud, vedere Introduzione alla scalabilità automatica in base a una metrica personalizzata in Azure

Per altre informazioni su come integrare Diagnostica di Azure con Application Insights per i servizi cloud, vedere Inviare i dati di diagnostica del servizio Cloud, della macchina virtuale o di Service Fabric ad Application Insights

Per altre informazioni su come abilitare Application Insights per i servizi cloud, vedere Application Insights per Servizi cloud di Azure

Per altre informazioni su come abilitare la registrazione diagnostica di Azure per i servizi cloud, vedere Configurare la diagnostica per i servizi cloud e le macchine virtuali di Azure

Per impedire che i client eseguano lo sniffing dei tipi MIME, aggiungere un'impostazione a web.config.

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

È possibile aggiungerla anche come impostazione in IIS. Usare il comando seguente con l'articolo sulle attività di avvio comuni.

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

Usare lo script di avvio di IIS dell'articolo sulle attività di avvio comuni.

Vedere Limiti specifici del servizio.

Questo comportamento è previsto e non dovrebbe causare alcun problema all'applicazione. L'inserimento nel giornale di registrazione è attivato per l'unità %approot% nelle macchine virtuali PaaS di Azure e ciò comporta essenzialmente l'utilizzo del doppio della quantità di spazio normalmente occupata dai file. Ci sono tuttavia alcuni aspetti da considerare che permettono di capire come questo non sia un vero problema.

Le dimensioni dell'unità %approot% vengono calcolate come <dimensioni del file con estensione cspkg + dimensioni massime del giornale di registrazione + margine di spazio libero> oppure 1,5 GB, a seconda di quale sia il valore maggiore. Le dimensioni della VM non sono rilevanti per questo calcolo. Le dimensioni della VM influiscono solo sulle dimensioni del disco C temporaneo.

La scrittura nell'unità %approot% non è supportata. Se si scrive nella VM di Azure, è necessario farlo in una risorsa LocalStorage temporanea (o in un'altra posizione, ad esempio archiviazione BLOB, File di Azure e così via). La quantità di spazio disponibile nella cartella %approot% non è quindi significativa. Se non si è certi del fatto che l'applicazione scriva nell'unità %approot%, è possibile lasciare il servizio in esecuzione per alcuni giorni e quindi confrontare le dimensioni prima e dopo. 

Azure non scrive nell'unità %approot%. Una volta che il disco rigido virtuale viene creato da .cspkg e montato nella macchina virtuale di Azure, l'unica cosa che può scrivere in questa unità è l'applicazione. 

Le impostazioni del giornale di registrazione non sono configurabili e quindi non possono essere disattivate.

È possibile abilitare l'estensione Antimalware usando lo script PowerShell nell'attività di avvio. Per l'implementazione seguire i passaggi descritti in questi articoli:

• Creare un'attività di avvio di PowerShell
• Set-AzureServiceAntimalwareExtension

Per altre informazioni sugli scenari di distribuzione dell'estensione Antimalware e sulla relativa abilitazione dal portale, vedere Scenari di distribuzione di Antimalware.

È possibile abilitare SNI in Servizi cloud usando uno dei metodi seguenti:

Metodo 1: Usare PowerShell

È possibile configurare l'associazione SNI tramite il cmdlet si PowerShell New-WebBinding in un'attività di avvio per un'istanza di ruolo del servizio cloud, come indicato di seguito:

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

Come descritto qui, $sslFlags potrebbe assumere uno dei valori seguenti:

Metodo 2: Usare il codice

È possibile configurare l'associazione SNI anche tramite il codice nell'attività di avvio del ruolo, come descritto in questo post di blog:

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

Usando uno qualsiasi degli approcci descritti in precedenza, è necessario che i rispettivi certificati (\*.PFX) per nomi host specifici vengano installati prima nelle istanze dei ruoli usando un'attività di avvio o tramite il codice perché l'associazione SNI diventi efficace.

Il servizio cloud è una risorsa classica. Solo le risorse create tramite Azure Resource Manager supportano i tag. Non è possibile applicare tag alle risorse classiche, ad esempio al servizio cloud.

L'aggiunta di questa funzionalità nel portale di Azure è in corso di sviluppo. Nel frattempo, è possibile usare i comandi seguenti di PowerShell per ottenere la versione dell'SDK:

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

Un servizio cloud già distribuito viene fatturato in base ai servizi di calcolo e archiviazione usati. Pertanto, anche se si arresta la macchina virtuale di Azure, l'archiviazione verrà comunque addebitata.

Ecco cosa è possibile fare per ridurre la fatturazione senza perdere l'indirizzo IP per il servizio:

1. Riservare l'indirizzo IP prima di eliminare le distribuzioni. Verrà addebitato solo questo indirizzo IP. Per altre informazioni sulla fatturazione degli indirizzi IP, vedere Prezzi per gli indirizzi IP.
2. Eliminare le distribuzioni. Non eliminare xxx.cloudapp.net, in modo che sia possibile usarla in futuro.
3. Se si vuole ridistribuire il servizio cloud con lo stesso indirizzo IP riservato nella sottoscrizione, vedere Reserved IP addresses for Cloud Services and Virtual Machines (Indirizzi IP riservati per i servizi cloud e le macchine virtuali).