I recently came across an issue when I tried to connect to an Azure server that has a shared folder using the UNC path. It kept saying: You might not have permissions to sue this network resource. Contact your administrator to find out if you have access permissions.
The user name could not be found.
After searching for a while the only suggestion I could find was to change the registry key to not cache credentials. The problem with this is that then it forces you to enter connection details even for local server resources on your domain. I’m sure other users won’t be to happy with that.
The only other solution I could find that worked was to create a credential for the Azure server in Credential Manager. Below is an example of what it would look like:
This solved the problem for me.
This is just a short post explaining how I understand the differences between running a runbook against an Azure VM and using the Runbook worker agent:
When I run a Powershell runbook for example the Powershell session is executed in an”Azure Powershell instance” This means that if I want to target one of my Azure VMs I need to either use the Azure Custom script extension to inject a script to run locally on the VM or use one of the remote PS tools to remotely connect to the VM and execute.
With the Runbook worker you install the Microsoft Management Agent on the VM itself and then register the Agent with your automation account. Once that is done you can directly target the runbook worker VM. This means that any Runbook that I run will run directly on this on premise machine, same as if running an actual powershell script while logged in.
To me this makes it a lot easier to run configurations as I don’t need to run the commands remotely for installing software etc.
Now according to Microsoft’s design as I understood it, you only install for example 1 runbook worker in your on premise environment and then target your other machines using this server. Like this picture below:
Azure on premise automation design
As you can see there is only one runbook worker that does all the work. My question is why not just install the runbook worker on all my machines and then I can target machines directly instead of going through the whole remoting scenario?
Then why not just install the Agent on my Azure machines so I can execute runbooks directly on them as well?