Configuración y problemas de administración de Azure Cloud Services (clásico): Preguntas más frecuentes (P+F)

Se recomienda que los clientes instalen la cadena de certificados completa (certificado de hoja, certificados intermedios y certificado raíz) en lugar de simplemente el certificado de hoja. Cuando se instala sólo el certificado hoja, se confía en que Windows construya la cadena de certificados recorriendo la Lista de Certificados de Confianza (CTL). Si se producen problemas intermitentes de red o del Sistema de Nombres de Dominio (DNS) en Azure o Windows Update cuando Windows está intentando validar el certificado, éste puede considerarse no válido. Cuando se instala la cadena de certificados completa, se puede evitar este problema. El blog de Cómo instalar un certificado SSL encadenado muestra cómo instalar la cadena de certificados completa.

Estos certificados se crean automáticamente cada vez que se agrega una extensión al servicio en la nube. Lo más común es que esta extensión sea la extensión WAD o la extensión RDP, pero podrían ser otras, como la extensión Antimalware o Log Collector. Estos certificados solo se utilizan para cifrar y descifrar la configuración privada de la extensión. Nunca se comprueba la fecha de expiración, por lo que no importa si el certificado ha caducado. 

Puede omitir estos certificados. Si desea borrar los certificados, puede intentar eliminarlos todos. Azure genera un error si se intenta eliminar un certificado que está en uso.

Consulte la siguiente documentación de guía:

Obtener un certificado para su uso con sitios web de Microsoft Azure (WAWS)

El CSR no es más que un archivo de texto. No tiene que crearse a partir de la máquina diseñada para usar el certificado. Aunque este documento está escrito para una instancia de App Service, la creación de CSR es genérica y se aplica también a Cloud Services.

Puede usar los siguientes comandos de PowerShell para renovar sus certificados de administración:

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

Get-AzurePublishSettingsFile crea un certificado de administración en Suscripción>Certificados de administración en Azure Portal. El nombre del nuevo certificado es algo así como "YourSubscriptionNam]-[CurrentDate]-credentials".

Puede automatizar esta tarea mediante un script de inicio (batch/cmd/PowerShell) y registrar dicho script en el archivo de definición de servicio. Agregue el script de inicio y el certificado (archivo. p7b) a la carpeta del proyecto del mismo directorio que el script de inicio.

Este certificado se usa para cifrar las claves de la máquina en los roles de web de Azure. Para más información, consulte este aviso.

Para más información, consulte los siguientes artículos.

• Configuración y ejecución de tareas de inicio en un servicio en la nube
• Tareas de inicio comunes de un servicio en la nube

Capacidad de generar un certificado nuevo para el Protocolo de escritorio remoto (RDP) disponible próximamente. Como alternativa, puede ejecutar el script siguiente:

$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

Posibilidad de elegir blob o local para la ubicación de carga de csdef y cscfg, disponible próximamente. Si usa New-AzureDeployment, puede establecer el valor de cada ubicación.

Capacidad para supervisar las métricas en el nivel de instancia. Hay más funcionalidades de supervisión disponibles en Supervisión de Cloud Services.

Se ha agotado la cuota de almacenamiento local para escribir en el directorio de registro. Para corregir este problema, puede elegir entre tres cosas:

• Habilitar los diagnósticos para IIS y periódicamente mover los diagnósticos al almacenamiento de blobs.
• Quitar manualmente los archivos de registro del directorio de registro.
• Aumentar el límite de cuota para los recursos locales.

Para obtener más información, vea los documentos siguientes:

• Almacenamiento y visualización de los datos de diagnóstico en Azure Storage
• IIS Logs stops writing in cloud service (Los registros de IIS dejan de escribir en el servicio en la nube)

Puede habilitar el registro de Microsoft Azure Diagnostics (WAD) a través de las opciones siguientes:

1. Habilitar desde Visual Studio
2. Habilitación mediante código de .NET
3. Habilitación mediante Powershell

Para obtener la configuración actual de WAD en Cloud Services, puede usar el cmd Get-AzureServiceDiagnosticsExtensions de PowerShell o verla en el portal en la hoja "Cloud Services --> Extensiones".

Puede especificar el tiempo de espera en el archivo de definición se servicio (csdef) de la forma siguiente:

<?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 Nuevo: Tiempo de espera de inactividad configurable para Azure Load Balancer para más información.

Para configurar una dirección IP estática, tiene que crear una dirección IP reservada. Esta dirección IP reservada se puede asociar a un nuevo servicio en la nube o a una implementación existente. Consulte los siguientes documentos para más información:

• Cómo crear una dirección IP reservada
• Reserva de la dirección IP de un servicio en la nube existente
• Asociación de una dirección IP reservada a un nuevo servicio en la nube
• Asociación de una dirección IP reservada a una implementación en ejecución
• Asociación de una dirección IP reservada a un servicio en la nube mediante un archivo de configuración de servicio

Azure tiene IPS/IDS básicos en los servidores físicos de los centros de datos para la defensa contra amenazas. Además, los clientes pueden implementar soluciones de seguridad que no son de Microsoft, como firewalls de aplicación web, firewalls de red, antimalware, detección de intrusiones, sistemas de prevención (IDS/IPS) y mucho más. Para más información, consulte ///Protect your data and assets and comply with global security standards (Protección de datos y recursos y cumplimiento de los estándares de seguridad global).

Microsoft supervisa continuamente servidores, redes y aplicaciones para detectar amenazas. La administración de amenazas de Azure se realiza en varios frentes utilizando detección de intrusiones, prevención de ataques con denegación de servicio distribuido (DDoS), pruebas de penetración, análisis de comportamiento, detección de anomalías y aprendizaje automático para reforzar su defensa constantemente y reducir los riesgos. Microsoft Antimalware para Azure protege Azure Cloud Services y las máquinas virtuales. Además, puede implantar soluciones de seguridad ajenas a Microsoft, como cortafuegos de aplicaciones web, cortafuegos de red, antimalware, sistemas de detección y prevención de intrusiones (IDS/IPS), y mucho más.

Windows 10 y Windows Server 2016 incluyen compatibilidad con HTTP/2 en el lado servidor y cliente. Si su cliente (navegador) se está conectando al servidor IIS a través de Seguridad de Capa de Transporte (TLS) que negocia HTTP/2 a través de extensiones TLS, entonces usted no necesita hacer ningún cambio en el lado del servidor. No necesita realizar cambios porque el encabezado h2-14 que especifica el uso de HTTP/2 se envía por defecto a través de TLS. Si, por otro lado, el cliente envía un encabezado Upgrade para actualizar a HTTP/2, necesita realizar el cambio siguiente en el lado servidor para garantizar que Upgrade funciona y que acabará con una conexión HTTP/2.

1. Ejecute regedit.exe.
2. Examine la clave del Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
3. Cree un nuevo valor DWORD denominado DuoEnabled.
4. Establezca su valor en 1.
5. Reinicie el servidor.
6. Vaya a Enlaces en el Sitio web predeterminado y cree un nuevo enlace TLS con el certificado auto firmado que creó.

Para más información, vea:

• HTTP/2 on IIS (HTTP/2 en IIS)
• Vídeo: HTTP/2 in Windows 10: Browser, Apps, and Web Server

Estos pasos se pueden automatizar mediante una tarea de inicio para que, cada vez que se cree una instancia de PaaS, puede realizar los cambios anteriores en el registro del sistema. Para más información, consulte Configuración y ejecución de tareas de inicio para un servicio en la nube.

Cuando termine, puede comprobar si HTTP/2 está habilitado o no mediante uno de los métodos siguientes:

• Habilite la versión del protocolo en los registros de IIS y busque en dichos registros. Muestra HTTP/2 en los registros.
• Habilite la herramienta de desarrollo F12 en Internet Explorer o Microsoft Edge y cambie a la pestaña Red. Aquí puede comprobar el protocolo.

Para más información, vea HTTP/2 on IIS (HTTP/2 en IIS).

Cloud Services no es compatible con el modelo de control de acceso de Azure basado en rol, ya que no es un servicio basado en Azure Resource Manager.

Consulte Descripción de los distintos roles en Azure.

Microsoft sigue un proceso estricto que no permite a los ingenieros internos ejecutar instancias de escritorio remoto en su servicio en la nube sin autorización por escrito (correo electrónico u otra comunicación escrita) del propietario o la persona designada a tal fin.

Este error puede producirse si usa el archivo RDP desde un equipo replicado en Microsoft Entra ID. Para resolver el problema, siga estos pasos:

1. Haga clic en el archivo RDP que ha descargado y seleccione Editar.
2. Agregue "\" delante del nombre de usuario. Por ejemplo, use .\username en lugar de username.

La suscripción de Azure tiene un límite en el número de núcleos que se pueden usar. El escalado no funciona si ha usado todos los núcleos disponibles. Por ejemplo, si tiene un límite de 100 núcleos, significa que puede tener 100 instancias de máquina virtual de tamaño A1 para su servicio en la nube, o bien 50 instancias de máquina virtual de tamaño A2.

Actualmente no se admite el auto escalado basado en métricas de memoria para los Cloud Services.

Para solucionar este problema, puede usar Application Insights. El escalado automático admite Application Insights como origen de métricas y puede escalar el número de instancias de rol en función de una métrica de invitado como "Memoria." Tiene que configurar Application Insights en el archivo de paquete del proyecto del servicio en la nube (*.cspkg) y habilitar la extensión de Azure Diagnostics en el servicio para implementar esta operación.

Para más información sobre cómo usar una métrica personalizada a través de Application Insights para configurar el escalado automático en Cloud Services, consulte Introducción al escalado automático por métrica personalizada en Azure

Para más información acerca de cómo integrar Azure Diagnostics con Application Insights para Cloud Services, consulte Envío de datos de diagnóstico de Cloud Services, Virtual Machines o Service Fabric a Application Insights

Para más información acerca de cómo habilitar Application Insights para Cloud Services, consulte Application Insights para Azure Cloud Services

Para más información acerca de cómo habilitar Azure Diagnostics Logging para Cloud Services, consulte Activación de diagnósticos en los proyectos de servicios en la nube antes de implementarlos

Para evitar que los clientes curioseen en los tipos MIME, agregue un ajuste a su archivo web.config.

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

También puede agregarlo como un ajuste en IIS. Use el comando siguiente con el artículo common startup tasks (tareas comunes de inicio).

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

Use el script de inicio de IIS del artículo common startup tasks (tareas comunes de inicio).

Consulte los Límites específicos del servicio.

Este es el comportamiento esperado, y que no debería causar ningún problema para la aplicación. El registro en diario está activado para la unidad %approot% en las máquinas virtuales de Azure PaaS, que esencialmente consume el doble de espacio que suelen ocupar los archivos. Sin embargo, hay varias cosas que debe tener en cuenta que convierten este evento no sea un problema.

El tamaño de la unidad %approot% se calcula como <tamaño de .cspkg + tamaño máximo del diario + un margen de espacio disponible>, o 1,5 GB, el que sea mayor de los dos valores. El tamaño de la máquina virtual no influye en este cálculo. (El tamaño de la máquina virtual solo afecta al tamaño de la unidad C: temporal).

No se admite para escribir en la unidad % approot %. Si va a escribir en la máquina virtual de Azure, debe hacerlo en un recurso temporal de LocalStorage (u otra opción, como almacenamiento de blobs, Azure Files, etc.). Por lo tanto, la cantidad de espacio libre en la carpeta %approot% no es significativa. Si no está seguro de si la aplicación va a escribir en la unidad % approot %, siempre puede dejar que el servicio se ejecute durante unos días y, después, comparar el tamaño "anterior" y el "posterior". 

Azure no escribe nada en la unidad %approot%. Una vez que el disco duro virtual (VHD) se crea desde su .cspkg y se monta en la máquina virtual de Azure, lo único que puede escribir en esta unidad es la aplicación. 

Los ajustes del diario no son configurables, por lo que no se pueden desactivar.

Puede habilitar la extensión antimalware mediante el script de PowerShell en la tarea de inicio. Siga los pasos descritos en los siguientes artículos para implementarla:

• Creación de una tarea de inicio de PowerShell
• Set-AzureServiceAntimalwareExtension

Para obtener más información sobre los escenarios de implementación de antimalware y cómo habilitarlo desde el portal, vea Escenarios de implementación de Antimalware.

Puede habilitar SNI en Cloud Services con alguno de los siguientes métodos:

Método 1: Uso de PowerShell

El enlace de SNI puede configurarse mediante el siguiente cmdlet de PowerShell New-WebBinding en una tarea de inicio de una instancia de rol de servicio en la nube:

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

Como se describe aquí, el $sslFlags podría ser uno de los siguientes valores:

Método 2: Uso de código

El enlace de SNI también puede configurarse a través de código en el inicio del rol, tal y como se describe en esta entrada de 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>

Con cualquiera de los enfoques anteriores, los certificados correspondientes (*.pfx) para los nombres de host específicos deben instalarse primero en las instancias de rol mediante una tarea de inicio o a través de código para que el enlace de SNI sea efectivo.

El servicio en la nube es un recurso clásico. Solo los recursos creados a través de Azure Resource Manager son compatibles con las etiquetas. No puede aplicar etiquetas a los recursos clásicos, como el servicio en la nube.

Estamos trabajando en la inclusión de esta característica en Azure Portal. Entretanto, puede usar los siguientes comandos de PowerShell para ver la versión del SDK:

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

En un servicio en la nube ya implementado la facturación la dicta los servicios Compute y Storage que utilice. Por consiguiente, aunque apague la máquina virtual de Azure, se facturará el servicio Storage.

Esto es lo que puede hacer para reducir la facturación sin perder la dirección IP de su servicio:

1. Reserve la dirección IP antes de eliminar las implementaciones. Azure solo le factura esta dirección IP. Para más información acerca de la facturación de direcciones IP, consulte Precios de las direcciones IP.
2. Elimine las implementaciones. No elimine xxx.cloudapp.net, para que pueda usarlo en el futuro.
3. Si desea volver a implementar el servicio en la nube con la misma dirección IP que reservó en su suscripción, consulte Reserved IP addresses for Cloud Services & Virtual Machines (Direcciones IP reservadas para Cloud Services y Virtual Machines).