Hi Dan,
In terms of AD and local permissions, I pretty much described the full setup I used in my organization in my SAPGUI Installation Server blog series, which I know you've seen. A link to the full series is at List of Blogs and Other Documents. Specifically, SAPGUI Installation Server Part 6 - LSH and Distribution describes the setup of Local Security Handling and how to use scripted installs on workstations for which the users don't have local administrator rights. SAPGUI Installation Server Part 2 - Initial Installation describes the domain permissions needed on your Installation server and how to setup the share permissions.
Part 6 also talks a little bit about different options for distributing the installation. For instance, you could put the script you mentioned into logon scripts, and there is a command-line switch for NwSapSetup (/once) which can be used to quickly bypass running the full setup if it detects that it has already been done on that workstation. This should keep the logon script fairly quick for those who have already installed. Then you could use various AD groups to determine who gets that particular logon script.
Another alternative is to use Microsoft SCCM (I think there's a new name for this tool now, but I forget what it is). The Installation Server has a utility to create a Package Definition File which can be used with SCCM to push the installation out that way. We haven't done that here, but we're looking into it for the future.
Or, you can simply publish the link to your script, perhaps on a departmental intranet webpage, or by sending out group emails, etc, and let users self-select when to click on it and start the install/upgrade. This is what I chose to do, just to keep things simple. Yes, there's a slight risk that everyone might click it at the same time, but in fact that didn't happen here. I did worry about the Automatic Workstation Update Server (AWUS), since it checks every 24 hours from the last workstation startup for updates, whether that would mean that when I pushed out a patch everyone would update at the same time in the morning, but again this turned out to be a non-issue. As it happens, many of our users don't bother to reboot very much, they just leave their workstations on all the time. Also, many of them come in at different times in the morning, so if they do reboot, it's not all at the same hour. Finally, we now have a central mechanism of controlling workstation (windows) patches that triggers reboots, so many people's workstations get auto-rebooted late in the evening a couple times per week. All of this has meant that in practice users hit the Installation Server at all different times, or at times of low network activity (at night), etc, so it just isn't much of a problem.
But, worry about this is why I put two cores and more RAM on my PRD Installation Server. If you use a VM, it's easy to add more CPU cores and RAM "on the fly," so you can just monitor utilization, and if it spikes -- beef up the VM.
Cheers,
Matt