Azure – Carl Webster https://www.carlwebster.com The Accidental Citrix Admin - The site for those who find themselves supporting Citrix involuntarily or accidentally Tue, 19 Jul 2022 13:00:07 +0000 en hourly 1 https://wordpress.org/?v=6.8.2 42228915 IGEL and Azure Virtual Desktops https://www.carlwebster.com/igel-and-azure-virtual-desktops/ Sat, 25 Sep 2021 17:40:33 +0000 https://www.carlwebster.com/?p=49825 In two previous articles, I talked about following my friend Claudio Rodriques’ excellent book DAAS The Complete Guide to learn Azure and Azure Virtual Deksttops (AVD). I had a few “spare” minutes, so I decided to see how to access my AVD resources from the UD3 and UD7 devices IGEL provided for Webster’s Lab. Getting access to my AVD resources turned out to be easier than I thought possible.

IGEL recently posted a blog article showing how easy it was to get IGEL working with AVD. I had to prove it to myself.

If you read the two previous articles or follow me on social media, you have seen me state how many changes there are in Azure and AVD since Claudio released his book. None of the changes prevented me from getting my AVD Workspace working and tested. Accessing my AVD Workspace from an IGEL device was another test I wanted.

To have the best experience with IGEL and AVD, since AVD changes rapidly, you must keep your IGEL console and device firmware updated. Here are the steps I took to get access to my AVD Workspace from IGEL.

1.  Make sure you power on your Azure AVD virtual machines (VMs).

  1. Make sure your Universal Management Suite (UMS) Console is the latest version. As of 25-Sep-2021, the version is 6.08.110, Figure 1.
Figure 1
Figure 1
  1. Make sure your firmware is the latest version. As of 25-Sep-2021, the version is 11.06.100, Figure 2.
Figure 2
Figure 2
  1. Assign the latest firmware to your IGEL device(s), Figure 3.
Figure 3
Figure 3
  1. Update the device(s) firmware, Figure 4.
Figure 4
Figure 4
  1. Verify your device(s) firmware updated, Figures 5 and 6.
Figure 5
Figure 5
Figure 6
Figure 6
  1. Create an AVD profile based on the latest firmware. Figures 7 and 8.
Figure 7
Figure 7
Figure 8
Figure 8
  1. Expand Sessions, AVD, AVD Sessions, and click the “+”. Figure 9.
Figure 9
Figure 9
  1. Expand AVD Session, click Logon, click the whatever color they are triangles to the right of Username@domain or @domain and Password. The two triangles should turn some other color, Figure 10. The Username@domain or @domain option did not work for me and caused me to lose a few minutes of troubleshooting.
Figure 10
Figure 10
  1. For Workspace resource to automatically start when connected, enter the AVD Workspace Claudio had you create starting on page 125. In Azure, click Home, Workspaces, Figure 11.
Figure 11
Figure 11
  1. Copy the Name of your Workspace, Figures 12 and 13.
Figure 12
Figure 12
Figure 13
Figure 13
  1. Paste the Workspace name, Figure 14. This is the MINIMUM configuration required to test access to your AVD Workspace.
Figure 14
Figure 14
  1. Click Save, Figure 15.
Figure 15
Figure 15
  1. Assign the AVD profile to your device(s). Click the “+“, Figure 16.
Figure 16
Figure 16
  1. Select the device(s), Figure 17.
Figure 17
Figure 17
  1. Select Now and click OK, Figure 18.
Figure 18
Figure 18
  1. After policy applies to the device(s), you see the AVD Session icon on the device’s desktop, Figure 19.
Figure 19
Figure 19
  1. Double-click the AVD Session icon and enter the credentials required to access your AVD resources, Figure 20.
Figure 20
Figure 20
  1. Your AVD Workspace resources appear, Figure 21.
Figure 21
Figure 21
  1. Launch any of the resources, Figures 22 and 23.
Figure 22
Figure 22

Figure 23

That wasn’t hard, was it? Using Claudio’s excellent book and IGEL’s easy-to-use console, it only took a couple of minutes to access your AVD Workspace resources using an IGEL device.

If you are now a member of the IGEL Community on Slack, please join.  You will find many helpful people and also keep up-to-date on the latest console and firmware releases.

 

 

]]> 49825 Removing an Old Stale Azure and Office 365 Domain for Use in a New Azure Active Directory Connection https://www.carlwebster.com/removing-an-old-stale-azure-and-office-365-domain-for-use-in-a-new-azure-active-directory-connection/ Fri, 17 Sep 2021 14:24:02 +0000 https://www.carlwebster.com/?p=49746 Recently, I started a new job where I needed to learn Microsoft’s Azure and Azure Virtual Desktop (AVD). My friend Claudio Rodrigues recently released his excellent book DAAS The Complete Guide, and I am using his book to guide my learning.

In Chapter 2, Azure Virtual Desktop, Claudio walks through configuring Synchronizing AD with Azure Active Directory. Step 4 in that process is verifying your custom domain. My verification failed with the message shown in Figure 1.

Figure 1
Figure 1

To make an hours-long story short, it took me a while to figure out when I had set up LabADDomain.com for use in Azure or Office 365 (along with the username and password). I eventually found that I created a free Azure account and an Office 365 account several years ago. Removing the domain LabADDomain.com for those accounts took a few hours because even Microsoft support didn’t know how to remove an old domain.

This article outlines the steps that took Microsoft and me over four hours to resolve. I hope you can follow these steps saving you hours of frustration for those with labs and possibly multiple domain names.

Several years ago, I created an Office 365 trial for LabADDomain.com with an admin account named ctxadmin@labaddomain.com. I used that account to create a free Azure trial using Azure AD Connect connecting to my on-premises AD LabADDomain.com domain. That version of the LabADDomain.com AD is long gone. Webster’s Lab gets rebuilt almost annually. The original domain and domain controllers no longer exist, so nothing to uninstall and remove the sync to Azure AD. To resolve the issue, it took many emails, phone calls, and remote support sessions with Microsoft Support.

When you create an Office 365 subscription, there are two domains created: YourDomain.com and YourDomain.OnMicrosoft.com.

Here are the steps we took to remove the stale domain.

1. Create a global admin for labaddomain.onmicrosoft.com named ctxadmin.

2. Log off from the old ctxadmin@labaddomain.com admin account.

3. Login with the new ctxadmin@labaddomain.onmicrosoft.com admin account.

4. Go to the O365 admin center, Figure 2.

Figure 2
Figure 2

5. Show all, Figure 3.

Figure 3
Figure 3

6. Setup, Figure 4.

Figure 4
Figure 4

7. Domains, Figure 5.

Figure 5
Figure 5

8. Select the old domain to remove.

9. Click the vertical three dots next to Filter.

10. Click either Delete Domain or Remove Domain (I can’t remember the verbiage).

11. Wait about an hour.

12. Click Refresh every few minutes. For me, it took about an hour before the console no longer showed the old domain. You must wait until the domain deletes before continuing.

13. You can now use the old domain as a new domain for AAD, Figure 6.

Figure 6
Figure 6

I hope this brief article helps someone else from spending hours with Microsoft support to remove a long-forgotten domain from a long-forgotten Azure or Office 365 trial.

Thanks

Webster

 

]]> 49746 Create a Site-to-Site VPN Between Webster’s Lab and Azure https://www.carlwebster.com/create-a-site-to-site-vpn-between-websters-lab-and-azure/ Tue, 14 Sep 2021 09:00:34 +0000 https://www.carlwebster.com/?p=49683 Recently, I started a new job where I needed to learn Microsoft’s Azure and Azure Virtual Desktop (AVD). My friend Claudio Rodrigues recently released his excellent book DAAS The Complete Guide, and I am using his book to guide my learning.

At the end of the first chapter, Claudio walks you through creating a site-to-site VPN using a Ubiquiti router. I don’t have one of those and needed to try something else. Claudio links to a Microsoft article where Microsoft gives configuration settings for many devices. Unfortunately, my NETGEAR Nighthawk X6 R8000 WiFi router was not on the Microsoft list. Claudio told me I could use Microsoft’s Routing and Remote Access Server (RRAS) to create the site-to-site VPN, but oddly, Microsoft provides no instructions on how to do so.

Claudio then sent me a link to a helpful article, and I adapted https://charbelnemnom.com/create-site-to-site-vpn-between-azure-and-windows-rras-server/ [Webster: That site’s owner has blocked me from linking to his article, but the link is still valid.] for my NETGEAR router, Claudio’s book, and my lab.

Assumptions:

  1. You followed my Building Webster’s Lab V2 series
  2. You are following Claudio’s DAAS The Complete Guide Book

The following instructions replace Claudio’s on page 52, the section Establishing the VPN Connection. The following instructions are for implementing Windows Routing and Remote Access Server (RRAS) on Server 2019.

The first thing we need is to determine the internal IP for our Windows RRAS Server. For me, that is 192.168.1.212.

Create port forwarding rules on NETGEAR Router

Login to the router.

Click on the Advanced tab, then Advanced Setup, and Port Forwarding / Port, as shown in Figure 1.

Figure 1
Figure 1

Select Port Forwarding and click the Add Custom Service button, as shown in Figure 2.

Figure 2
Figure 2

Enter the following information, as shown in Figure 3. After entering all information, click Apply.

  • Service Name: A descriptive name for the service. I used AZ RRAS 500.
  • Protocol: UDP
  • External Port Range: 500
  • Use the same port range for Internal port: Selected
  • Internal IP address: IP address of the RRAS server. For me, that is 168.1.212.
Figure 3
Figure 3

Repeat the process shown in Figures 2 and 3 and enter the following information in Figure 4.

  • Service Name: A descriptive name for the service. I used AZ RRAS 4500.
  • Protocol: UDP
  • External Port Range: 4500
  • Use the same port range for Internal port: Selected
  • Internal IP address: IP address of the RRAS server. For me, that is 168.1.212.
Figure 4
Figure 4

Figure 5 shows the two services added to the router.

Figure 5
Figure 5

Create Static Route on NETGEAR Router

Now we need to configure the router to route traffic to Azure from our on-premises virtual machines.

From Advanced Setup, click Static Routes, as shown in Figure 6.

Figure 6
Figure 6

Click Add, as shown in Figure 7.

Figure 7
Figure 7

Enter the following information and click Apply, as shown in Figure 8.

  • Route Name: A name for the route. I used Azure.
  • Verify that Private is not selected.
  • Select Active.
  • Destination IP Address: If you follow Claudio’s book, the Destination IP Address is on page 41 or Step 4 of the Creating a Virtual Network and Subnets section. I used what Claudio used: 16.0.0.
  • IP Subnet Mask: If you follow Claudio’s book, the IP Subnet Mask is on page 41 or Step 4 of the Creating a Virtual Network and Subnets section. I used what Claudio used: 255.0.0.
  • Gateway IP Address: The IP address of the RRAS server. For me, that is 168.1.212.
  • Metric: 10
Figure 8
Figure 8

Figure 9 shows the Static Route added.

Figure 9
Figure 9

Log out and exit the router’s web interface.

Create VM from Server 2019 Template

Follow the instructions from Building Webster’s Lab V2 – Create VMs from the Server 2019 Template.

This RRAS computer is not domain-joined.

Assign a static IP address to the server, as shown in Figure 10.

Figure 10
Figure 10

Rename the current network adapter to LAB Internal, as shown in Figures 11 and 12.

Figure 11
Figure 11
Figure 12
Figure 12

Install RRAS

Open an elevated PowerShell session and run the following commands, as shown in Figure 13.

Install-WindowsFeature -Name RemoteAccess, DirectAccess-VPN, Routing -IncludeManagementTools

Rename-Computer -NewName "LabAZRRAS" -Restart

Those commands install the RRAS, DirectAccess VPN, and Routing features, RRAS management tools, rename the computer and restart the computer.

Figure 13
Figure 13

After the computer restarts, shut down the computer. We need to add a second network adapter.

VMware Add Network Adapter

In vCenter, right-click the new RRAS VM, click Edit Settings…, click the Add New Device dropdown and click Network Adapter, as shown in Figure 14.

Figure 14
Figure 14

Verify that the new Adapter Type is VMXNET3, as shown in Figure 15.

Figure 15
Figure 15

Click OK.

Power on the RRAS VM and go ahead and install all Windows Updates.

XenServer Add Network Adapter

Select the RAS VM, click the Networking tab, and click Add interface…, as shown in Figure 16.

Figure 16
Figure 16

Select the correct Network and click Add, as shown in Figure 17.

Figure 17
Figure 17

Power on the RRAS VM and go ahead and install all Windows Updates.

Configuring the New Network Adapter

In Server Manager, click the new adapter, as shown in Figure 18.

Figure 18
Figure 18

Rename the new adapter to Azure External, as shown in Figures 19 and 20.

Figure 19
Figure 19
Figure 20
Figure 20

Configuring RRAS

Click Tools, Routing and Remote Access, as shown in Figure 21.

Figure 21
Figure 21

Right-click the RRAS server and click Configure and Enable Routing and Remote Access, as shown in Figure 22.

Figure 22
Figure 22

Click Next, as shown in Figure 23.

Figure 23
Figure 23

Select Secure connection between two private networks and click Next, as shown in Figure 24.

Figure 24
Figure 24

Select Yes and click Next, as shown in Figure 25.

Figure 25
Figure 25

Select Automatically and click Next, as shown in Figure 26.

Figure 26
Figure 26

Click Finish, as shown in Figure 27.

Figure 27
Figure 27

As shown in Figure 28, the Routing and Remote Access service starts.

Figure 28
Figure 28

The Demand-Dial Interface Wizard starts.

Click Next, as shown in Figure 29.

Figure 29
Figure 29

Enter an Interface name and click Next, as shown in Figure 30. I used AzureGW.

Figure 30
Figure 30

Select Connect using virtual private networking (VPN) and click Next, as shown in Figure 31.

Figure 31
Figure 31

Select IKEv2 and click Next, as shown in Figure 32. We select IKEv2 because that is the default value, as shown on page 50 of Claudio’s book or Step 6 of the Creating a Connection section.

Figure 32
Figure 32

Enter the Public IP from your Azure Virtual Network Gateway (VNG following Claudio’s naming scheme) and click Next, as shown in Figure 33.

Figure 33
Figure 33

Select only Route IP packets on this interface and click Next, as shown in Figure 34.

Figure 34
Figure 34

Click Add, as shown in Figure 35.

Figure 35
Figure 35

Enter the address space on the Azure virtual network, enter 10 for the Metric and click OK, as shown in Figure 36. If you follow Claudio’s book, the address space is on page 41 or Step 4 in the Creating a Virtual Network and Subnets section.  I used the same address space as Claudio of 172.16.0.0/16.

Figure 36
Figure 36

Click Next, as shown in Figure 37.

Figure 37
Figure 37

Click Next, as shown in Figure 38.

Figure 38
Figure 38

Click Finish, as shown in Figure 39.

Figure 39
Figure 39

In the Routing and Remote Access console, expand the RRAS server and click on Network Interfaces. Figure 40 shows the new network interface in the expected Disconnected state.

Figure 40
Figure 40

Double-click the new network interface, click the Options tab, and enter 3 for Redial attempts, as shown in Figure 41.

Figure 41
Figure 41

Click the Security tab, select Use preshared key for authentication, enter the Shared key (PSK) from page 50 in Claudio’s book or Step 6 in the Creating a Connection section, and click OK, as shown in Figure 42.

Figure 42
Figure 42

In the Routing and Remote Access console, expand IPv4, right-click Static Routes, and click New Static Route…, as shown in Figure 43.

Figure 43
Figure 43

Enter the following information and click OK, as shown in Figure 44.

  • Interface: The new network interface from Figure 30.
  • Destination: The Azure address space from Figure 36.
  • Network mask: From Figure 36.
  • Metric: From Figure 36.
  • Use this route to initiate demand-dial connections: Selected.
Figure 44
Figure 44

Verifying the Connection between Webster’s Lab and Azure

Go to your Azure portal, Local Network Gateway Connections, and your connection should show as Connected, as shown in Figure 45.

Figure 45
Figure 45

The new network interface shows as Connected in the Routing and Remote Access console, as shown in Figure 46.

Figure 46
Figure 46

At this point, Claudio had me create a basic VM to test pinging between my lab and Azure. After creating a basic Windows Server 2019 VM, I logged in and disabled the Windows Firewall on the Azure VM.

On my RRAS server, I enabled the Windows Firewall Inbound Rule File and Printer Sharing (Echo Request – ICMPv4-In), as shown in Figure 47.

Figure 47
Figure 47

I opened a command prompt from the Azure VM and pinged my RRAS server, as shown in Figure 48.

Figure 48
Figure 48

I opened a command prompt from the RRAS server and pinged my Azure VM, as shown in Figure 49.

Figure 49
Figure 49

I now shut down my Azure Test VM and deleted it, and all its resources before Microsoft started charging me money!

At this point, I am ready to continue to the Azure Virtual Desktop chapter in Claudio’s book.

]]> 49683