How to use Windows Azure PowerShell
This guide describes how to use Windows PowerShell cmdlets to create, test, deploy, and manage Windows Azure Services. The scenarios covered include importing your publishing settings, creating Windows Azure services to host applications, running a service in the Windows Azure compute emulator, deploying and updating a cloud service, setting deployment options for a service, and stopping, starting, and removing a service.
Table of contents
What is Windows Azure PowerShell
Windows Azure PowerShell provides a command-line environment for developing and deploying applications for Windows Azure through a few Windows PowerShell cmdlets.
The following tasks are supported:
- Import publishing settings to enable you to deploy services in Windows Azure.
- Generate configuration files and a sample application for a cloud service. Create a Windows Azure service that contains web roles and worker roles.
- Test your service locally using the Windows Azure compute emulator.
- Deploy your service to the Windows Azure staging or production environment.
- Scale and update services in Windows Azure.
- Enable and disable remote access to service role instances.
- Start, stop, and remove services.
Get started using Windows Azure PowerShell
The recommended way to install the Windows Azure PowerShell cmdlets is via the Microsoft Web Platform Installer. After installing and launching the Web Platform Installer, select Windows Azure PowerShell and follow the prompts to install the cmdlets. The Web Platform Installer will install all dependencies for the Windows Azure PowerShell cmdlets. Note that you can also select Windows Azure SDK for Node.js - July 2012 or Windows Azure SDK for PHP - July 2012 as these SDKs will include the Windows Azure PowerShell cmdlets.
Getting started with Windows PowerShell
If you have not used Windows PowerShell before, the following resources can help you get started:
-
For basic instructions, see Using Windows PowerShell in the Windows PowerShell Getting Started Guide.
-
While you are working in Windows PowerShell, your best source of help is the Help cmdlet. The following table summarizes some common help requests. For more information, see Getting Help: Help, or, in Windows PowerShell, type: help.
| Cmdlet Format | Information Returned |
| help | Displays a help topic about using the help cmdlet |
| help azure | Lists all cmdlets in the Windows Azure PowerShell snap-in |
| help node-dev | Lists cmdlets for developing and managing Node.js applications |
| help php-dev | Lists cmdlets for developing and managing PHP applications |
| help <cmdlet> | Displays help about a Windows PowerShell cmdlet |
| help <cmdlet> -parameter * | Displays parameter definitions for a cmdlet |
| help <cmdlet> -examples | Displays example syntax lines for a cmdlet |
| help <cmdlet> -full | Displays technical requirements for a cmdlet |
Getting started with Windows Azure PowerShell
The Windows Azure PowerShell cmdlets have a few special requirements that are not common to all Windows PowerShell components:
-
To deploy your applications in Windows Azure, you must have a Windows Azure subscription. Before you can deploy applications by using a cmdlet, you must download your subscription information (by using Get-AzurePublishSettingsFile) and then import those settings (by using Import-AzurePublishSettingsFile).
-
You must run cmdlets that act on a cloud service from within the service directory.
When you create a new cloud service, a service directory is created in the current directory, and the focus of the Windows PowerShell command prompt moves to the service directory. From the service directory, you can add web roles and worker roles to the service. All other cmdlets for the service can be run from any child directory of the service directory.
-
After you create and configure a new cloud service, or after you run any cmdlet that updates the configuration of a deployed service, you must run the Publish-AzureServiceProject cmdlet to publish the updates to the cloud service deployment. For example, after you run Set-AzureServiceProjectRole with the -Instances parameter to add additional web role instances to a service configuration, run Publish-AzureServiceProject to scale out the cloud service.
If you are running the deployment locally in the Windows Azure compute emulator, you must run Start-AzureEmulator again after you update the service definition file (.csdef) or the service configuration file (.cscfg). However, the compute emulator renders updates to the server.js (for Node.js applications) and web.config files instantly.
-
Although Windows Azure PowerShell cmdlets and parameters are not case-sensitive, the following values that are entered for cmdlets are case-sensitive: service names, subscription names, storage account names, and deployment locations.
To open Windows Azure PowerShell
On the Start menu, click All Programs, click Windows Azure, and then click Windows Azure PowerShell.
Example syntax lines
In the example syntax lines in this guide, all services are created from a C:\app folder. A C:\app folder is not required; you can create your Windows Azure services from any location. Most example syntax lines use a service named MyService, and cmdlets performed on the service are entered at the following command prompt:
C:\app\MyService>
How to: Import publishing settings
To deploy your applications in Windows Azure, you must have a Windows Azure subscription. If you do not have a Windows Azure subscription, see purchase options for Windows Azure for information.
Before you can deploy applications by using a PowerShell cmdlet, you must download your subscription information (by using Get-AzurePublishSettingsFile) and then import those settings (by using Import-AzurePublishSettingsFile).
The Get-AzurePublishSettingsFile cmdlet opens a web page on the Windows Azure Management Portal from which you can download the publishing profile. You will need to login to the portal using the credentials for your Windows Azure account.
When you download the publishing profile, note the path and the name of your settings file. You must provide this information when you use Import-AzurePublishSettingsFile to import the settings. The default location and file name format is:
C:\Users\<MyAccount>\Downloads\[MySubscription-…]-downloadDate-credentials.publishsettings
The following example shows how to download publishing settings for your Windows Azure account.
Get-AzurePublishSettingsFile
In the following example, publishing settings that were downloaded to the default path on 11-11-2011 are imported. In this case, the user is a co-administrator for the Project1 subscription in addition to his own subscription.
Import-AzurePublishSettingsFile C:\Users\MyAccount\Downloads\MySubscription-Project1-11-11-2011-credentials.publishsettings
If, after you import your publish settings, you are added to other subscriptions as a co-administrator, you will need to repeat this process to download a new .publishsettings file, and then import those settings. For information about adding co-administrators to help manage services for a subscription, see How to Add and Remove Co-Administrators for Your Windows Azure Subscription.
Important You should delete the publishing profile that you downloaded using Get-AzurePublishSettingsFile after you import those settings. The downloaded profile contains a management certificate that should not be accessed by unauthorized users. If you need information about your subscriptions, you can get it from the Windows Azure Management Portal or the Microsoft Online Services Customer Portal.
How to: Create a Windows Azure service
Use the New-AzureServiceProject cmdlet to create the scaffolding for a cloud service for your application.
The following example shows how to create a new cloud service named MyService.
PS C:\app> New-AzureServiceProject -ServiceName MyService
The cmdlet creates a service subdirectory on your local computer, adds service configuration files to the service directory, and changes the focus of the Windows PowerShell command prompt to the new service directory.
After you create the service, you can run any of the following cmdlets from the service directory to configure a web role or worker role for the service.
- Add-AzureNodeWebRole
- Add-AzureNodeWorkerRole
- Add-AzurePHPWebRole
- Add-AzurePHPWorkerRole
- Add-AzureDjangoWebRole
When your application is deployed as a cloud service in Windows Azure, it runs as one or more roles. A role simply refers to the application files and configuration. You can define one or more roles for your application, each with its own set of application files and its own configuration. A web role is customized for web application programming, while a worker role is intended to support general development and periodic or long-running processes. For more information about service roles, see Overview of Creating a Hosted Service for Windows Azure.
The cmdlets listed above create a role directory that is ready to run code written in the specified language (Node.js or PHP). After creating a role, you can put code in the role directory and run it in the compute emulator with the Start-AzureEmulator cmdlet or publish it to Windows Azure with the Publish-AzureServiceProject cmdlet.
You can run these cmdlets with no parameters to create a single role instance with the name WebRole1 or WorkerRole1. Use the -Name parameter to use a different role name.
For each role in your application, you can specify the number of virtual machines, or role instances, to deploy using the -Instances option.
The following example shows how to use the Add-AzureNodeWebRole cmdlet to create a new web role named MyWebRole that has two instances.
PS C:\app\MyService> Add-AzureNodeWebRole MyWebRole -I 2
How to: Test a service locally in the Windows Azure Emulators
The Start-AzureEmulator cmdlet starts the service in the Windows Azure compute emulator and also starts the Windows Azure storage emulator. You can use the compute emulator to test the service locally before you deploy the service to Windows Azure. You can use the storage emulator to test storage locally before your application consumes Windows Azure storage services.
If your application includes a web role, you can use the –Launch parameter to open the web role in a browser.
The following example runs the MyService application in the compute emulator and opens the web role in a browser.
PS C:\app\MyService> Start-AzureEmulator -Launch
After you finish testing an application locally, run the Stop-AzureEmulator cmdlet to stop the Windows Azure compute emulator, as shown below.
The following example shows how to use Stop-AzureEmulator to stop the emulator.
PS C:\app\MyService> Stop-AzureEmulator
How to: Set default deployment options for a service
You can use the Set-AzureServiceProject cmdlet with the -Location, -Slot, -Subscription and -Storage parameters to set the default deployment location, slot (Staging or Production), Windows Azure subscription, and storage account to use when you deploy a service. The default options apply to an individual service. You can run the cmdlet from anywhere in the service directory.
These options take effect when you next deploy the service (using Publish-AzureServiceProject). If you want to override a default deployment option during a service deployment, you can use a parameter for the Publish-AzureServiceProject cmdlet.
If you have not set a default deployment option and you do not specify a deployment option to use when you publish the service, the service is deployed using the following settings:
| Setting | Default Value |
| Location | Randomly assigns the service to either South Central US or North Central US. |
| Slot | Deploys the service to a production slot. |
| Subscription | Uses the first subscription in your publishing profile. If you are an administrator for more than one subscription, you should specify a subscription to ensure that the intended subscription is used. |
| Storage account | Creates a new storage account that has the same name as the service, If the name has been used for a storage account for any other subscription, the deployment fails. In that case, you must specify a storage account to use for the service. |
In the following example, the default deployment location for the MyService service is set to Southeast Asia:
PS C:\app\MyService> Set-AzureServiceProject -Location "Southeast Asia"
By default a service is published to a production slot, where it is assigned a friendly URL based on the service name (http://MyService.cloudapp.net). If you prefer to deploy the service to a staging slot for testing before you deploy to production, you can set the default deployment slot to Staging.
The following example sets the default deployment slot for the MyService service to Staging.
PS C:\app\MyService> Set-AzureServiceProject -Slot Staging
You only need to set a deployment subscription for a service if you are an administrator for more than one Windows Azure subscription. If you have been assigned as a co-administrator for subscriptions other than your own subscription, use the -Subscription parameter to specify which subscription to use for a service.
The following example sets the ContosoFinanace subscription as the default subscription to use for the MyService service.
PS C:\app\MyService> Set-AzureServiceProject -Subscription Contoso_Finance
How to: Use a storage account with more than one service
When you deploy a new service, by default, a new storage account is created in the deployment location, and the application package and configuration files are copied to the Windows Azure Blob service using that storage account. The new storage account has the same name and location as the service, and it is associated with the subscription that was used to deploy the service.
If you want to use an existing storage account with a service, you can use the -Storage parameter to specify that storage account as the default storage account for service deployments, or you can use the -Storage parameter for Publish-AzureServiceProject to specify the storage account for the current service deployment.
To find out which storage accounts are available for your Windows Azure subscription, run the Get-AzureStorageAccount cmdlet. If you are a co-administrator for more than one subscription, use the -Subscription parameter to specify which subscription to retrieve the storage information for. The cmdlet retrieves the storage account name and access keys for each storage account.
In the following example, a service co-administrator retrieves storage account information for the subscription with the imported publish settings.
PS C:\ > Get-AzureStorageAccount
Account Name: ContosoUS
Primary Key: YSAwVSjixHpcsK/IX7cRcqzVVa19YCUEhzndhZMZL9aMmNT2Du1DPiufPDBiJUO7FW4Dcb7tkzw14VoK0EppnA==
Secondary Key: OBlsaR6A4untNNwuhHDkWkcI7pKwTEPA9JYO/Jv2m/zERqrtMjUGVpz8xRZ2mTPp5qksu9K2JawAo5rEKDaL+w==
Account Name: ContosoAsia
Primary Key: OzAqwcrrtHa4/5qUyekSRK1F257PrzQHE+i4TJc38MHDBDNjZesbbftfm5tta2rsNH0SM7DEnlqt9PW70AB1VA==
Secondary Key: xjCQHNwgedo/RXMOk1PKqRHiEpox001/H+qgl/OphoKzOoQTzR/FAGGobsf5HgjE35lfPAD0KeApGFv4ga0hhw==
The co-administrator then sets ContosoUS as the default storage account to use for the MyService service, running the cmdlet from the MyService service directory.
PS C:\app\MyService> Set-AzureServiceProject -Storage ContosoUS
How to: Deploy a cloud service to Windows Azure
When you are ready to deploy your service to Windows Azure, use the Publish-AzureServiceProject cmdlet. When you deploy a new cloud service, Windows Azure performs the following tasks:
-
Packages the source and configuration files into a service package (.cspkg file).
-
Creates a new cloud service.
-
If no storage account is specified, creates a new storage account if needed.
-
Copies the service package and configuration files to the Windows Azure blob store for the storage account.
-
Creates the cloud service and deployment using the uploaded service package.
Use the following parameters to specify deployment options for the current deployment.
Changing the service name
The service name must be unique within Windows Azure. If the name you gave the service when you created it is not unique, you can use the -Name parameter to assign a new name.
In the following example, the service name is changed to MyService01 when the service is deployed. The name of the service directory does not change, but the service will be known in Windows Azure as MyService01.
PS C:\app\MyService> Publish-AzureServiceProject -ServiceName MyService01
Note If you specify a service name that is not unique in Windows Azure, the service deployment fails, and you will see the following error: "Publish-AzureServiceProject : The remote server returned an unexpected response: (409) Conflict."
Setting a subscription for this deployment
You only need to use the -Subscription parameter if you are an administrator for more than one Windows Azure subscription. In that case, it is recommended that you include this parameter to ensure that you use the intended subscription with the service.
In the following example, the Contoso_Finance subscription is used to deploy the MyService service.
PS C:\app\MyService> Publish-AzureServiceProject -Subscription Contoso_Finance
Specifying the location for this deployment
Use the -Location parameter to specify a geographic region for the service deployment. If you have not set a default deployment location for the service, and you do not specify a location using this parameter, the service is assigned randomly to either to North Central US or South Central US.
To get a list of available locations, run the following cmdlet.
Help Publish-AzureServiceProject -Parameter Location
In the following example, the Publish-AzureServiceProject cmdlet is used to deploy the service to the Southeast Asia data center:
PS C:\app\MyService> Publish-AzureServiceProject -Location "Southeast Asia"
Using an existing storage account
If you manage multiple services in the same location, you can include the -StorageAccountName parameter to assign an existing storage account in that location instead of creating a new storage account for the service. If you have not specified a default storage account for the service, and you do not specify a service account when you deploy the service, a new storage account is created, even if an existing storage account is available in that location. For information about creating and managing storage accounts, see How to: Manage Storage Accounts for a Windows Azure Subscription.
In the following example, the MyService service is deployed using the StorageUS storage account for the ContosoFinance subscription.
PS C:\app\MyService> Publish-AzureServiceProject -Subscription ContosoFinance -StorageAccountName StorageUS
Deploying a service to staging or production
Use the -Slot parameter to specify whether to deploy the service to the staging environment or the production environment in Windows Azure. By default, services are deployed to production. In Windows Azure, the staging and production environments are distinguished by the address that is used to access the service. Use the staging environment to test a service before deploying it to production, where a friendlier URL is assigned:
In the following example, the MyService service is deployed to the Windows Azure staging environment.
PS C:\app\MyService> Publish-AzureServiceProject -Slot Staging
Opening the web role in a browser
If the service contains a web role, you can include the -Launch parameter to open the web role in a browser. All services are started automatically after they are deployed, but the web role is not opened unless the -Launch parameter is included.
Examples
In the following example, the MyService service is deployed using values that have been set previously. A new storage account is created. The service is deployed to the production environment.
PS C:\app\MyService> Publish-AzureServiceProject
Publishing to Windows Azure. This may take several minutes...
6:15:58 PM - Preparing deployment for MyService with Subscription ID: 0807028c-e0a5-4773-82e3-8cae71dd5702...
6:16:04 PM - Connecting...
6:16:07 PM - Creating...
6:16:09 PM - Created hosted service 'MyService'.
6:16:09 PM - Verifying storage account 'myservice'...
6:18:14 PM - Uploading Package...
6:20:41 PM - Created Deployment ID: 7ce799c2023a4ae9b346b970045cd14c.
6:20:41 PM - Starting...
6:20:41 PM - Initializing...
6:20:55 PM - Instance WebRole1_IN_0 of role WebRole1 is creating the virtual machine.
6:24:26 PM - Instance WebRole1_IN_0 of role WebRole1 is busy.
6:25:42 PM - Instance WebRole1_IN_0 of role WebRole1 is ready.
6:25:43 PM - Created Website URL: http://MyService.cloudapp.net.
6:25:43 PM - Complete.
In the following example, parameters are used to set the subscription (ContosoFinance), slot (Staging), and location (North Central US) for the current service deployment.
PS C:\app\MyService> Publish-AzureServiceProject -Subscription ContosoFinance -Sl staging -L "North Central US"
How To: Update a deployed service
When you use Publish-AzureServiceProject on a deployed service, the service is either updated in place or a new deployment is created. The update method depends on the types of changes that you make.
The following types of update are performed in place, without redeploying the service:
-
Adding a new web role or worker role to the service, or changing the number of instances of an existing role.
-
Updating the application or the service configuration file.
-
Enabling or disabling remote access to service role instances.
The following types of update initiate a new service deployment:
-
If you change the subscription, storage account, or deployment location, a new service deployment occurs, and the previous deployment is deleted.
-
If you change the deployment slot - for example, you deploy a service that is in the staging environment to the production environment - a second deployment is performed without deleting the first deployment.
In the following example, the MyService service is updated in place after a second service role instance is added to the MyWebRole service role.
PS C:\app\MyService> Set-AzureServiceProjectRole -RoleName MyWebRole -Instances 2
PS C:\app\MyService> Publish-AzureServiceProject
The following example shows how you would publish a new service deployment to production. If a service deployment exists in staging, both deployments are retained.
PS C:\app\MyService> Publish-AzureServiceProject -Slot Production
In the following example, a service that has been deployed to the Anywhere Europe location is redeployed to North Europe. Because the location is changing, the service is redeployed and the existing deployment is removed. An existing storage account for the North Europe location is used.
PS C:\app\MyService> Publish-AzureServiceProject -Location "North Europe" -StorageAccountName NorthEuropeStore
How to: Scale out a service
You can scale a running service out or in by using the Set-AzureRole cmdlet to add or remove instances to a web role or a worker role.
The following example shows how to update the MyService service by changing the number of instances of the MyWebRole web role to two:
PS C:\app\MyService> Set-AzureRole -Service MyService -Slot Production -RoleName MyWebRole -Count 2
Note that the Set-AzureRole cmdlet does not require you to republish the service since it updates the deployed service configuration file.
How to: Create a dedicated cache
The Windows Azure PowerShell cmdlets allow you set up a worker role as a dedicated cache, and configure web roles to access the cache using the memcache protocol.
To create a dedicated cache in an existing project, use the Add-AzureCacheWorkerRole cmdlet. The following example adds a role called mycacherole:
PS C:\app\MyService New-AzureCacheWorkerRole -Name mycacherole
You can then configure a web role to access the dedicated cache using the memcache protocol by using the Enable-AzureMemcacheRole cmdlet. The following example configures an existing web role (called mywebrole) to access the dedicated cache (mycacherole):
PS C:\app\MyService Enable-AzureMemcacheRole mywebrole mycacherole
Clients that can use the memcache protocol (such as PHP and Node.js) can then connect to the dedicated cache using the host name localhost_mywebrole (on port 11211 by default). The following examples show example connection code for PHP and Node.js:
PHP
$memcache = new Memcache;
$memcache->connect('localhost_mywebrole', 11211) or die ("Could not connect"); Node.js
var mc = require("mc");
var mcclient = new mc.Client('localhost_mywebrole');
mcclient.connect(function() {
console.log("Connected to the localhost memcache on port 11211!");
}); For information about Caching pricing, see Pricing Details.
How to: Stop, start, and remove a service
A deployed application, even if it is not running, continues to accrue billable time for your subscription. Therefore, it is important that you remove unwanted deployments from your Windows Azure subscription. You also have the option to stop your service but not remove it. However, if you do not remove the service, you will still accrue charges for the compute units (virtual machines), even if the service is stopped.
Use the Stop-AzureService cmdlet to stop a running, deployed service. If you have deployments in both staging and production, you can use the -Slot parameter to specify which deployment to stop. If you do not specify a slot, both deployments are stopped.
The following example shows how to stop the MyService service.
PS C:\app\MyService> Stop-AzureService
Use the Start-AzureService cmdlet to restart a service that is stopped. For a service with both staging and production deployments, the -Slot parameter specifies which deployment to start. If the -Slot parameter is not included, both deployments are started.
The following example shows how to start the production deployment of the MyService service.
PS C:\app\MyService> Start-AzureService -Slot production
To remove a service, use the Remove-AzureService cmdlet. If a service has associated deployments, this cmdlet will prompt you to delete the deployments.
PS C:\app\MyService> Remove-AzureService -ServiceName MyService
You can bypass the prompt by using the -Force option with the Remove-AzureService cmdlet. The following example shows how to delete all deployments associated with the MyService service, and the service itself.
PS C:\app\MyService> Remove-AzureService -ServiceName MyService -Force
How to: Create and manage a Windows Azure Web Site
Many of the web site creation and management tasks that you can perform in the Windows Azure Management Portal can be performed using the Windows Azure Powershell cmdlets. The sections below show you how to perform some basic tasks. For a complete list of web site cmdlets, use the help command:
PS C:\MySite> help website
Note The examples below assume that the root directory of your local site is MySite.
Create a web site
You can create a web site with the New-AzureWebsite command. The following command shows how to create a new site called mysite. The URL for the site will be mysite.azurewebsites.net.
PS C:\MySite> New-AzureWebsite mysite
Deploy with Git
To create a web site that is Git-enabled, you must have Git installed locally, and the Git executable must be in your Path environment variable. The following example shows you how to create a web site (mysite) that is Git-enabled:
PS C:\MySite> New-AzureWebsite mysite -Git
Note When you run the command above from a directory that is not a Git repository, you will receive the following message, even though the command was successful: fatal: Not a git repository (or any of the parent directories): .git.
If the local directory is not a Git repository, the command will create one for you. After the repository has been created (or if it was a repository to begin with), the command will also create a remote repository (azure) and create a reference to it in your local repository. You can then proceed to add, commit, and push changes to the remote repository:
git add .
git commit -m "your commit comments"
git push azure master
Deploy from GitHub
If you have a local clone of a GitHub repository or if you have a local repository with single remote reference to a GitHub repository, you can use the -Github flag when creating a new web site to enable publishing from GitHub:
PS C:\MySite> New-AzureWebsite mysite -Github
This command will immediately publish content in your GitHub repository. From then on, any changes pushed to the repository will automatically be published.
After you have pushed changes, you can use the Get-AzureWebsiteDeployment cmdlet to get deployment information:
PS C:\MySite> Get-AzureWebsiteDeployment
Configure app settings
App settings are key-value pairs that are available to your application at runtime. In ASP.NET web applications, app settings are accessible via the Configuration.AppSettings property and will override settings with the same key defined in the Web.config file. For Node.js and PHP applications, app settings are available as environment variables. The following example shows you how to set a key-value pair:
PS C:\MySite> $settings = @{"myKey" = "myValue"}
PS C:\MySite> Set-AzureWebsite -AppSettings $settings Start, stop, or restart a web site
The Windows Azure PowerShell cmdlets allow you to start, stop, or restart a web site with the following commands:
PS C:\MySite> Start-AzureWebsite
PS C:\MySite> Stop-AzureWebsite
PS C:\MySite> Restart-AzureWebsite
How to: Create, modify, and remove a SQL Database server
Windows Azure SQL Database is a cloud-based relational database platform built on SQL Server technologies. (For more information, see Introducing Windows Azure SQL Database.) Windows Azure Powershell provides cmdlets that allow you to create, modify, and remove SQL Database servers.
Note SQL Database servers are not associated with Cloud Service projects. The SQL Database cmdlets shown below do not need to be run from a project directory as in the examples above.
Create a server
To create a SQL Database server, use the New-AzureSqlDatabaseServer cmdlet. You will need to supply an adminstrator name and login, and a location:
PS C:\> New-AzureSqlDatabaseServer -AdministratorLogin MyLogin -AdministratorLoginPassword MyPassw0rd -Location "North Central US"
Upon successful creation of a new server, you will see output simailar to this:
ServerName Location AdministratorLogin
---------- ---------- ----------
t9qh586619 North Central US MyLogin
To get a list of servers, use the Get-AzureSqlDatabaseServer cmdlet. To update a server, use the Set-AzureSqlDatabaseServer cmdlet.
After creating a server, you will need to create a firewall rule to make it accessible.
Create a firewall rule
To allow connections to a SQL Database server, you must create a firewall rule that specifies a range of IP addresses from which connections are allowed. The following example show how to use the New-AzureSqlDatabaseServerFirewallRule cmdlet to allow connections from IP address between 111.111.111.111 to 222.222.222.222:
PS C:\> New-AzureSqlDatabaseServerFirewallRule –RuleName MyRule -ServerName t9qh586619 -StartIpAddress 111.111.111.111 -EndIpAddress 222.222.222.222
Note To allow other Windows Azure services to access the server, create a rule that specifies the StartIpAddress and EndIpAddress both as 0.0.0.0.
To update an existing rule, use the Set-AzureSqlDatabaseServerFirewallRule cmdlet:
PS C:\> Set-AzureSqlDatabaseServerFirewallRule –RuleName MyRule -ServerName t9qh586619 -StartIpAddress 111.111.111.222 -EndIpAddress 222.222.222.111
To get a list of rules for a server, use the Get-AzureSqlDatabaseServerFirewallRule cmdlet:
PS C:\> Get-AzureSqlDatabaseServerFirewallRule -ServerName t9qh586619
To remove a firewall rule, use the Remove-AzureSqlDatabaseFirewallRule cmdlet.
Remove a server
To remove a SQL Database server, use the Remove-AzureSqlDatabaseServer cmdlet, specifying the server name:
PS C:\> Remove-AzureSqlDatabaseServer -ServerName t9qh586619
The command above will require confirmation that you want to delete the specified server. To override this default behavior, use the -Force parameter. Using this parameter will delete the server without requiring confirmation.
Additional resources