I wonder if there is a way to make Windows scripts (batch scripts) to run without displaying the CMD window on Software Delivery distribution process. I know the $#bg parameter that causes the script to run in the background (and it worked perfectly) but I don’t want to lose the ability to display to users the installation progress presented on "DSM Software Delivery Job Check" window.
I would like to better explain my scenario to have other community suggestions:
Most of the actions that I will list below are due (in my opinion) to an incorrect programming logic of Software Delivery that doesn’t allow package to be Unsealed after the package distribution. There is an idea in the community about allowing this possibility (RTC 193192), despite the existence of the idea think it should exist since the conception of Software Delivery module. The solution to change a package already distributed presented in a CA support article is to create a new version based on the first. I don’t think this a viable solution because in many cases I'm just wanting to add a parameter that has been forgotten or even add an error exception I did not know before the distribution in my environment.
So to get around this, after lot of reading Software Delivery documentation and Client Automation community I came to the conclusion of the possible ideal solution for creating packages for distribution:
1 - Select the "Checksum control of package consitency" option. To be able to change the scripts and files contained in the package without the occurrence of checksum error control
2 - Create the procedures for installation/uninstallation script-based. Create scripts that call the installer instead of using the installers themselves. This is to ensure:
- Ability to handle the script with nonzero error returns because some of them can mean success. (e.g. Error 3010)
- Ability to add parameters that have been forgotten or have become necessary after a while.
- Set pre and post requirements (e.g. map a network drive) without having to create additional procedures.
- Have error returns (errorlevel) of all the script commands in the Job Output
- Ability to have in the same script sequential installations (a software package that despite having more than one installer is still one package and should respect a sequence) without the use of procedures (because procedures cannot be published on Catalog).
Based on the scenario presented above:
My only problem now is the script window that is displayed making it possible by theusers close the window and finish the installation.
PS. The script window is displayed via the Windows Interactive Services Detection, because is running in session 0 of the Operating System. (However users continue with the possibility to terminate the script execution if they choose "View Message" option of the Windows service)
I wonder if there is a solution to my problem and I'll be very happy with any suggestion or criticism of the method presented
I apologize for not being word-perfect in English, I hope you understand everything that was written.
I am afraid that if you are using a script to call the install then the only way to hide this is with the $#BG. The reason why the package cannot be unsealed once it has been deployed is that the install history would then be inaccurate. there would be no way to determine which version of the package had been deployed.
The only way to hide the CMD prompt but NOT to have the $#bg parameter, would be to make the procedure EXTERNAL and call START.EXE with the parameters:
/wait /min cmd /c
i also use script-based procedures. in order to hide these windows, i'm using the command-line tool cmdow.exe --> cmdow @ /HID
CMDOW Commandline Window Utility for NT4/2000/XP/2003/7