Forum Replies Created
Your best bet is going to be resetting it back to Factory Defaults.
I’ve got some clients here that are using the single button connect. It is a method for to allow the users to start their session by clicking one button. The connection you’re referring to is an ICA connection, which is probably leftover from the previous owner.
Does the G key reset work on these? Try holding the G key down while it’s booting up. If it works, it will reset it to factory defaults and you should be able to get to the control panel.
Actually, you should be able to RDP into Vista. It won’t be as “pretty” as the new clients, but you can do it.
There is a policy in Vista that is preventing it from happening. I don’t have a vista machine handy, so I can’t give you the exact wording, but I believe it is something along the lines of allow only newer clients to connect or something like that. Basically you need to tell your vista machine to allow it to answer connection requests from previous RDP clients.
You might also run into problems with other policies that prevent you from logging in, but that should get you started.
I’m going to recycle this topic. I’ve got the SAME issue here trying to upgrade from 4.5.1 to 4.5.3.
While upgrading the application, I get to the database portion and it tries to upgrade. It tells me that the database is password protected and I need to enter the password for the SA account. I entered both ThinMgmt and ThinMgmt_451 and neither seemed to do the trick.
I’m running 4.5.1 (not the SR1 release) on Windows 2k3. The backend database is stored on a SQL box (enterprise).
I thought it would upgrade using the Rapport user, which is a db owner. But it’s looking for the sa password to do the upgrade. It’s going to make my upgrade MUCH more complex if I have to get the SA account to do this, so I’d like to find a way around it.
Does anyone know which account it is using? I’m should have administrator rights to the database — is there a way I can change this password to get through the install?
4.5.1 is driving me crazy and I need to move to .3 for some of the fixes that have been introduced! I appreciate any help. Sorry for bumping an old thread, but I felt it went well with the OPs question!
When I mentioned refreshing the device, I didn’t mean deleting it. Send it a job, and when you’re sure it’s not going to execute, right click on the thin client (in the device manager) and choose refresh — does the job execute?
You can try clearing the system log. I’ve seen this cause problems like this in the past. You’ll have to get MDTools from wyse unless you’re familiar with SQL enough to go in and clear out the table. MDTools makes it easy to empty the table if it gets full.
Do you happen to have your logging turned up too much? You should only have it set for errors, otherwise the log can get too full.
Make sure you have no firewall (or proper rules created!) on your WDM server.
And did you get a chance to look through that document on WDM support that I linked you before? Lots of good stuff in there that will probably fix your problem!
If you know you’re going to overwrite it, can you just delete it before copy the new one over?
Since it’s an XPe machine, it’s probably got the write filter running. Is it properly disabling itself before the script is executed?
I’ve done a lot with USB devices, specifically mass storage devices, and I have to say it’s very unreliable.
With that said, I found that certain versions of the MSSTorage Driver/addon worked best. Specifically, the changes after b19 broke ALL of my devices (including simple USB memory sticks). This remained broken until b31. In between those versions, they played with some new logic that caused the machines to pop up messages, reboot, and do other funky things. Becuase of that, I would recommend dropping way back to b19, or getting build 31 or newer.
From within Citrix, you shouldn’t see any type of popup when you insert a USB drive unless the system doesn’t know how to handle it. If this is the case, you’ll get a message asking you to specify the driver, but at that point, I’m pretty sure the process is broken because if the driver was on the system, it would have automatically found it and started working. I saw this message in build 29 for many common USB flash drives (I test about 6 different models).
So once you get yourself a working MSSTorage driver that likes the devices you’re plugging in, and you’re happy with the user interaction required when the device is plugged in, you need to map a drive to it. You can do this by mapping to \clienta$ from within your citrix session. You don’t necessarily have to map a drive — you could browse to that location if you have the access to do that from within your citrix session.
It’s been a while since I’ve played around with this, but I seem to remember that the a$ share is always there. When it recognizes media, it mounts it to the share and the files will “appear”.
In summary, if you’re having problems, get the latest MSStorage driver and give it a shot. If that doesn’t fix it, give build 31 a shot, and then build 19 if that one doesn’t do it for you.
If you don’t mind me asking, what type of devices are you using? Just flash drives? What version of the driver are you using? You can find that in the control panel/addons applet.
And most importantly, what’s that error message that pops up? Is it the one aslking you for a driver that I mentioned above?
Check the timezone on your database server and your WDM server. If these do not match, it can cause problems.
You will also want to verify that the time is the same on both servers.
As a test, push an image. If everything is working as you say, it will not deploy. Find the device in device manager and refresh it. Does the image deploy?
Give ConfGen’s WDM faq a once over. There is some good stuff in it, as well as a section regarding jobs not executing.
…but is there any Wyse thin client which CPU could overcome that VNC limitation?
I use both s30 and v90 devices. The s30 is unbearably slow, but the only reason I remote into these is if there was a problem that needs to be corrected on the machine itself. As a thin client, that doesn’t happen too often. I think the biggest request is when a user in the field gets one and sets it up with an LCD monitor and I have to VNC in and get change the resolution and the refresh rate.
When I change the refresh rate on the s30, it’s pretty common that I click something, disconnect, wait a few seconds and VNC back in. It is VERY slow.
The v90, on the other hand, is very speedy and it doesn’t seem to have an impact on the performance of the machine.
Clear the SERVER table so the services can checkin properly (common issue if you backed up DB while Services were connected)
Thats what did it. Clearing that table resolved the problem.
Thanks for the info, I do appreciate it.
If you had any IP Helpers configured on your routers to help your clients find your PXE server, they may still be pointing to the old server. They will need to be changed, too.
While I’ve never worked with the clients you have, when you attempt a PXE boot, the IP address it attempts to boot from is usually shown on the screen. Does it possibly show your old server still?
I don’t have any s90 machines, so I’m not very familiar with them. However, I think thats just an S class with Windows XPE, correct?
I have a TON of s30 devices, and I don’t have any problems using USB keyboards in the BIOS. Do you have any other keyboards you can try to use?
I don’t even think there is an option in the BIOS for USB support. If I remember correctly, the only thing you can do is change the boot order and the administrator password…
Can you do a “g key reset” on the 9150?
If PXE is setup on the network properly, and no other devices out there are answering the PXE requests, everything should work fine. Make sure the device is set to boot to lan/network before IDE, otherwise it won’t be able to PXE boot.
If it’s set to PXE boot, it should find the PXE server even if a job isn’t requesting. If the information flashes too fast, go into the BIOS of the device and set the first boot device to lan/network/pxe, and disable the rest of the boot devices. Now start it back up and you should be able to see the information. Is it picking up the right server?
Out of curiosity, what does it say in device manger under Imageable. It should say yes, but if it’s not PXE booting properly, it will say no.
Also, make sure your view of the jobs shows all jobs. Someone might have scheduled a job that doesn’t fit the criteria for your view, and you’re just not seeing it.
If you’re familiar with your database, check the COMMAND table out. See if there is an entry in it for that client. I’ve seen jobs get “stuck” before…