Azure-pipelines-agent: Support Windows Server Nano

[peder]

Not sure if you want random questions posted here or if there's a forum elsewhere, but are you planning on supporting running the agent on Windows Server Nano?

[TingluoHuang]

@peder the agent should be able run on any platform that dotnet core supported.
I would like to ask @bryanmacfarlane to answer whether we will support WinServer Nano.

[bryanmacfarlane]

Theoretically it should

https://github.com/dotnet/cli/issues/2967

If it runs on it, we will support it.

Interesting question would be what you would be automating (powershell scripts). Not sure, you'll get VS etc.. on a nano server but I could see deploying to it.

Try it out and let us know what you find.

[hamidshahid]

Hi,
Can we re-open this issue. I tried to run it on Nano-Server and didn't work.

[bryanmacfarlane]

Can you add details about what didn't work? What error did you get?

[hamidshahid]

Yes, sure.

So when I run config.cmd file, it first gives the following error

-Sta : The term '-Sta' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is
correct and try again.
At line:1 char:1

• -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Comman ...
• ~~~~
  
  
  
  • CategoryInfo : ObjectNotFound: (-Sta:String) [], CommandNotFoundException
  
  
  • FullyQualifiedErrorId : CommandNotFoundException
  
  

Which is followed by prompt to enter my server URL, authentication type and PAT. Once I gave it, I get the following errror

An error occurred while sending the request. Failed to connect. Try again or ctrl-c to quit

Had a look at the diag folder and saw the following in the logs

[2016-10-18 07:29:46Z ERR Terminal] System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.Http.WinHttpException: The parameter is incorrect at System.Net.Http.WinHttpAuthHelper.SetWinHttpCredential(SafeWinHttpHandle requestHandle, ICredentials credentials, Uri uri, UInt32 authScheme, UInt32 authTarget) at System.Net.Http.WinHttpAuthHelper.CheckResponseForAuthentication(WinHttpRequestState state, UInt32& proxyAuthScheme, UInt32& serverAuthScheme) at System.Net.Http.WinHttpHandler.d__101.MoveNext() --- End of inner exception stack trace --- at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.d__3.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Net.Http.HttpClient.d__58.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult()
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d__45.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult() at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.d__421.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult() at Microsoft.VisualStudio.Services.Location.Client.LocationHttpClient.d__6.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult() at Microsoft.VisualStudio.Services.WebApi.Location.VssServerDataProvider.d__41.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.Agent.AgentServer.d__3.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.Agent.Listener.Configuration.ConfigurationManager.d__10.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.Agent.Listener.Configuration.ConfigurationManager.d__7.MoveNext() [2016-10-18 07:29:46Z ERR Terminal] WRITE ERROR: Failed to connect. Try again or ctrl-c to quit

Following are the details of my OS

Windows Version: Microsoft Windows [Version 10.0.14393]

.Net Core Version : 1.0.1
.Net Core Build : cee57bf6c981237d80aa1631cfe83cb9ba329f12

[hamidshahid]

I have stored the container in a tar file, in case you need to access it

[TingluoHuang]

@hamidshahid Can you check the PAT you used hasn't expired and has agent pool manage scope?
Also what version of PowerShell you have on that box?

[hamidshahid]

No, it hasn't expired yet. I used it from my host machine and it worked fine.
Below is my PS version info

Major Minor Build Revision

---

5 1 14393 1000

[hamidshahid]

HI,
Any luck with finding a solution to this issue please?

[ericsciple]

It's likely not just this issue. The Windows build of the agent currently makes an assumption that Full .NET is installed. It has validation checks that verify that .NET >= 4.5 is installed. It sounds like it's missing validation to distinguish between .NET Full and .NET Core.

My understanding is that Nano doesn't have .NET Full, and only has .NET Core. We'll need to take a pass through the agent, given Nano constraints, and figure out what it means for an agent running on Nano.

[hamidshahid]

Thank you for the update. I had to install dotnet core on Windows Nano. Please update the issue when there is progress on this. Many thanks.

[Joon]

I could really use Windows NanoServer support too.

I have a requirement to run a VM as a release agent in every one of my Azure subscriptions, and using NanoServer is preferable because of the ease of management and small footprint of the NanoServer OS.

[NickMRamirez]

This is caused by Nano server having a different version of powershell.exe that does not support all of the flags as on other OS versions. For example, running powershell -? on Windows 10 returns many flags, including -Sta, but on Nano it only returns this:

USAGE: powershell [-Verbose] [-Debug] [-File <filePath> <args>] [-Command] <CommandLine>

So, it looks like the -Sta flag is not available on Nano.

The config.cmd file uses many powershell.exe flags, such as:

powershell.exe -NoLogo -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ...

[NickMRamirez]

This may be a way to check if the OS is nano: http://www.dexterposh.com/2016/05/powershell-check-script-running-on-nano.html

[Schapp0]

Was there any workaround or update installing vstsagent on a Windows Nano Server as I'm having the same issues running config.cmd with '-Sta' is not recognized as the name of a cmdlet error.

[jabbera]

That flag should not even be necessary. Powershell 3.0 starts in a single threaded apartment by default and that is the minimum required for the agent.

https://docs.microsoft.com/en-us/powershell/scripting/core-powershell/console/powershell.exe-command-line-help?view=powershell-5.1#-sta

https://docs.microsoft.com/en-us/vsts/build-release/actions/agents/_shared/qa-windows-agent-powershell-version

[wes566]

@ericsciple any update on this?

[ericsciple]

Nope, user voice might be a good place to gain traction on this

Note, the work involved isn't just about making the agent startup. It's about making the capability scripts work, making the source providers work, making tasks work, proxy settings, run as service/autologon, etc. Many of the implementations for tasks on Windows leverage the powershell task execution handler. Today we don't have a powershell-core execution handler - but I think we are probably going to add one. So it might make sense to do that work at the same time.

[jabbera]

See the following issue for why this would be a gr at idea: https://github.com/Microsoft/vsts-agent-docker/issues/33

[bryanmacfarlane]

@jabbera - regarding nano and docker, we're about to release formal docker support. In formal docker, the agent won't be in the container. So you will be able to use nano for docker. The agent runs in the host and runs tasks in the container. That also allows some steps to run in one image, then others produce an image, then others run in the image created etc...

Design here: https://github.com/Microsoft/vsts-agent/pull/1384/files

[jabbera]

Thanks @bryanmacfarlane! This will be excellent. Yaml only? I’m really looking for my teams to be able to manage their own image/build deps off our base image with all the basics. They still will want the ui for managing their pipelines though.

[bryanmacfarlane]

It will start in yaml then make it's way to the UI. yaml might still end up with more controls and flexibility. But the UI will at a minimum offer run this phase in a container.

[jabbera]

That’s fine. Most of my teams want 4 things: an ephemeral build environment, the ability to maintain their own build image, the ability to use the same build steps on their desktop for compilation/testing, and a simple way to layout their task sequence. This covers most of those it looks like.

[WinInsider]

@ericsciple PowerShell team was been making improvements to more portable support via https://github.com/PowerShell/PowerShellStandard

Please reexamine feasibility of making vsts agent run on Nano Server... As is a great platform !

Let's all embrace .net core, even on Windows

[bryanmacfarlane]

We embraced .net core on windows :) The agent is written in .net core

We will take another look. The issue will likely not be in the agent. There's tasks written in powershell (released in the market place) that have scripts that likely have expectations on full .net desktop and full powershell.

We propbably would need to introduce the ability to create tasks in powershell core and then deprecate full powershell / .net to increase our reach

[WinInsider]

@bryanmacfarlane this line is a problem... In agent.listener.program.cs there is no .NET 4.5 on Nano Server

https://github.com/Microsoft/azure-pipelines-agent/blob/3cd0b5dd4331c83f235887735bf546c161ade7d4/src/Agent.Listener/Program.cs#L103

Removing this line is first step, 3rd party plugins, are responsibility of there authors.

[lezardo]

Any news 7 months later?

Besides the release of formal docker support @bryanmacfarlane mentioned on Feb 20, 2018 do you really plan to support Azure pipelines agent running on nano server containers?

I have to go with a servercore image which has much bigger footprint. It’s annoying to be forced to use Linux to build .Net Core on containers even if has been partly designed for that.

Please tell us where do we stand on that.

[bryanmacfarlane]

@jtpetty can discuss with Zac and have a fresh look at this issue.

[garfbradaz]

We embraced .net core on windows :) The agent is written in .net core

We will take another look. The issue will likely not be in the agent. There's tasks written in powershell (released in the market place) that have scripts that likely have expectations on full .net desktop and full powershell.

We propbably would need to introduce the ability to create tasks in powershell core and then deprecate full powershell / .net to increase our reach

@bryanmacfarlane Are there any up-for-grabs issues for this so the community can help? There is a Nano Image that comes with Powershell Core now, but unfortunately as stated, there is a Powershell dependency the agent needs. Example error I get when I attempt to run the agent:

1. Running Azure Pipelines agent...
   'powershell.exe' is not recognized as an internal or external command,
   operable program or batch file.
   Error reported in diagnostic logs. Please examine the log for more details.
   
   
   
   • C:\azp\agent_diag\Agent_20191206-180945-utc.log
     
     An error occurred: PowerShell is not installed. Minimum required version: 3.0
     
     Cleanup. Removing Azure Pipelines agent...
     
     'powershell.exe' is not recognized as an internal or external command,
     
     operable program or batch file.
     
     Error reported in diagnostic logs. Please examine the log for more details.
   
   
   • C:\azp\agent_diag\Agent_20191206-180946-utc.log
     
     An error occurred: PowerShell is not installed. Minimum required version: 3.0
   
   

Use Case:

I want to roll out a slim self hosted agent to each developers VM so they can run "local" builds. The Windows Server core image is just too large.

[SQLHorizons]

Hi, tried running this on mcr.microsoft.com/windows/nanoserver:1903 & 2004 but failing due to issue with PowerShell:

An error occurred: PowerShell is not installed. Minimum required version: 3.0

Notes below:

Running ado-agent on nano

• remove ado-agent container: docker rm ado-agent --force
• launch ado-agent container:

$vsts_container = @{
    FilePath     = "docker"
    ArgumentList = @(
        "run"
        "--name ado-agent"
        "--restart=on-failure:1"
        "-d=true"
        "-it"
        "--volume=`"C:\Program Files\PowerShell`":`"C:\Program Files\PowerShell`""
        "mcr.microsoft.com/windows/nanoserver:1903"
    )
}
Start-Process @vsts_container

• append to PATH: docker exec -u administrator ado-agent cmd /c setx /M PATH "%PATH%;C:\Program Files\PowerShell\"
• set VSTS_TOKEN: docker exec -u administrator ado-agent cmd /c setx /M VSTS_TOKEN $env:VSTS_TOKEN
• set url to functions: $url = "https://raw.githubusercontent.com/SQLHorizons/functions/master/public"
• set functions: docker exec -u administrator ado-agent cmd /c setx /M functions $url
• create ado agent deployment script block:

$deploy = {
    $ServerParams = @{
        DeploymentGroup = "UKDB-DEVOPS"
        role            = "deployment"
        dns             = "ado-agent.sqlhorizons.com"
    }

    Invoke-WebRequest -UseBasicParsing "$env:functions/Install-VSTSAgent.ps1" | Invoke-Expression
    Install-VSTSAgent -ServerParams $ServerParams
}

• deploy ado agent: docker exec -u administrator ado-agent pwsh -Command $deploy -NoLogo -NoProfile
• start interactive shell inside the container: docker exec -u administrator -it ado-agent pwsh.exe

[2020-08-14 15:57:05Z ERR  Terminal] WRITE ERROR: An error occurred: PowerShell is not installed. Minimum required version: 3.0
[2020-08-14 15:57:05Z ERR  AgentProcess] System.InvalidOperationException: PowerShell is not installed. Minimum required version: 3.0
   at Microsoft.VisualStudio.Services.Agent.Util.PowerShellExeUtil.GetPath()
   at Microsoft.VisualStudio.Services.Agent.Listener.Program.MainAsync(IHostContext context, String[] args)

[github-actions[bot]]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[hangy]

This issue has had no activity in 180 days. Please comment if it is not actually stale

The bot doesn't seem to recognize the no-stale label?