Merge pull request #30277 from iainfoulds/windowsguidelinesfreshness

Windows VM guidelines freshness

articles/virtual-machines/virtual-machines-windows-infrastructure-availability-sets-guidelines.md

@@ -14,7 +14,7 @@
 	ms.tgt_pltfrm="vm-windows"
 	ms.devlang="na"
 	ms.topic="article"
-	ms.date="06/30/2016"
+	ms.date="09/08/2016"
 	ms.author="iainfou"/>
 
 # Availability sets guidelines
@@ -33,17 +33,17 @@ Tasks:
 
 - Define the number of VMs in each application tier you require.
 - Determine if you need to adjust the number of fault or update domains to be used for your application.
-- Define the required availability sets using your naming convention and what VMs will reside in them. A VM can only reside in one availability set. 
+- Define the required availability sets using your naming convention and what VMs reside in them. A VM can only reside in one availability set. 
 
 ## Availability sets
 
-In Azure, virtual machines (VMs) can be placed in to a logical grouping called an availability set. When you create VMs within an availability set, the Azure platform will distribute the placement of those VMs across the underlying infrastructure. Should there be a planned maintenance event to the Azure platform or an underlying hardware / infrastructure fault, the use of availability sets would ensure that at least one VM remains running.
+In Azure, virtual machines (VMs) can be placed in to a logical grouping called an availability set. When you create VMs within an availability set, the Azure platform distributes the placement of those VMs across the underlying infrastructure. Should there be a planned maintenance event to the Azure platform or an underlying hardware / infrastructure fault, the use of availability sets ensures that at least one VM remains running.
 
-As a best practice, applications should not reside on a single VM. An availability set that contains a single VM doesn't gain any protection from planned or unplanned events within the Azure platform. The [Azure SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines) requires two or more VMs within an availability set in order to allow the distribution of VMs across the underlying infrastructure.
+As a best practice, applications should not reside on a single VM. An availability set that contains a single VM doesn't gain any protection from planned or unplanned events within the Azure platform. The [Azure SLA](https://azure.microsoft.com/support/legal/sla/virtual-machines) requires two or more VMs within an availability set to allow the distribution of VMs across the underlying infrastructure.
 
-The underlying infrastructure in Azure is divided in to update domains and fault domains. These domains are defined by what hosts will share a common update cycle, or share similar physical infrastructure such as power and networking. Azure will automatically distribute your VMs within an availability set across domains to maintain availability and fault tolerance. Depending on the size of your application and the number of VMs within an availability set, you can adjust the number of domains you wish to use. You can read more about [managing availability and use of update and fault domains](virtual-machines-windows-manage-availability.md).
+The underlying infrastructure in Azure is divided in to update domains and fault domains. These domains are defined by what hosts share a common update cycle, or share similar physical infrastructure such as power and networking. Azure automatically distributes your VMs within an availability set across domains to maintain availability and fault tolerance. Depending on the size of your application and the number of VMs within an availability set, you can adjust the number of domains you wish to use. You can read more about [managing availability and use of update and fault domains](virtual-machines-windows-manage-availability.md).
 
-When designing your application infrastructure, you should also plan out the application tiers that you will use. Group together VMs that serve the same purpose in to availability sets, such as an availability set for your front-end VMs running IIS. Create a separate availability set for your back-end VMs running SQL Server. The goal is to ensure that each component of your application is protected by an availability set and at least once instance will always remain running.
+When designing your application infrastructure, you should also plan the application tiers that you use. Group VMs that serve the same purpose in to availability sets, such as an availability set for your front-end VMs running IIS. Create a separate availability set for your back-end VMs running SQL Server. The goal is to ensure that each component of your application is protected by an availability set and at least once instance always remains running.
 
 Load balancers can be utilized in front of each application tier to work alongside an availability set and ensure traffic can always be routed to a running instance. Without a load balancer, your VMs may continue running throughout planned and unplanned maintenance events, but your end users may not be able to resolve them if the primary VM is unavailable.
 

articles/virtual-machines/virtual-machines-windows-infrastructure-example.md

@@ -14,14 +14,14 @@
 	ms.tgt_pltfrm="vm-windows"
 	ms.devlang="na"
 	ms.topic="article"
-	ms.date="07/01/2016"
+	ms.date="09/08/2016"
 	ms.author="iainfou"/>
 
 # Example Azure infrastructure walkthrough
 
 [AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-intro](../../includes/virtual-machines-windows-infrastructure-guidelines-intro.md)] 
 
-This article walks through building out an example application infrastructure. We'll detail designing an infrastructure for a simple on-line store that brings together all of the guidelines and decisions around naming conventions, availability sets, virtual networks and load balancers, and actually deploying your virtual machines (VMs).
+This article walks through building out an example application infrastructure. We detail designing an infrastructure for a simple on-line store that brings together all the guidelines and decisions around naming conventions, availability sets, virtual networks and load balancers, and actually deploying your virtual machines (VMs).
 
 
 ## Example workload
@@ -32,13 +32,13 @@ Adventure Works Cycles wants to build an on-line store application in Azure that
 - Two IIS servers processing data and orders in an application tier
 - Two Microsoft SQL Server instances with AlwaysOn availability groups (two SQL Servers and a majority node witness) for storing product data and orders in a database tier
 - Two Active Directory domain controllers for customer accounts and suppliers in an authentication tier
-- All of the servers are located in two subnets:
-	- a front end subnet for the web servers 
-	- a back end subnet for the application servers, SQL cluster, and domain controllers
+- All the servers are located in two subnets:
+	- a front-end subnet for the web servers 
+	- a back-end subnet for the application servers, SQL cluster, and domain controllers
 
 ![Diagram of different tiers for application infrastructure](./media/virtual-machines-common-infrastructure-service-guidelines/example-tiers.png)
 
-Incoming secure web traffic needs to be load-balanced among the web servers as customers browse the on-line store. Order processing traffic in the form of HTTP requests from the web servers needs to be balanced among the application servers. Additionally, the infrastructure must be designed for high availability.
+Incoming secure web traffic must be load-balanced among the web servers as customers browse the on-line store. Order processing traffic in the form of HTTP requests from the web servers must be balanced among the application servers. Additionally, the infrastructure must be designed for high availability.
 
 The resulting design must incorporate:
 
@@ -49,12 +49,12 @@ The resulting design must incorporate:
 - Availability sets for the VMs with a similar role
 - Virtual machines
 
-All of the above will follow these naming conventions:
+All the above follow these naming conventions:
 
 - Adventure Works Cycles uses **[IT workload]-[location]-[Azure resource]** as a prefix
 	- For this example, "**azos**" (Azure On-line Store) is the IT workload name and "**use**" (East US 2) is the location
 - Storage accounts use adventureazosusesa**[description]**
-	- Note that 'adventure' was added to the prefix to provide uniqueness, and storage account names do not support the use of hyphens.
+	- 'adventure' was added to the prefix to provide uniqueness, and storage account names do not support the use of hyphens.
 - Virtual networks use AZOS-USE-VN**[number]**
 - Availability sets use azos-use-as-**[role]**
 - Virtual machine names use azos-use-vm-**[vmname]**

articles/virtual-machines/virtual-machines-windows-infrastructure-naming-guidelines.md

@@ -14,14 +14,14 @@
 	ms.tgt_pltfrm="vm-windows"
 	ms.devlang="na"
 	ms.topic="article"
-	ms.date="06/30/2016"
+	ms.date="09/08/2016"
 	ms.author="iainfou"/>
 
 # Infrastructure naming guidelines
 
 [AZURE.INCLUDE [virtual-machines-windows-infrastructure-guidelines-intro](../../includes/virtual-machines-windows-infrastructure-guidelines-intro.md)] 
 
-This article focuses on understanding how to approach naming conventions for all your various Azure resources in order to build a logical and easily identifiable set of resources across your environment.
+This article focuses on understanding how to approach naming conventions for all your various Azure resources to build a logical and easily identifiable set of resources across your environment.
 
 ## Implementation guidelines for naming conventions
 
@@ -31,7 +31,7 @@ Decisions:
 
 Tasks:
 
-- Define the affixes that you will use across your resources to maintain consistency.
+- Define the affixes to use across your resources to maintain consistency.
 - Define storage account names given the requirement for them to be globally unique.
 - Document the naming convention to be used and distribute to all parties involved to ensure consistency across deployments.
 
@@ -41,11 +41,11 @@ You should have a good naming convention in place before creating anything in Az
 
 You might choose to follow a specific set of naming conventions defined for your entire organization or for a specific Azure subscription or account. Although it is easy for individuals within organizations to establish implicit rules when working with Azure resources, when a team needs to work on a project on Azure, that model does not scale well.
 
-You should agree on a set of naming conventions up front. There are some considerations regarding naming conventions that cut across that sets of rules.
+Agree on a set of naming conventions up front. There are some considerations regarding naming conventions that cut across that sets of rules.
 
 ## Affixes
 
-As you look to define a naming convention, one decision comes as to whether the affix will be at:
+As you look to define a naming convention, one decision comes as to whether the affix is at:
 
 - The beginning of the name (prefix)
 - The end of the name (suffix)
@@ -70,11 +70,11 @@ When establishing your naming conventions, make sure that they clearly state whi
 
 ## Dates
 
-It is often important to determine the date of creation from the name of a resource. We recommend the YYYYMMDD date format. This format ensures that not only the full date is recorded, but also that two resources whose names differ only on the date will be sorted alphabetically and chronologically at the same time.
+It is often important to determine the date of creation from the name of a resource. We recommend the YYYYMMDD date format. This format ensures that not only the full date is recorded, but also that two resources whose names differ only on the date is sorted alphabetically and chronologically at the same time.
 
 ## Naming resources
 
-You should define each type of resource in the naming convention, which should have rules that define how to assign names to each resource that is created. These rules should apply to all types of resources, for example:
+Define each type of resource in the naming convention, which should have rules that define how to assign names to each resource that is created. These rules should apply to all types of resources, for example:
 
 - Subscriptions
 - Accounts
@@ -96,11 +96,11 @@ When you create a virtual machine (VM), Microsoft Azure requires a VM name of up
 
 In case a VM is created from a .vhd image file that already contains an operating system, the VM name in Azure can differ from the VM's operating system computer name. This situation can add a degree of difficulty to VM management, which we therefore do not recommend. Assign the Azure VM resource the same name as the computer name that you assign to the operating system of that VM.
 
-We recommend that the Azure VM name be the same as the underlying operating system computer name.
+We recommend that the Azure VM name is the same as the underlying operating system computer name.
 
 ## Storage account names
 
-Storage accounts have special rules governing their names. You can only use lowercase letters and numbers. See [Create a storage account](../storage/storage-create-storage-account.md#create-a-storage-account) for more information. Additionally, the storage account name, in combination with core.windows.net, should be a globally valid, unique DNS name. For instance, if the storage account is called mystorageaccount, the following resulting DNS names should be unique:
+Storage accounts have special rules governing their names. You can only use lowercase letters and numbers. See [Create a storage account](../storage/storage-create-storage-account.md#create-a-storage-account) for more information. Additionally, the storage account name, along with core.windows.net, should be a globally valid, unique DNS name. For instance, if the storage account is called mystorageaccount, the following resulting DNS names should be unique:
 
 - mystorageaccount.blob.core.windows.net
 - mystorageaccount.table.core.windows.net