Questions about the correct licensing of Microsoft Azure Local
Hello dear Tech Community, I hope I am posting this in the right place, please move to the correct section if necessary. We have the following customer situation: Planned acquisition of 2 host servers (2x 32 Core AMD EPYC CPU per Server) for Microsoft Azure Local usage with Windows 11 Multihost locally hosted (220 users). Is it possible to avoid the monthly costs for Azure by using the Azure Hybrid Benefit and license regularly via OEM Datacenter + Software Assurance or Open Value Datacenter + Software Assurance? Planned licensing options: Licensing Option 1: (Software Assurance only for SRV license, no Software Assurance for CALs): OEM licenses + Software Assurance for server OS. Use of Azure Hybrid Benefit (Bring your Own License - only with active Software Assurance!) 8x Microsoft Windows Server 2025 Datacenter OEM 16 Core 44x Microsoft Windows Server 2025 5-User CAL OEM 8x Microsoft OPEN Value Windows Server Datacenter 16 Core Licence Software Assurence 3 Years Upfront Cores - OVL - NL Licensing Option 2: Open Value 3Y Upfront Use of Azure Hybrid Benefit (Bring your Own License - only with active Software Assurance!) 8x Microsoft Windows Server Datacenter Edition Software Assurance 16Core 3Y-Y1 OVL 220x MS OVL-NL Windows Server CAL Lic+Software Assurance 3Y-Y1 Licensing Option 3: CSP Subscription Use of Azure Hybrid Benefit (Bring your Own License via subscription license) 12x Windows Server 2025 Datacenter - 8 Core License Pack - 3 Year Term- CSP - ABO 220x Windows Server 2025 CAL - 1 User CAL - 3 Year Term- CSP - ABO Licensing Option 4: Azure Local directly (no CAL´s needed) 128x Azure Local - Monthly service fee - per core per month 128x Windows Server subscription (for guests) - Monthly service fee - per core per month Are the four options I listed legally applicable for the planned project mentioned above? Thank you in advance!Deploy Open Web UI on Azure VM via Docker: A Step-by-Step Guide with Custom Domain Setup.
Introductions Open Web UI (often referred to as "Ollama Web UI" in the context of LLM frameworks like Ollama) is an open-source, self-hostable interface designed to simplify interactions with large language models (LLMs) such as GPT-4, Llama 3, Mistral, and others. It provides a user-friendly, browser-based environment for deploying, managing, and experimenting with AI models, making advanced language model capabilities accessible to developers, researchers, and enthusiasts without requiring deep technical expertise. This article will delve into the step-by-step configurations on hosting OpenWeb UI on Azure. Requirements: Azure Portal Account - For students you can claim $USD100 Azure Cloud credits from this URL. Azure Virtual Machine - with a Linux of any distributions installed. Domain Name and Domain Host Caddy Open WebUI Image Step One: Deploy a Linux – Ubuntu VM from Azure Portal Search and Click on “Virtual Machine” on the Azure portal search bar and create a new VM by clicking on the “+ Create” button > “Azure Virtual Machine”. Fill out the form and select any Linux Distribution image – In this demo, we will deploy Open WebUI on Ubuntu Pro 24.04. Click “Review + Create” > “Create” to create the Virtual Machine. Tips: If you plan to locally download and host open source AI models via Open on your VM, you could save time by increasing the size of the OS disk / attach a large disk to the VM. You may also need a higher performance VM specification since large resources are needed to run the Large Language Model (LLM) locally. Once the VM has been successfully created, click on the “Go to resource” button. You will be redirected to the VM’s overview page. Jot down the public IP Address and access the VM using the ssh credentials you have setup just now. Step Two: Deploy the Open WebUI on the VM via Docker Once you are logged into the VM via SSH, run the Docker Command below: docker run -d --name open-webui --network=host --add-host=host.docker.internal:host-gateway -e PORT=8080 -v open-webui:/app/backend/data --restart always ghcr.io/open-webui/open-webui:dev This Docker command will download the Open WebUI Image into the VM and will listen for Open Web UI traffic on port 8080. Wait for a few minutes and the Web UI should be up and running. If you had setup an inbound Network Security Group on Azure to allow port 8080 on your VM from the public Internet, you can access them by typing into the browser: [PUBLIC_IP_ADDRESS]:8080 Step Three: Setup custom domain using Caddy Now, we can setup a reverse proxy to map a custom domain to [PUBLIC_IP_ADDRESS]:8080 using Caddy. The reason why Caddy is useful here is because they provide automated HTTPS solutions – you don’t have to worry about expiring SSL certificate anymore, and it’s free! You must download all Caddy’s dependencies and set up the requirements to install it using this command: sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list sudo apt update && sudo apt install caddy Once Caddy is installed, edit Caddy’s configuration file at: /etc/caddy/Caddyfile , delete everything else in the file and add the following lines: yourdomainname.com { reverse_proxy localhost:8080 } Restart Caddy using this command: sudo systemctl restart caddy Next, create an A record on your DNS Host and point them to the public IP of the server. Step Four: Update the Network Security Group (NSG) To allow public access into the VM via HTTPS, you need to ensure the NSG/Firewall of the VM allow for port 80 and 443. Let’s add these rules into Azure by heading to the VM resources page you created for Open WebUI. Under the “Networking” Section > “Network Settings” > “+ Create port rule” > “Inbound port rule” On the “Destination port ranges” field, type in 443 and Click “Add”. Repeat these steps with port 80. Additionally, to enhance security, you should avoid external users from directly interacting with Open Web UI’s port - port 8080. You should add an inbound deny rule to that port. With that, you should be able to access the Open Web UI from the domain name you setup earlier. Conclusion And just like that, you’ve turned a blank Azure VM into a sleek, secure home for your Open Web UI, no magic required! By combining Docker’s simplicity with Caddy’s “set it and forget it” HTTPS magic, you’ve not only made your app accessible via a custom domain but also locked down security by closing off risky ports and keeping traffic encrypted. Azure’s cloud muscle handles the heavy lifting, while you get to enjoy the perks of a pro setup without the headache. If you are interested in using AI models deployed on Azure AI Foundry on OpenWeb UI via API, kindly read my other article: Step-by-step: Integrate Ollama Web UI to use Azure Open AI API with LiteLLM Proxy
Question: How to allow multiple users on Azure VM
Some partners followed the below article and were able to resolve their issue: https://community.dynamics.com/365/b/dynamics365enterprisecloudfronts/posts/setup-simultaneous-remote-login-for-multiple-users Here are a few other responses from community influencers: Comment: This sounds like a scenario where you are hosting an application/service for end customers, e.g. a SaaS offering, but as rich client where RDP protocol is required. The solution is to enable Remote Desktop Services to allow multiple users working simultaneous on a VM. You could either build a RDS farm in Azure yourself, or you use Windows Virtual Desktop as Gateway/broker Service to publish the application, which I would recommend. You need to use WVD with Windows Server-based session hosts though, not WVD with Windows 10 Multi-Session - this is because of licensing reasons. Since you are providing a hosted service, the access of the end customers would need to be licensed via RDS Subscriber Access Licenses (RDS SALs) obtained via SPLA, for hosted scenarios like this there is no other option then to use SPLA licenses because usage of RDS role is not covered with the Windows VM license that Azure offers. Comment: Does not change that you need RDS and the licenses (RDS CALs - or RDS SALS via SPLA when it is about a hosted solution like described by the OP). Since this thread was revived via the new post, and since there were changes, some additional information: You can now also offer Windows Client OS (Windows 10/11 Multisession) in Azure Virtual Desktop as basis for your hosted, custom services/apps, not only Windows Server how I described. This is possible because there is a new licensing options - AVD remote app streaming: What is Azure Virtual Desktop remote app streaming? - Azure | Microsoft Docs
