This section provides guidance on setting up the Blob Share sample for deployment to the Windows Azure Platform. This mainly entails following a similar setup process to the one used when configuring the sample to run locally, but providing appropriate settings for running the application in the cloud environment.

Altogether, deploying the sample application to Windows Azure involves the following steps:

  • Creating an AppFabric Access Control Service (ACS) namespace (see the steps in the Get Started section)
  • Creating a Windows Azure Storage account
  • Creating a SQL Azure server
  • Creating a Windows Azure hosted service to deploy the sample application
  • Editing an XML file to provide the following configuration settings:
    • SQL Azure server and database settings
    • Windows Azure Storage account name and key
    • Hosted service name
    • AppFabric Access Control Service namespace and management key
    • AppFabric Access Control Service (ACS) configuration values (namespace, which identity providers to use, etc.)
    • SMTP Server to allow the application to send invitations (refer to the steps in the Get Started section)
  • Deploying the service package to the hosted service

Although you can carry out all the steps to deploy Blob Share manually, the package includes a deployment script that takes advantage of the Windows Azure Platform PowerShell Cmdlets to fully automate the deployment of the application to Windows Azure.

You only need to specify some additional configuration settings in the Configuration.xml file and then execute a script that builds the service package, creates the hosted service and storage accounts, as well as a SQL Azure server to host the application database. However, if you prefer to execute the deployment manually, you will find instructions for doing so in the Appendix.

noteNote:

For more information about deploying applications to Windows Azure, refer to the following MSDN article: http://msdn.microsoft.com/en-us/library/gg651132.aspx#deploy

Preparing the Application for Deployment

Regardless of the deployment method, you first need to configure the application to operate in the Windows Azure environment. This section describes every setting that you need to provide in order to deploy the application.

note[1]Note:

If you ran the application in the compute emulator previously, you will have already configured certain settings, for example the SMTP server configuration, that are common to both environments. Nevertheless, the following description does not assume any previous configuration and you should be able to prepare the application for deployment by following these steps.
The only exception is the creation of the AppFabric Access Control Service namespace, which you should have already created. For instructions on how to create the namespace, see the section Creating an AppFabric Access Control Service Namespace in the Get Started section. After creating the namespace, you may return here and continue with these steps.

  1. In Visual Studio, open the Configuration.xml file located inside the root folder of this package.
  2. Near the top of the file, locate the UseLocalComputeEmulator setting and ensure that its value is set to false to indicate to the setup script that you will deploy the application to Windows Azure.
  3. Now, locate the BootstrapAdministratorSecret entry and make a note of its value. You will be prompted for the administrator secret value the first time you sign in to the application to verify your identity. You can change the default value, if you wish to do so.

    cbb645ea-0039-4929-b764-4cc71209f54a

    Figure 31 - Configuring the administrator secret value

  4. The application stores its information in a relational database. To configure the database server used by the application, locate the Database section in the configuration file and enter the settings required to access the server that will host the application’s database.

    The table below summarizes each setting in this section.

    image
    note[2]Note:

    The Quick Configuration column in this table shows the values that you need to enter when using the automated scripts to create a new SQL Azure server in the chosen location and with the specified credentials.

    621cf390-3e8d-4bee-9fe7-bdff230f93ff

    Figure 32 - Creating a new SQL Azure server in the South Central US data center with the specified credentials

  5. Authentication in the application is handled by the AppFabric Access Control Service. To configure it, find the AccessControlService section and enter the settings for the service namespace that you created previously. Additionally, you can enable one or more identity providers that the application can use by setting the value of the corresponding UseXXXProvider element to true. By default, all the available providers except Facebook are enabled.

    note[3]Note:

    Note: Although the settings are essentially unchanged from the ones used to run the application in the compute emulator, you do need to update the RelyingPartyRealm when deploying the application to Windows Azure to use the URL of the hosted service where the application will be deployed.

    The table below describes each setting in this section.
    image

    note[4]Note:

    The Quick Configuration column in this table shows the values that you need to enter when deploying the application to Windows Azure, with Windows Live ID, Yahoo!, and Google enabled as identity providers. The values for the ACS namespace and management key are your own, which you obtained previously. For the relying party realm, you need to specify the URL of the hosted service where you plan to deploy the application (e.g https://blobshare.cloudapp.net/).
    For more information on, see Creating an AppFabric Access Control Service Namespace in the Get Started section.

    note[5]Note:

    To use Facebook as an identity provider, you need to provide a Facebook application name, Id and secret. For detailed instructions on how to do this, see this article: http://msdn.microsoft.com/en-us/library/gg185919.aspx.

    b62dca58-3ed6-4d94-9dc5-5c9b70a824f7

    Figure 33 - Configuring AppFabric Access Control Service settings for your namespace

  6. The application sends invitations and can notify users whenever a resource is updated. To enable this functionality, you need to configure an SMTP server that the application can use for this purpose. To do this, locate the SMTP section in the configuration file and enter the settings for the SMTP server of your provider.

    The table below summarizes each setting in this section.

    image
    note[6]Note:

    The Quick Configuration column in this table shows the values that you need to enter when using Windows Live as your email service.
    If you choose an SMTP provider different from Windows Live, you need to update the host address and port to match the one used by your provider.

    480a3790-4925-41c1-8595-54cb4ed05e0b

    Figure 34 - Configuring the application to send invitations and notification emails

  7. The application stores uploaded content in a container in blob storage. To configure the storage account, locate the WindowsAzureStorage section in the configuration file and enter the settings for the storage account to use. Note that if the specified account does not exist, it will be created by the deployment script.

    note[7]Note:

    Storage account names are essentially DNS names and thus shared with other subscriptions in the Windows Azure environment so choose a name that is unlikely to collide with other storage account names in existence (e.g. do not use blobshare, but prefer blobshare<youruniquevalue> instead).

    The table below summarizes each setting in this section.

    image

    0436e313-8ba1-491b-a57e-58b5c9a9f3d8

    Figure 35 - Configuring the storage account settings

  8. To specify where the application is to be deployed, locate the hostedService section in the configuration file and enter the settings for the hosted service to use. Note that if the specified hosted service does not exist, it will be created by the deployment script.

    note[8]Note:

    Hosted service names are essentially DNS names and thus shared with other subscriptions in the Windows Azure environment so choose a name that is unlikely to collide with other hosted service names in existence (e.g. do not use blobshare, but prefer blobshare<youruniquevalue> instead).

  9. The table below summarizes each setting in this section.

    image

    cc2b5395-3039-4a02-afdd-5b8c7532f439

    Figure 36 - Configuring the hosted service settings

  10. The Windows Azure Platform PowerShell Cmdlets used by the automated deployment script need to access the Service Management API to execute some of the required tasks. To authenticate with the management API, they need a subscription ID and a management certificate for the account where the application is to be deployed.
  11. Locate the subscriptionId setting in the configuration file and enter the ID of your Windows Azure subscription. Next, locate the managementCertificateThumbprint setting and specify the thumbprint of the management certificate to use.

    note[9]Note:

    The management certificate must already be uploaded to your subscription and also needs to be installed in the machine where the deployment script is to be executed.
    To upload the certificate, go to the Windows Azure Management Portal, select the Hosted Services, Storage Accounts & CDN option in the navigation pane, and then the Management Certificates subarea. Select Add Certificate on the toolbar and upload the *.cer file with the public key of your management certificate.
    To install the certificate locally, double-click the *.pfx file with the private key of your management certificate and follow the wizard to install in your certificate store.

    2a197285-604c-42a6-a659-02692a5d0e59

    Figure 37 - Configuring authentication with the Service Management API

    note[10]Note:

    When using the certificate provided in the package to secure the SSL binding, be aware that it is a self-signed certificate and that it was issued for a subject named blobshare.cloudapp.net. When you visit the site, the browser will show a warning indicating that the certificate is not trusted.
    If needed, you may replace the certificate with one that is appropriate to the hosted service name that you choose. To avoid the security warning, the certificate must be issued by a trusted root authority and issued to a subject that matches the authority of your hosted service URL.
    If you replace the certificate, you must update its thumbprint in the service configuration file. To do this, expand the Roles node of the BlobShare project and double-click the BlobShare.Web role to open its properties window. Switch to the Certificates tab, select the certificate named “ssl” and replace its thumbprint with the one from your replacement certificate. You will also need to update the certificate thumbprint in the Web.config file of the BlobShare.Web project. To do this, locate the section named microsoft.identityModel/service/serviceCertificate, and update the thumbprint value in the certificateReference element. Note that this is different from the thumbprint in the trustedIssuers section.


Using the Automated Deployment Script

After you complete the previous steps and enter all the necessary information, you may now use the automated script to deploy the application to Windows Azure.

The script runs unattended to create all the resources required by the application, including the hosted service, the storage account, the SQL Azure server, and it configures the AppFabric Access Control Service by creating a relying party and its rules. By default, the script deploys the application to the staging slot of the hosted service and then performs a VIP swap to place the new deployment into production.

If you prefer to carry out these tasks manually, you will find instructions in the Appendix for doing so.

  1. To deploy the application, browse to the setup folder in this package and double-click deploy.cmd to launch the script.

    06148a5e-024c-4d0f-9088-fe0ea1740587

    Figure 38 - Deploying the Blob Share application using the automated scripts

    note[11]Note:

    There is a known issue where the script will prematurely exit before the service completely starts and goes into the Ready state. If this occurs, you may need to wait several minutes before the service becomes available and you can access it successfully.

  2. Once the deployment is complete, open a browser window and navigate to the URL of your hosted service (e.g. https://{yourhostedservice}.cloudapp.net) to verify that the sample is running successfully. You may sign in and use the application.

    6b54b658-e37e-4e10-97a2-6fe6ccf8b9d7

    Figure 39 - Blob Share sample running on the cloud

Last edited Oct 21, 2011 at 4:57 PM by wwegner, version 2

Comments

dmaxwell Jan 27, 2013 at 10:40 PM 
It is over one year later and no comments though this is a very significant sample. I am beginning to think that ACS and WIF are just not being picked up as noted by the scarcity of documentation or media for integrating with MVC applications.

I wish there were a simpler example, one that has just a simple controller adaptation and the ACS Windows Live, Google, Yahoo, and Facebook identities along with some simple roles. I see examples for ASP.NET but not ASP.NET MVC 4 on .NET 4.5 with the "Identity and Access" extension for Visual Studio 2012. It is a shame. I have spent days researching how to get the MVC controllers to work.

This example is big and I will study it further.

Thank you.
Daniel