Forum Replies Created
-
Posts
-
Finally importing old images is easy, if you don’t have a script just download one from wyse.com. Lets say you have V90 image to import, download the factory image, replace the 9V90.i2d with your own and edit the packge Number and description. Easy!
To see what a script is right click on an existing package and select view script, you can cut and past this to recreate the original .rsp
I manually imported all of my packages and it was pain. We’ve got ~200 packages. Most of them were just different configurations, and for that, it was pretty easy to get the script. I just wrote a batch script that looked at each directory in my old FTP repository. If it found just a .REG file, then it created the script on the fly.
The problem, and it really wasn’t a HUGE problem, is getting them back into WDM. As you can imagine, 200 packages takes a long, long time to import and it’s a very boring and repetitive task! 🙂
Thanks for the tips though, I do appreciate it.
One thing about images… I found if you used FTP to deploy the images, they could exist in any folder. But if you deployed with the imaging solution, it will fail if the image isn’t in the Image folder. Hopefully that will change in a patch… I would love to organize my packages, and subfolders would be amazing! 🙂
I don’t know that you’ll have much luck imagining with a USB memory stick.
I’ve used the simple imager to image s30’s in the past. Using Internet Connection Sharing as a DHCP server I was able to get the machine to accept a DHCP address. I was using a hub (a switch won’t work), but a crossover cable would work fine.
Maybe that will help you get an image on the machines until you figure out your DHCP problem. I’ve never had any issues with getting an s30 to accept an IP address.
It sounds like you’re using a network sniffer to see what the machine is going on. Do you see any NAKs after the DHCP server send out an address?
Thanks for the info!
I’ve got WDM running already. We’ve got a licensed version of the enterprise version up and running, so it sounds like we’re half way there.
Thanks for the explanation of the way the thin client works. I’ll be sure to look at that documentation!
Thanks again for another answer!
-joeAfter digging into the Rapport scripting a bit, it looks like you could set this for the User with a package.
You could use the SV command to set the .default value, then use the MR command to merge it into the User registry.
Well, don’t you always figure out what the problem is when 5 minutes after you post looking for some help?
I found a better command reference that showed a little more information on the MR command. Apparently you can’t Merge a registry file to a different user, UNLESS that user is currently logged in. I was logged in as administrator while I was trying to push the package, and not user.
So that part APPEARS to be fixed, however, I’m still getting the FTP -1 error and I can’t figure out what that means. 🙁
I wasn’t able to find a local machine setting, but I think the one you have will work just fine.
The setting that you are configuring is for the default user. That means, from the point you make that change, any NEW user that logs in will get that setting and it should work. Which is good; you should make this setting as well just in case your profiles ever get corrupt or you add new users to the client.
To “fix” the other users, you will need to open regedit as Administrator. Open up the HKEY_USERS hive and look for users. Now, you aren’t going to see anything like Administrator or User, you’re going to see their SID. Each user is going to be a string of numbers and dashes that start with an S. You’ll need to modify everything with a [+] next to it to make sure you get everyone.
When you expand the users SID, you’re going to see something familiar like you did when you expanded the .Default key. So open up the users SID and you should be able to browse to Control Panel under that, and then keyboard under that one. After opening up keyboard, you should see the InitialKeyboardIndicators value. You should change that to a 2 to enable num lock.
One “gotcha” that I saw was that the datatypes on my V90 were not string values (REG_SZ). I don’t recall if it was a DWORD or BINARY, but it wasn’t string. I believe the value needs to be a string! I had to delete the value recreate it as a string in order to get it to work.
Another “gotcha” is that Windows XP saves the state of the Numlock key for you. So, when you are making the changes, turn the numlock key ON. If it’s off when you shut down (or log off)it will overwrite the value that you just changed for the user you are currently logged in as.
So in short, you need to manually edit that value for each user, as well as the default user, and turn the num lock key on manually for the user you are doing the edits on.
You could also disable the write filter, log in each user, turn the num lock key on manually, then enable the write filter again. But that seems a little more cumbersome to me.
You could also write a VB script to modify the value, then send it to the machines with a Rapport package and have it execute the file. It would be a little more scripting, but if you have a lot of machines it might be the way to go. Your VB script would need to enumerate the HKEY_USERS hive and determine if a branch was a user, make the change if it was, then move to the next branch.
Hopefully that helps you! I know how frustrating it is to be so close to a solution and not have it working! 🙂
What steps are you using to capture the device configuration? Are you trying to capture a configuration or an image?
I use this procedure:
1: Right click the Package Manager branch, choose new, choose Package
2: Choose Register a configuration from a device
3: Give it a name and description, click next
4: Expand device manager to the proper view, click next
5: Choose the device I want to capture, click next
6: Choose the settings I want to capture, click next
7: Click next and walk through the rest of the process.Thats with WDM. My only problem is that, when deploying the configuration, the connections aren’t deployed with it. Everything else seems fine (as far as I can tell), just the connections aren’t there. They seem to be in the reg file that it captures, though.
Good luck!
I take that back…
Discover is very flaky, and unreliable. It isn’t finding any devices anymore.
I just fixed it.
I had to slow down the scan by increasing the Connect timeout to 2000MS. I currently have my delay timeout at 2000 as well, but I’ll be lowering both of those values to find the best one for us, as I’m pretty sure they both don’t need to be at 2000.
As far as I can tell, the firewall is seeing the scan as an attack and it starts to block it after so many sequential address scans. Putting a delay in seems to do the trick, though!
Do you have a hub or a crossover cable you can try? I think the switch might be causing you problems.
Thanks for the input!
I’ve actually been playing with WDM, but using it isn’t possible for me at the moment. We’re going to be implementing a WDM server and enabling the PXE boot function, but it’s still a ways out.
Looks like I’ll be doing manual configs until we get that setup!
Thanks again,
JoeI had a problem, and the resolution I came up with might help you as well. I posted it in another thread here:
http://www.freewysemonkeys.com/site/modules.php?name=Forums&file=viewtopic&t=346
My solution was to reinstall the service. You can easily do that with the following steps:
1: Open a command prompt (start/run/CMD)
2: Change to the Wyse Directory (CdProgram FilesWyseWDM)
3: Uninstall the service (RptStdSvc.exe -u)
4: Reinstall the service (RptStdSvc.exe -i)
5: Start the service (RptStdSvc.exe -r)No guarantee that it will work for you, but I had a similar problem where the service would start up, and immediately stop. It was running under WinXP SP2 with no firewall enabled.
I was poking around the wyse knowledgebase and I found some information that helped me figure out what the problem was.
It seems that during installation the Standard Service didn’t install properly. It installed enough to make windows think the service was running, but it really wasn’t. I verified this by querying the service from the command line and I received an error. I fixed it by manually reinstalling the service then forcing it to start. Here’s information on how to do that:
1: Open a command prompt (start/run/CMD)
2: Change to the Wyse Directory (CdProgram FilesWyseWDM)
3: Uninstall the service (RptStdSvc.exe -u)
4: Reinstall the service (RptStdSvc.exe -i)
5: Start the service (RptStdSvc.exe -r)You can, at this point, query the service to see it’s status by using RptStdSvc.exe -q. If it’s running, you’ll get the following message:
[STDSVC] – service is running
Hope this helps someone else who might be having the same problem…
