How to Setup Hybrid Worker Extension in Windows Server Core

Sticking with the most recent theme around Azure Arc, I feel like it is time to update a previous post I wrote about Hybrid Workers with Automation Accounts. At this point, Microsoft is clearly trying to drive everyone to Azure Arc, as they are now recommending using the Hybrid Worker Extension model for deployment. This is great if you are leveraging Azure Resource Manager already, and are looking to get deeper into automation. It’s also great if you are already using Azure Arc. Since I’m looking to move in both of these directions within the lab, it is time to cover setting up a Hybrid Worker as an extension.

To make things more interesting, I intend to run this as Windows Server 2022 Core, rather than the Desktop Experience, as I don’t have as great of a need for a GUI with something like this. Nearly everything will be managed remotely, so why not. I have yet to cover adding a machine running Windows Server Core to Azure Arc yet, so we will cover that as well. Server Core is likely the future of Windows Server, so there’s no reason we shouldn’t be including it where we can. This ought to be short and sweet, so lets get to it!

DISCLAIMER

Please understand that the content herein is for informational purposes only. This existence and contents shall not create an obligation, liability or suggest a consultancy relationship. In further, such shall be considered as is without any express or implied warranties including, but not limited to express and implied warranties of merchantability, fitness for a particular purpose and non-infringement. There is no commitment about the content within the services that the specific functions of the services or its reliability, applicability or ability to meet your needs, whether unique or standard. Please be sure to test this process fully before deploying in ANY production capacity, and ensure you understand that you are doing so at your own risk.

Table of Contents

Notes to Get Started
Enroll Windows Server Core Server in Azure Arc
Hybrid Worker Extension Deployment
Conclusion


Notes to Get Started

There are a few obvious prerequisites that should be covered. First, go check out my previous posts to get an idea of where we are starting. Both of these go through what I am talking about here with Azure Arc and the original Hybrid Worker setup.

How to Bring Your Home Lab to the Cloud – Azure Arc » See Smitty…
More Automation! Using Hybrid Worker Runbooks in Azure Automation » See Smitty…

Connectivity

So we need to figure out some connectivity. With my previous blog post for Azure Arc, we configured public endpoint access as the default. This is fine for the home lab for now, but long term we should consider whether or not we want to maintain that. A private endpoint would require that we have a VPN tunnel between Azure and the Lab, so I’ll need to stick with that for now. If you wanted to have more secure access, then you should consider creating a VPN tunnel and using a private endpoint. Blog post for another time perhaps…

Capability

One thing to consider about this is whether or not the capabilities you are looking for can actually run using the extension. My original long term plan was to automate Windows Patch Management with Automanage, which uses a Hybrid Runbook Worker and Azure Automation. Moving to the extension ensures that we can stay on the latest features as we move in this direction. However, at present, Update Management isn’t supported with the Azure Monitor Agent, and it won’t in the future either. So I’ll be finding a separate use for this instead 🙂


Enroll Windows Server Core Server in Azure Arc

To use the Hybrid Worker Extension, we will need to have the server enrolled in Azure Arc. Extensions are leveraged by Azure Servers to add additional capabilities, similar to installing applications, so naturally our On-Premises server will need to be enrolled in Azure Arc for the extension to work.

I’m including this for 2 reasons. One, I didn’t know how to do it and I would likely forget when I have to do it again, so like many other things in this blog, I’m saving it here for my own benefit. Two, its not obvious if you aren’t familiar with Windows Server Core, so you may not know how to do this either. For additional information, check out this link here.

Connect to Remote Session

  • First we will connect to our Server core server using a PSSession. This will be performed on a device with a GUI (our workstation or a Windows Server with Desktop Experience). Saving these things as variables makes exiting and re-entering the session easy if we need to be able to switch between sessions, without needing to create a new session every time.
#Prompt to enter session credentials
$creds = Get-Credential

#Create a new session to the server we want to connect to with our saved credentials
$session = New-PSSession -ComputerName "serverNameHere" -Credential $creds

#enter our remote session in the console
Enter-PSSession -Session $session

Now we have a session on our remote server.

Device Code Authentication

Something I didn’t realize you could do was to force device code based authentication for sessions that don’t support browser login. This is helpful for remote PS sessions, which is most common when working with Windows Server Core. That is how we will be connecting to Azure in PowerShell for a remote session.

  1. To connect to our remote session we first have to ensure we have the right modules in place. In this instance, we are going to install the ConnectedMachine sub-module from the Az module from PSGallery.
creating a remote session to prepare for remote authentication
Install-Module -Name Az.ConnectedMachine
  1. Next we will get connected with a device code, since a remote PowerShell session won’t support the default Browser login. This will allow you to perform authentication from a different device.
Connect-AzAccount -DeviceCode
begin remote powershell authentication
  1. You will be informed to open https://microsoft.com/deviceLogin from another device, and enter the code on the screen. You should be able to complete authentication on a separate device for your remote session.
remote session powershell sign in screen.

Finish Azure Arc Enrollment

  1. Once your console shows your session is authenticated, run these commands to enroll your remote device into Azure Arc.
#Establish our variables
$rg = "Resource-Group-Name"
$name = "hybrid-worker-device-name"
$loc = "region"

#Connect the machine to Azure
Connect-AzConnectedMachine -ResourceGroupName $rg -Name $name -Location $loc
installation of azure arc to prepare for the hybrid worker extension

Once complete you will see a message confirming the region and whether it was successful. Now all that is needed is to login to the Azure Portal and confirm you see the new server listed.

azure arc servers eligible for the hybrid worker extension

Hybrid Worker Extension Deployment

From here, we will deploy our Hybrid Worker Extension. If you don’t already have a Hybrid Worker Group created, you will need to create one following these instructions. After that, follow these steps to connect your Azure Arc server as a Hybrid Worker.

  1. After logging into the Azure portal, go to your Hybrid Worker Group in Azure Automation. Click on the group you’ve created for your Hybrid Workers.
hybrid worker groups
  1. From here, click on Hybrid Workers to see any workers you already have assigned to the group. Click Add to add your newly created worker.
hybrid worker group
  1. Select the newly added Azure Arc server and hit Add. This will install the extension and allow us to run our scripts in the lab from our Azure Automation Account.
selecting a server to deploy the hybrid worker extension
  1. From here, we wait for the Hybrid Worker extension to finish installing. This can take a few minutes depending on your available resources.
hybrid worker extension is installing

Once it is finished, we will see the new server in the list.

our new server is connected with the hybrid worker extension

I recommend running a test script on it from the runbook console to make sure it was successful. Something like this should work.

#Returns the Device Name where the PowerShell script is running
Get-WmiObject -Class Win32_ComputerSystem | Select-Object -ExpandProperty Name

As we can see below, we have managed to connect to our Hybrid Worker, and return the correct name.

successfully ran on the hybrid worker extension

Conclusion

There you have it! Now we have a Server core instance running on premises, connected via Azure Arc and available to Azure Automation for running our scripts. Leveraging this Hybrid Worker Extension deployment model will allow us to continue running Azure Automation scripts for a long time without needing to upgrade. This should provide us with additional flexibility for our Azure Automations, and give us an opportunity to continue learning. Eventually I would like to go back and create a VPN connection, and add a private link to our Hybrid Workers, but in the mean time, we have a connection and can continue to use what we have.

I hope this bit about deploying the Hybrid Worker Extension was interesting to you. If you found it useful, please hit me up on the ‘site formerly known as Twitter’ @SeeSmittyIT to let me know what you thought of this post. Or if you are avoiding the X-bird site, I’m also posted up on Mastodon @[email protected]. Thanks for reading!

Smitty

Curtis Smith works in IT with a primary focus on Mobile Device Management, M365 Apps, and Azure AD. He has certifications from CompTIA and Microsoft, and writes as a hobby.

View all posts by Smitty →