As somebody who's experienced several different thin client vendors, I'd like to say that LTSP was the only one that even remotely worked in a practical manner. All of our other thin client solutions needed to be rebooted frequently to behave and stay connected, and even at that their boot times were unbearable being upwards of 15 minutes or so for all clients to finally respond.
Not only have I not rebooted any of our LTSP servers since I installed them, but when I have rebooted them during setup, their reboot time is just like a regular desktop. It's the only thin client solution I'd ever consider using in the future.
Moving along... have you gotten anywhere with it? I did set up LTSP to be on our Windows DHCP, much like you're trying to do, and I had no issues. Are you absolutely positive it is *identical* formatting with the proper slashes and whatnot?
Also, have you taken a client (a laptop, or whatever) and plugged in a cat5e line in closer to the server to see if you can eliminate some network hops? You could also (if you're comfortable with this) fire up DHCP on the Linux server and plug a cat5e line directly in to the server with a laptop and see if it boots.
I always start small then span out. If it works in the server closet with my guinea pig laptop, then I move outward and eventually to the lab. If it works, I call it a day and we move on to other projects.
For what it's worth, it's getting to the point that using the Windows DHCP functionality might not be optimal in our environment. I'm telling you this in case you run into the same thing. It's looking to get to the point where we may have multiple LTSP servers which serve several labs. That being said, if you use the Windows DHCP option you seem to be stuck with one LTSP server. In our environment, we began to VLAN and subnet accordingly. I let my LTSP servers handle DHCP on their own with their own scope, and thanks to VLANing it keeps the traffic segregated. Just some food for thought.
Good luck.
