IIS hosts a .Net Core that simply needs to run a bat file. The file is part of the project.
On the local machine, everything works properly, but on the server, the bat file is not triggered because it is blocked by UAC virtualization.
On the server, the double-click script runs smoothly, but cannot be started automatically by .NetCore
.Net core has admin rights to execute the script, also AppPool has the
rights to execute the script. But the script simply stays blocked by
UAC.
I tried to completely disable UAC and restarted the server but again the same.
I tried to create a shortcut with admin rights that will run the script but without success.
We have an old application which uses has it's executable (EXE) build on VB6 (Setup Bootstrap for Visual Basic Setup Toolkit ). We are trying to silently install the setup by and running it in a scheduled manner using task scheduler.
Command use : Start-Process -FilePath "D:\SETUPXXX.EXE" -Verb runAs -ArgumentList "/qn"
While running this stand alone from a power shell console or command line the setup executes and shows up on the screen , completes installation and goes off(without clicking anything). This installs is successfully.
But wherever we are trying to schedule this on a task scheduler it doesn't pop up anything and neither it installs the application.
We tried other ways "setupxxx.exe /sc:\setup.log" but the results are same it works when executed from command line and pops up the installation completes but fails to do the same when scheduled or run as a batch file.
Is there a way to stop the installer popup coming which might be stopping the instillation while running.
Refer :https://theether.net/kb/100165
I created an exe with NSIS that installs my application, but if the application is already running, it gets updated at startup.
It seems this simplest way to achieve this is by added a registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
My entry looks like this:
Value name: InstallRUS
Value data: cmd /C "C:\Location\of\my\program.exe /S"
This executable simply copies files to a directory and runs a script to register the app as a windows service.
If I restart windows, it runs twice, the first time in silent mode, and the second time it seems to ignore the silent flag.
If I log out and log back in, it's correctly ran once in silent mode.
This leads to the conclusion that the task is ran at windows startup and login, yet the documentation states :
Run and RunOnce registry keys cause programs to run each time that a
user logs on...By default, the value of a RunOnce key is deleted before the command line is run.
Does windows starting up counts as "user login"?
Why is the entry not deleted after the first run?
How can I fix this?
Why is windows lying to me?
Note:
I'm using Windows 7 Professional x32
Seems to be related to this: Windows Registry RunOnce Loop but I am not writing to the registry
I had no problems with SCCM 2007 scripting application deployments, but SCCM 2012 has me pulling my hair out and I have very little left.
We tend to have heavily scripted installs and most of the time the installs fail in SCCM 2012, the latest failure is symantec enterprise vault, I wrote a script that would check the main DLL plugin version and use the correct uninstall string to remove the previous version, before installing the latest version.
my script is very simple and works fine outside of SCCM, but inside SCCM it fails.
If I recreate the application as a MSI deployment and use the MSI file then it installs fine, so SCCM is working correctly to the client. The uninstall that SCCM puts in from the MSI failed, but that is covered below in the example. I have checked all the client side log files and can not find any issue.
I even return the successfull install return code 1707 and 0 at the end of the script to try and get SCCM to make it a success.
I have written the script first in VB.net as a console service app and then rewrote it in vb script. both scripts fail. I used to use AutoIT to write scripts in the past, but that too was failing, so I thought I would switch to something more microsoft.
For detection I use the windows installer selection and point to the msi file where it picks up the product code.
deployment type is script.
The only thing I can think of is SCCM 2012 does not like the sleeps that are in the scripts.
or it just does not like scripts. :-(
The MSI uninstall failed, because it needed to run as administrator, as you can see from the script below, I run as administrator and this works outside SCCM, but not in SCCM. the install uses pretty much the same code but more logic and many more uninstall strings.
even the uninstall fails and here is how simple the uninstall script is;
Set WshShell = WScript.CreateObject("WScript.Shell")
If WScript.Arguments.length = 0 Then
Set ObjShell = CreateObject("Shell.Application")
ObjShell.ShellExecute "wscript.exe", """" &
WScript.ScriptFullName & """" & "RunAsAdministrator", , "runas", 1
Else
end if
Set objShell = CreateObject("WScript.Shell")
Set objExec = objShell.Exec("MsiExec.exe /x{ADEBB592-4986-4FD1-868C-D59DB32F0BC2} /q")
WScript.Sleep 8000
returnValue = 1707
WScript.Quit(returnValue)
Just because it works outside of SCCM, does not mean a lot if you have to make it work with SCCM! people make that comparison all the time a work and it means nothing, what you need to do, is enable verbose logging on the MSI, the command line it's something like this msiexec /x {xyz-code} /l*v c:\somelogpath.log, try it you may find something equally bizarre like a 1303 error inside the log files
Use PSEXEC and execute the command under system account.
I found some setups/installers do not like to be executed without GUI or other non-user account.
Another thing, in SCCM 2012 you have packages that just simple execute the program, with only exit code check.
And there are Applications that can have detection rules, which can be used to really verify if the program installed/executed correctly.
Also always check ITninja for tips.
Something like this you may need to make sure that outlook.exe is closed you may want to add a taskkill to your script and then try it:
taskkill /IM outlook.exe /T
msiexec /a "path to file" /qn
might work as a simple .cmd file
This is an old thread, but maybe this is helpful for people searching the web:
SCCM Applications usually run as SYSTEM, no need to "run as administrator" (you could configure that within the Deployment Type).
You cannot "break" out of SYSTEM context and do a "run as"
runas and system account.
Tried that once and finally did an ugly workaround by creating a scheduled task that runs under a specific user, then ran that task from my script, which is running as SYSTEM.
As already mentioned, test your scripts interactively using SYSTEM account:
psexec.exe \\localhost -s cmd
Check with whoami that you're running the cmd with SYSTEM.
Make sure you add the COMPUTER account of your test client to the share/folder ACL of your networked scripts folder, otherwise the system account does NOT have access rights.
If running the script as SYSTEM works but SCCM still reports an error, chances are high that the Detection Method failed, NOT the actual install!
Check the following logs here: C:\Windows\CCM\Logs
(See 4. below how to use the index service to speed up troubleshooting logs.)
AppDiscovery.log
AppEnforce.log
AppIntentEval.log
Open up the Windows Indexing Service Options. Configure *.log to index file contents as well. Then add the path C:\Windows\CCM\Logs to the index. Howto.
This way you could easily search for the application name and you will find all log files which deal with that application. You will also find the matching AppDT ID, so you could search for that ID and will find even more info about your package/application.
On your admin machine create a new log collection folder, add this folder to the index. This allows you to copy the whole log folder of a client to your admin folder. A few minutes later it's indexed and fully searchable on your local machine!
There's a tool available from Microsoft which could gather a full log package on a client: ConfigMgr Support Center
Do you have SCCM setup to run it as administrator in the program that you defined?
Trying to schedule a task on a Windows Server 2008 R2 box.
I have a vbscript connects to an oracle database to pull data, and I want this to run at intervals.
The vbs is working standalone on the same machine, only when run with 32-bit csript.exe (needs a 32-bit ODBC driver). I can kick the vbs file off with a batch file to call C:\Windows\SysWOW64\cscript.exe "c:\scriptLoc" and it works fine.
But when I try to schedule a task I get the same error I got when trying to run the vbs directly by double clicking - which uses cscript.exe 64-bit (I presume).
I have also tried opening the 32-bit Task Scheduler C:\Windows\SysWOW64\taskschd.msc, and adding the job there, but getting the same results.
Any suggestions?
Thanks
Edit-------------------------------------------------------------------------------------------------------------
The error is that Oracle Client cannot be found, driver is 32-bit and won't work with 64-bit. This error occurs when I manually run vbs with the default cscript.exe, but it all works ok when I manually run with 32-bit cscript.exe
The solution for the scheduled task was:-
Start a Program
Program script = C:\Windows\SysWOW64\cscript.exe (which is the 32-bit csscript.exe)
Add Arguments = C:\Scripts\test.vbs (my vbs script to run)
Start in = C:\Windows\SysWOW64\ (run in the 32-bit directory)