"Invoke-VMScript -ScriptType BAT "return garbled when guestos is Chinese edition

[qdljc]

GuestOS:Win2016 core Chinese edition

ESXI version: 6.5.0 Update 1 (Build 5969303)

PowerCLI version: 6.5 R1 4624819

vmware tools version:10.2.0-7253323

===1: BAT===

$VM = 'Win2016-SC-Core'

$script ="ipconfig"

$GuestUser = ‘administrator’

$GuestPassword = '***'

$secpasswd = ConvertTo-SecureString $GuestPassword -AsPlainText -Force

$GC = New-Object System.Management.Automation.PSCredential ($GuestUser, $secpasswd)

Invoke-VMScript -vm $VM -GuestCredential $GC -ScriptText $script -ScriptType BAT

===running result=======

|  Windows IP ����

|

|

|  ��̫�������� Ethernet0:

===2: Default===

$VM = 'Win2016-SC-Core'

$script ="ipconfig"

$GuestUser = ‘administrator’

$GuestPassword = '***'

$secpasswd = ConvertTo-SecureString $GuestPassword -AsPlainText -Force

$GC = New-Object System.Management.Automation.PSCredential ($GuestUser, $secpasswd)

Invoke-VMScript -vm $VM -GuestCredential $GC -ScriptText $script

===running result=======

|  Windows IP 配置

|

|

|  以太网适配器 Ethernet0:

===================

local chcp:      cp936

guestos chcp: cp936

How do I get the results of Chinese？

[LucD]

Not sure if it even is possible to return double-byte character set output via Invoke-VMScript when running a BAT type script.

But as a bypass, you could run the ipconfig command through the PowerShell scripttype, s in your example code2.

Is there a specific reason why you would need to run the code as BAT?

[qdljc]

GuestOS didnot install Power shell。

[LucD]

Does it not contain PowerShell because you install the OS like that, or did the PowerShell installation fail?

[qdljc]

I have several versions of Windows in different networks(DMZ/dev/test/inside), and all Windows does not have the power shell installed. Now I want to modify all Window's DNS Server, now the script can work, just return the garbled.

If I send “chcp 65001” first, it return English. I'm just wondering why Chinese font is garbled in BAT mode and powershell is right. Bug? or can add some cmdlet or parameters?

[LucD]

I suspect that the BAT and Invoke-VMScript have issues with UniCode characters.

Can you try sending cmd.exe /U /C ipconfig which forces UniCode.

Did you change the CodePage (chcp) on both stations (the one where you call Invoke-VMScript and the VM to which you send the commad/script

[qdljc]

Thank you Luc, I will test the cmd command parameters later, it looks like this parameter may be effective. I'll let you know the result.

I have tested both chcp65001, it returns english, but I want to get the results in Chinese.

[LucD]

I'm suspecting this is more of an issue of Windows/DOS regional settings, than it is a PowerCLI issue.

[qdljc]

I'm sorry to tell you cmd.exe /U /C ipconfig has no effect.  cmd.exe /A /C ipconfig has no effect too.

Local CHCP 936/65001 has no effect on results. Remote CHCP 936 means garbled, Remote CHCP 65001 means garbled.

Tomorrow I will test the VC installed on the English Windows。

Command: chcp && cmd.exe /U /C ipconfig

ScriptOutput

-----------------------------------------------------------------------------------------------------------------------

|  �����ҳ: 936

|

|  Windows IP ����

|

|

|  ��̫�������� Ethernet0:

Command: chcp 65001 && cmd.exe /U /C ipconfig

ScriptOutput

-----------------------------------------------------------------------------------------------------------------------

|  Active code page: 65001

|

|  Windows IP Configuration

|

|

|  Ethernet adapter Ethernet0:

[LucD]

I assume that the station from where you launch the Invoke-VMScript has the corresponding setting?

[qdljc]

Here are the tests I've done.

The UTF8 format of the sent Chinese can be returned to normal, Remote CMD's output of Chinese is garbled all.

I install VC on English OS, I got the same.

1. Run-RemoteVM-WinBat2.txt     //BAT command file. UTF-8 wothout BOM.

2. Run-RemoteVM-WinBat-test2.ps1          //PS1 file. UTF-8 wothout BOM.

3. Local 936, GuestOS 936，

4. Local 65001, GuestOS 936

5. GuestOS  set chcp 65001

6. Local 65001, GuestOS 65001

7. Local 65001, GuestOS 65001

8. In GuestOS 936:

9. In GuestOS 65001