- This topic is empty.
-
Posts
-
I went and downloaded the S90 XP SP2 image to update my 9150’s to XP2. Do I need to alter the RSP script file to make it work properly?
I just went in to WDM and added that package to the the Images section using the RSP that came with it. And when i schedule it to be pushed out now, it says it’s scheduled, and I go to the client and it just sits there. If i reboot it, when it restarts, the PXE says it’s set to LocalBoot and it just goes back to Windows and sits there.
All the while, WDM still says it’s pending and it hasn’t attempted anything yet.
Am i missing something?
I’m new to all this. And this website has been my salvation. Thank you all SO SO much!
Looks like the 9150 is never informed that there is a job.
How did you add the 9150 to WDM?
You can try scheduling the job again (delete the old one), right click on the job and select “Roll to boot”. Now reboot the 9150. Even if the 9150 is not communicating with WDM while XPe is loaded this should trigger the imaging process.CG
I added the 9150 through WDM’s standard auto-discover.
I tried rescheduling the job 3 times, and Roll to Boot on 2 of those, and I would reboot the device and it still just had “LocalBoot” auto-selected on PXE and went straight back to XPe.
I tried to send a non-image package to see if that would take. I tried upgrading the HAgent. I noticed that the newest version, it appeared, was 4.0.5.2 and the HAgent on the client was 4.0.4.5.
When I kicked that package off, it didn’t do anything for a bit. Then I just let it sit for a while and it finally started pushing that package and the window popped up on the client, and I chose Upgrade Now, and it did whatever it does, and then rebooted.
But when it rebooted, i checked the version tab on the file’s properties window, and it was still 4.0.4.5?
I don’t know if any of that helps at all. Thanks so much for all your help. You really are a life saver!
Please delete all pending updates for that unit and afterwards delete the unit itself from the Device Manager.
Then reboot the unit and check if it is checking in automatically.CG
Ok, so I updated to 4.7.1 and it seems to be seeing the PXE server just fine now. So I schedule the package, it tries booting PXE and it says it’s connecting, and going thru HTTP protocol, then I see the tons of lines showing that it’s evaluating and searching for stuff on the FTP site, and after it scrolls thru more lines the client just reboots and starts over and tries again. It does that like 3 or 4 times before it finally gives up and boots into the OS.
Any ideas? I tried to see if i could see any errors but the text scrolls so fast, I can’t make anything out before it’s already rebooted again.
Does the job under Scheduled Package show any error messages?
CG
Under Scheduled packages it finally errors out and says “[Previous errors not found] [Update moved to error by garbage collector, due to timeout]”
If I go to Report Manager and run a Log report, it’s filled with entries that say under Description:
“[TFTP] –serverIP 2070 error 10038 writing udp packet”
“[TFTP] –serverIP 2071 error 10038 writing udp packet”
“[TFTP] -read error from serverIP 2070 – closed session”i’ve checked the user rights on the FTP folder and they’re set correctly. If i go to the command line on the thin client, i can connect to the FTP server and login just fine.
any ideas?
Do you have any other SW running on your WDM server?
The error you mentioned is not a FTP but TFTP error. But TFTP is normally only used right at teh beginning and you have written that this imaging process goes through a bunch of lines which indicates it is already doing FTP stuff.
Try installing MS NetMon or similar on your WDM server and trace the traffic. Maybe this helps finding the root cause.CG
I installed Netmon and i’ve linked you to a text file that shows what’s showing up under the traffic info for ‘inetinfo.exe’ between the Thin Client and WDM.
https://upload.campbellclinic.com/download.php?file=115WyseIssues.txt
when i look at everything through WireShark it looks like traffic from the client to the server turns out fine, but when the server sends packets to the client, it seems like almost all of them have a bad checksum?
I’m not sure what to do at this point. And no, no other software is installed on the WDM server.
IT WORKS!
Ok, So apparently I completely missed the section in the Installation Guide on setting up the WebDAV stuff. And that it has to be setup before you install the WDM software. So I did that, and made sure to double check that I didn’t miss anything else, and now it’s working.
So, lesson once again learned. RTFM.
Thanks so much for you help, ConfGen. You truly are the Jedi Master!
Thanks for reporting. This is really interesting as the WebDAV part is only needed if you are flashing the units via HTTP instead of default FTP.
Have you changed this in the Preferences? Have you also changed from Wisard imaging to Merlin (can also be found in the Configuration Manager-Preferences)?CG
No, I never set any of the preferences at all. I just left them at Default.
But for whatever reason whenever I send an image to a client, when the client reboots, it says “+- Searching for Interface: (HTTP)” then it continues into it’s imaging process.
But I’ve never specified any method it should or should not use? I don’t know how this would have been set. Should I change something?
In my opinion I would think like “Never touch a running system”.
WebDAV does not harm anything, so leave it running.CG
Sounds good to me!! 😀
Is there a significant speed advantage to having it push via FTP instead of HTTP? that would be the only reason I would think about changing
- You must be logged in to reply to this topic.