We used to use LANdesk (and SMS) once upon a time too. You will enjoy TEM once you get the swing of it.
Since the TEM agent runs as local system, most software packages install just fine in that context without any additional credentials. In some cases even installers without documented silent installation methods can be successfully installed by using msiexec parameters such as “/qn” or by re-packaging. This is the exception rather than the rule.
Running vb, powershell, batch, js, .NET, or pick-your-favorite-language is able to be handled by TEM (provided the target machine has the correct run-time; if not, you can always install that too as part the script). With a script, you can either attach the finished script as a file attachment or build the script on the fly as part of the actionscript (using either the appendfile or createfile commands). There are no limitations. Any thing you can run from your machine, you should also be able to execute in TEM. Executing is easy. For example, wait cscript myscript.vbs.
For actions that require installation from the perspective of a particular user, try leveraging the RunAsCurrentUser utility.
In many ways running scripts from TEM are much superior to running them by themselves. The key distinction is relevance substitution. If you build a script on the fly in the actionscript, you can substitute in attributes that are applicable to the local machine. This is not only easy, but also very powerful. It can also be “nested”. For example, you could build a vbs on the fly, substituting in location-specific information of the machine. The output of the vbs might be a customized batch or powershell that is tailored for that specific location. Then you could execute that batch or powershell to achieve your end result.
It isn’t uncommon to use each script type to its strength, sometimes inter-mixing them within the same actionscript. We frequently have custom tasks that co-mingle Actionscript, VBS, batch, and/or powershell in the same action.