Azure

Drinking our own VDI champagne.

So my laptop packed up over the weekend, and that gave me the opportunity to actually walk the walk rather than just talking about Windows Virtual Desktop and Azure, actually drinking our own champagne.
Hence for the last couple of days I have been using my own Windows 10 VDI that is in Azure delivered via Windows Virtual Desktop, and in fact I am writing this post form that very Virtual Machine.

So first off I have an Azure subscription - in to that subscription I have provisioned a Windows Virtual Desktop hostpool (see the document links at the end for deployment guidance).

A hostpool is a collection of similar VM's hosting a set desktop or set of applications for the in scope group of users.

In my case to make my demo's slightly less boring I have chosen an N-Series VM from Azure which have Tesla M60 GPU cards within the hosts. This allows me to run some graphical applications that look interesting rather that standard apps. It also demonstrates the power and flexibility of Azure as even the largest VM in Azure takes around five minutes to deploy and users can thus be up running and productive in significantly reduced amounts of time compared to doing this on-premises.

To make things slightly more interesting I was using a Samsung Galaxy S10e mobile phone running Samsung Dex. DeX allows you to connect your mobile phone via an HDMI cable to a monitor or TV, and launch a full desktop like experience. In that desktop you can launch any apps that run on the phone which is great of itself.

However the real power comes about when you connect to your VDI session running in Azure. The Samsung DeX supports both the Microsoft Remote Desktop Client and Citrix Workspace. I have my VM running in Windows Virtual Desktop in Azure, I also have a number of other VM's in Azure being orchestrated by Citrix Cloud that I could equally, easily connect to. So in essence I am using a device that I always have with me no matter where I am and at anytime - as a thin client allowing me to connect into my corporate VDI session to use my line of business apps and data.

Once on the VDI the user experience is very good, with no noticeable delay and as I am typing this blog there has been no pauses or delays to every character appearing as i type them. The actual experience is indistinguishable from having a full local device. This is particularly impressive seeing as I am located in the UK and I am accessing my VM that is located in our South Central US Azure region which is nearly 5000 miles away.

Now if you have worked in this space you may well remember two other devices that did the same thing - definitely in the past tense! The first was the Motorola Atrix, which required a dock to place the phone into and also connect cables to for the monitor, keyboard and mouse. Whilst it was pretty small it was still too clunky to carry around. This meant that the dock was left on the desk. This in turn meant that whilst the mobile phone was a mobile device - accessing your VDI from that device required you to be back at your desk, which worked fine but tied you to that desk, so you weren't able to be fully mobile and productive.

Following later Microsoft released a device called Continuum which was an improvement on the Atrix but still suffered the same issue of people not wanting to carry the hardware device around with them.

Whereas the Samsung Dex requirement is just one HDMI cable, which is about the same size as a power cable and thus no problem to put in a bag and carry around. This means that you can be fully mobile and able to connect into your VDI session anywhere at any time - you just need to have a monitor or TV available.
Now you do also need a Bluetooth keyboard and mouse, but i'm sure everyone who carries a laptop also carries a Bluetooth mouse, and it takes all of about 20 seconds to connect a mouse to the phone, so people could quite easily carry the one mouse and connect to their phone when needed. Plus you need a Bluetooth keyboard of which their is a plethora of them about. But in terms of size Microsoft have a Universal folding keyboard that is so small anyone can chuck it into their work bag.

What this results in, is that all I need to carry around is the phone that I would have with me anyway, a mouse that I always have in my bag, an additional cable which is nothing and this small keyboard. My bag doesn't notice the difference.

Which when in use looks like:


The other item that is worth noting is the price. In my case I picked an N-Series VM which is one of the more expensive VM's due to the nVidia Tesla M60 GPU within the host.
The specific VM is an NV6 in the South Central US Azure region. The NV6 VM has six vcpu's, 56GB of RAM and the one M60 GPU.

With three years Reserved Instances and Azure Hybrid Use Benefits applied the VM costs £0.4523 per hour to run. But this VM should support up to 36 "light" users, which gives a price per user per hour of just £0.013p. 

As mentioned the N-Series are quite bespoke for specific workloads and probably not all that common in VDI environments. The D series VM's are better for this workload. The generally recommended VM for multi-session Windows 10 VM's is the D8s_V3. This VM has 8 vcpu's and 32 GB of RAM and again with three years Reserved Instances and Azure Hybrid Use Benefits applied the VM costs £0.1346/hour in the South Central US Region. This VM supports 48 "light" users which gives a price per user per hour of just £0.0028.

Pricing for these is listed here in the context of Windows Virtual Desktop providing typical scenarios: https://azure.microsoft.com/en-us/pricing/details/virtual-desktop/


I created a little video of this whole user experience.



To get started in the Windows Virtual Desktop preview you can follow this documentation:  https://docs.microsoft.com/en-us/azure/virtual-desktop/overview

Windows Virtual Desktop pre-requisites - everything in the right place to enable you to deploy without errors

Windows Virtual Desktop is a newly announced service for managing VDI and RDSH as a service from Azure. It went into public preview in March of 2019, with many successful deployments for testing having been completed. However we have seen a large number of failures of the Azure Resource Manager deployment from a set of customers, all for very similar quite simple errors entered into the Azure portal deployment.

Hence this guide is just to clearly explain what prerequisites are required to be in place and where to get the relevant information and then where to exactly put these details into the Windows Virtual Desktop HostPool creation process in the Azure portal. This is to ensure the deployment process will complete successfully. This is not a full deployment guide, there is already existing full deployment instructions available.

This guide will enable to collect all the relevant pieces of information and have them all in one place that you can then put back into the Azure portal at deployment time. In this guide you will either create and record or just record the information needed in the WVD deployment process and keep it in one place in Notepad to use later in the full deployment.

Use this in conjunction with the existing deployment guide from Microsoft docs.

From a high level you will require the following items before you can deploy Windows Virtual Desktop
  1. An Azure Active Directory
  2. An Active Directory
  3. Azure Active Directory Connect
  4. An Azure Virtual Network updated with your DNS server(s)
  5. An Azure subscription and its associated ID.
  6. A Windows Virtual Desktop tenant
Why do you need this?
  1. The Azure Active Directory is your identity provider in the cloud and users authenticate against AAD to get access to the Windows Virtual Desktop service
  2. When launching published Desktops and Applications - Windows still requires Active Directory authentication.
  3. Azure AD Connect is the tool that will provision accounts from AD to AAD to enable 1. above.
  4. The Virtual Machines all need to be located on a Virtual Network. That vNet needs access to Active Directory, that can either be located in Azure or on-premises as long as there is connectivity. When Azure deploys new VM's it will join these VM's to your Active Directory domain and as such the VM's need to located the Domain Controller via DNS, without this DNS server setting by set the VM's have no name resolution for the local AD.
The high level deployment process for a WVD hostpool and why you need these pre-requisites already in place is to automate all of the following actions:
  • Deploy a Virtual Machine (or multiples)
  • Join the Virtual Machine to your Active Directory
  • Install the local WVD Client agents and join to the WVD hostpool specified 
  • Publish the default published desktop to the user specified.

1. So lets get item 1 - your Azure Active Directory Tenant ID.

If you don't already have an AAD then you will need to create one. To do so follow this guide: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-access-create-new-tenant

If you do have an AAD then we just need to copy the Azure Active Directory Tenant ID. To do this open the Azure Portal. On the left click on All Services

Either go down to the Identity section and select Azure Active Directory

Alternatively in the Search field in the All Services section at the top of the blade start typing        Azure Active Directory and the resulting list of services will reduce displaying AAD.

Once you have the AAD blade open, on the left go down to Properties and then on the right look for the Directory ID Field

Click on the copy button at the right of this field

Now open Notepad and paste this in as Item 1.

Whilst you are in AAD create an admin account that will be used as the Windows Virtual Desktop admin account. Go back to the top on the left and Click on Users and click on + New User and create an account such as wvdadmin@contoso.onmicrosoft.com.

Copy this user ID into your Notepad file as Item 1.1

Notepad should look like this:
1. abc4-5a45-4533-8ab4-8991abc98abc
1.1 wvdadmin@contoso.onmicrosoft.com

2. Onto Item 2 - your Active Directory

If you don't have AD already, the easiest way to deploy Active Directory in Azure is to use this Azure Resource Manager template: https://azure.microsoft.com/en-us/resources/templates/active-directory-new-domain/

Or alternatively deploy it manually on a Virtual Machine. Record the IP Address of your Domain Controller VM

Once you have Active Directory deployed create an admin account that you can use in the WVD deployment process to automatically join the host pool VM's that get created to this AD i.e. "domainjoin@contoso.com"

Go back to Notepad and enter your AD domain UPN for this user account in full as Item 2

You will also need an account in AD to test as a user logging into and launching an app from Windows Virtual Desktop. Create a user account in AD i.e. test1@contoso.com. 
In section 3. below we deploy AAD Connect which will sync this account with AAD where it will in addition have the full UPN of  test1@contoso.onmicrosoft.com.
Enter this account in Notepad as Item 2.1

Notepad should like this now:
1. abc4-5a45-4533-8ab4-8991abc98abc
1.1 wvdadmin@contoso.onmicrosoft.com
2. domainjoin@contoso.com
2.1 test1@contoso.onmicrosoft.com

3. Now we need to deploy Azure Active Directory Connect to provision your AD users up into AAD.


During the install you will need an AAD global admin account and an AD admin account. For simplicity you can use Items 1.1 and 2.1 from your Notepad file.

Once completed AAD connect will provision your test account up into AAD, which we can later use for testing.

4. Now we need to update your Virtual Network with the IP address(es) of your AD domain controllers so that when new VM's are placed on this vNet they and are joined to your domain they can access the Domain Controller using DNS for local name resolution.

In the Azure portal go the Virtual Network that your domain controller was deployed onto. In the Settings section click on DNS Servers and enter the IP Address of your domain controller and click on Save above:


5. Finally lets grab your Azure Subscription ID.
Back in the Azure subscription open the Subscriptions blade:

Click on the subscription you want to deploy your hostpools into. Then in the Overview section copy the Subscription ID

Paste this into your Notepad file as Item 3

Now your Notepad file should look like this:
1. abc4-5a45-4533-8ab4-8991abc98abc
1.1. wvdadmin@contoso.onmicrosoft.com
2. domainjoin@contoso.com
2.1. test1@contoso.onmicrosoft.com
3. 12345a125-1234-12a1-123af-123456abc123

If it does you have all the information you need and so you are now ready to follow the rather good Windows Virtual Desktop deployment documentation starting in the link below. Open this document and have these two documents open in to tabs side by side

If you follow the above guide accurately you will successfully deploy your first WVD hostpool. Below are the steps where you need to paste in the information from your Notepad file in to the relevant steps in the process stated in the guide above, follow both guides step by step.

1. In this document you are asked to provide consent for WVD to use your AAD. 
From your Notepad file paste Item 1 into the "AAD Tenant GUID or name" field:



In the next section "Assign the TenantCreator application role to a user in your Azure Active Directory tenant" section you can use the user account in section 1.1 from Notepad.

In the next section "Create a Windows Virtual Desktop Preview tenant" section in the second PowerShell command: 

New-RdsTenant -Name <TenantName> -AadTenantId <DirectoryID> -AzureSubscriptionId <SubscriptionID>

Replace <DirectoryID> with item 1. from Notepad and <SubscriptionID> with item 3, i.e.

New-RdsTenant -Name <TenantName> -AadTenantId abc4-5a45-4533-8ab4-8991abc98abc -AzureSubscriptionId 12345a125-1234-12a1-123af-123456abc123

The resulting Powershell output will conform the tenant name that has been created. Copy this in to item 4. in Notepad file - which should now look like:

1. abc4-5a45-4533-8ab4-8991abc98abc
1.1 wvdadmin@contoso.onmicrosoft.com
2. domainjoin@contoso.com
2.1 test1@contoso.onmicrosoft.com
3. 12345a125-1234-12a1-123af-123456abc123
4. YourTenantName


2. In the second stage: "Tutorial: Create a host pool with Azure Marketplace" which deploys the hostpool from within the Azure portal you will need to enter the remaining parts from Notepad. You are directed to the Azure portal and will deploy a Windows Virtual Desktop Host pool.

In the 1st section enter your test user UPN

In the first "Basics" section within "Default desktop users" enter item 2.1 from Notepad:
In the third "VM Settings" section enter your:
  • AD admin account to do the VM domain join which is item 2. from your Notepad file.
  • As well as entering the vNet that your AD domain controller is on that has the DNS server set correctly providing name resolution for the VM's to then locate the Domain Controller to complete the domain join.






In the 4th "Windows Virtual Desktop" information section enter your:
  • "Windows Virtual Tenant Name" - which is item 4 in your Notepad File
  • "Windows Virtual Desktop Tenant RDS owner UPN" - which is item 1 in your Notepad file



Finish the remaining screens and the instructions from the main deployment guide and your WVD hostpool deployment will commence and if you have followed this pre-guide correctly will successfully complete.
The main guide will have the steps to test user access.

 How to deploy Citrix XenApp Essentials on Azure

Citrix have recently released a new edition to the XenApp family called XenApp Essentials.
But what is the new flavour of XenApp and why has it been created?

So, a brief history lesson.
Microsoft have had for a number of years an Azure services called Azure RemoteApp. This was essentially Remote Desktop Services "as a service" from the the Azure cloud.
It was cost effective, simple to deploy and had many of the great capabilities that only the cloud provides, such as auto scaling, usage based pricing, etc.

It allowed organisations to publish applications (no desktops) directly to the users, without the need to manage an estate of virtual machines, and the need to build these out to meet the peak user load.
However, on the 31st of August 2017 this product will be switched off. In fact this will be the first ever Azure product to be switched off. The reason it is being switched off is because there simply are not enough users on the service, and the reason there are not enough users on the service is the same reason that enterprise haven't historically used RDS on its own in their on-premises app delivery and virtual desktop estates. These enterprises have been willing to pay Citrix for the additional management capabilities and access to the many tools that they have developed over the last 25 years of extending upon RDS.

So where did that leave this capability and the existing RemoteApp users. Well Microsoft approached Citrix and asked if they could produce a replacement for RemoteApp. Citrix as such produced XenApp Express subsequently renamed to Essentials.

This "Essential" moniker is there to represent only the fact that it is the Essential services of XenApp, because the edition has been designed to replace not another edition of XenApp but rather RemoteApp which itself was a simple solution. Hence Citrix have simplified XenApp Essentials by removing some of the more advanced capabilities to try to draw it closer to what RemoteApp was.
For example, it only allows application publishing - no desktops which is what RemoteApp provided, there are a limited amount of Policies, RemoteApp had none.


So essentially, Essentials is marketed as the RemoteApp replacement, plus SME's or greenfield projects inside larger organisations. For enterprises, they may well be better of choosing one of the other higher editions of Citrix cloud running on Azure.

So then how to you deploy this?
At the top level, there are only two requirements. 1. An Azure Subscription and 2. a Citrix Cloud account.
This guide assumes you have an Azure subscription. If you don't have one - go and get one now.
What is the Citrix Cloud, well it’s not a public cloud in the same sense that Azure is. Rather this is Citrix "cloudifying" their management service, plus Netscaler and Storefront. It provides Studio and Director as a service via a browser and optional use of Netscaler and StoreFront as a service.


Hence, the second requirement is a Citrix Cloud account. As the name suggests this is just an account in the Citrix Cloud. You then have services enabled for that account that can then be consumed by your organisation.
Easiest way to create a Citrix Cloud Account is by completing the form at https://onboarding.cloud.com/ where you can also optionally register for a trial of the full Citrix Cloud suite.
Or if you are a RemoteApp user you can register for a XenApp Essentials trial here: https://www.citrix.com/products/citrix-cloud/form/xenapp-essentials-trial/


So now to deploying XenApp Essentials.
This depends on what Citrix Cloud enablement you have. If you have specifically requested a XenApp Essentials trial account as per the second option above - you don't actually have to deploy the XenApp Essentials product in Azure, as per section 1 below, you can move to section 2. You will already have this enablement in your Citrix Cloud account and all you need to deploy are your Azure infrastructure.


If, however you have a Citrix Cloud account without XenApp Essentials then you will need to deploy XenApp Essentials from the Azure marketplace, so you will need to complete both sections 1 and 2.

Section 1 - Deploying XenApp Essentials via the Azure Marketplace.

Step 1:  Go to the Azure Portal and Click on New



Step 2: Type Citrix…. And Select Citrix XenApp Essentials


Step 3: Then Select Citrix XenApp Essentials

Then the Create button on the next Blade
Step 4: In the resulting blade, start by providing a name for the Resource itself, chose the Azure Subscription you would like place this resource, then either Create a new Resource Group, or use an existing one, and chose an Azure region to locate it:
Step 5: 

Now you will need to connect this resource back to your Citrix Cloud Account.Click on the Connect button




Step 6: This will bring up another browser for you to enter your Citrix Cloud credentials




Step 7: If there is an existing Citrix Cloud account this will return and show you the name of the customer when you created your Citrix Cloud Account



Then you just need to select the number of users you want with a minimum of 25, and any additional Data Transfer. 
Then just click on Create

Step 8:  This will take a couple of hours to complete. You can see the progress by looking at the overview of this resource and look at the Status, you will be ready to proceed when the status changes to “Ready”.

Step 9: This doesn’t actually deploy anything at this point, it just sets up the billing and related services in the Citrix backend.
As this takes some time to complete, it’s worth doing two things in the interim.
1.  View the Citrix Cloud. Click on “Manage through Citrix Cloud”. This will take you directly to your Citrix Cloud Account which if you are just enabled for XenApp Essentials will look like this:



This look is unique just for XenApp Essentials, as it is designed to be as simple as Azure RemoteApp was. All the other editions will have a different albeit similar appearance. All the other editions will show you the standard Studio console, whilst the XenApp Essentials is a very simple point and click user interface.
We will come back here to configure our catalogues.
You can achieve the same directly by thing by logging into citrix.cloud.com

2.  Start considering your core Azure services that you need, such as VM size, Storage Accounts, and storage type, connectivity, generally the recommendation is to use ExpressRoute for enterprise grade connectivity.

You will need to have a Virtual Network available with at least one subnet when you come to deploy a catalogue later. This virtual network will need to have DNS configured using the Custom option to add the IP address(es) of your DNS server(s) in its options to enable the deployment of the master images to work correctly as they need to reach your domain controllers in order to join your domain.


Section 2 - Deploying Workloads into your Azure Subscription

Step 10:  Once the status is Ready you are well, ready to go. Its worthwhile reading the information here, and once you’re ready you can click on I’m ready to start!


The first thing we will do is create a new Catalog




Step 11: Give the Catalog a name and Save it.




Step 12: Now link this to your Azure Subscription. Click on the Subscription Name Drop Down and click on Link an Azure subscription.






Click on Sign in





Step 13: You will be redirected to the Azure Sign in page, note it will have "XenApp Essentials" at the top of the page. Log in with the Azure credentials for the subscription you will use to host your VDA’s.


Then Click on Accept to allow XenApp Essentials to have permissions to the Subscription.



Step 14: You will be returned to your Citrix Cloud configuration. If you have more than one Azure subscription this will list them all. Select the one(s) you would like to use.


Now ensure the Subscription is selected, then choose a Resource Group to deploy into, then select a Virtual Network and Subnet that you will have needed to have created previously.





Click on Save

Step 15: Enter the details of the domain you want these VM’s to join, and click on Save



Step 16: Now you need to link to a master image that includes your apps for this catalogue. You have three choices:
1. Select an existing image – Use this if you already have a custom image.
2. Import a new image - this will require you to have uploaded your VHD to an Azure Storage account.
3. Use a Citrix prepared image – this is for demo purposes as it is a Citrix prepared image.
For this we will use option three to demonstrate how it works.
Click on Use a Citrix Prepared Image, and select an image name, then click on Save



Step 17: Now select the disk type, the capacity on the VM’s that get deployed, and scaling settings.
You can choose Standard Disks which are magnetic disks or for better performance, premium disks which are SSD backed. Then you can select the user load expected per VM, by selecting a preconfigured value or by selecting your own custom value, in accordance with your known app/user workload figures


Step 18: Now select your scaling settings.



Step 19: Once you have everything selected correctly you can click on Start deployment:
and the Citrix Cloud will start provisioning.

So what gets deployed?

This will take a few hours to complete, but if you are watching it will the Citrix Cloud will firstly deploy two Virtual Machines that host the Cloud Connector client, with the associated Azure infrastructure components, such as NIC's, Storage accounts, Network Security Groups and a Key Vault. 


These components will be deployed in to the same Resource Group that you selected in Step 14. Refresh your Resource Group and you will start to see these resources being deployed.

The Cloud Connector VM's will be named something like: XAE60xxx-Edge1 and 2, and will be a Standard  A2-V2, but you can scale them up or down manually by going to the Size blade and changing the size to something you would prefer.
After this is complete it will move on to create the Catalog. It will create a new Resource Group using the name of the Catalog as the Resource Group name. In here it will create the infrastructure required for the Resource Group.
Go back to the Resource Groups and refresh and you will see a new Resource Group Called XenApp-"Your catalog name", and you will start to see components appearing in this new Resource Group.




Section 3 - Publishing Applications and Assigning users



You will notice that the Catalog has been successfully created when the Citrix Cloud console moves to Section 2



Now we need to add some applications and some users.


Step 20: Click on + Apps



Step 21: You will now have two options to find your application. 1, is from the Start menu, and 2, is from a path.


Select Publish from Start menu on the left and then click on the drop down on the right to select your app:
This screen seems a little un-intuitive here as the app is published as soon as you click on it there is no "Publish" type of button. However selecting the radio button to the left of the app just gives you the option to Unpublish the app. Then you just click the X at the top right but this feels as if you are actually cancelling this action instead you are just closing.

Step 22: Now we need to add users. click on Add Users. In the search field on the right type in your user name:
Here you do need to put a tick in the box and make sure you click the "Assign Users button at the top.

You should now get two green ticks at the right of the rows.

Step 23: Now all that is left is to launch the app. Go to Section 3 which will show you your StoreFront URL. Click on the link and you can log in and launch your applications.

That's it you now have an app published from Azure orchestrated by Citrix XenApp Essentials.

Notes: 
You can easily deploy a global Citrix farm, by deploying a Catalog into any of the 30 Azure regions around the world. This is a compelling capability that is next to impossible without the power of Azure. You just need to deploy two Citrix Cloud connectors in any region, and deploy then deploy a Catalog to that region.

You can also integrate multiple domains simply by deploying Cloud Connectors that are connected to other domains, and then the standard domain drop down in StoreFront will display the domain names.

You can also add in multiple Azure subscriptions, just by going to the Subscriptions and clicking on Add Subscriptions, then just signing in with credential for another subscription. This will then allow you to deploy infrastructure into other subscriptions.




Using PowerShell to create a Windows VM Hosted AD and join VM's to that Domain - in Windows Azure

There seem to be numerous PowerShell snippits of scripts out there to create an AD and to join VM's to that domain. However this Microsoft article (bit.ly/LEOSocseems to suggest that people are still having difficulties doing so, myself included and it took hours of trial and error to get the scripts correct.

So I thought that I would document exactly what I have got that now works every time (for me at least). My intention is that there would be nothing missing to get this to work.

So we are going to use two PowerShell scripts, one to create a VM that will have AD installed on it, and a second to create a VM that is automatically joined to that domain all hosted in Azure.

There are numerous prerequisites that are still needed in order to get this script to work. I.e. the script depends on you having an Azure subscription with the following items already created: Storage Account, Certificate, Publish settings file, Affinity Group, Virtual Network and subnet. These can all be created by following the link above.

You also need to have Azure Powershell installed, and use the PowerShell ISE (Integrated scripting environment). Microsoft have released the October version  with new features. One of those new features is the ability to use Azure AD support to configure Powershell to integrate with your Azure subscription (see 
http://michaelcollier.wordpress.com/2013/10/28/windows-azure-ad-authentication-support-for-powershell), which is great as it prevents having to download and specify a .publishsetings file and creating, uploading and installing a certificate and specifying it  in your scripts. 

However this version (0.7.0) of the Azure PowerShell cmdlets also has a bug that prevents the  function that joins VM's to a domain, as per (bit.ly/1b3tf94). This means that you need an older version of the Azure PowerShell cmdlets, namely June's version which is 0.6.19. This should get resolved in early November.


You can get this from the Microsoft download site or from here.


So the scripts are also here. You need two. The first creates a base VM that you will then need to deploy AD on. The second creates a VM that is joined to the domain created by running the first script. You will need some basic scripting knowledge and knowledge of the values that are required in relation to your subscription - only you will know these!


The brief overall instructions are:

1. Install Powershell 0.6.19 (until the issue mentioned above is fixed).
2. Create, upload to your Azure subscription and install locally a suitable certificate (not required if the above issue is resolved)
3. Get your Azure publish.settings file by following this link:
https://manage.windowsazure.com/publishsettings/Index?client=vs&SchemaVersion=1.0

Once you have all of this you are ready to configure your PowerShell scripts. The first script is split into three sections. The first is where you will need to configure:
1. The path to the Azurepsd1 file (if its not as per the default location).
2. Your certificate and its thumbprint (you get this from the Azure portal in SETTINGS>MANAGEMENT CERTIFICATES. You also need to have installed the certificate locally in the local personal certificate store.
3. The path to your publish.settings file you got in step 3 above.
4. Define your subscription name and storage account using the $Storage variable

The second section is where you will define all of the variables related to your Azure subscription and the VM your are creating, these include:

1. DNS Service name
2. VMName
3. Azure Windows OS Image (these change frequently and a current list can be retrieved by running Get-AzueVMImage, then paste into the scrip the image you want.
4. Affinity Group
5. Virtual Network and Subnet
6. Cloud Service
7. Password for a local user account
8. VMSize

The third section has the PowerShell commands used in conjunction with the variable settings to build your VM.


Once you have specified all of these variables then you can paste the scrip into the PowerShell ISE and press enter. If the text turns white it is all good to go, and you will be prompted to enter a username. This username is for a local account on the VM that you will use to connect over RDP, with the password specified in the script. PowerShell will then connect to the Azure API and configure your VM. You then need to follow the instructions in bit.ly/LEOSoc to configure AD.


Once you have done this then you are ready to add VM's to that domain as part of the provisioning process. This requires the second script.


This script requires many of the same variable as script one, so just copy them in where appropriate. The one different variable that you need to set is $myDNS, this needs to be the AD and DNS server that you have created using the first script and have manually deployed AD and DNS.

Once you have the variables configured correctly, again just copy and paste it into the PowerShell ISE and it will create you a VM that is automatically joined to your Windows VM hosted Active Directory. If you want to deploy additional Domain joined VM's just change the variable that need to be unique such as VMName and run it again, saving you alot of time.


No comments:

Post a Comment