In this blog post, I want to guide you through the process of using Visual Studio Code (VS Code) and the AZ PowerShell module to do automation in Azure. I have three main points I want to go through and that is
As many of you probably know I do a lot of PowerShell scripting when time allows it, and after scripting, for many years I finally saw the need for source control. Source control not only ensures that I can revert back to a previous version of my code, but it also provides me with a single place to find all my code. I am using source control for both my personal work (like Citrixlab.dk and helping others out) and also for my professional work where I use a shared repository with my colleagues.
One of the most exciting news I got at Citrix Summit and PTEC was that Citrix is integrating their purchase of Sapho into their Workspace. This integration has so much potential to help the end-users in their daily work and it is huge opportunity to get new customers in that doesn’t use the traditional Citrix products like Virtual Apps and Desktop and ADC.
In part 3 I showed you how to create the Citrix Machine Services Catalog. The machine catalog is now created and we have a virtual machine running the Citrix in the Microsoft Azure Cloud. In this final part of the blog series, I will show you have to create the Citrix Delivery Group which is the mechanism that allows you to publish a desktop or applications. There are different options for assigning these desktops and applications, and in this blog, I will be using the Citrix Cloud library tool to accomplish this.
In part two I showed you how to install the Citrix VDA on a virtual machine running in Microsoft Azure. I also explained that I believe that any updates for software and new software should result in building a new master image from scratch. This is something I recommend based on my experience in editing in very old images, old images often makes you feel nervous of doing any changes. If you have the confidence to build your image from scratch every time you also prove that you have a valid mechanism for migrating to a new cloud provider or on-premises hypervisor. This build mechanism is also valid as a disaster recovery scenario where you can rebuild your Citrix workers instead of trying to restore from a backup.