The git repo you get when creating a new azure web site uses a password scheme. Not that annoying except you can’t use the default git credential cache from Windows. As usual, there’s an excellent answer on Stack Overflow, and a very nice Windows Credential Store for Git on CodePlex.

Grab the codeplex git-credential-winstore.exe, run it, and you’ll have the Windows credential manager to handle your git remote credentials.

If you want to remove or edit your credentials, dig in your Control Panel –> User Accounts –> Credential Manager.

I stated in a previous post you didn't have to care for virtual networks, here's a more detailed explanation.

1/ What happens when you don't use virtual networks

Your machines get a random private IP address. Each machine in a given service (I should maybe say deployment, but there's a cloud service underneath your virtual machine, and it forms the network boundary) can see other machines in the same service. The default DNS gets you name resolution inside a service.

2/ What happens when you use a virtual network

To make that happen, you must declare an affinity group (an alias for a region), and use it to create a storage account and the VMs you want in that virtual network.

You then define a virtual network and a subnet. Once this is done, you can create virtual machines in that virtual network (more accurately, in a subnet of that virtual network). Now, you get inter-services network connectivity, as long as you're in the same virtual network, and even across subnets. What you don't get, though, is name resolution (you still get intra-service name resolution if you have VMs in the same service).

3/ An illustration

Suppose I have defined a virtual network (mynicevnet) and a subnet (mynicesubnet). now, let me create those machines :

machine1 (servicename : service1, subnet : mynicesubnet)

machine3 (servicename : service2, subnet : mynicesubnet)

machine2 (servicename : service1, subnet : mynicesubnet)

Note that I created the machines in the order above, and my subnet is 10.0.0.0/23

Now, let's SSH into machine1 :

As you can see, machine1 and machine2 have IPs 10.0.0.4 and 10.0.0.6, and machine1 resolves machine2

Now, let's ping 10.0.0.5 :

It works. Let's check the IP on machine3 :

As expected.

4/ Sum-up

If you only need a few machines, your best bet is to connect directly them in the same service (using the -c switch in the azure vm create command). You'll get name resolution and network visibility in a snap.

If you need more machines, or a more resilient setup, you can create several services in the same virtual network, and you'll have an expanded network visibility. Note that you'll get visibility across subnets as well. Machines living in the same service will also have name resolution inside the service.

If you want name resolution across services, you'll have to provide your own DNS. That could be an on-premise DNS if you use your Virtual Network with a VPN, or a remote DNS, or a cloud-hosted DNS. I won't elaborate on how to set up a DNS in detail, but know that in Azure it's a pain to reconfigure the DNS address in a virtual network once you have machines deployed, which causes a chicken-and-egg problem if you want to provision the DNS in the virtual network... I hope we'll soon have a better way to do this, but I have seen in my tests that the IPs are allocated sequentially when you provision machines, starting at 4. (in other words : if you create a subnet 10.0.0.0/23, the first machine you create in there will have the IP 10.0.0.4). So, just declare your DNS as 10.0.0.4 and make sure this is the first VM you provision.

This is just a crude outline, from memory. The basic idea is to prepare your VM on a machine using hyper-v, add the windows azure linux agent, run the deprovision command, and upload.

1/ Prerequisites

Read http://wiki.debian.org/Cloud/WindowsAzureImage
Install the azure command-line tools on your machine
Install hyper-v

2/ Create a new virtual machine in hyper-v

Create the VM without a virtual hard disk, then add one at the VHD format (not VHDX). Choose wisely the VHD size ! You won't pay for uploading data to Azure, but uploading 30Gb is a pain if you have average connectivity. Besides, you'll be able to create data disks on azure and mount them directly.

3/ Install your stuff

Install whatever you want on that VM, and finish with the Azure tools:
sudo apt-get install waagent

4/ (Optional) Save your work

Stop the VM, backup its VHD, restart. If you have to tweak things the backup will save tons of time.

5/ Deprovision the VM

sudo waagent -deprovision+user

6/ Upload and test

You can shutdown your VM, the VHD is ready to be tested on Azure. To do that you'll need to create a storage account and upload the VHD (see the azure command-line tool to do that : azure vm image create --help)

A note about step 6: I did my uploads in a more complicated way last time I tested, if you encounter problems there let me know (@piercou).

I get a *lot* of questions on how to setup networking in Windows Azure Virtual Machines, so here's a quick braindump. You'll need to install the azure command line tool, instructions are available on the debian-cloud wiki

You don't need a virtual network

That's the most important thing you have to understand. A virtual network sounds very nice when you see it for the first time, but it's mainly designed for VPN connectivity. As long as you don't need to bridge your on-premise network with Azure VMs, forget about it.

Isolated VMs

Azure VMs only get private, non-routable IPs. The communication with the outside world goes through a load balancer. The load balancer owns public IPs, your machines don't.

If you create 2 standalone VMs, like :

azure vm create mydnsname [a bunch of options] --ssh
azure vm create myotherdnsname [a bunch of options] --ssh

You'll get 2 machines that only see each other through the load balancer. This is usually not what you want.

VM Farm

What you're looking for is a farm of machines, with a few visible from the outside world, and open connectivity between machines. Take for example this setup:

    Web Frontend VM (let's call it web1)
    Database VM (let's call it data1)

In this case you want web1 to see data1, and the other way around, but you only want web1 exposed to the outside world.
Here is how you do it:

azure vm create mydnsname [some options] -n web1
azure vm create mydnsname [some options] -n data1 -c mydnsname

That mydnsname is called the Service name. When you create a new VM, you can join it to an existing service, hence ensuring it will see every other machine deployed in the same service.

The load balancer

If you want to open a port to a given machine, the syntax is

azure vm endpoint create machinename lbport machineport

If you want to create a load-balanced endpoint to a set of machines, the syntax is

azure vm endpoint create -b endpointname machine1name lbport machine1port
azure vm endpoint create -b endpointname machine2name lbport machine2port

And so on.

How do my machines see each other ?

Standalone VM : use their public dns name and the port you set up in the load balancer if needed.

VM Farm : use the machine name from the inside network, every VM will resolve that correctly. Use the public DNS name from the outside world.

ssh gotchas

If you don't specify --ssh when creating a Linux VM, ssh won't be enabled on the machine.
If you specify --ssh but no port, this will work on standalone VMs. When creating a farm, make sure you specify --ssh portnumber with a different portnumber for every machine.
I know it's a bit dumb, we should enable ssh without exposing it to the outside world, delete the endpoint after creating the machine if that's what you want.

On m'en avait parlé plusieurs fois mais j'avais jamais essayé Mono.Options, pour faire des applis console paramétrables sans être un devin. Mono.Options est disponible dans NuGet  (un petit clic droit dans les références de votre projet console, ou bien directement par un Install-Package Mono.Options).

Comment ça marche ? Voilà par exemple mon outil d'extraction du pfx à partir du fichier de publish settings Azure :

using System;
using System.Xml.Linq;
using Mono.Options;

namespace GetPfx
{
    class Program
    {
        static void Main(string[] args)
        {
            bool help=false;
            string publishFile="";
            string outPfxFile = "";

            OptionSet o = new OptionSet()
            .Add("?|h", "help file", v => help = v != null)
            .Add("in=|pub=", "{file} saved from https://windows.azure.com/download/publishprofile.aspx", 
                  v => publishFile = v)
            .Add("out=|outpfx=", "{file}name for the resulting pfx", v => outPfxFile = v);

            o.Parse(args);
            
            if (help || publishFile=="" || outPfxFile=="")
            {
                Console.WriteLine("Extracts a pfx file from the Azure publish profile");
                Console.WriteLine("Options:");
                o.WriteOptionDescriptions(Console.Out);
                Environment.Exit(-1);
            }

            var x = XDocument.Load(publishFile);
            string pfx = x.Element("PublishData")
                            .Element("PublishProfile")
                            .Attribute("ManagementCertificate").Value;
            System.IO.File.WriteAllBytes(outPfxFile,Convert.FromBase64String(pfx));
        }
 
    }
}

Voilà la mise à jour du packager PHP pour le SDK 1.6.

Les petites nouveautés :

• Suppression de la mise à jour par FTP
• Passage par défaut sur des instances extra small
• Activation de la fonctionnalité d'upgrade

Ce package n'autorise pas la prise de contrôle à distance de l'instance, mais le prochain comblera ce petit manque.

Mode d'emploi :

1. dézippez le squelette,
2. déposez votre application PHP dans le répertoitre yourPHPApp
3. lancez package.bat
4. déployez sur Azure le contenu de DeployWhatsInThere

Petit cadeau pour les abonnés MSDN : une machine sur Azure, avec un disque en WebDAV (taille limitée à 10Go pour les abonnés Pro, et 200 pour les abonnés premium si vous cherchez un peu dans les fichiers de configuration...)

Les infos détaillées : http://www.microsoft.com/france/visual-studio/msdn/azurepowerpack.aspx

La doc d'install : http://azdocs.cloudapp.net/modules/blogengine/post/2012/03/02/Installation-du-paquet-Azure4Msdn.aspx

La petite vidéo d'utilisation du partage réseau :

Et l'utilisation de l'accès RDP à la machine Azure :

Microsoft colle à l'actualité PHP, avec la sortie le 29 février de PHP 5.4 pour Windows, l'équipe Sql Server vient de publier une version 3.0.1 des drivers PHP pour Sql Server et Sql Azure. Les versions 2 et 3 sont disponibles sur http://www.microsoft.com/download/en/details.aspx?id=20098

Attention, les dépendances changent entre les versions 2.0 et 3.0. Voici les liens d'installation des runtimes requis pour utiliser le driver en version 3.0.1 :

32 bits : X86 Package

64 bits : X64 Package

Due to many requests, here is a very crude PHP deployment sample for your apps in Azure. Here is how it works : I created a dummy Web role application that does nothing but execute a startup task. That project is then used as a skeleton for your PHP application. What you have to do to use it is :

0/ Install the latest Azure SDK (I tested this against the 1.4 refresh)

1/ Unzip skeleton.zip somewhere

2/ in the YourPHPApp folder, put your php application

3/ Launch Package.bat and you"ll get back the package in DeployWhatsInThere

Things you can tweak :

If you need a different PHP Runtime, go to the PHPRuntime\PHP folder and do what you want (the version is 5.3.6 NTS VC9, match the extensions if you add some)

If you need to tweak permissions and the like, change PHPRuntime\InstallPHP.cmd

If you want to add remote desktop capabilities, open the solution skeleton.sln and you'll have access to the dummy web role. If you recompile the new version will be picked up by package.bat (Note : you can also manually edit the csdef and cspkg file)

If you need ftp access to the box : drop some ftp binaries somewhere alongside the php runtime and launch them from installphp.cmd (oh, don't forget to add a port in the firewall by adding an endpoint in ServiceDefinition.csdef, something like :

      <InputEndpoint localPort="21" port="21" name="ftp" protocol="tcp"/>

Here is the thing :

(Comments should go to my inbox rather than here, just send them to pierre.couzy at microsoft.com)

J'ai réalisé il y a quelques jours une série de petites vidéos sur Azure, et l'une d'entre elles est spécifquement dédiée à PHP et Azure. Comment installer son application, comment utiliser les composants de Windows Azure, et quels sont les frameworks dèjà capables de faire tout ça :

Je ferai un billet plus spécifique à Zend Framework prochainement. Si vous avez besoin de billes rapidement, un petit mail à pierre point couzy at microsoft point com et on en discute.