Archives

Here’s a modified snippet of code from one of our PowerShell scripts that uses SNMP to query info from WYSE thin clients:

#– The below assumes you have a value set for $WYSEClientAddress and SNMPUTIL.EXE in c:tools
#– Get the uptime remotely
$WYSEUptimeTimeTicks = c:toolsSNMPUTIL.exe get $WYSEClientAddress SNMPWYSE .1.3.6.1.2.1.1.3.0 | Select-Object -Skip 1 |% {$(($_ -split ‘=’)[1] -replace (‘TimeTicks’,”)).Trim()}
$WYSEUptimeDays = ([datetime]::Now – ([datetime]::Now).AddSeconds(-($WYSEUptimeTimeTicks[0]/100))).days
$WYSEUptimeHours = ([datetime]::Now – ([datetime]::Now).AddSeconds(-($WYSEUptimeTimeTicks[0]/100))).hours
$WYSEUptimeMins = ([datetime]::Now – ([datetime]::Now).AddSeconds(-($WYSEUptimeTimeTicks[0]/100))).minutes
$WYSEUptimeSecs = ([datetime]::Now – ([datetime]::Now).AddSeconds(-($WYSEUptimeTimeTicks[0]/100))).seconds
$WYSEUptime = “$WYSEUptimeDays” + ” days ” + “$WYSEUptimeHours” + ” hours ” + “$WYSEUptimeMins” + ” mins ” + “$WYSEUptimeSecs” + ” secs”

#– Get the NIC speed remotely
$WYSENICSpeed = c:toolsSNMPUTIL.exe get $WYSEClientAddress SNMPWYSE .1.3.6.1.4.1.714.1.2.6.2.4.0 | Select-Object -Skip 1 |% {$(($_ -split ‘=’)[1] -replace (‘String’,”)).Trim()}

#– Get the firmware version remotely
$WYSEfirmware = c:toolsSNMPUTIL.exe get $WYSEClientAddress SNMPWYSE .1.3.6.1.2.1.1.1.0 | Select-Object -Skip 1 |% {$(($_ -split ‘=’)[1] -replace (‘String’,”)).Trim()}

#– Get the INI server details remotely
$WYSEConfigServer = c:toolsSNMPUTIL.exe get $WYSEClientAddress SNMPWYSE .1.3.6.1.4.1.714.1.2.6.2.2.0 | Select-Object -Skip 1 |% {$(($_ -split ‘=’)[1] -replace (‘String’,”)).Trim()}
$WYSEConfigServerPath = c:toolsSNMPUTIL.exe get $WYSEClientAddress SNMPWYSE .1.3.6.1.4.1.714.1.2.6.2.3.0 | Select-Object -Skip 1 |% {$(($_ -split ‘=’)[1] -replace (‘String’,”)).Trim()}

#– Output the details
$WYSEUptime
$WYSENICSpeed
$WYSEfirmware
$WYSEConfigServer
$WYSEConfigServerPath

I got the MIBs from this post:
http://www.freewysemonkeys.com/modules.php?name=Forums&file=viewtopic&p=8198

This works for us here and we have 761 R10Ls/Xenith Pros here which we issue that remote reboot cmd when we want to quickly get all devices up to the latest firmware.

If you’re getting a failed to connect with the cmd above, set the value of -c:SNMPWYSE to -c:put_your_SNMP_community_string_here

If it doesn’t work, what firmware are you at and also, make sure the SNMP port (I think it’s UDP port 161 or something like that) isn’t blocked.

Hi Fred,

The smart card reader (internal or external) is consumed by WTOS via it’s device driver that it loads. Any CCID compliant reader shows up as a locally connected device.

The method of connectivity of the smart card reader to the remote session is different depending on whether you’re using a non-brokered or brokered environment.

If you are using a non-brokered environment and are directly connecting via RDP or ICA, the smart card virtual channel used by these protocols are instantiated once the session is up and running. The GINA (Windows XP/2003) or Credential Provider (Vista/Win7/2008) get notified of the smart card insertion event via the smart card virtual channel and then allow smart card usage. In this scenario, assuming you have the proper smart card cryptographic service provider (CSP), you’ll be able to use that smart card for logon and PKI-enabled (public key infrastructure) applications.

If you are using .NET smart cards, Windows Vista/7/2008 have the Microsoft BaseCSP built-in which make these type of cards really attractive and easier to support. It’s also the card of choice for the WYSE thin clients since they tend to be more “standardized” than the CSP’s that cater to brand-specific cards (i.e. Axalto CSP for Gemalto Cyberflex JAVA smart cards).

If you are using a broker on the WYSE V10L/V10LE/C10LE’s, this changes quite a bit. Essentially, you are opening the contents of the card at the WYSE device level and allowing the certificate on the smart card to pass-through into the session. The disadvantage here is that there’s a limited set of cards that work since the smart cards have to be unlocked using a PIN prompt at the WYSE device WTOS level. WYSE supports .NET cards and Aladdin eTokens today which should cover the majority of the population but don’t support JAVA-type cards since this would require hefty engineering.

My preference would be to take Gemalto .NET v2+ cards, load ’em up with the appropriate certs, and use a simple Microsoft PKI infrastructure for a small shop and enterprise-grade PKI infra for a big shop (we use Entrust here).

If you’re using a broker, both Citrix Xendesktop and VMware View work with the .NET smart card for both logon and in-session reads/writes. It is also great for session-smooth-roaming or hot-seating or whatever they call it today. If you’re not using a broker, then you’ll have better luck on logons and in-session use on odd-ball cards as long as you have the vendors CSP installed. Non-brokered also allows for hot-seating as you can make a session disconnect on smart card removal. 🙂

Hope this helps and sorry for the long email. I figured I’d put everything down in the email that I know since it might help others. 🙂

If there’s any more info you’d like to know, feel free to ping me. I’ve been trying to learn the smart card space and think it’s getting pretty interesting as VDI benefits greatly from it.

Warmest regards,
–Adam