Users can setup 'Integrate Source Control' for an Azure Web Site from a variety of sources like Visual Studio Online, Local Git Repository, GitHib, BitBucket etc. The complete list can be checked by looking into the options under 'Set up deployment from source control' option.

One of the user was trying to setup the deployment with BitBucket and it failed with error "Failed to set up continuous deployment for website xxxx, using Bitbucket. Repository 'UpdateSiteSourceControl' operation failed with Microsoft.Web.Hosting.SourceControls.OAuthException: Bitbucket GetWebHookInfo: (403) Forbidden."

The complete stack trace may look something like below:

Failed to link source control 'Bitbucket' with site xxxx. Microsoft.Web.Hosting.SourceControls.OAuthException: Bitbucket GetWebHookInfo: (403) Forbidden.

at Microsoft.Web.Hosting.SourceControls.OAuthV1Provider.<ProcessResponse>d__7c`1.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

at Microsoft.Web.Hosting.SourceControls.OAuthV1Provider.<GetAsync>d__58`1.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Microsoft.Web.Hosting.SourceControls.BitbucketProxy.<GetWebHookInfo>d__40.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

at Microsoft.Web.Hosting.SourceControls.BitbucketProxy.<AddWebHook>d__1b.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Microsoft.Web.Hosting.Administration.BitbucketSiteRepositoryProvider.<UpdateSiteSourceControl>d__6.MoveNext()

In general, 403 – Forbidden errors refers to permissions issue.

In this case, the user's BitBucket ID was not having admin access to the account. Hence the setup was failing unable to authorize the user to setup the hook in BitBucket.

The issue was fixed by providing admin access to the ID of the user.

LogFiles folder for Azure Web Sites contains details of almost and everything of all the related logs from IIS logs, Detailed Error Logs, FREB logs, Event Logs, Application Logs, KUDS Logs (deployment and traces) and more.

This would be the first place to look at when your application running on Azure Web Sites has any issues. Below are few ways to download the LogFiles to your local machine for easy access.

Download using KUDU console:

• Browse to the KUDU console at https://<sitename>.scm.azurewebsites.net/DebugConsole where <sitename> should be replaced by your Azure Web Site name

   

• Go to "LogFiles" folder and this would contain all related logs for your site, if they are enabled. The "LogFIles" folder can also be downloaded by clicking on the down arrow image.

   

  

   

Download using FTP:

• FTP to your website using FTP clients like FileZilla or other tools

   

• FTP credentials for your website can be found in the Dashboard of your Azure Web Site. The user name is the "FTP USER" highlighted below and the format is usually like websitename\LiveID

   

  

   

   

   

IIS loads all its configuration for websites, application pools, etc from the ApplicationHost.config file. This file has been integral part since IIS 7.0. Also, in the PaaS offering of Azure (Azure Web Sites), IIS is the primary web server on which all the sites are hosted and hence the file is important in Azure Web Sites. More details on ApplicationHost.config file can be found at https://www.iis.net/learn/get-started/planning-your-iis-architecture/introduction-to-applicationhostconfig.

The ApplicationHost.config file for your Azure Web Site can be accessed/downloaded following the below steps:

• Login to the KUDU console for your Azure Web Site at https://<sitename>.scm.azurewebsites.net/DebugConsole where <sitename> should be replaced by your Azure Web Site name

   

• Click on "Site Root" image highlighted in the below screen shot and go to "Config" folder

   

  

   

• The ApplicationHost.config file will be listed which can be accessed/downloaded by clicking on the "Down Arror" mark highlighted below. The file can be edited/deleted using the other options.

   

  

Most of you would be aware of the Deployment Slots in Azure Web Sites. For those who are not familiar, Deployment Slots provide an option to deploy your changes to staging environment instead of directly moving the changes to the production environment. This helps you to validate your changes in the Azure Web Sites environment before you can swap the changes with the production environment. For details about the deployment slots, check https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/.

The swapping can be achieved easily using the Azure Management Portal using the 'SWAP' option under 'DASHBOARD' of the website/slots. It is also discussed in https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/#Swap.

But there are many instances where people want to make use of the powerful Azure PowerShell cmdlets to swap the slots.

Switch-AzureWebsiteSlot is the cmdlet to swap between the slots and the actual production environment. Below are some examples.

When there is only one slot and you want to swap the slot with the production environment, the example can be as simple as:

Switch-AzureWebsiteSlot –Name <AzureWebsiteName>

When there are two or more slots and you want to swap between the slots, the example can be as simple as:

Switch-AzureWebsiteSlot –Name <AzureWebsiteName> -Slot1 <slotName> -Slot2 <slotName>

But when there are two or more slots and you want to swap between one of the slot and the production environment, and you provided only one slot name in the syntax as below:

Switch-AzureWebsiteSlot –Name <AzureWebsiteName> -Slot1 <slotName>

It will then throw error like "The website has more than 2 slots you must specify which ones to swap" as shown below

In this case, it is necessary to provide the slot name for the actual/production environment which is 'Production'. The syntax would be something like below:

Switch-AzureWebsiteSlot –Name <AzureWebsiteName> -Slot1 'Production' -Slot2 <slotName>

This will swap the corresponding slot content with the production slot of the Azure Web Site.

So far, there was a limitation on the Web Deploy feature where the proxy was not supported.

If you try to publish using Web Deploy to Azure Web Sites over Proxy, then you would run into error something like:

"Could not connect to the remote computer ("****.scm.azurewebsites.net"). On the remote computer, make sure that Web Deploy is installed and that the required process ("Web Management Service") is started. Learn more at: https://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE"

You might get the above error for many reasons while deploying to Azure Web Sites and one of the reasons is if you are trying to use proxy.

With the latest version of the Web Deploy 3.6 (BETA), the proxy support has been newly featured which helps you to address the above error.

Download Link:        https://www.microsoft.com/en-us/download/details.aspx?id=43717

Add the below code snippet to the msdeploy.exe.config file after the installation of the latest Web Deploy 3.6

<system.net>

<defaultProxy useDefaultCredentials="true" />

</system.net>

Microsoft Azure Web Sites (https://azure.microsoft.com/en-us/services/websites/) provides you with wonderful and easier means to host your content online across many platforms. The ease of scaling up the website based on the traffic/load, the various deployment options of the source code and piece of mind to not worry about the frequent updates to the different platforms/security patches are some of the highlights.

You can get started with a free trial for a month by signing using live account at https://azure.microsoft.com/en-us/pricing/free-trial/.

Once the new account is setup, you can access the portal at https://manage.windowsazure.com. There is also a new portal under construction which provides a different look at https://portal.azure.com.

Create your simple website easily by following the article https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-deploy/. By default, the domain of the users looks like *.azurewebsites.net. The users can change to custom domain as discussed in the article  https://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/. Once the custom domain is setup correctly, you can also verify the DNS lookup using https://www.digwebinterface.com/.

Based on the storage and compute need, there are various website pricing offers (https://azure.microsoft.com/en-us/pricing/details/websites/) for you to scale the sites and there is also auto-scaling option if needed. 

The status of the azure websites and for updates on any issues can be checked at https://azure.microsoft.com/en-us/status/.

All the features of the Azure Website has been discussed in various articles in the Azure blog site https://azure.microsoft.com/blog/.

For any issues\clarifications with the websites, you can contact Azure Websites forum https://social.msdn.microsoft.com/forums/azure/en-US/home?forum=windowsazurewebsitespreview for inputs. Also, for any feedback on the features, you can write at https://feedback.azure.com/forums/169385-web-sites.