I saw this solution posted here and on a different website as well but it hasn't worked for me. My installation folder is in C:\Program Files instead of the (x86) version but I modified the batch file to match. But still it asks for administrator priviledges...
My process:
Open notepad
Paste AJB's batch file contents and delete (x86) [since my installation folder is in C:\Program Files]
Save as a .bat
Double-click the .bat
Result: An Amcrest pop-up that says "Please run SmartPss as administrator!"
If I right-click the .bat and run that as administrator, it works...but obviously the purpose is defeated that way. Am I missing a step somewhere? Or are you guys just setting this as a login script with Windows Task Scheduler and opening it up on login for your users?
Amcrest Surveillance Pro (ASP) is about the same as SmartPSS.
You could try these SmartPSS instructions on ASP to see if they will work for you. I have not used the instructions. https://dahuawiki.com/SmartPSS/How_to_I ... in_Account
I solved this, but it wasn't easy.
The COMPAT_LAYER answer mentioned earlier does NOT solve the problem because there is no way that the program can run correctly WITHOUT admin privs, and setting COMPAT_LAYER avoids UAC but DOES NOT ELEVATE, so the only answer that will work must describe a way to run ASP (Amcrest Serv Pro) with Admin rights while avoiding UAC - not an easy task at all.
My solution involved the following:
1) AS Administrator, create a service task that runs when the computer starts. This task runs with the highest privs and runs a powershell script that does nothing more than loop and wait for a request to spawn an instance of ASP. It uses SysInternals PsExec to startup ASP with admin rights in the correct desktop session.
2) Create a shortcut on the public desktop that runs a batch or powershell script that talks to the service task to trigger it. This is what users actually click on.
Although it may seem easy, there's a lot of work involved to get things JUST RIGHT, but with perseverance I got it done. I had to NTFS protect the powershell script for the service task to prevent any non-admin users from opening it--as it contains the password to an admin login--but that's the extent of the security risks of this solution - acceptable in my opinion.
Now, after doing all that work, I found something I didn't have to code up, so I'll also mention it here; it's called RunAsRob. Google it. It's software that's designed to do just what I described. You should be able to use it to accomplish what I did with internal windows commands and 3rd party tools but without the headache of writing some code and glue-ing everything together.
I will attach my project files (in a zip file) for your reference. If you decide to use them, you'll have to figure out how things glue together and how to deal with the system permission issues you'll run into. Good luck.