Hi,
re: a batch script, is the intended usage for me to launch that from the command line of the build agent(s) at the time that I upgrade the Jenkins master? If so, I would agree that it's slightly more convenient than me pointing a web browser to the master and clicking slave.jar with the intent of saving it locally and then killing/re-running (when I remember to do so).
The point of logging this issue isn't that there is no path forward to proceed – it's certainly not a high priority 'bug', I'm sure we're all in agreement. And today, everyone can update their slave.jar file manually (or create a script like the one you proposed), so nobody is 'stuck'. But there are so many aspects of Jenkins that are slick and provide a good user experience, why shouldn't this be one of them?
The potentially bad/awkward aspect of not doing this is that (I think) slave.jar can get out of sync to the point where there is a bug – there is no slave<->master compatibility version enforcement that I am aware of, _if _the user doesn't remember to upgrade their slave(s) each time. I know there have been multiple Jenkins users that have had that question and the same feeling of (hmm, is the current problem I'm seeing with this slave due to the fact that I didn't upgrade the slave.jar when I upgraded the master, even though slave.jar rarely changes?)
Anyway, that's the scoop behind me logging this. The benefit (to me) seems clear, even though we'd probably both be in violent agreement that it's not a P0...
If you use "Let Jenkins Control this Windows Slave as Windows service" as the launch method, this is what happens.