Global Azure Bootcamp France 2017 - Paris et 5 autres villes

GAB2017

Global Azure Bootcamp France 2017 - Paris et 5 autres villes

Le Global Azure Bootcamp est un événement gratuit pour découvrir le Cloud Microsoft Azure, organisé le même jour, le Samedi 22 avril 2017, par des groupes d'utilisateurs et communautés du monde entier.
En France, AZUG FR la communauté française des utilisateurs de Microsoft Azure, en collaboration avec les communautés MUG LyonMUG Strasbourg et CMD, est ravie d'organiser cette nouvelle édition 2017 dans six villes : Paris, Aix-Marseille, Bordeaux, Lyon, Nice et Strasbourg.
Cette journée vous permettra de découvrir ou approfondir vos connaissances sur Microsoft Azure, mais aussi de pratiquer. Rejoignez-nous sur place, et faites partie de cet événement mondial rassemblant des milliers de personnes, sous le hashtag social #GlobalAzure.
Pour vous inscrire:

Azure Multi-VNET Topologies in the ARM Era (Part 1)

If you have visited before on the pages of this blog, you may have seen this article : “Azure VNET to VNET VPN, across regions and data centers: not so complicated”. At that point, I wrote about how to put in place a connection between multiple Azure Virtual Networks, in particular a VNET-to-VNET-to-VNET relationship. All based on PowerShell scripting and classic deployment in Azure.

Today is the time to write again about this subject, but this time under a new cover related to several aspects: ARM (Azure Resource Manager) deployment,  usage of the new Azure Portal, and application of new networking concepts in Azure, like VNET Peering.

This is a two-part series of articles on these aspects. The series is related to the publication of a dedicated MS Experiences Online recording. In the recording we speak about these concepts, so I will focus here mainly on detailing and documenting the forenamed recording.

The first article includes the business case, the networking concepts and topologies and their applicability in Azure, and the technical solution we propose for the given use case.

Business Case

We propose to make communicating multiple environments (or resources) between each-other, in a IaaS (networking) context. That may be within the same Azure data center or region, or across regions. For this, we are required to put in place network connectivity between these environments.

To put it even more concrete, we chose to facilitate the deployment of a SQL Server AlwaysOn Cluster (available with SQL Server 2012 editions and later ones), cluster to be deployed as follows:

- 1 primary replica in Dublin (North Europe region)
- 1 secondary replica in Dublin
- 1 secondary replica in Amsterdam (West Europe region)

The solution will be focused on the network connectivity aspects, and not on the network security ones.

Azure Technical Concepts and Services

The following concepts will be used in the next lines, so we need to reference first the corresponding definitions in the Azure documentation:

- VNET – Virtual Network, Subnet [https://docs.microsoft.com/fr-fr/azure/virtual-network/]
- Public IP [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-ip-addresses-overview-arm]
- Network Interface Card [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-network-interface-overview]
- VPN Gateway [https://docs.microsoft.com/fr-fr/azure/vpn-gateway/]
- ExpressRoute [https://docs.microsoft.com/fr-fr/azure/expressroute/]
- VNET Peering [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-peering-overview]
- Network Security Group [https://docs.microsoft.com/fr-fr/azure/Virtual-Network/virtual-networks-overview]
- Virtual Appliances [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-overview]
- User Defined Routes [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-udr-overview]

Most of these are already known and used from some time. I will insist on one concept only: the VNET Peering. As stated in the documentation, it practically allows you to join 2 VNETs located in the same region, by passing directly through the local backbone without needing a VPN gateway. This is very practical, as the VMs across the 2 VNETs will communicate with each-other on a bandwidth limited by the VMs’ network cards only.

Initial Environment

Let’s take a look at the networking structure of the original environment as we assumed it in our scenario.

The first VNET, named “net1dublin”, based in Dublin DC (North Europe): a classical VNET configuration, with a 10.0.1.0/24 range and composed from a single subnet named “default” having 10.0.1.0/25 range.

clip_image002_thumb[1]_thumb

There is a single virtual machine deployed in this subnet, named “vm1net1”, having attached one network card with the IP address 10.0.1.4. As remark, the access to the VM is controlled via the Network Security Group “nsg1net1”.

Similarly, we have a second VNET in Dublin, “net2dublin”, range 10.0.2.0/24, containing the VM “vm2net2” with the IP address 10.0.2.4.

clip_image003_thumb[1]_thumb

Finally, the third VNET, deployed in Amsterdam DC (West Europe), is named “net3amsterdam”, has an IP range of 10.0.3.0/24 and contains the VM “vm3net3” having the IP address 10.0.3.4.

clip_image004_thumb[1]_thumb

In our scenario – a SQL Server AlwaysOn cluster – we would have:

- “vm2net2” : primary replica (“master”) in Dublin
- “vm1net1” : a synchronous secondary replica in the same region
-“ vm3net3” : an asynchronous secondary replica in Amsterdam.

Networking Architectures and Topologies

1. Simple hybrid topology

First of all, will remind the simple topologies, starting with the “classical” hybrid Azure-VNET-to-On-premises-Network:

image

This “point-to-point” topology es at the base of all coming ones. The connection is made either over public internet (IPSec Site-to-Site VPN Azure, via an VPN Gateway in Azure and a network gateway device on-premises), or over private infrastructure (Azure ExpressRoute + typical MPLS infrastructure put in place for you by the provider of your choice and availability). You can have – if you need, for example, in a HA / DR architecture – both S2S VPN and ExpressRoute working at once.

2. Simple cloud-only topology

Now we’ll apply the same concepts for S2S VPN, but this time between 2 VNETs (in the same region or across regions):

image

So the solution is quite similar, but you will simply pass through the Microsoft backbone infrastructure. Note that you can make profit of your hybrid ExpressRoute circuit – if any – to put in connection Azure VNETs also. In that case, the S2S VPN Gateways will be replaced by ExpressRoute ones.

Under the same simple cloud-only topology, you may have this time a VNET Peering put in place (if the VNETs are in the same region):

image

Note that you can connect either ARM-to-ARM VNETs or ARM-to-Classic VNETs. This is a perfect solution for Azure “legacy” infrastructure” (a bit strange to speak about “legacy” in Azure Smile ) deployed on classic networks, in order to avoid their migration to ARM if not absolutely necessary, while still let them communicate with all the new [ARM] deployments.

3. Complex topologies: Hub & Spoke

When the requirements become more complicated, we will use adapted connectivity patterns to cover them. Here is the “Hub & Spoke” topology.

Cases are when there is a central system which needs to communicate with “satellite” systems. In the case of an SQL Server AlwaysOn cluster with multiple replicas for higher availability and throughput, the VNET of the master replica will be “surrounded” by the VNETs corresponding of secondary replicas.

image

In this case, we will configure simple bidirectional communications between the master VNET end the satellite VNETs. Any of the direct connectivity options described before (IPSec VPN, ExpressRoute if the case, or Peering) can be used here.

Note that the Hub & Spoke topology doesn’t imply connectivity transitivity : the left VNET won’t (necessarily) communicate with the right one.

4. Complex topologies: Daisy Chain

The transitivity comes into the game in the Daisy Chain topology. The left VNET will communicate with the right one via specific routing configuration set up in the middle VNET:image

This can be achieved in Azure via User Defined Routes functionality. But you will find another solution out a bit later in the article.

If the Daisy Chain topology has the advantage of getting profit of a connection already established (e.g. center with right) for the usage of another VNET (left one), you may have surely seen its inconvenient also: if the VNET on the center (or its gateway) loses its connectivity, it will also affect the connectivity between the lateral VNETs.

5. Complex topologies: (Full) Mesh

The Full Mesh let you master with precision the direct connectivity between various VNETs, without having dependencies on intermediate VNETs or their gateways :

image

On the other side, definitely there is much more work to getting it done; also, the complexity increases exponentially with each new VNET you want to add to the topology.
You may remark, by the way, that the picture reflects a Mesh which is not “full” actually; it’s up to you to decide if you want the left VNET communicate with the right VNET.

How do you implement a topology like this in Azure? The VPN gateways let you create this type of connectivity, but you can put it in place very quickly with multiple VNET peerings.

 

Technical Solution for the Given Scenario

Let’s depict the technical solution we propose for our business case:

image

So, recall that we have a primary replica in VNET2, and we need a secondary replica in VNET1 and another one in VNET3.

The solution is composed of 3 main segments:
1. VNET Peering between VNET2 and VNET1 (both VNETs being in the same region)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1. This connection transitivity will be configured in the VNET Peering settings directly.

Implementation

You will find the implementation of this solution in the next (and last) article of this series: http://blog.lecampusazure.net/2016/11/azure-multi-vnet-topologies-in-arm-era.html.

Azure Multi-VNET Topologies in the ARM Era (Part 2)

This article is the second (and the last) one of the series dedicated to Azure Multi-VNET Topologies in ARM implementation. You may find the first article here: http://blog.lecampusazure.net/2016/11/azure-multi-vnet-topologies-in-arm-era-1.html .

We will continue with the implementation of the technical solution as it was defined in the first article.

Technical Solution for the Given Scenario

The diagram for the technical solution we proposed is below:

image_thumb3

The solution is composed of 3 main segments:
1. VNET peering between VNET2 and VNET1 (both VNETs being in the same datacenter)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1, configured in the VNET Peering settings directly.

 

Implementation

a. VNET Peering configuration

The first part of our implementation consists in putting in place the NET Peering configuration between VNET1 and VNET2.

For this, in the “net1dublin” Settings, section Peerings, we will add a new peering, by giving it a name, selecting the corresponding VNET (“vnet2dublin” in our case):

clip_image005_thumb[1] 
Keep all other values by default (for the moment).
You should have the successful message right after that:

clip_image006_thumb 

Then you will see the peering listed in the Peerings list:

clip_image001

See that the Peering status is “Initiated” at this stage.

Similarly, let’s add a peering in the other way – “net2dublin” to “net1dublin”:

clip_image008_thumb[1]

Here it is, listed in “net2dublin” ‘s Peerings list:

image

Quickly, both Peerings pass in the Connected state. You can see it if go back  in “net1dublin” ’s Peerings list:

clip_image009_thumb[1]

And that’s all for the VNET Peerings part Smile

Testing the VNET Peering

At this point, you can already test the connectivity between the two virtual machines deployed across the networks. Download the proposed RDP file for the first VM (click “Connect” in the VM blade), connect via RDP to the VM, “vm1net” (private IP identified as 10.0.1.4), and then ping the second one, “vm2net2” (private address 10.0.2.4):

clip_image016_thumb[2]

In the same way, test the connectivity from vm2net2 to vm1net1:

clip_image017_thumb[2]

You may remark the very fast response time between the two VMs (and the underlying networks).

 

b. VNET-to-VNET VPN configuration

Now let’s add the VNET-to-VNET VPN configuration. We will start by creating a first VPN Gateway, “gw1net1”, for “net1dublin”. From the Azure portal, add a new Virtual Network Gateway as follows:

clip_image010_thumb[1]

Note the main steps during this configuration:
- selection of the gateway type: VPN
- selection of the VPN type: route-based (known also as “dynamic” gateway)
- selection of the SKU (which will give you the expected performance level)
- selection of the VNET
- configuration of the IP address range for the gateway instances (which will create behind a dedicated subnet in our VNET)
- configuration of the Public IP Address (newly created, by default, or select an existing one).

The result (after 30-45 min, the gateway provisioning is quite long) will look as follows:

image

The same steps will be followed for the second VPN Gateway, “gw3net3”:

clip_image011_thumb[1] 

And here is the result for this configuration:

image

After creating the gateways, we will create the connections between the gateways. We need to create 2 VNET-to-VNET connections, that is one connection from the first gateway to the second, and another way around.

From the gateway “gw1net1” Settings, Connections, add a new Connection “conn-net1-net3”:

image

Configure it as follows:
- type: VNet-to-VNet
- second gateway: “gw3net3”
- shared PSK key (a string to your choice).

Here is the result:

clip_image015_thumb 

The connection is created, but the status either “Unknown” or  “Not connected” at this stage:

clip_image019_thumb[2]

The connection with its details:

image 
Going to the second gateway, we will see that the connection is also listed here:

clip_image018_thumb[4]

Proceed in the same way to create a connection “conn-net3-net1”, from “gw3net3” to “gw1net1”. After a few seconds (52, to be precise Smile ), we have the result :

clip_image021_thumb[1] 

At this stage, you will see the 2 connections in both “gw1net1” and “gw3net3” settings.

After a few minutes of attempts, you will see the 2 connections passing in “Connected” status:

image

Testing the VPN connection

If you connect remotely to “vm3net3”, from there you will be able to ping the VM “vm1net1”:

clip_image023_thumb[1]

Note the ~25ms response time between the 2 datacenters at a few hundreds kilometers distance, which is a very good performance indeed.

c. Connection Transitivity

There is one last piece missing from the assembly : connectivity between “vnet2dublin” and “vnet3amsterdam”.

Due to the awesome implementation of the Peering feature, this will be solved by 2 clicks configuration only:

1. In the “net1dublin” settings, “net1-net2-peer” peering, under Configuration, check “Allow gateway transit” checkbox:

clip_image024_thumb[1]
(note that the service detects the existence of a VPN gateway in the VNET and predefines the options accordingly)

2. In the “net2dublin” settings, “net2-net1-peer”, under Configuration, check “Use remote gateways” checkbox:

clip_image025_thumb[1]

And that’s it. Really!

Testing the connection transitivity

As you may expect, the ping from “vm2net2” to “vm3net3” will start working:

clip_image026_thumb[1] 

And the same thing in the other way:

clip_image027_thumb[1]

 

Conclusion

We have seen together the essential networking concepts and architectures to be able to implement simple or complex topologies in the Cloud, depending on our needs.

You have seen demonstrated the implementation of a relatively complex VNET-to-VNET-to-VNET topology, within the same Azure region and across regions.

With the switch to the Azure Resource Manager (ARM) deployment model in Azure, the previously existing functionalities in classic model were ported and published in the new Azure portal, but also simplified enormously. The new features like VNET Peering are equally configurable in a simple manner and are integrated seamlessly, permitting the connection transitivity via adjacent VPN gateways, or more advanced scenarios like IP forwarding for the usage of VPN appliances.

Scripting and Automation

As the ARM deployment model is based on ARM templates, you can have the complete solution implemented as ARM template which can be used in automation scenarios.

Here is for conformity a screenshot showing the resource group of the demo implementation:

image

For automating the deployment, you can either develop the ARM template in your preferred tooling (like Visual Studio or VS Code), or export it directly from the portal (from the resource group level).

Please note that as of today not all the resources are exportable as is from the portal; some of them are not yet available. However, you can still go to Resource Explorer (http://resources.azure.com) and extract the template elements from there.

Resources

The “MS Experiences Online” corresponding video (in French, named: “Architecture et topologie Azure multi-VNet”) is available on https://experiences.microsoft.fr/.

A “From-Zero-to-Hero” white-paper on this subject (in French also) is available on Cellenza’s blog.

A demo ARM template of this technical solution is available on GitHub: https://github.com/LeCampusAzure/demo-assets.

CloudBrew.be - December 3, 2016

After Cloud Expo Europe, I will head to Belgium on December 3rd, 2016, for one of the famous conferences in the region, CloudBrew:

image

There, I will speak about “Azure Networking - innovative features and Multi-VNET topologies” :

“Are you looking to deploy a more complex structure of resources in Azure, all secured and segregated by precise boundaries while closely communicating with each other? Following the arrival of the advanced IaaS networking features in Azure (network security groups, routing, multi-NIC,…) and their maturation in the last months, here is the moment for you to find a modern architectural vision of networking in Azure, with focus on multi-VNET / VPN topologies, and based on ARM deployment model”

If it sounds interesting to you, link to http://cloudbrew.be/ and check the organizers’ web site.

Cloud Expo Europe – November 29-30, 2016 !

On November 29th and 30th, at the Exhibition Center Porte de Versailles Paris, will take place the conference Cloud Expo Europe & Data Centre World 2016.

Within this conference I have the honor to be speaker in a session dedicated to Cloud governance and identity : “Gouvernance unifiée et sécurisation de vos ressources Cloud avec Azure Active Directory”. This session will be held on November 30th at 15h, on Hall 6, and will include Q&A on the subject.

If you are interested by these problematics as well as by Microsoft Azure services and Cloud architectures, or if you want to simply meet me, you will be welcomed.

Here is for reference a link to the session, on the organizers’ web site.

Naming of Azure Resources (Part 1)

 

Azure naming conventions

Context

In most demos and tutorials about Azure (and not just that) you will find a variety of resources provisioned in "fast / light" mode, that is to say without being super strict on concepts such as naming artifacts. "WebApp1", "MyVM", "MyRG" are names commonly found in demonstrations or even the "Proof-of-Concepts" (which are supposed to be much more than basic demos).
No particular concern at this point, we're supposed to be focused on the principles and concepts of the demo involved. But what about what about naming Azure artifacts when moving to a real project or an application to put into production? How do we ensure that the names we choose will be well in tune with the architectural complex context, environment, safety, operation of this application, project or system?

Naming in IT projects

First, the notion of strict naming is not specific to Azure; each IT project should follow a set of naming rules, rules that will help to properly structure the project, easily find the terms we already knew before, or even be able to identify resources exposed in lists not always structured. Naming rules are present in each programming language, in each infrastructure provisioning.
That said, there are concepts specific to the cloud (even specific to Azure) which will complement the already existing concepts. We must first catalog the list of naming aspects that is applicable for our organization, our project and our cloud.
Key principles:
Today, who said cloud, said agile mind. The cloud itself (and the public cloud in particular) is agile by his speed provisioning, scaling elasticity, and especially its fast pace of updates and new features. To respect this spirit, rules must accept flexibility. One should not be blocked to deploy a prototyping environment because, for example, the project name has not been clearly defined, or the type of artifact or resource is fresh in the cloud; however, even in this case, we should be able to easily understand afterwards in what context the resource was provisioned (if only for environment deprovisioning to avoid Azure consumption). This article will not try, so, to impose a set of rules as universal, but rather guide you how to define your own set of rules and then apply. That said, we still try to exemplify concretely (and for those who will see the example very close to their cases, apply directly the model in its state). Finally, the last "disclaimer", the dynamic spirit of the Azure will make possible that certain rules or constraints no longer apply (or are different) at the time of reading. In this case, a feedback from you will be very useful for the update of the article.  

What’s a name of an Azure resource?

Let’s start from the base: the name of a resource Azure represents a string which allows unique identification of the Azure resource.
The very general vision of this definition stops here:
  • The name itself can be a simple "code" unique, or may correspond to a "namespace" (ex. Azure Service Bus), an "account name" (ex. Azure Storage), a "hostname" (ex. Azure VM) or other specific significance to the type of resource
  • Unique identification, where? Names can have a context (scope) global public (eg. Based on an Azure subdomain, like the Azure Service Bus namespaces, Azure Storage accounts etc.), local to the subscription (eg. Azure VNET) or local to the parent resource (ex. the names of files or blobs in Azure Blob Storage container)
    • To further complicate the task, some types of resources have naming rules different for different types within the same type (difficult to understand? example: the Azure VMs have stronger constraints - maximum 15 characters - for VMs based on Windows, than on Linux. Historical issue, of course, coming from on-premises infrastructure, but that is reflected in the cloud naming).
  • The characters allowed in names also vary; but we can identify some sets of applicable characters - like below (but not limited to):
    • Alphanumeric (numbers and letters)
    • Alphanumeric plus underscore and dash
    • Alphanumeric plus underscore, dash and dot
    • Any character allowed in a URI
    • Any character
  • The majority of names cannot begin or end with a hyphen or underscore
  • Also, a particular point is the variability of case sensitivity:
    • Case sensitive names (ex. blob names in Azure Storage container)
    • Case insensitive names (eg. resource groups)
    • Mandatory lowercase names (eg. the Azure Storage accounts)
  • Length constraints are widely varying – both on the lower limit and the upper one. Certain names require between 1-64 characters other between 1-80, 2-80, 1-1024 etc.. Very, very variable, therefore, no specific marker on this.
On the whole, unfortunately there isn’t an overall view (regarding Azure, here, but AWS is suffering the same punishment, for that matter) - no overview of consolidated and (more) uniform naming rules for artifacts and resources.
Hence once again the importance of this naming structuring task. It is not unusual that you start with the rules that you consider sufficient (for the types of resources you deal with at that time) and which fall blocking for the naming of the very new resource you need in your project).

Naming constraints for Azure resources

To give you a more accurate and centralized reference for these constraints, here they are (compiled from the Azure documentation and following the requirements outlined in the resources creation process):
Resource or artifact Context (Scope) Min len Max len Case Valid character set
Resource Group Global 1 64 Insensitive Alphanumeric, underscore and hyphen
Availability Set Resource Group 1 80 Insensitive Alphanumeric, underscore and hyphen
Virtual Machine (Windows) Resource Group 1 15 Insensitive Alphanumeric, underscore and hyphen
Virtual Machine (Linux) Resource Group 1 64 Insensitive Alphanumeric, underscore and hyphen
Storage account Global 3 24 Lower cap Alphanumeric
Azure Storage Container Storage account 3 63 Lower cap Alphanumeric and hyphen
Azure Storage Blob Container 1 1024 Sensitive URL characters
Azure Storage Queue Storage account 3 63 Lower cap Alphanumeric and hyphen
Azure Storage Table Storage account 3 63 Insensitive Alphanumeric
Azure Storage File Storage account 3 63 Lower cap Alphanumeric
Virtual Network (VNet) Resource Group 2 64 Insensitive Alphanumeric, underscore, hyphen and point
Network Subnet Parent VNet 2 64 Insensitive Alphanumeric, underscore, hyphen and point
Network Interface Resource Group 1 80 Insensitive Alphanumeric, underscore, hyphen and point
Network Security Group Resource Group 1 80 Insensitive Alphanumeric, underscore, hyphen and point
Network Security Group Rule Resource Group 1 80 Insensitive Alphanumeric, underscore, hyphen and point
Route table Resource Group 1 80 Insensitive Alphanumeric, underscore, hyphen and point
ExpressRoute Circuit Resource Group 1 80 Insensitive Alphanumeric, underscore, hyphen and point
Public IP Address Resource Group 1 80 Insensitive Alphanumeric, underscore, hyphen and point
Load Balancer Resource Group 1 80 Insensitive Alphanumeric, underscore, hyphen and point
Load Balanced Rules Config Load Balancer 1 80 Insensitive Alphanumeric, underscore, hyphen and point
App Service Plan Subscription 2 40 Insensitive Alphanumeric
Web App Global 2 60 Insensitive Alphanumeric and hyphen
Function Global 2 60 Insensitive Alphanumeric and hyphen
Mobile App Global 2 60 Insensitive Alphanumeric and hyphen
Logic App Global 2 60 Insensitive Alphanumeric and hyphen
API App Global 2 60 Insensitive Alphanumeric and hyphen
App Service Environment Global 2 60 Insensitive Alphanumeric and hyphen
App Service Certificate Global 3 15 Insensitive Alphanumeric
API Management Global 1 50 Insensitive Alphanumeric
Notification Hub Subscription 1 260 Insensitive Alphanumeric, underscore, hyphen and point
Notification Hub Namespace Global 2 50 Insensitive Alphanumeric and hyphen
SQL Database Subscription 1 28 Insensitive Alphanumeric, underscore and hyphen
SQL Server Global 1 63 Lower cap Alphanumeric and hyphen
SQL Data Warehouse Database Subscription 1 28 Insensitive Alphanumeric, underscore and hyphen
Document DB Global 3 50 Lower cap Alphanumeric and hyphen
Redis Cache Global 1 63 Insensitive Alphanumeric and hyphen
Search Service Global 2 60 Lower cap Alphanumeric and hyphen
Power BI Workspace Collection Subscription 3 64 Insensitive Alphanumeric and hyphen
Cognitive Services Account Subscription 2 64 Insensitive Alphanumeric, underscore and hyphen
Data Catalog Subscription 2 26 Insensitive Alphanumeric
HDInsight Cluster Global 1 59 Insensitive Alphanumeric and hyphen
Machine Learning Workspace Subscription 3 24 Insensitive Alphanumeric and hyphen
Data Factory Subscription 3 64 Insensitive Alphanumeric and hyphen
Event Hub Subscription 1 50 Insensitive Alphanumeric, underscore and hyphen
Service Bus Namespace Global 6 50 Insensitive Alphanumeric and hyphen
Service Bus Queue Subscription 1 50 Insensitive Alphanumeric, underscore and hyphen
Service Bus Topic Subscription 1 50 Insensitive Alphanumeric, underscore and hyphen
Stream Analytics Job Subscription 3 63 Insensitive Alphanumeric and hyphen
IoT Hub Subscription 3 50 Insensitive Alphanumeric and hyphen
Traffic Manager Global 1 63 Insensitive URL characters
Media Service Account Global 3 24 Lower cap Alphanumeric
CDN Profile Global 1 ? Insensitive Alphanumeric and hyphen
Azure AD Domain Global 1 27 Insensitive Alphanumeric
Azure AD Subscription 1 256 Insensitive Any character
Team Services Account Global 1 50 Insensitive Alphanumeric and hyphen
Team Project Account 1 65 Insensitive Alphanumeric and hyphen
DevTest Labs Subscription 1 27 Insensitive Alphanumeric, underscore, hyphen and parenthesis
Application Insights Subscription 1 255 Insensitive Any except 3 characters
Automation Account Subscription 6 50 Insensitive Alphanumeric and hyphen
Recovery Services Vault Subscription 2 50 Insensitive Alphanumeric and hyphen
Scheduler Job Subscription 1 260 Insensitive Alphanumeric, underscore and hyphen
Scheduler Job Collection Subscription 1 100 Insensitive Alphanumeric, underscore and hyphen
Cloud Service Global 1 63 Insensitive Alphanumeric and hyphen
Batch Account Global 3 24 Lower cap Alphanumeric
BizTalk Service Global 6 20 Lower cap Alphanumeric
Mobile Engagement Collection Global 2 50 Insensitive Alphanumeric and hyphen
Mobile Engagement App Resource Global 1 50 Insensitive Alphanumeric, underscore and hyphen
Mobile Engagement Application Subscription 1 ? Insensitive Any character
RemoteApp Collection Subscription 3 13 Insensitive Alphanumeric
Key Vault Global ? ? Insensitive Alphanumeric and hyphen
Operations Mgmt Suite Namespace Global 4 24 Insensitive Alphanumeric and hyphen
Tag Name Resource 1 512 Insensitive Alphanumeric
Tag Value Resource 1 256 Insensitive Alphanumeric

Follow-up

This first article about the naming of Azure resources and artifacts will be followed soon by other items, which will include details of the aspects or particles included in the names, reference charts of particles, composition rules and the good practices. Note: you will find the French version of this article at: http://blog.cellenza.com/cloud-2/azure/partie-1-nommage-ressources-azure/.







Azure App Service Environment – error on creating a new Web App

When creating a new Web App hosted inside an App Service Environment (ASE) via an ARM template, you may encounter the following error:

"Resource Microsoft.Web/sites 'yourapplication-web01' failed with message 'Server farm with name yourappserviceplan not found.' ". Here is the reference line in the template: "serverFarmId": "/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/resourceGroups/yourresourceid/providers/Microsoft.Web/serverfarms/ yourappserviceplan".

(where: yourapplication-web01 = the name of your web app,  yourresourceid = the name of your resource group, yourappserviceplan = the name of your app service hosting plan)

This error comes usually from an insufficient information in the ARM template you are trying to deploy. If in a Web App deployment outside ASE it is enough to reference the hosting plan which hosts the application, within an ASE you need to specify also the information for referencing the ASE environment which includes the hosting plan:

[template segment for the web app definition]

  {

      "apiVersion": "2015-08-01",
      "name": "[parameters('siteName')]",
      "type": "Microsoft.Web/sites",
      "location": "[parameters('location')]",
      "tags": {
        "displayName": "[parameters('siteName')]"
      },
      "properties": {
        "name": "[parameters('siteName')]",
        "hostingEnvironment": "[parameters('environmentName')]",
        "hostingEnvironmentId": "[resourceId('Microsoft.Web/hostingEnvironments', parameters('environmentName'))]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('hostingPlanName'))]"
      }
    }

So for the parametering aspect, you will need to include the hosting plan name ('hostingPlanName') as well as the ASE name ('environmentName').

Note: if the web site will be deployed in a different resource group, then you will need to qualify the resource references with their resource group name:
"serverFarmId": "[resourceId(parameters('hostingPlanResourceGroupName'), 'Microsoft.Web/serverfarms', parameters('hostingPlanName'))]"

That’s all. Have a good deployment!



Connect() 2015

L'événement Connect() se tiendra du 18 au 19 Novembre à New York MVP. L'événement est surtout axé sur les outils de développement, mais couvrira également le contenu sur Microsoft Azure, le développement de bureau et autres. Scott Guthrie sera prononcera le discours et il est rejoint par une gamme d'orateurs passionnants. L'événement sur le site est sur invitation seulement, mais l'événement sera la diffusion en direct de New York pour les développeurs du monde entier.
• Vous pouvez participer à cet événement virtuel, il suffit de cliquer 'Save the Date': http://connect2015.visualstudio.com/
• Vous pouvez suivre l'événement à travers vos canaux de médias sociaux, Twitter en utilisant le hashtag ‪#‎connect2015‬
• Vous pouvez également suivre directement ci-dessous l'évènement:


P-SELLER : sur scène à WPC 2015



Plus besoin de détailler qu'est-ce que WPC, sauf éventuellement l'acronyme lui même : Microsoft Worldwide Partner Conference - 2015 (Orlando, FL).
J'ai l'honneur d'y représenter la France et mon entreprise, Econocom, en tant que speaker partenaire dans la session: CA04 : Accelerating Growth in Corporate Accounts . Session très intéressante focalisée sur le rôle du programme P-SELLER dans le partenariat Microsoft. Je vous invite d'y participer si vous êtes à WPC, je parlerai de mon expérience dans le programme, mais aussi des modalités et astuces de gagner en tant que partenaire dans le business Azure. Je vous attends !

Global Azure Bootcamp Paris 2015


Samedi prochain, 25 avril 2015, comme chaque année dans cette période, il y aura Global Azure Bootcamp, événement ayant rassemblé à travers le monde et le même jour 7432 personnes, 154 Speakers, 96 villes, 194 sessions techniques et 74 MVP.
En France, l'évènement se tiendra à la fois à Paris et Lyon. Pour Paris - où vous pourrez me rencontrer - vous trouverez les informations logistiques ici.

QUEL PROGRAMME ?

Des sessions techniques sur Azure se tiendront toute la journée.
Des environnements de laboratoires Microsoft Azure seront mis en place ad-hoc. Les experts seront à vos côtés pour vous apporter le support nécessaire à votre initiation dans le Cloud ou, au contraire, pour donner vie à vos expériences techniques les plus folles sur la plateforme Azure.

Agenda du jour :
Track 1
Track 2
9H
Accueil
9H30
Keynote
10H35
Nouveautés sur le stockage de données dans Azure
Atelier : Science Lab Azure Bootcamp
11H25
Concevoir une architecture distribuée avec Azure WebJobs
12H10
Déjeuner
13H10
Azure IoT
Atelier : Machine Learning
14H00
Pourquoi le Cloud Azure pour votre stratégie eCommerce et digitale ?
15H10
Premiers pas avec Azure Search
Atelier : Racing Lab
16H00
Automati(sati)on de votre application Azure
16H50
Clôture
 

 Voici la session que je présenterai ensemble mon collègue Maxime Launay:
Automati(sati)on de votre application Azure. Passage sur les solutions d'automatisation des processus Azure. Moment pour discuter, bien sûr, d'Azure Automation, mais aussi  PowerShell DSC. D'autres surprises à venir.

Venez nombreux !