Problemas de configuração e gerenciamento dos Serviços de Nuvem do Azure (clássico): perguntas frequentes (FAQs)

Recomendamos que os clientes instalem a cadeia de certificados completa (leaf cert, intermediate certs e root cert) em vez de apenas o leaf certificate. Ao instalar apenas o certificado folha, você confia no Windows para criar a cadeia de certificados seguindo a CTL (Lista de Certificados Confiáveis). Se ocorrerem problemas intermitentes de rede ou DNS (Sistema de Nomes de Domínio) no Azure ou no Windows Update quando o Windows estiver tentando validar o certificado, o certificado poderá ser considerado inválido. Quando você instala a cadeia de certificados completa, esse problema pode ser evitado. O blog em Como instalar um certificado SSL encadeado mostra como instalar a cadeia de certificados completa.

Esses certificados são criados automaticamente sempre que uma extensão é adicionada ao Serviço de Nuvem. Mais comumente, essa extensão é a extensão WAD ou a extensão RDP, mas pode ser outras, como a extensão Antimalware ou Log Collector. Esses certificados são usados apenas para criptografar e descriptografar a configuração privada para a extensão. A data de validade nunca é verificada, por isso não importa se o certificado expirou. 

Você pode ignorar esses certificados. Se você quiser limpar os certificados, você pode tentar excluí-los todos. O Azure lança um erro se você tentar excluir um certificado que está em uso.

Consulte o seguinte documento de orientação:

Obtendo um certificado para uso com os Sites do Microsoft Azure (WAWS)

O CSR é apenas um ficheiro de texto. Ele não precisa ser criado a partir da máquina destinada a usar o certificado. Embora este documento tenha sido escrito para um Serviço de Aplicativo, a criação de CSR é genérica e se aplica também aos Serviços de Nuvem.

Você pode usar os seguintes comandos do PowerShell para renovar seus Certificados de Gerenciamento:

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

O Get-AzurePublishSettingsFile cria um novo certificado de gerenciamento em Certificados de Gerenciamento de Assinatura> no portal do Azure. O nome do novo certificado se parece com "YourSubscriptionNam]-[CurrentDate]-credentials".

Você pode automatizar essa tarefa usando um script de inicialização (batch/cmd/PowerShell) e registrar esse script de inicialização no arquivo de definição de serviço. Adicione o script de inicialização e o certificado (arquivo .p7b) na pasta do projeto do mesmo diretório do script de inicialização.

Este certificado é usado para criptografar chaves de máquina em Funções Web do Azure. Para saber mais, confira este comunicado.

Para obter mais informações, consulte os seguintes artigos:

• Como configurar e executar tarefas de inicialização para um serviço de nuvem
• Tarefas comuns de inicialização do Serviço de Nuvem

A capacidade de gerar um novo certificado para o protocolo RDP (Remote Desktop Protocol) será disponibilizada em breve. Como alternativa, você pode executar este script:

$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

A capacidade de escolher blob ou local para o seu local de upload csdef e cscfg está chegando em breve. Usando New-AzureDeployment, você pode definir cada valor de local.

Capacidade de monitorar métricas no nível da instância. Mais recursos de monitoramento estão disponíveis em Como monitorar serviços de nuvem.

Você esgotou a cota de armazenamento local para gravar no diretório de log. Para corrigir esse problema, você pode fazer uma das três coisas:

• Habilite o diagnóstico para o IIS e faça com que o diagnóstico seja movido periodicamente para o armazenamento de blobs.
• Remova manualmente os arquivos de log do diretório de log.
• Aumentar o limite de cota para recursos locais.

Para obter mais informações, consulte os documentos seguintes:

• Armazenar e ver dados de diagnósticos no Armazenamento do Azure
• Os logs do IIS param de gravar no Serviço de Nuvem

Você pode habilitar o log do Diagnóstico do Microsoft Azure (WAD) por meio das seguintes opções:

1. Habilitar do Visual Studio
2. Ativar através do código .NET
3. Habilitar por meio do PowerShell

Para obter as configurações WAD atuais do seu Serviço de Nuvem, você pode usar Get-AzureServiceDiagnosticsExtensions PowerShell cmd ou visualizá-lo através do portal na folha "Serviços de Nuvem --> Extensões".

Você pode especificar o tempo limite em seu arquivo de definição de serviço (csdef) da seguinte forma:

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

Consulte Novo: Tempo limite de inatividade configurável para o Azure Load Balancer para obter mais informações.

Para configurar um endereço IP estático, você precisa criar um IP reservado. Esse IP reservado pode ser associado a um novo serviço de nuvem ou a uma implantação existente. Consulte os seguintes documentos para obter detalhes:

• Como criar um endereço IP reservado
• Reservar o endereço IP de um serviço de nuvem existente
• Associar um IP reservado a um novo Serviço de Nuvem
• Associar um IP reservado a uma implantação em execução
• Associar um IP reservado a um serviço de nuvem usando um arquivo de configuração de serviço

O Azure tem IPS/IDS em servidores físicos de datacenter para defesa contra ameaças. Além disso, os clientes podem implantar soluções de segurança que não sejam da Microsoft, como firewalls de aplicativos Web, firewalls de rede, antimalware, deteção de intrusão, sistemas de prevenção (IDS/IPS) e muito mais. Para obter mais informações, consulte Proteja seus dados e ativos e cumpra os padrões globais de segurança.

A Microsoft monitora continuamente servidores, redes e aplicativos para detetar ameaças. A abordagem multifacetada de gerenciamento de ameaças do Azure usa deteção de intrusão, prevenção de ataques distribuídos de negação de serviço (DDoS), testes de penetração, análise comportamental, deteção de anomalias e aprendizado de máquina para fortalecer constantemente sua defesa e reduzir riscos. O Microsoft Antimalware para Azure protege os Serviços de Nuvem do Azure e as máquinas virtuais. Além disso, você pode implantar soluções de segurança que não sejam da Microsoft, como paredes de incêndio de aplicativos Web, firewalls de rede, antimalware, sistemas de deteção e prevenção de invasões (IDS/IPS) e muito mais.

O Windows 10 e o Windows Server 2016 vêm com suporte para HTTP/2 no lado do cliente e do servidor. Se o seu cliente (navegador) estiver se conectando ao servidor IIS por TLS (Transport Layer Security) que negocia HTTP/2 por meio de extensões TLS, você não precisará fazer nenhuma alteração no lado do servidor. Você não precisa fazer alterações porque o cabeçalho h2-14 que especifica o uso de HTTP/2 é enviado por padrão por TLS. Se, por outro lado, seu cliente estiver enviando um cabeçalho de atualização para atualizar para HTTP/2, então você precisa fazer a seguinte alteração no lado do servidor para garantir que a atualização funcione e você acabe com uma conexão HTTP/2.

1. Execute regedit.exe.
2. Navegue até a chave do Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
3. Crie um novo valor DWORD chamado DuoEnabled.
4. Defina seu valor como 1.
5. Reinicie o servidor.
6. Vá em Ligações no seu Site Padrão e crie uma nova ligação TLS com o certificado autoassinado que você criou.

Para obter mais informações, consulte:

• HTTP/2 no IIS
• Vídeo: HTTP/2 no Windows 10: Navegador, aplicativos e servidor Web

Essas etapas podem ser automatizadas por meio de uma tarefa de inicialização, para que sempre que uma nova instância de PaaS seja criada, ela possa fazer as alterações anteriores no registro do sistema. Para obter mais informações, consulte Como configurar e executar tarefas de inicialização para um serviço de nuvem.

Quando terminar, você pode verificar se o HTTP/2 está habilitado ou não usando um dos seguintes métodos:

• Habilite a versão do protocolo nos logs do IIS e examine os logs do IIS. Ele mostra HTTP/2 nos logs.
• Habilite a F12 Developer Tool no Internet Explorer ou Microsoft Edge e alterne para a guia Rede. Aqui, você pode verificar o protocolo.

Para obter mais informações, consulte HTTP/2 no IIS.

Os Serviços de Nuvem não dão suporte ao modelo de controle de acesso baseado em função do Azure, pois não é um serviço baseado no Azure Resource Manager.

Consulte Compreender as diferentes funções no Azure.

A Microsoft segue um processo rigoroso que não permite que engenheiros internos façam desktop remoto em seu Serviço de Nuvem sem permissão por escrito (e-mail ou outra comunicação por escrito) do proprietário ou de seu representante.

Este erro pode ocorrer se você usar o arquivo RDP de uma máquina que está associada ao Microsoft Entra ID. Para resolver este problema, siga estes passos:

1. Clique com o botão direito do rato no ficheiro RDP que transferiu e, em seguida, selecione Editar.
2. Adicione "\" como prefixo antes do nome de usuário. Por exemplo, use .\username em vez de username.

Sua Assinatura do Azure tem um limite no número de núcleos que você pode usar. O dimensionamento não funciona se você usou todos os núcleos disponíveis. Por exemplo, se você tiver um limite de 100 núcleos, isso significa que poderá ter 100 instâncias de máquina virtual de tamanho A1 para seu Serviço de Nuvem ou 50 instâncias de máquina virtual de tamanho A2.

O dimensionamento automático com base em métricas de memória para um Serviço de Nuvem não é suportado no momento.

Para contornar esse problema, você pode usar o Application Insights. O Auto-Scale suporta o Application Insights como uma fonte de métricas e pode dimensionar a contagem de instâncias de função com base na métrica de convidado, como "Memória". Você precisa configurar o Application Insights em seu arquivo de pacote de projeto do Serviço de Nuvem (*.cspkg) e habilitar a extensão de Diagnóstico do Azure no serviço para implementar esse feito.

Para obter mais informações sobre como utilizar uma métrica personalizada por meio do Application Insights para configurar o dimensionamento automático em serviços de nuvem, consulte Introdução ao dimensionamento automático por métrica personalizada no Azure

Para obter mais informações sobre como integrar o Diagnóstico do Azure com o Application Insights para Serviços de Nuvem, consulte Enviar dados de diagnóstico do Serviço de Nuvem, Máquina Virtual ou Service Fabric para o Application Insights

Para obter mais informações sobre como habilitar o Application Insights para Serviços de Nuvem, consulte Application Insights for Azure Cloud Services

Para obter mais informações sobre como habilitar o Log de Diagnóstico do Azure para Serviços de Nuvem, consulte Configurar diagnósticos para Serviços de Nuvem do Azure e máquinas virtuais

Para impedir que os clientes detetem os tipos MIME, adicione uma configuração no arquivo web.config .

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

Você também pode adicionar isso como uma configuração no IIS. Use o seguinte comando com o artigo de tarefas comuns de inicialização.

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

Use o script de inicialização do IIS do artigo de tarefas comuns de inicialização.

Consulte Limites específicos do serviço.

Esse comportamento é esperado e não deve causar nenhum problema ao seu aplicativo. O registro no diário é ativado para a unidade %approot% nas VMs PaaS do Azure, que essencialmente consome o dobro da quantidade de espaço que os arquivos normalmente ocupam. No entanto, há várias coisas a ter em conta que tornam este evento num não-problema.

O tamanho da unidade %approot% é calculado como <o tamanho de .cspkg + tamanho máximo do diário + uma margem de espaço> livre ou 1,5 GB, o que for maior. O tamanho da sua VM não tem qualquer influência neste cálculo. (O tamanho da VM afeta apenas o tamanho da unidade C: temporária.)

Não há suporte para gravar na unidade %approot%. Se você estiver gravando na VM do Azure, deverá fazê-lo em um recurso temporário LocalStorage (ou outra opção, como armazenamento de Blob, Arquivos do Azure, etc.). Portanto, a quantidade de espaço livre na pasta %approot% não é significativa. Se você não tiver certeza se seu aplicativo está gravando na unidade %approot%, você sempre pode deixar seu serviço ser executado por alguns dias e, em seguida, comparar os tamanhos "antes" e "depois". 

O Azure não escreve nada na unidade %approot%. Depois que o VHD (disco rígido virtual) é criado a partir do seu .cspkg e montado na VM do Azure, a única coisa que pode gravar nessa unidade é seu aplicativo. 

As configurações do diário não são configuráveis, portanto, você não pode desativá-lo.

Você pode habilitar a extensão Antimalware usando o script PowerShell na Tarefa de Inicialização. Para implementá-lo, siga as etapas nestes artigos:

• Criar uma tarefa de inicialização do PowerShell
• Set-AzureServiceAntimalwareExtension

Para obter mais informações sobre cenários de implantação de antimalware e como habilitá-lo no portal, consulte Cenários de implantação de antimalware.

Você pode habilitar o SNI nos Serviços de Nuvem usando um dos seguintes métodos:

Método 1: Usar o PowerShell

A associação SNI pode ser configurada usando o seguinte cmdlet do PowerShell New-WebBinding em uma tarefa de inicialização para uma instância de função do Serviço de Nuvem:

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

Conforme descrito aqui, o $sslFlags pode ser um dos seguintes valores:

Método 2: Usar código

A ligação SNI também pode ser configurada via código na inicialização da função, conforme descrito nesta postagem do 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 qualquer uma das abordagens anteriores, os respetivos certificados (*.pfx) para os nomes de host específicos devem ser instalados primeiro nas instâncias de função usando uma tarefa de inicialização ou via código para que a vinculação SNI seja efetiva.

O Serviço de Nuvem é um recurso Clássico. Apenas recursos criados através de etiquetas de suporte do Azure Resource Manager. Não é possível aplicar tags a recursos clássicos, como o Serviço de Nuvem.

Estamos trabalhando para trazer esse recurso para o portal do Azure. Enquanto isso, você pode usar os seguintes comandos do PowerShell para obter a versão do SDK:

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

Um serviço de nuvem já implantado é cobrado pela computação e armazenamento que usa. Portanto, mesmo que você desligue a VM do Azure, ainda será cobrado pelo armazenamento.

Eis o que pode fazer para reduzir a sua faturação sem perder o endereço IP do seu serviço:

1. Reserve o endereço IP antes de excluir as implantações. O Azure cobra apenas por este endereço IP. Para obter mais informações sobre a cobrança de endereços IP, consulte Preços de endereços IP.
2. Exclua as implantações. Não exclua o xxx.cloudapp.net, para que você possa usá-lo para o futuro.
3. Se pretender reimplementar o Serviço de Nuvem utilizando o mesmo IP de reserva que reservou na sua subscrição, consulte Endereços IP reservados para Serviços de Nuvem e Máquinas Virtuais.