Microsoft Virtualization Discussions

Invoke-NcSysstat returns different output format when called within a script

lewis_pomeroy

When running Connect-NcController and then Invoke-NcSysstat -node <nodename> from a PS command line, it returns the standard output like in the documentation.  Includes the node name, CPU %, various protocol stats, etc etc on a single line updating on the 5 second interval as would be expected.   However when you run this from within a powershell script, the results are very much different.  I have looked at all the PS settings and environment variables and found no differences so far.  Wondering if anyone else has ran into this by chance or knows of a workaround to prevent it?   The client is Win7 and Toolkit version 3.1

A PS script determines some info as to how many nodes a cluster has and then executes the following line:

start-process powershell.exe -argument "-nologo -noexit -File .\Stats.ps1"

The script Stats.ps1 then attempts to run the Invoke-NcSysstat cmdlet in the resulting window:

Connect-NcController -name cluster01 -Cred loginID

Invoke-NcSysstat -node cluster1-01

The cmdlet runs just fine, but the output is completely weird compared to any documentation that I have seen.  This resulting output in the newly created powershell window is listed below.  I am trying to discover why this output is so drastically different when Invoke-NcSysstat is called within a script versus when it is ran on a command line, and hopefully find a workaround if anyone else has ran into this issue before.

NcController          : cluster1
Node                  : cluster1-01
CifsOps               : 0
FcpOps                : 0
HttpOps               : 0
IscsiOps              : 0
NfsOps                : 5859.8333333333333333333333333

NetBytesReceivedPerSecond : 238311594.66666666666666666667

NetBytesSentPerSecond : 253685760
DiskBytesReadPerSecond: 38395904

DiskBytesWrittenPerSecond : 40650069.333333333333333333333

CpuBusy               : 74.663116524428080281888226490
AvgProcessorBusy      : 35.006236760762406766790643610
TotalProcessorBusy    : 280.04989408609925413432514891
TimeStamp             : 5/15/2014 12:19:46 PM
Name                  : system
Uuid                  : cluster1-01:kernel:system
CPU                   : 35.006236760762406766790643610
NFS                   : 5859.8333333333333333333333333
CIFS                  : 0
HTTP                  : 0
FCP                   : 0
iSCSI                 : 0
NetRcvd               : 238311594.66666666666666666667
NetSent               : 253685760
DiskRd                : 38395904
DiskWr                : 40650069.333333333333333333333
1 REPLY 1

beam

When running commands in a script, any objects written to the pipeline are automatically sent to the default output formatter.  The Connect-NcController command writes the controller object to the pipeline, which is written to the console in a table format.  The Invoke-NcSysstat also writes objects to the pipeline, but they are not controller objects, so they do not fit into the controller table that had been created.  As a result, the sysstat objects are written as a list.  There are a few ways to change this.

1) You could capture the output of Connect-NaController into a variable.  Then you can use Write-Host to write a message to the console indicating the connection context.  For example:

$controller = Connect-NaController <IP>

Write-Host "Connected to $($controller).Name"

Invoke-NcSysstat

2) You could direct the output of Connect-NaController to Out-Null so it is not written at all.  For example:

Connect-NaController <IP> | Out-Null

Invoke-NcSysstat

3) You can direct Invoke-NcSysstat to format-table to force the table formatting.  For example:

Connect-NaController <IP>

Invoke-NcSysstat | Format-Table

-Steven

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public