- This topic has 14 replies, 5 voices, and was last updated 6 years, 10 months ago by Stevie.
-
AuthorPosts
-
December 28, 2012 at 5:34 pm #7645
Hello again,
My company is currently using about 10 Wyse Xenith Pro units that are running firmware version 1.7.130. I have been using the USB Firmware Tool to update individual terminals to test the 2.0.015 firmware however we ran into some issues with that version and had to roll back for the time being.
I see what Wyse has released version 2.0.017 and I would like to test this to see whether or not it will resolve our issues however I am not sure about the best way to go about updating our clients for testing.
With version 2.0.015 I was able to easily flash a USB drive with the bios.img, cmos.img, par1.img, and commandsXml.xml files that were downloaded from Wyse to create an image to manually push to the terminals. This time I only have access to the C00_xen and R00_xen files for the new version. Unless I am mistaken, the USB tool us unable to create an image with just these files.
I see that the proper method of widely updating these is through FTP/HTTP from the Xen file server however I want to limit this deployment to a single device for testing until it is adopted globally. Is there a way to do that using this method of upgrading or do I need to push it manually using WDM?
I am looking at the Scruptbuilder create a .rsp script to push the update to a single client through WDM however I am not familiar with the script language and the documentation seems pretty slim at best. Which command would I use to update the device with the new firmware? I’m assuming it would be Send File (SF) to copy it, however I am a bit confused about whether or not this command is used with the Xenith OS. Can someone provide a sample script that would be used to update a Xenith Pro in this manner?
Is there another method I’m overlooking to update a single device for testing?
Thanks very much for any advice.
-Joe
December 28, 2012 at 8:24 pm #23224UPDATE:
The USB Firmware Tool does support .rsp scripts, I overlooked that ability previously. Knowing this now, and having read up a bit on creating .rsp scripts, I should be able to use this to push the R00_xen to the terminal via usb for testing however I’m still a bit hung up on creating the script itself.
So now I need to make sure that the script correctly pushes and installs the update. Will SF (Send File) just copy the R00_xen file or will that also run it as well?
I figured out the value for the source of the files I’m going to push but I don’t know what value I should be entering for the Device Filename value. Do I need to specify a path or can that just be the file name?
Do I need to add any other commands to update the image or will this do it?
As a test I just tried to create a .rsp script with only a SF and RB command to push the R00_xen file to my terminal and reboot it. After saving the script I tried to use the USB Firmware Tool to flash a USB drive with this update however it failed with the error “Invalid file type. Please select a valid rsp or i2d file.”
The script was created using the Wyse Scriptbuilder application and was saved with the following file structure:
2.0.017.rsp
2.0.017R00_xenHere is the content of the script itself:
[Version]
Number=2.0.017
Description=Updates Wyse Xenith Pro to firmware version 2.0.017.
OS=XEN
Category=Agent Update
USE_REMOTE=Yes
; Date: 12/28/2012[Script]
SF “R00_xen” “R00_xen”
RBI feel like I’m missing something important here. Any thoughts what that might be?
Many thanks again as always for any assistance!
-Joe
December 28, 2012 at 11:23 pm #23225Don’t try any further. This will not work.
I guess you are using ftp to configure and update all clients centrally.
Why not using the same way to update only one client?
Create a folder /inc inside the wnos folder. Place a mac.ini file in there, eg. 008064123456.ini and put Autoload=2 in it.
Then put
Include=$mac.ini in the xen.ini or wnos.ini, depending on what you are using. But make sure you put that parameter AFTER the autoload=0 (has to be in there) parameter that is already in your xen.ini .
Also make sure that the name of the mac.ini file corresponds to the correct mac address of the one client you want to upgrade.
Now save the test firmware in the default wnos folder and reboot your test machine.
Done.CG
December 31, 2012 at 3:28 pm #23229ConfGen’s method is probably easiest, but you could separate the client on the network level.
The way I do all my testing is to have different VLANs which allows me to have different DHCP servers, and hence I have a testing environment ‘LAN’ and a production environment ‘LAN’. However, if your router+switches aren’t VLAN/Multi DHCP server capable, this option won’t work for you.
January 9, 2013 at 5:36 pm #23273@ConfGen wrote:
Don’t try any further. This will not work.
I guess you are using ftp to configure and update all clients centrally.
Why not using the same way to update only one client?
Create a folder /inc inside the wnos folder. Place a mac.ini file in there, eg. 008064123456.ini and put Autoload=2 in it.
Then put
Include=$mac.ini in the xen.ini or wnos.ini, depending on what you are using. But make sure you put that parameter AFTER the autoload=0 (has to be in there) parameter that is already in your xen.ini .
Also make sure that the name of the mac.ini file corresponds to the correct mac address of the one client you want to upgrade.
Now save the test firmware in the default wnos folder and reboot your test machine.
Done.CG
im trying to do this method but no update is happening, heres a look at my xen.ini. i put the firmware in the root of wnos folder, and the mac.ini file in a folder called “inc” which resides on the root of the wnos folder.
Autoload=0 Include=008064A81C8C.ini
BootpDisable=yes
AdminMode=yes username=XXXXXX password=XXXXXX
Privilege=None Lockdown=yes
EnableGKey=yes
formurl=header_main_transp.bmp;*************************************************************
;* General 2 *
;*************************************************************Locale=English
;*************************************************************
;* Time *
;*************************************************************Timeserver=XXXXXXXXXXXXXXX Timeformat=”12-hour format” Dateformat=mm/dd/yyyy
TimeZone=’GMT – 08:00′ ManualOverride=yes Daylight=yes Start=030507 End=100507 TimeZoneName=”Pacific Standard Time” DayLightName=”Pacific Daylight Time”;*************************************************************
;* Network *
;*************************************************************SignOn=Yes
;Signon=NTLM DisableGuest=yes
MaxVNCD=1
VncPassword=”JHGCKIHKOGHFOB” Encrypt=yes
VncPrompt=Yes Accept=10;*************************************************************
;* General Session *
;*************************************************************SessionConfig=ALL MapDisks=yes DisableSound=No unmapprinters=yes
;*************************************************************
;* ICA *
;*************************************************************Seamless=yes FullScreenReserved=Yes
PnliteServer=http://XXXXXXXXXXXXXXXXXXXXconnectAtLogon=2 ReconnectFromButton=2 AutoConnectList=”Desktop”
SessionConfig=ICA DesktopMode=Fullscreen SessionReliability=yesJanuary 9, 2013 at 6:10 pm #23275also which file exactly should i be renaming to C00_xen as the firmware file. is it the zip file?
January 10, 2013 at 8:54 am #23280No need to rename it. Leave it as it is.
But you misunderstood my previous post.
The include parameter has to be in a separate line after Autoload=0.
Autoload=0
Include=008064A81C8C.iniCG
January 10, 2013 at 5:07 pm #23291thanks i got it all to work, however it still worked for me when i put include include=$mac.ini
March 7, 2013 at 8:00 pm #23599Ok, so I am revisiting this many weeks later, sorry for the huge delay. My boss’s priorities shifted significantly so this had to go to the very low end of the to do list for a while…
I used the method you described to successfully update the terminal using the mac.ini file however it appears that this update is being applied to all terminals, not just the one mac specified.
Here’s a sample of my xen.ini:
Autoload=0
Include=008064A2D718.ini
BootpDisable=yes
Fileserver=*****.*****.***
AdminMode=yes Admin-Username=******* Admin-Password=*******
Privilege=None
PasswordServer=I created the file …inc08064A2D718.ini which contains a single line:
Autoload=2Despite specifying the mac address of that one unit in both .ini files, every device on the network apparently is applying the firmware update when they boot regardless of their mac.
Luckily none of these unintended updates have caused any problems however I’d like to make sure that we can successfully specify individual units as intended in the future.
Any thoughts on what I’m doing wrong are greatly appreciated.
Thanks!
March 8, 2013 at 4:21 pm #23610Looks good to me.
Can you start by adding some other stuff to your mac.ini file like a different background image or privilege level and retest?CG
March 18, 2013 at 6:37 pm #23644Ok, I added some random lines to the mac.ini such as a “desktop=background.jpg” and “disabledomain=no” and confirmed that those options are also being applied to all of the terminals, not just the one specified in the mac.ini
Any further thoughts on what I’m missing here?
Thanks!
March 19, 2013 at 2:51 pm #23649Of course, all clients will get those.
Change Include=008064A2D718.ini to Include=$mac.iniCG
May 26, 2017 at 3:48 pm #44466Trying to setup something similar so we can test firmware and wnos.ini settings on a single device but I but keep running into an issue loading the FR package, apparently Autoload=0 means no package loading?
Wnos.ini:
Autoload=0
Include=$mac.ini
AddPkg=”FR”0123456789.ini
Autoload=101
AddPkg=”FR”
……
Exit=AllMay 26, 2017 at 5:00 pm #44471Yes, autoload=0 means no update.
Put both parameters on the same line in your mac.ini:
autoload=101 AddPkg=”FR”CG
May 29, 2017 at 12:34 pm #44479Oooooh blimey, I feel silly now, been staring at it and didn’t see it.
That’ll teach me to stay away from ENTER…thanks a bundle! -
AuthorPosts
- You must be logged in to reply to this topic.