When using Windows Virtual Desktop the public IP of which you are NATed to the internet changes consistently. In some cases you would want to have the traffic origination the WVD hosts to use the same public IP adress. So that it can be whitelisted to use some external service, or so that it can be used as a trusted location for Conditional Access. This way users can connect to Windows Virtual Desktop and be prompted for MFA, but once they are signed in, in a managed environment they aren’t prompted for MFA again.
Traditionally you could accomplish this setup by using an Azure Load Balancer. I didn’t find this very easy to implement, luckily Microsoft introduced a new service called Virtual NAT Gateway which make this a lot easier to implement. By using a Virtual NAT Gateway you can NAT your outbound connections through one, or more Public IP addresses. This way all the VM’s within a certain subnet of your virtual network will use a dedicated public IP to make outbound connections.
Please note that the Virtual NAT Gateway is still in preview, so I wouldn’t recommend using this in production environments.
To create a NAT gateway, you select create resource and look for NAT Gateway.
Select your subscription, resource group and give the NAT Gateway a name and continue to the next step.
Here you can create or select a public IP address, if you need more one PIP you can also choose to create a whole range of PIPs. Notice that the SKU and assignment are Standard and Static, this means that the PIP you select won’t change over time.
Select a virtual network with the subnet(s) you want to associate the NAT Gateway, add tags and Create the NAT Gateway.
After the deployment is ready you can verify your settings by logging into the VM and checking your public IP on a website like https://www.myip.com/
You could then add this IP as a trusted location to use with Conditional Access so users wont have to two-factor authenticate within a WVD session.
I think we can all agree that application deployment is probably the most challenging part of an Intune implementation. The wide variety of Line of Business applications and different installation types can give you sleepless nights. It’s true that Microsoft has made some real improvements in application deployment with the support for most applications extensions. But there are always some applications that simply can’t be deployed with Intune or are very hard to deploy and manage.
With the introduction of MSIX I dare to say that you can now practically deploy any application successfully with Intune. In this blog I describe how you can create and deploy an MSIX package with Microsoft Intune. In this blog I will cover:
Create a Self-Signed Certificate (testing purposes)
Before you can deploy a MSIX package you need a certificate to sign your package. The signing of a package is a required step in the creation of the package. This is necessary because this is the only way you can assure that package is valid and came from a trusted provider. Preferably you should use a Code Signing certificate from a 3rd party provider. For now I use a self-signed certificate so that the deployment can be tested, but for you production environment I wouldn’t recommend this.
To create a self-signed certificate, you can start PowerShell as an administrator from any VM. Enter the following cmd, where you replace <Your Organisation> with a name of your choosing:
To Export the certificate open certmgr, your certificate is located in the Personal Certificates folder. Select the certificate –> all Tasks –> Export. Choose Next –> Yes, Export the private Key –> Choose Next –> For Encryption choose AES265 and enter a Password –> Enter a save location –> and choose Finish. You now have the certificate with a pfx extension.
We also need a certificate with the cer extension, so run the export Wizard again. Select the certificate –> all Tasks –> Export. Choose Next –> No, do not export the private key –> Choose Next –> Enter a save location –> and choose Finish.
You now have the certificate to sign your MSIX package and you have a certificate to distribute it via Intune.
Deploy Certificate Using Intune
Before you can install the MSIX package on any machine the certificate to sign the application must be trusted by the machine. Otherwise the application wont start. To install the certificate on the machine we can use Intune to distribute the certificate.
From the Intune Management Portal go to –> Device Configuration –> Profiles and choose Create Profile. Here you enter the name and description of the Profile. For the platform you choose Windows 10 and later, for Profile type select Trusted certificate. In the new blade you select the .cer certificate that you exported. After you created the Profile you than assign the profile to a group with has a test device in it.
Create a MSIX Package
For this blog I wanted to package an application that I had some trouble with in the past, the Citrix Receiver.
I have copied the Citrix Receiver installation file and the pfx certificate to the packaging VM and have launched the MSIX Packaging Tool. Here I want to create a new package, so I select ‘Application Package’.
Select Create package on this computer and choose Next. The packaging tool will now check some prerequisites and make sure that the drivers are installed.
In the next screen select the installation file. For now, I leave the installer arguments empty. For Signing preference, I select Sign with a certificate. This step is important. If you don’t select a certificate the application won’t be able to install.
Now provide some information for you package. Give your package a Name and a Display name. The Publisher name is provided from the certificate. The display name must be the same as the certificate, if these values don’t match the application won’t install. The installation location is not a mandatory field but is recommended.
By clicking next you will now enter the installation stage. The installation of your application will now start. You can just run through the installation as you normally would. When the installation is completed you can continue by clicking Next.
If the application requires any first launch tasks, they can now be performed otherwise press Next and continue Yes, move on. The package will now be created.
Finally provide a save location for the package and choose Create.
Deploy MSIX with Intune
Now that the MSIX package is ready we can start deploying it with Intune. Simply go to the Intune management portal –> Client apps –> Add App. Here you select Line-of-business app. Here you can upload the MSIX package you created.
When you click the app information blade you can see that most of the information is already filled out with the information from the MSIX package. After adding the app, just wait till the application is uploaded. The final step is to assign the application to a group.
After some time check your test machine to confirm that the application is deployed.
As you can see the packaging and distribution of an application with MSIX and Intune is really easy. But it doesn’t stop here, after you deployed one version of the application you might want to provide the application with an update. With MSIX this process is even easier. So in my next blog I will show you can can upgrade the Citrix Receiver application to the new Citrix Workspace application!
Windows Virtual Desktop is probably one of the most anticipated new products of Microsoft. If you haven’t heard from it, I would suggest that you start catching up ;). With the announcement of Scott Manchester GA (General Availability) just became a little bit closer.
There are plenty of blogs about how to set up a WVD tenant and sessions hosts, so I don’ want to go into detail on how to set it up. But if you have set up a WVD tenant you must have noted the lack of management tools. Or actually the absents of management tools, you can’t even find WVD in the Azure portal. Everything is managed with PowerShell, which can be a bit challenging. Microsoft did provide some management options for you but you will have to deploy them manually. They also require you to have an App service plan, which of course will cost you money, but you won’t have to use PowerShell for you management. Nevertheless I hope Microsoft will include these managements functionalities in the Azure Portal, but for now this is your best option.
WVD Management UX
The first management tool I would like to share is the WVD Management UX. The Managment UX helps you to preform basic management tasks. In here you can:
Create a New Host Pool
Add New Hosts to a Host Pool
Allow or block new connections to a host.(If you would like to drain the server for maintenance)
Create App groups. You can create App groups for Desktops or you can create App groups for RemoteApp
Assign permissions to App groups
Even though this may seem somewhat limited there are some extra functions you can use. However, these basic management tasks will help you a lot in doing day to day management for WVD.
The second tool Microsoft has provided is the Diagnostics tool and it has just been released. With the introduction of WVD Microsoft also introduced some new RDS roles. We all know the Connections broker, Gateway, Session Hosts and we all know it was very hard to troubleshoot failing connections. Therefore Microsoft introduced the new Diagnotics role, which is also fully managed by Microsoft.
Starting with the preview it was only possible to view the diagnostics using PowerShell, luckily Microsoft has made an App so you can troubleshoot using your browser. With the new Diagnostics app you can do the following:
Look up diagnostic activities (management, connection, or feed) for a single user over a period of one week.
Gather session host information for connection activities from your Log Analytics workspace.
Review virtual machine (VM) performance details for a particular host.
See which users are signed in to the session host.
Send message to active users on a specific session host.
Sign users out of a session host.
Unfortunately these functions aren’t available in the Management UX, you’ll have to deploy another application with an new app service plan. Which will cost you 70 euro/dollar extra each month, plus the additional storage for the log files. The deployment is pretty straightforward, Microsoft will guide you through the steps.
Azure files is a file share as a service that you host on Azure. You can mount the file share to a server so that you get an extra file share without having to physically extend the storage of that server. This is especially handy when you want to go through the transition of moving from IAAS to SAAS. In a cloud only environment Azure files would be preferable over and VM which is configured as a file server. Azure Files is also the preferred location for saving your FSLogix profile containers, when using Windows Virtual Desktop.
A Virtual Machine that is joined to Azure Active Directory Domain Services. Active Directory is not supported!
A Storage Account where you enable Azure Active Directory Domain Services (Azure AD DS) for the Identity-based Directory Service for Azure File Authentication
Set the general permissions to the share. You can compare this with the share settings in Windows.
You need Azure AD Domain Services for you authentication, since the file share make use of Kerberos authentication and your Azure AD doesn’t support Kerberos.
You can create a new storage account or use an existing storage account. All you need to do is configure Identity-based Directory Service for Azure File Authentication to Azure Active Directory Domain Services (Azure AD DS).
Set the Access permissions on the share. You can compare this with the share settings in Windows, where you would set global share permissions and then set NTFS permissions for more detailed permissions. Microsoft introduced three new roles for this.
Storage File Data SMB Share Reader allows read access in Azure Storage file shares over SMB.
Storage File Data SMB Share Contributor allows read, write, and delete access in Azure Storage file shares over SMB.
Storage File Data SMB Share Elevated Contributor allows read, write, delete and modify NTFS permissions in Azure Storage file shares over SMB.
After that just mount your share to the VM and you can set permissions!
In Deploy a Azure Web App using Gitlab – Part 1 a Gitlab server was installed and some basic settings were applied. In Deploy a Azure Web App using Gitlab – Part 2 a SSL certificate was added so that HTTPS traffic could be used. In this third and final part I will start with what I intended to do; namely deploying a simple web page from Gitlab to an Azure Web App. More specific using a private Git repository so that the “code” will be safe. In short this is what’s going to happen:
1. Create a new project in Gitlab
2. Create a new App service
3. Connecting Gitlab with Azure
4. Connecting Azure with Gitlab
5. Configuring triggers or Webhooks
So creating a new project is pretty easy. Just hit the New Project button and give your project a name. I want to use a private project so that I know nobody can access the resources.
So create the new project and then we can start uploading some basic content. I like to use Visual Studio Code for this. Gitlab is kind enough to provide you with all the necessary commands to get started. These can be found at the project starting page.
In the second part I wanted to share how to implement a SSL certificate into your Gitlab server so you can have a secure connection. Please note that I bought a certificate for my sub domain. There is also documentation available on Gitlab, but I will show every step I took to accomplish this. Furthermore I came across some issues synchronizing Gitlab with my local PC. This was caused by not having the appropriate Root Certificates on the Gitlab server, however this was not explained in the Gitlab documentation.
OK so you will need your key and .crt file. These files will be copied to Gitlab. If you enable HTTPS on your Gitlab server, Gitlab will check the /etc/gitlab/ssl/ directory for the key and certificate. This directory does not exist by default so this has to be created by running
So recently I decided to start writing about things that I want to learn and that interest me. One of the first things I thought of doing was to use Gitlab to deploy virtual machines on Azure. I recently saw the power of using Desired State Configuration (DSC) to manage Windows machines, which were deployed from Gitlab. Basically you can deploy entire environments with some simple code. I thought this was amazing and I wanted to learn how to do this.
But I wanted to start small, and first set up an environment from where I can build more complex projects. So I decided to create a simple Azure Web app to test my environment. This Web App should be connected to a private Gitlab repository. In the process of building this environment I was faced with some challenges, so I thought why not make this the subject of my first blog post. I will show some basic configurations, including enabling HTTPS on Gitlab. And I will show how to deploy a simple website using Gitlab, by pushing code from a local pc.