Configuration and management issues for Azure Cloud Services (classic): Frequently asked questions (FAQs)

We recommend that customers install the full certificate chain (leaf cert, intermediate certs, and root cert) instead of just the leaf certificate. When you install just the leaf certificate, you rely on Windows to build the certificate chain by walking the Certificate Trust List (CTL). If intermittent network or Domain Name System (DNS) issues occur in Azure or Windows Update when Windows is trying to validate the certificate, the certificate may be considered invalid. When you install the full certificate chain, this problem can be avoided. The blog at How to install a chained SSL certificate shows how to do install the full certificate chain.

These certificates are automatically created whenever an extension is added to the Cloud Service. Most commonly, this extension is the WAD extension or the RDP extension, but it could be others, such as the Antimalware or Log Collector extension. These certificates are only used for encrypting and decrypting the private configuration for the extension. The expiration date is never checked, so it doesn’t matter if the certificate is expired. 

You can ignore these certificates. If you want to clean up the certificates, you can try deleting them all. Azure throws an error if you try to delete a certificate that is in use.

See the following guidance document:

Obtaining a certificate for use with Microsoft Azure Web Sites (WAWS)

The CSR is just a text file. It doesn't have to be created from the machine intended to use the certificate. Although this document is written for an App Service, the CSR creation is generic and applies also for Cloud Services.

You can use following PowerShell commands to renew your Management Certificates:

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

The Get-AzurePublishSettingsFile creates a new management certificate in Subscription > Management Certificates in the Azure portal. The name of the new certificate looks like "YourSubscriptionNam]-[CurrentDate]-credentials".

You can automate this task by using a startup script (batch/cmd/PowerShell) and register that startup script in the service definition file. Add both the startup script and certificate(.p7b file) in the project folder of the same directory of the startup script.

This certificate is used to encrypt machine keys on Azure Web Roles. To learn more, check out this advisory.

For more information, see the following articles:

• How to configure and run startup tasks for a Cloud Service
• Common Cloud Service startup tasks

Ability to generate a new certificate for Remote Desktop Protocol (RDP) is coming soon. Alternatively, you can run this 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

Ability to choose blob or local for your csdef and cscfg upload location is coming soon. Using New-AzureDeployment, you can set each location value.

Ability to monitor metrics at the instance level. More monitoring capabilities are available in How to Monitor Cloud Services.

You exhausted the local storage quota for writing to the log directory. To correct this issue, you can do one of three things:

• Enable diagnostics for IIS and have the diagnostics periodically moved to blob storage.
• Manually remove log files from the logging directory.
• Increase quota limit for local resources.

For more information, see the following documents:

• Store and view diagnostic data in Azure Storage
• IIS Logs stop writing in Cloud Service

You can enable Microsoft Azure Diagnostics (WAD) logging through following options:

1. Enable from Visual Studio
2. Enable through .NET code
3. Enable through PowerShell

In order to get the current WAD settings of your Cloud Service, you can use Get-AzureServiceDiagnosticsExtensions PowerShell cmd or you can view it through portal from “Cloud Services --> Extensions” blade.

You can specify the timeout in your service definition (csdef) file like this:

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

See New: Configurable Idle Timeout for Azure Load Balancer for more information.

To set up a static IP address, you need to create a reserved IP. This reserved IP can be associated to a new Cloud Service or to an existing deployment. See the following documents for details:

• How to create a reserved IP address
• Reserve the IP address of an existing Cloud Service
• Associate a reserved IP to a new Cloud Service
• Associate a reserved IP to a running deployment
• Associate a reserved IP to a Cloud Service by using a service configuration file

Azure has IPS/IDS in datacenter physical servers to defend against threats. In addition, customers can deploy non-Microsoft security solutions, such as web application firewalls, network firewalls, antimalware, intrusion detection, prevention systems (IDS/IPS), and more. For more information, see Protect your data and assets and comply with global security standards.

Microsoft continuously monitors servers, networks, and applications to detect threats. Azure's multipronged threat-management approach uses intrusion detection, distributed denial-of-service (DDoS) attack prevention, penetration testing, behavioral analytics, anomaly detection, and machine learning to constantly strengthen its defense and reduce risks. Microsoft Antimalware for Azure protects Azure Cloud Services and virtual machines. You can deploy non-Microsoft security solutions in addition, such as web application fire walls, network firewalls, antimalware, intrusion detection and prevention systems (IDS/IPS), and more.

Windows 10 and Windows Server 2016 come with support for HTTP/2 on both client and server side. If your client (browser) is connecting to the IIS server over Transport Layer Security (TLS) that negotiates HTTP/2 via TLS extensions, then you don't need to make any change on the server-side. You don't need to make changes because the h2-14 header specifying use of HTTP/2 is sent by default over TLS. If on the other hand your client is sending an Upgrade header to upgrade to HTTP/2, then you need to make the following change on the server side to ensure that the Upgrade works and you end up with an HTTP/2 connection.

1. Run regedit.exe.
2. Browse to registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
3. Create a new DWORD value named DuoEnabled.
4. Set its value to 1.
5. Restart your server.
6. Go under Bindings on your Default Web Site and create a new TLS binding with the self-signed certificate you created.

For more information, see:

• HTTP/2 on IIS
• Video: HTTP/2 in Windows 10: Browser, Apps, and Web Server

These steps could be automated via a startup task, so that whenever a new PaaS instance gets created, it can make the previous changes in the system registry. For more information, see How to configure and run startup tasks for a Cloud Service.

When you finish, you can verify whether the HTTP/2 is enabled or not by using one of the following methods:

• Enable Protocol version in IIS logs and look into the IIS logs. It shows HTTP/2 in the logs.
• Enable F12 Developer Tool in Internet Explorer or Microsoft Edge and switch to the Network tab. Here, you can verify the protocol.

For more information, see HTTP/2 on IIS.

Cloud Services doesn't support the Azure role-based access control model, as it's not an Azure Resource Manager based service.

See Understand the different roles in Azure.

Microsoft follows a strict process that doesn't allow internal engineers to remote desktop into your Cloud Service without written permission (email or other written communication) from the owner or their designee.

This error may occur if you use the RDP file from a machine that is joined to Microsoft Entra ID. To resolve this issue, follow these steps:

1. Right-click the RDP file you downloaded and then select Edit.
2. Add "\" as prefix before the username. For example, use .\username instead of username.

Your Azure Subscription has a limit on the number of cores you can use. Scaling doesn't work if you used all the cores available. For example, if you have a limit of 100 cores, this means you could have 100 A1 sized virtual machine instances for your Cloud Service, or 50 A2 sized virtual machine instances.

Autoscale based on Memory metrics for a Cloud Services isn't currently supported.

To work around this problem, you can use Application Insights. Auto-Scale supports Application Insights as a Metrics Source and can scale the role instance count based on guest metric like "Memory." You have to configure Application Insights in your Cloud Service project package file (*.cspkg) and enable Azure Diagnostics extension on the service to implement this feat.

For more information on how to utilize a custom metric via Application Insights to configure Auto-Scale on Cloud Services, see Get started with auto scale by custom metric in Azure

For more information on how to integrate Azure Diagnostics with Application Insights for Cloud Services, see Send Cloud Service, Virtual Machine, or Service Fabric diagnostic data to Application Insights

For more information about to enable Application Insights for Cloud Services, see Application Insights for Azure Cloud Services

For more information about how to enable Azure Diagnostics Logging for Cloud Services, see Set up diagnostics for Azure Cloud Services and virtual machines

To prevent clients from sniffing the MIME types, add a setting in your web.config file.

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

You can also add this as a setting in IIS. Use the following command with the common startup tasks article.

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

Use the IIS startup script from the common startup tasks article.

See Service-specific limits.

This behavior is expected, and it shouldn't cause any issue to your application. Journaling is turned on for the %approot% drive in Azure PaaS VMs, which essentially consumes double the amount of space that files normally take up. However, there are several things to be aware of that turn this event into a nonissue.

The %approot% drive size is calculated as <size of .cspkg + max journal size + a margin of free space>, or 1.5 GB, whichever is larger. The size of your VM has no bearing on this calculation. (The VM size only affects the size of the temporary C: drive.) 

It's unsupported to write to the %approot% drive. If you're writing to the Azure VM, you must do so in a temporary LocalStorage resource (or other option, such as Blob storage, Azure Files, etc.). So the amount of free space on the %approot% folder isn't meaningful. If you aren't sure if your application is writing to the %approot% drive, you can always let your service run for a few days and then compare the "before" and "after" sizes. 

Azure doesn't write anything to the %approot% drive. Once the virtual hard disk (VHD) is created from your .cspkg and mounted into the Azure VM, the only thing that might write to this drive is your application. 

The journal settings are nonconfigurable, so you can't turn it off.

You can enable Antimalware extension using PowerShell script in the Startup Task. To implement it, follow the steps in these articles:

• Create a PowerShell startup task
• Set-AzureServiceAntimalwareExtension

For more information about Antimalware deployment scenarios and how to enable it from the portal, see Antimalware Deployment Scenarios.

You can enable SNI in Cloud Services by using one of the following methods:

Method 1: Use PowerShell

The SNI binding can be configured using the following PowerShell cmdlet New-WebBinding in a startup task for a Cloud Service role instance:

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

As described here, the $sslFlags could be one of the following values:

Method 2: Use code

The SNI binding could also be configured via code in the role startup as described on this blog post:

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

Using any of the preceding approaches, the respective certificates (*.pfx) for the specific hostnames have to be first installed on the role instances using a startup task or via code in order for the SNI binding to be effective.

Cloud Service is a Classic resource. Only resources created through Azure Resource Manager support tags. You can't apply tags to Classic resources such as Cloud Service.

We're working on bringing this feature on the Azure portal. Meanwhile, you can use following PowerShell commands to get the SDK version:

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

An already deployed Cloud Service gets billed for the Compute and Storage it uses. So even if you shut down the Azure VM, you still get billed for the Storage.

Here's what you can do to reduce your billing without losing the IP address for your service:

1. Reserve the IP address before you delete the deployments. Azure only bills you for this IP address. For more information about IP address billing, see IP addresses pricing.
2. Delete the deployments. Don’t delete the xxx.cloudapp.net, so that you can use it for future.
3. If you want to redeploy the Cloud Service by using the same reserve IP that you reserved in your subscription, see Reserved IP addresses for Cloud Services and Virtual Machines.