There are 3 things to configure:

1. Configure Azure Websites Virtual Network . If you plan to first create Virtual Network, make sure to have a Dynamic routing gateway and to have Point to Site enabled.

2.  Configure  Internal Load Balancer in the Azure WebRole. (Review the section Internal Load Balancing (ILB) in the referenced article). The changes are to Azure Web Role cscfg and csdef files.

3. Configure the Web Role to connect to Virtual Network  

4. Get the IP address of the Internal Load Balancer (ILB) using Powershell: Get-AzureDeployment -ServiceName websitetowebroleilbvnet2 | Get-AzureInternalLoadBalancer

5. The final config(cscfg) file for the Web Role will look like:

 <VirtualNetworkSite name="VNET NAME" />

    <AddressAssignments>

      <InstanceAddress roleName="WebRole1">

        <Subnets>

          <Subnet name="Subnet-1"/>

        </Subnets>

      </InstanceAddress>

    </AddressAssignments>   

    <LoadBalancers>

      <LoadBalancer name="FaridaLB">

        <FrontendIPConfiguration type="private" subnet="Subnet-1" />

      </LoadBalancer>

    </LoadBalancers>

   </NetworkConfiguration>

6. In the WebRole definition file, reference the load balancer

CSDEF:

<Endpoints>

      <InputEndpoint name="Endpoint1" protocol="http" port="80" loadBalancer="FaridaLB" />

    </Endpoints>

Resolution:
1.Close the Azure Powershell window
2.Delete the XML files in %appdata%\Windows Azure Powershell.
3.Open Azure Powershell and run Add-AzureAccount.

I recently saw an issue when trying to do remote debugging, we got the following error: "There was a failure to launch the remote debugger"

Steps Taken:
1.We setup another machine in Azure and installed Visual Studio. We were able to successfully attach the debugger to Azure Cloud Service process and do remote debugging.
This step proves whether it is a client side issue or a problem with the way you have configured remote debugger in your Azure role.

2. The above step proved that the problem was either with the client machine or the firewall.
--The debugger uses ports 30400-30424 and 31400-31424
--The incoming request comes on a different port than the outgoing request.Some firewalls will not allow new incoming request on a different port.

Remote Debugging feature was released in Azure SDK 2.2. 

The following articles describe how the remote debugging works and how to configure it. 

https://msdn.microsoft.com/library/azure/ff683670.aspx

https://www.codeproject.com/Articles/723677/Remote-debugging-Windows-Azure-Cloud-Services-from

https://blogs.msdn.com/b/cie/archive/2014/01/24/windows-azure-remote-debugging.aspx

For this sample, we will use REST API to increase the number of cores for the deployment.

All REST API calls are asynchronous. This means that as soon as the initial call is accepted by the server, the server returns 202.

If you want to know the status of executing that request, then you have to make get-operationstatus call with the operation ID of the previous call.

The correct process to increase the number of cores using REST API would be:

1.Make a POST call to change deployment configuration to increase the number of cores:
The Change Deployment Configuration is documented at https://msdn.microsoft.com/en-us/library/ee460809.aspx
Example: https://management.core.windows.net/<subscription-id>/services/hostedservices/<cloudservice-name>/deploymentslots/<deployment-slot>/

2. The above call will return 202 if the request is accepted. It will also return an  operation ID in the header: x-ms-request-id: 92fc04ca3f8e91538560ae8e964ec0

3. Using the operation ID returned from the above POST call, you make a GET operationstatus call. This call will let you know the result of execution of ‘change the deployment configuration’. Did the operation succeeded or failed?
The get-operationstatus call is documented at: https://msdn.microsoft.com/en-us/library/azure/ee460783.aspx
Example: https://management.core.windows.net/<subscription-id>/operations/<request-id>

This blog mainly talks about the Traffic Manager's Round Robin Policy

In my day to day job I have seen the following question come up:
Traffic manager does not seem to distribute traffic as per the policy. How can we validate this?

The following article explains how traffic manager distributes the traffic:
https://msdn.microsoft.com/en-us/library/azure/dn339010.aspx

There is one more important factor to consider:
Each client machine uses a DNS server. The clients DNS server caches the endpoint entries for the timeframe specified in Traffic Managers TTL(default value is 300sec). Hence all the machines that use the same DNS server will go to the same endpoint for the 300sec(TTL timeframe).

Example:
I have defined Round Robin load balancing and have TTL as 300sec for traffic manager. I have 2 cloud services in my traffic manager.
When I tested from 10 different client machines that use the same DNS server, all the 10 client machines went to the same endpoint for 300sec(DNS TTL) and it appeared that traffic manager was not distributing the traffic.

To check if traffic manager is distributing the traffic as per the policy I used the following site: https://cloudmonitor.ca.com/en/ping.php

This site uses machines at different locations in the world and hence different DNS. I saw that resulting IP ping was almost 50% for each IP.
(We can ignore the  packet lost Result because the cloud services will not respond to Pings.)

Thanks to Kevin for explaining this concept and sharing the method to validate the traffic manager load distribution.

The REST API calls are well documented for Azure.
https://msdn.microsoft.com/en-us/library/azure/ee460799.aspx

However, at times when you try to make the REST calls, you get 400 Bad request error message.

To make sure that you are using the right URL, headers and body for the REST call, you can try the following:
1. You can enable debugging for powershell using the following command:
PS C:\> $DebugPreference="Continue"
Azure Powershell uses REST calls.

2. After this run the powershell cmdlet equivalent to the REST API call. Example, I wanted to set the Azure deployment status, I ran the following command:
set-azuredeployment -Status

3. When this cmdlet executed, it showed me the exact REST URL, headers and body that was needed to do the function using REST APIs.
I can use any http tool or code to create HTTP request and make the REST API call. The following is a good blog if you wish to write your own code
https://blogs.msdn.com/b/mcsuksoldev/archive/2013/08/08/azure-calling-the-azure-management-rest-api.aspx

PowerShell cmdlet and output:
PS C:\> $DebugPreference="Continue"
PS C:\> set-azuredeployment -Status

cmdlet Set-AzureDeployment at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
ServiceName: test
Slot: production
NewStatus: running
DEBUG: 9:35:58 AM - SetAzureDeploymentCommand begin processing with ParameterSet 'Status'.
DEBUG: ============================ HTTP REQUEST ============================

HTTP Method:POST

Absolute Uri:
https://management.core.windows.net/0f736ead-5ffa-4cf8-927d-47e7a8f0b/services/hostedservices/test/deploymentslots/Production/?comp=status

Headers:
x-ms-version                  : 2014-04-01
User-Agent                    :
Microsoft.WindowsAzure.Management.Compute.ComputeManagementClient/0.9.0.0,WindowsAzurePowershell/v0.8.0
client-tracking-id            : 1

Body:
<UpdateDeploymentStatus xmlns="https://schemas.microsoft.com/windowsazure">
  <Status>Running</Status>
</UpdateDeploymentStatus>

ISSUE:
When trying to browse to a website hosted in Azure Web Role, I was getting “HTTP Error 404 – File or Directory not found”.
This error could be caused due to many different reasons. I have shown the troubleshooting for one reason.

TROBLESHOOTING STEPS:
1. Remote into the Azure Web Role.
2. Go to IIS Manager. (You can get to IIS Manager by typing inetmgr)
3. Go to your site. Click Content View at the bottom.
 

4. Right click the default.aspx and click browse. See if the webpage comes up. This is to see if IIS is able to load a simple webpage or not.
5. If the above does not work, then put a simple test.html file in the same location as default.aspx and browse to test.html file and see if it works. In Azure Web roles, the contents are generally located at E:\Siteroot\0 (0Role instance ID)
6. In my case, the default.aspx and test.html did not display and I continued to get the 404 error.
7. Rename the Global.asax file to Global.asax.txt and the web.config file to web.config.txt. Check if you can browse to the page after renaming these files.
8. In my case, I was able to browse to the page after renaming the above 2 files. It means, that there was some code in either global.asax or web.config that was preventing execution of my test.html page.
9. I reviewed the code. In global.asax there was a redirect to https://mysite.com . However, there was no SSL certificate or endpoint that was configured.
10. To make sure that we could browse to the https site, we created and installed a self-generated SSL certificate using the steps in this article. (See the steps under the section ‘IIS Manager’).
11. After installing the self-signed certificate, we were able to browse to the site using SSL. Renamed the global.asax and web.config to its original names. I could still access my test.html page.
12. The web role was redeployed by adding the SSL certificate and updating the web roles configuration and definition files (csdef and cscfg). You can configure SSL for Azure Web Roles by using the steps in this article. 

This was a very simple error. However, for complicated errors, the following log files can be helpful:
1. IIS Logs
2. Failed Request Tracing (FREB logs)
3. Fiddler/Netmon traces
4. Stack traces from the code
5. Debugging the code using a debugger

CAUSE OF THE PROBLEM:
The global.asax had redirection code and it was redirecting me to https endpoint. However the https endpoint was not configured and SSL certificate was not defined in the role config and role definition files.

RESOLUTION:
Install a self-signed certificate and tested the site. Redeployed the role after configuring SSL for the site.

Remote Desktop used to work for the Windows Azure Web Role instance. One day when trying to do remote desktop to Windows Azure Web Role(after entering username and password) I see the following error:
An authentication error has occurred.
The Local Security Authority cannot be contacted
Remote computer: computername.cloudapp.net

CAUSE: Remote desktop certificate had expired.

RESOLUTION: Updated my RDP certificate expiration date. This can be done from the Azure portal. 

• From the portal, select your web role.
• Click the configure tab.
•  At the bottom, click download. This will open the 'Configure Remote Desktop' screen.
• Make sure that the 'Expires On' date is some date in future. If not, update the date to a future date.
• You will have to enter the Password. This can be the same as the old password you used before for remote desktop.
• After the changes are saved to Azure, try to RDP into the instance and make sure it works.