fix: use azcli login for azcopy in windows

[awesomenix]

Missed some spots with azcli login

[Copilot]

Pull request overview

Updates Windows AzCopy usage to rely on Azure CLI-based authentication instead of MSI for both Windows VHD build-time downloads and Windows e2e log uploads.

Changes:

• Switch AzCopy auth to AZCLI auto-login and adjust env vars for concurrency.
• Remove explicit --login-type=MSI usage and add azcopy login calls in Windows scripts.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
vhdbuilder/packer/windows/configure-windows-vhd.ps1	Updates VHD build-time AzCopy download flow to use AZCLI auto-login.
e2e/vmss.go	Updates the Windows VM RunCommand log-upload script to use AZCLI auto-login and adds an azcopy login step.

[Copilot]

The Windows VM RunCommand log-upload script switches AzCopy auth from MSI to AZCLI, but it doesn't install Azure CLI or run az login. If Azure CLI isn't present on the node image (typical), azcopy login/copy will fail and you'll lose failure diagnostics. Either keep MSI-based AzCopy auth here, or add a non-interactive Azure CLI install + az login --identity flow as part of this script.

Suggested change

	$env:AZCOPY_AUTO_LOGIN_TYPE = "AZCLI"
	$env:AZCOPY_CONCURRENCY_VALUE = "AUTO"
	C:\k\debug\collect-windows-logs.ps1
	$CollectedLogs=(Get-ChildItem . -Filter "*_logs.zip" -File)[0].Name
	.\azcopy.exe login
	$env:AZCOPY_AUTO_LOGIN_TYPE = "MSI"
	$env:AZCOPY_CONCURRENCY_VALUE = "AUTO"
	C:\k\debug\collect-windows-logs.ps1
	$CollectedLogs=(Get-ChildItem . -Filter "*_logs.zip" -File)[0].Name
	.\azcopy.exe login --identity

[Copilot]

uploadLogsPowershellScript still takes $arg3 (and the Go code still passes the VM identity resource ID), but after this change $arg3 is no longer used. Either remove the unused parameter/wiring, or keep MSI-based auth that consumes it, to avoid confusion about which identity AzCopy is using.

Suggested change

	$env:AZCOPY_AUTO_LOGIN_TYPE = "AZCLI"
	$env:AZCOPY_CONCURRENCY_VALUE = "AUTO"
	$env:AZCOPY_AUTO_LOGIN_TYPE = "MSI"
	$env:AZCOPY_CONCURRENCY_VALUE = "AUTO"
	if (-not [string]::IsNullOrEmpty($arg3)) {
	$env:AZCOPY_MSI_RESOURCE_ID = $arg3
	}

[Copilot]

AZCOPY_AUTO_LOGIN_TYPE is being switched to AZCLI, but the script never ensures Azure CLI is installed/logged in on the Windows build VM. On a default Windows Server image this typically means azcopy.exe login/copy will fail (or prompt for interactive device login), breaking VHD builds that rely on Download-FileWithAzCopy for private downloads. Consider either (a) explicitly performing a non-interactive az login --identity before running AzCopy (and avoid azcopy login entirely), or (b) keep using --login-type=MSI for headless builds.

[Copilot]

azcopy.exe login is now invoked with no --login-type, which can default to an interactive device-code flow in automation. Since AZCOPY_AUTO_LOGIN_TYPE is already set, you can usually remove the explicit login call and let AzCopy auto-auth, or force a non-interactive login type explicitly to avoid hanging the build.