How to find all the available Windows Server 2012 R2 images in Azure in Powershell (Service Manager)

The following command can be used to outline all the available Windows Server 2012 R2 images that are available to you when creating Azure VM's (Service Manager). 

( Get-AzureVMImage | where-object { $_.Label -like "Windows Server 2012 R2*" } )

You can of course change the label string if you are looking for something else. 

When the command returns the results it is the "ImageName" property that is required for commands such as New-AzureVMConfig.

In an example I needed to reference a Windows Server based image in order to spin up a new VM using Service Manager.

New-AzureVMConfig -Name vmhostname -InstanceSize Small -ImageName "a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-20161214-en.us-127GB.vhd"

Azure VHD Upload Fails “An upload is already in progress on machine HOSTNAME with process ID”

Uploading VHD’s to an Azure Storage Account is straight forward, the following command;

Add-AzureVHD -Destination https://storageaccountcontainer -LocationFilePath “C:\Win7.vhd”

You must create your Storage Account and relevant containers prior to running the command. I tried to upload a VHD, which failed to complete successfully this was due to a network connectivity issue on the client uploading the VHD file.

I tried to run the command again and received the following error “An upload is already in progress on machine HOSTNAME with process ID” even though I knew it had failed.

The fix here was to manually delete the partially uploaded VHD file. This can be done using the Web-GUI if you enter the Container that the original VHD select it and Delete the disk.

Run the Azure command again and the VHD should begin uploading again. 

First look Azure File System Configuration

Just announced is the Microsoft Azure File System (https://azure.microsoft.com/en-gb/blog/azure-file-storage-now-generally-available/) which allows users to present Azure storage over the SMB protocol, much like what has been used in the enterprise for many years.

Full details can be found in the link above.

Data is stored in the following structure on Azure. Account\Share\Directory\File. 

The Azure File System is build upon the same technology as the existing Azure storage architecture which includes blobs, containers etc. Therefore Azure File System is backed by all of the same SLA's and guarantees for durability, resiliency and availability as you would have come to expect.

In this post I am going to outline the steps required to create a Storage Account with File Share, and how to present that share to an Azure instance. Firstly login to the Azure Preview Portal. The Storage Account must be an ordinary Storage Account, and not one labelled "Classic", depending on when your subscription was first set up will determine if you even have access to Classic VM's and Storage.

If you do not have a Storage Account click the Add button.

Enter a name for the Storage Account, this must be globally unique. Configure the Resource Group and Regional settings to suit your requirements and click Create.

Once the Storage Account has provisioned click on it, and expand Services. You will notice there is now an option for "Files", if your Storage Account is "classic" the option for Files is not present. Click the Files tile.

Click the + File Share button.

Name the File Share, this only has to be unique to your Storage Account. Also give the file share a quota if you want to. Click Create.

Now click on the File Share, and you will be faced with the following options. As per the Azure file structure, the next step is to create a Directory inside of the File Share. Click the + Directory button.

Once the directory is created, you then have the ability to upload files into the directory. 

Now that the Storage Account is configured with a Share, Directory and sample file. You can now map a client device to the SMB Share, at the time of writing the following versions of Windows with the outlined version of the SMB protocol were supported. You can connect certain versions of Linux/Unix to SMB Share, further details can be found in the article above.

In order to authenticate the Azure instance you are using to connect to your SMB Share, you must have the Storage Account access key, you can expose these from the Preview Portal. Copy Key 1 to the clipboard.

cmdkey /add:demotesting.file.core.windows.net /user:demotesting.file.core.windows.net /pass:y/Do/lCNNGkRiqivgtFlX+XXXXXXXXXXXXSbZ6VOuSkpexVGYCRaGa1x0xBaNtg12FzCQaKb/DhQ==

net use Z: \\demotesting.file.core.windows.net\smbshare /u:demotesting y/Do/lCNNGkRiqivgtFlX+Wt9aJ2B2lkRjIXXXXXXXXXXkpexVGYCRaGa1x0xBaNtg12FzCQaKb/DhQ==

Azure VM Active Directory Move NTDS Database Location

When extending an Active Directory to Azure, I stupidly forgot to install the Active Directory Database and Logs on to a dedicated Azure data disk. All of the Active Directory documentation that relates to Azure recommends doing this for integrity purposes

https://azure.microsoft.com/en-gb/documentation/articles/active-directory-new-forest-virtual-machine/

The AD was installed and configured, so I had to gracefully move the DB and Logs files from there default locations. If you have not already installed Active Directory on your Azure VM's, simply change the installation location when you are going through the wizard.

To create a new data disk in Azure for your VM, click the VM in the Preview Portal, and click All Settings.

Click on Disks.

Click the Attach New icon.

Select a Storage Container in which to provision the data disk into, label the disk something descriptive and also set a size. You should probably do some investigation into how big your Active Directory database is before you do this.

Its important Host Caching is set to none. Click Create.

Once the operation to create an attach the new data disk is complete, use Disk Management (or diskpart) to online, initialize and format the disk. Please note, as the Active Directory database requires some special permissions, the disk must be formatted in NTFS.

On a Domain Controller open an Administrative Command Prompt. The following command will stop the AD DS service, please hit Y to confirm that the AD DS service can be stopped along with the other dependent services.

net stop ntds

The following commands (and sub-commands of NTDSUTIL) should move your AD database and logs without any problems. You do not have to pre-create the folder on the new disk.

ntdsutil activate instance ntds file move db to E:\NTDS move logs to E:\NTDS integrity quit shutdown –r –t 1 (optional)

After the reboot the AD files should now be re-homed.

Azure External Load Balancer "Failed to join virtual machine to load balanced set. The operation failed Port 443 is already in use by one of the endpoints in this deployment."

When you try to create an external/public Azure Load Balancer for HTTPS traffic, you recieve "Failed to join virtual machine to load balanced set. The operation failed Port 443 is already in use by one of the endpoints in this deployment. Ensure that the port numbers are unique across endpoints within a deployment."

The key thing to understand here is that "deployment" actually means the Cloud Service, therefore this error is saying another application or service is currently using TCP port 443 within your current Cloud Service.

Problem spotted, if you click on your Cloud Service and review what is listed under Input Endpoints you will probably find there is a VM instance using TCP 443 behind your Cloud Service public IP address.

The best way to fix this (and only from a GUI) is to use the Preview Portal. Click on the VM that is listed under the Cloud Service as using port 443 and click All Settings then Load Balanced Sets.

As you will see I currently have two Load Balanced Sets, one for Internal traffic and one for External traffic. The public load balanced set is causing the issue here for me, the internal LB was created only a few minutes ago to load balance the internal "tier" of ADFS. The external LB is going to point to WAP endpoints on separate VM's.

So I clicked on the Public LB and it was currently using the Cloud Services IP on TCP 443.

After selecting the Public LB you must click Leave to remove the old endpoints from the LB, if this is the last endpoint within an LB the LB will be automatically deleted. As this was a stale LB instance that I had created weeks ago for testing I went ahead and removed it.

Hopefully deleting the load balanced set works first time, I believe some people have experienced problems doing this from the preview portal, and have had to revert to Powershell to complete the operation.

Now lets try re-creating our Public/External Load Balanced Set with the Cloud Service public IP and TCP port 443. Click the VM's you want to provision into the LB set and click All Settings/Load Balanced Sets, in my case this was the first of my WAP servers that were going to be internet facing. 

Click Join.

If you had the same problem as me and you have successfully removed everything that was conflicting the operation should complete successfully.

Azure Cloud Service Connecitivity "Remote Desktop can't find the computer "name.cloudapp.net". This might mean that "name.cloudapp.net" does not belong to the specified network.

Azure Cloud Service Connecitivity "Remote Desktop can't find the computer "name.cloudapp.net". This might mean that "name.cloudapp.net" does not belong to the specified network.

When you try to connect to a VM in a Cloud Service (name.cloudapp.net) it was working until I provisioned an additional 6 VM's into the same Cloud Service. I then tried to RDP to any of the other instances to see if it was a particular VM, or the Cloud Service itself.

The fix was easy login to Azure using the Preview Portal, expand the VM in question and click on the Reset Remote Desktop Settings, and click Yes to confirm. Then reboot the instance, and you should be able to RDP.

Azure VM Instance DNS “Default Server” Unknown and Cannot Join the Windows Server 2012 R2 Domain

Today I run into a strange issue related to DNS with my traditional on premise Active Directory and an Azure VM that was to be promoted to a Domain Controller. I was basically extending an Active Directory domain to Azure to test a DR configuration of AD FS.

There is an IPsec Site-to-Site VPN from my corporate network to the Azure tenancy, this is terminated by a Cisco ASA firewall on our site. As you can see the VPN is established and passing traffic without problem. At this stage I will also mention TCP/UDP 53 is allowed both way in the firewall configuration.

In order to promote an Azure VM to a Domain Controller from an already existent Active Directory, Microsoft recommend configuring the Azure vNet to point to one (or more) of the existing DC/DNS servers so that it can join the domain etc. The guidelines are to then change the Azure DNS Servers to the local Azure server, once the VM has successfully became a DC. Microsoft state that DNS Servers should be configured on the vNet themselves instead of statically configured inside the VM’s, this is to ensure the DNS Server settings are retained if the instance is automatically moved to another underlying Hyper-V host by Azure. Azure instances are addressed dynamically by default.

I did just this, under my vNet/Configuration/DNS Servers I configured the entire vNet to look to a Domain Controller which was at 192.168.1.1. The problems started when I logged onto my Azure instance, the DNS Server had been assigned by the internal Azure DHCP as it was my primary name server if I run the nslookup tool.

As you will see from the image above the DNS requested “timed out”, and the Default Server is “unknown”. This is indeed a well-known problem if you do not have reverse lookup’s configured correctly inside your Active Directory DNS. In my case Reverse Lookups were configured and working correctly so that did not solve my problem. It’s worth noting that at this stage I had already defined an Active Directory Subnet and Site for my Azure tenancy.

Obviously without DNS working correctly I could not promote this Azure VM to a Domain Controller, therefore the troubleshooting began. My first port of call was the BPA’s for both Active Directory and DNS, I run both of these and there were no errors returned.

I then decided to check Active Directory’s general health and replication state. The following commands came in handy to do this;

repadmin /replsummary

repadmin /showrepl

repadmin /replsum

repadmin /syncall

dcdiag /a

In this particular environment there was two Active Directory sites, each with a single Domain Controller (it’s a PoC lab). At first I was not paying much attention to the DC in the secondary site, as the VPN from Azure was only terminated to the primary site. Network routes to the secondary site were also not configured. It turns out there was a replication issues between the two DC’s, they had not replicated in over 4 days.

The replication issue was 1722 The RPC Server is unavailable I followed this guide https://technet.microsoft.com/en-us/library/replication-error-1722-the-rpc-server-is-unavailable(v=ws.10).aspx which sorted the problems. I then rebooted the Azure VM and the DNS resolved properly. I suppose it goes without saying before you make any significant changes to an Active Directory always perform a mini-health check on it to ensure it’s working correctly.

Configuring Azure Site to Site VPN with Cisco ASA 9.x Firewall

It is highly likely you will be required to create a site to site VPN from your on-premises network to the Azure public cloud. In order to do this you must have a compatible VPN peer that is capable of terminating the IPsec VPN. All of the main network vendors have supported devices such as Cisco, Juniper and Palo Alto etc. You can consult the following website to see what devices are supported;

https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpn-devices/

Windows Server 2012/2012 R2 is also a supported configuration with the Routing and Remote Access (RRAS) role installed, this however when I tried to do it behind my Cisco ASA I could not get it to work. If you research around some forums etc most people only get RRAS to work with Azure if it is directly connected to the internet without any kind of NAT in-between. Most enterprises won’t be using RRAS anyway.

This example will cover setting up an Azure vNet with an Azure Gateway that is connected to a Cisco ASA 5505 firewall. At the time of writing Azure automatically generated configuration scripts for Cisco and Juniper devices, although these sometimes need tweaking before they work correctly, I cover this further down.

Define Local Network

The first stage is to define the Local Network, which is the network space in which your on premise environment works with. It is with the Local Network you also specify the outside global address that your VPN device has on its outside (or public) interface.

Open the Azure Management console, click New then Network Services, Virtual Network and then Custom Create.

Input a name for the local network, something descriptive is best and then enter the VPN Device IP as stated above.

You must then specify the address space that is being used within your on premise network, the address spaces used on premise and the cloud cannot overlap. Therefore you cannot have 192.168.1.0/24 on site and in the cloud.

Define DNS Servers

The next step is to define the name resolution servers, you require at least one on premise and in the cloud, click New > Network Services > Virtual Network > Register DNS Server and define the DNS servers.

Create Virtual Network

Now create a new Virtual Network click New > Network Services > Virtual Network > Custom Create. The vNet is the logical entity that the VM instances connect to.

Enter a descriptive name for the vNet and set the location. 

From the next pane click the DNS Servers that were defined in the previous step. Tick Configure site-to-site VPN and then select the Local Network object that was defined in a previous step.

Now configure the address spaces you intend to use for your cloud based instances. Also click Add Gateway Subnet this will provision a small subnet to be used for the inter-tunnel communications. 

When the network is created the next step is to create a Virtual Gateway, which is assigned a public address. This process can take around 15-20 minutes to complete.  Click Create Gateway and select the Routing type, the Cisco ASA actually only supports Static Routing. Consult the following document to check if dynamic routing is supported for your VPN device 

https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpn-devices/

Click Yes to confirm you want to create a gateway.

The interface will appear like it is below, the VPN cannot be formed until the VPN device is up dated with the configuration script. Unfortunately if you do not have a Cisco or Juniper firewall device you may have to do some manual configuration.

Click Download VPN Device Script from under Quick Glance. You can then select what options suit your environment, I hope Microsoft increase the number of devices and operating systems. The current options do not come close to what Amazon Web Services offers, they have pre-created scripts for almost all of the networking vendors I can name, with multiple different operating system versions.

Something that is not obvious when you download the configuration script for the Cisco ASA is that it assumes your firewall's interfaces are called inside/outside, for example some environments use private/public, this is not obvious if you are not a familiar with firewall scripts. I have highlighted everything below that must be changed to reflect your exact firewall configurations.

! Microsoft Corporation ! Windows Azure Virtual Network ! This configuration template applies to Cisco ASA 5500 Series Adaptive Security Appliances running ASA Software 8.3. ! It configures an IPSec VPN tunnel connecting your on-premise VPN device with the Azure gateway. ! --------------------------------------------------------------------------------------------------------------------- ! ACL and NAT rules ! ! Proper ACL and NAT rules are needed for permitting cross-premise network traffic. ! You should also allow inbound UDP/ESP traffic for the interface which will be used for the IPSec tunnel. object-group network azure-networks  network-object 172.16.0.0 255.240.0.0  exit object-group network onprem-networks  network-object 10.0.0.0 255.0.0.0  exit access-list azure-vpn-acl extended permit ip object-group onprem-networks object-group azure-networks nat (inside,outside) source static onprem-networks onprem-networks destination static azure-networks azure-networks ! --------------------------------------------------------------------------------------------------------------------- ! Internet Key Exchange (IKE) configuration ! ! This section specifies the authentication, encryption, hashing, Diffie-Hellman, and lifetime parameters for the Phase ! 1 negotiation and the main mode security association. We have picked an arbitrary policy # "10" as an example. If ! that happens to conflict with an existing policy, you may choose to use a different policy #. crypto isakmp enable outside crypto isakmp policy 10  authentication pre-share  encryption aes-256  hash sha  group 2  lifetime 28800  exit ! --------------------------------------------------------------------------------------------------------------------- ! IPSec configuration ! ! This section specifies encryption, authentication, and lifetime properties for the Phase 2 negotiation and the quick ! mode security association. crypto ipsec transform-set azure-ipsec-proposal-set esp-aes-256 esp-sha-hmac crypto ipsec security-association lifetime seconds 3600 crypto ipsec security-association lifetime kilobytes 102400000 ! --------------------------------------------------------------------------------------------------------------------- ! Crypto map configuration ! ! This section defines a crypto map that binds the cross-premise network traffic to the ! IPSec transform set and remote peer. We have picked an arbitrary ID # "10" as an example. If ! that happens to conflict with an existing crypto map, you may choose to use a different ID #. crypto map azure-crypto-map 10 match address azure-vpn-acl crypto map azure-crypto-map 10 set peer x.x.x.x crypto map azure-crypto-map 10 set transform-set azure-ipsec-proposal-set ! Note that you can only bind one crypto map to the "outside" interface. You can, however, define ! different peer/transform-set within a crypto map and identify them with different IDs. crypto map azure-crypto-map interface outside ! --------------------------------------------------------------------------------------------------------------------- ! Tunnel configuration ! ! This section defines an IPSec site-to-site tunnel connecting to the Azure gateway and specifies the pre-shared key ! value used for Phase 1 authentication.  tunnel-group x.x.x.x type ipsec-l2l tunnel-group x.x.x.x ipsec-attributes  pre-shared-key xxxxxxxxx  exit ! --------------------------------------------------------------------------------------------------------------------- ! TCPMSS clamping ! ! Adjust the TCPMSS value properly to avoid fragmentation sysopt connection tcpmss 1350 exit

For example if you see my interfaces on my home ASA are inside/outside so the script is fine for me, but if your interfaces are different you will have to edit the script. My ASA is also running IOS 9.3 and the script is for 8.3, the difference is how the static NAT statement is written.

You can use the ASDM or an SSH session to your firewall to input the script, if you are using ASDM click Tools and Command Line Interface...

Select Multiple Lines and copy and paste the lines of code into the box, I have found the exit statements in the script get returned by the ASA as none executable code, so I edit them out.

Return to the vNet page and click Connect. If everything has been completed successfully your VPN should form correctly, all of the routes etc should automatically be in place therefore when you ping an on premise server it should get all the way to your Azure instances.