- This topic has 31 replies, 7 voices, and was last updated 13 years, 2 months ago by
.
-
Posts
-
Hi All,
I’ve just recently upgraded WDM 4.7.2 to 4.8 (after installing the hotfixes), and since then it would appear that very few of our terminals are checking in properly… All of our XPe terminals that should be checking in are doing so, however we have quite a lot, by which I mean in the vicinity of 80% of our WTOS clients that appear not to be checking in with WDM since the upgrade. In fact the last time that a lot of these terminals checked in was on the day of the upgrade, but before ~8:30pm (around when I did the upgrade). The version of WTOS seems irrelevant by the way, we have 1200LE’s on 4.4, s10’s on 6.4, v10l’s on 6.5, and they seem to be all experiencing this. I obviously can’t account for all the terminals, however I can pick out entire labs of terminals that I know have been used since then and they have not checked in. To add to this weirdness, we recently deployed some new terminals, they reported in as you’d expect when they were first turned on, but have not done so since, and a f/w upgrade was performed, and they were renamed (neither of which has been reflected on wdm since they have not reported again).
Any ideas? The only idea I currently have is to roll back to a pre 4.8 upgrade stage to see if the issue goes away.
CheersP.S. DHCP Scope Option 186 is set to our wdm server address
Have you checked on 1-2 of the failing devices locally if the WDM server IP is correct?
Can you get a network trace of the time these 1-2 units are started up?
Any other changes on the WDM server beside the upgrade?
What OS is WDM running on?CG
We had this problem with our site. It turned out to be a very strange issue. In the file server path of the terminals that were not checking in a space had appeared at the end of the wyse server name. Logging into the terminal and manually removing the space resolved our issue.
I have no idea how that space got in there as you can’t replicate the issue (if you configure a wyse terminal manually with a space in the file server path, it is automatically removed when you click ok)
We picked the issue up by running sys internals utility “file mon” on the wyse server as an affected terminal logged in. The path to the wnos file was wrong but somehow it still got it’s config.
I’m still not sure if I have corrected the problem but we have specified the “fileserver” setting in our wnos file in the hopes that terminal will replace their corrupted space setting with the setting defined in the wnos file.
I’m not sure if this will be your problem but maybe worth checking.Thanks for the replies guys.
It doesn’t seem to be an ftp fileserver path issue, as this is still working fine, and any changes I have made have been received. I have checked the wdm server ip on a couple of the devices to verify it, and it was correct as you’d expect, as the wdm server ip hasn’t changed, and the dhcp scope option is the same as ever. As far as I know there have been no changes on the wdm server, and it is running windows server 2003 sp2 (I am planning to upgrade it to 2003 r2 soon). I haven’t tried a network trace yet, but I’ll try that soon and see how i go. Silly question, is it possible that it’s now neccessary to set the wdm server port using dhcp scope options…?
Cheers
UPDATE: I’ve just been running wireshark and i’ve found a terminal that is on and tried to report, and I can see that the terminal sent all it’s information, and the wdm server sent back “&ER|Agent Not Sending valid value”. Is this a wdm bug maybe?
Okay that does sound a bit different. One thing however is that when I used wireshark for tracing it didn’t pick up the specific issue we had. It just traced an successful FTP transaction etc (as you would expect).
Filemon gave us a little bit of different angle as it was able to trace the interaction on the file system itself.
If I think of anything else I’ll let you know
😀
OK so there seems to be a bit of confusion…
The ftp server we are using is working as it should, as I can make changes to the configuration files and they are received. What we’re having issues with is the http reporting to the wyse device manager server, which seems to have gone pear-shaped since the upgrade to 4.8. When the terminals are on, they periodically checkin with the wdm server by posting their details to a http address (http://wdmserver/hserver.dll). There appears to be 2 types of checkin, a “small” checkin, and a full checkin. I’m making an assumption that periodically a full checkin has to occur, and for the rest of the time a small checkin is used. I’ve checked some of our terminals that are not checking in according to wdm, and they are attempting a full checkin, and the wdm server is returning “&ER|Agent Not Sending valid value”. The terminals that are checking in correctly are just using a small checkin, and this is working, however, according to my assumption, the 20% that we currently have reporting will eventually stop, because they will need to perform a full checkin and will not be able to.
Hope this clears things up,
CheersP.S. The terminals that are not reporting are also showing “HAgent: Invalid Command” in their local event logs.
Hi All,
Just an update… I got in contact with Wyse on Friday, and I spoke to a nice chap who informed me that it is a known issue. Apparently when you have a ‘-‘ or ‘_’ in your terminal name this behaviour occurs. The good news is that we should be seeing a patch soon 🙂
@gavin0001 wrote:
Hi All,
Just an update… I got in contact with Wyse on Friday, and I spoke to a nice chap who informed me that it is a known issue. Apparently when you have a '-' or '_' in your terminal name this behaviour occurs. The good news is that we should be seeing a patch soon 🙂
Unreal! I’ve been having issues renaming my clients and it’s because of this known issue! Thanks for posting. Any news on the patch? I don’t see it on wyse.com and I’m somewhat f’d until I do.
This patch is not available at the moment.
But this issue only applys t WTOS based units. Others should not be affected.CG
I’ve been fighting this problem for a few weeks now. Upgraded from 4.7 to 4.8 and my clients stopped checking in. All because of a ‘-‘ in the name…. 👿
Repeats to himself: “always check wysemonkeys… always check wysemonkeys” 😀
Anyone have any ideas on when this patch will be available?
Got the patch from WYSE support but am running in to an issue trying to install it. I have a ticket open with them.
Thanks!
The patch is available on wyse.com and works fine for me.
ftp://support-emea.wyse.com/public/WDM/HF04080029010.zip
CG
@Nardo wrote:
Got the patch from WYSE support but am running in to an issue trying to install it. I have a ticket open with them.
Thanks!
Also having an issue installing the patch and also have a ticket open.. Is yours regarding the following error:
“Could not connect to FTP and send FTPTest.txt file using the Remote information from WDM Database Software Repository table.”I have read the pdf which comes with the hotfix and it outlines that I should make sure that either HTTP&FTP or FTP only are enabled. I can confirm that FTP only is checked under Preference > Services > Repository Preferences.
FTP also works fine from my browser and all thin clients are getting their config from the http://ftp.. so not sure what the issue is.
In the WDMHFInst.log i get the following error:
#1(TEST FTP: svDest) #2(/rapport/FTPTest.txt) #3(99)
#1(TEST FTP: szErrorMess) #2(FTP Error:530 ) #3(99)Ive been waiting for over 3months for a resolution regarding the naming of thin clients.. we have a naming convention which includes hyphens (-) and now that a hotfix is out, it doesnt even install.. ridiculous!
Loris
Do you have more than one SW Repository defined?
Have you checked the FTP log after the failed install?CG
Loris, yes that is the same error I am getting! Same as you, FTP is the only option checked under preferences and my thin clients are also getting .ini files via FTP.
I’m getting the same messages in the log file.
Error 530 is an authentication issue, right? The hotfix never prompts for credentials, so I’m not sure where it is failing….
ConfGen, how would I check for the things you asked?
- You must be logged in to reply to this topic.