Yeah... upgrading forwarders using Deployment Server isn't possible. All it does is roll out apps with Splunk configuration in them.
This lack of functionality seems like silliness... what if we created an app that ran a script or batch file (whatever matches the client) which in effect does:
a) retrieves a new pkg or msi to the client from wherever you host the new UF version if the local (client version does not match what is on the hosted location) - ok maybe even check the package download/copy for accuracy (using hash)
b) stop the UF locally (on the client)
c) runs the new pkg or msi (which by default the UF will auto-start yes? or if no, start the local UF).
d) exits gracefully.
so this would be an experiment but I bet someone has come up with this already (anyone have a working example?)
Point b would not stop the script; the script or batch file runs independently - it is an invoked process. What it is - a little wasteful because each time the client checks in, it would invoke the script. But then again, do clients need to check in every five minutes? In most environments, probably not and every so many hours may suffice. Just saying.
Give it a go yourself. Save a foo.bat file in etc/system/bin and enable that as a scripted input. Put this into the file:
path\to\splunk\bin\splunk stop path\to\splunk\bin\splunk start
Same approach but different slashes for 'nix. You'll see your Splunk stopped, but not started.
Works for me if I invoke it with cmd.exe batchfilename.bat or Linux-esque 'myrefresh.sh &'
If you run that yourself it works, but if you let splunk invoke that as a scripted input the scripted input will terminate when splunk terminates.