I have an "Advanced Installer" project that I am trying to use to install my "TopShelf" windows service that I have built.
I found the spot in Advanced Installer to grant permissions to the installation folder, but I don't see a way to grant permissions to the "Local System" account.
Manually, this is done by going to the security option in the properties of the folder and adding a user with the same name as the computer name but ending with a $. For Example MyNiceComputer$. (Oh, and you have to select the "Computers" option in the types area.)
But there is no way to do all this in Advanced Installer. If I do make one like MyNiceComputer$, it just makes an empty entry in the security tab. (No Permissions on it, even though I setup for full control.)
Has anyone ever needed to do this with Advanced Installer?
Additional Details:
I am installing an app that runs as a windows service. (It is a console app built with TopShelf).
Our company policy is to install all our applications into a folder that looks like this:
C:\OurCompanyApps\MyApp
When I create the installer, it runs fine, but then I when I start up the Windows Service, I get the following error:
Windows could not start the MyApp service on Local Computer
Error 5: Access is denied.
But when I grant access to Local System (by giving Full Control rights to myNiceComputer$ on the MyApp folder), then this error goes away and the app runs fine. From what I read, this is because the application is running as Local System.
It seems odd that it needs full control but it does not work without it. (But as far as I can see, the contents of the folder are un-altered).
#Bogdan Mitrache seems to indicate that granting permissions to Local System is not possible via Advanced Installer. This is good to know (so I don't waste more time looking). I will probably ask my System Admins for a dedicated system account to run my service as. Not ideal, but it will serve as a work around.
So, in one of my "less finer" moments of debugging, I mixed up two different things.
There was also a file missing, (my config file). I restored that and changed the permissions at the same time. But then I forgot to go back and verify which one was the actual fix. (I know, not good debugging.)
So, the Access is denied error was due to a missing file.
Related
I'm working with the following:
Docker for Windows v20.10.11
Docker running in Windows container mode
mcr.microsoft.com/windows:1903 base image
Proprietary application installed on top of this base image
Each year we create a Docker image with the latest version of our company's software. However this year's version behaves differently. Host machine installation runs fine. Containerized installation fails to run in certain situations. I can start the application as a simple EXE, for example using the Docker run command. The app will start and show up in "tasklist". However I can't start the app via the COM API, which is a critical requirement. The problem appears to be COM related. Normally we can create COM objects for our software just like for any other application. For example, IE returns a COM object just fine:
Creating these objects for our application works outside containers. However inside the container, our latest installation gives this error:
Access permissions appear to be ok. I tried a couple tests to prove this. First I can install other software like MS Word into a container and create COM objects for that:
Second I tried retrieving + modifying the application's DACL in PowerShell.
Changing access masks or trustees can cause an Access Denied error:
This also appears to confirm the access permissions were Ok by default.
Next I made sure COM is aware of the application. This appears to be fine. I get the same result on host machine and container when running this PS script:
gci HKLM:\Software\Classes -ea 0| ? {$.PSChildName -match '^\w+.\w+$' -and
(gp "$($.PSPath)\CLSID" -ea 0)} | ft PSChildName
The application shows up just like any other. The details show up fine when querying by AppID. LocalServer32 points to the correct EXE:
Some other things I tried:
Querying registry keys. There are 7 keys created when installing our software. These appear identical on host machine install and container install.
Even though permissions appear fine, I still tried logging into the container as alternate users. For example "nt authority\system" is another virtual admin user. I also changed the password of the "builtin\administrator" user to enable logging in with that one. Lastly tried creating new users entirely and adding them to the Administrators user group. All these attempts had the same errors as "builtin\containeradministrator" (default user).
A minor check was ensuring CMD.exe / Powershell is running as x64:
Re-registering the DLLs associated with the installation using regsvr32.
Starting from different base images. https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images. The full Win Server base image behaves exactly the same way regarding errors. The smaller Win Server Core base image is even more problematic, as I can't even start the app's EXE manually using that base. Lastly I tried other tags of the full Windows base image such as 20H2 and 2004. Same result from those. Multiarch or x64 makes no difference.
Included the "Ogawa hack" which was historically needed to make MS Office apps function correctly with COM: https://stackoverflow.com/a/1680214/7991646. It could be necessary for other COM apps too, but didn't help with my specific installation.
Is there anything else I can do to diagnose or solve this COM issue?
There are several things to consider:
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
The When CoCreateInstance returns 0x80080005 (CO_E_SERVER_EXEC_FAILURE) page describes possible reasons.
If many COM+ applications run under different user accounts that are specified in the This User property, the computer cannot allocate memory to create a new desktop heap for the new user. Therefore, the process cannot start. See Error when you start many COM+ applications: Error code 80080005 -- server execution failed for more information.
Finally, you may find a similar thread here helpful, see Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
I am working on windows service application where currently it is running on administrator privileges.
For that I need to set administrator info in service log on settings.
Above windows service is creating child processes with local user privileges.
This is working fine.
Now I want to change windows service application to run with "Local System" privileges instead of administrator.
But if I change the log on setting to "Local System" then, Child processes are not starting and throws exception "access denied".
I think that "local system" account has all permission to do anything.
It is even stronger than administrator account.
Then why it cannot start child processes?
Please guide me if my perception is wrong
Local System certainly DOES NOT have "all permission to do anything". That would mean that if someone managed to get INTO that process.. they could really run amok on the system.
Group Policy Editor will show you EXACTLY who can do what so you don't need to guess your way through.
Open GPEDIT.MSC
Navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
On the right hand side, Look for Obtain an impersonation token for another user in the same session.
I am not 100% sure that this is the setting you need (I haven't tried it) but I THINK it is. Even if it isn't, browse around this section of group policy to see who can do what. Clearly the setting you want won't have "Local System" on the list ;)
I hope this helps. :) GOOD LUCK!
I created an electron app which can only be started as admin, because it needs it for various command executions. Now it prompts that it must be started as admin.
This question was very helpful.
Now I want to start it with admin privileges right away so windows asks for the acception. It shouldn't be able to start the app without admin privileges.
I tried adding --win32metadata.requested-execution-level=requireAdministrator, but then it writes an error on startup (always):
The application has failed to start because the side by side configuration is incorrect.
How can I achive this with the electron packager?
Your electron-packager code looks fine, and the switch works for me.
This can happen if you are missing Visual C++ Runtimes, or if they're corrupted. Try installing them from here and try again.
If that doesn't help, then you should dig into the Event Viewer, which should come installed on your machine, and see what the specific error is. This page has some additional tips on troubleshooting this issue.
I am creating a program that runs as a service and creates database backups (using pg_dump.exe) at certain points during the day. This program needs to be able to write the backup files to local drives AND mapped network drives.
At first, I was unable to write to network drives, but solved the problem by having the service log on as an administrator account. However, my boss wants the program to run without users having to key in a username and password for the account.
I tried to get around this by using the Network Service account (which does not need a password and always has the same name). Now my program will write to network drives, but not local drives! I tried using the regular C:\<directory name>\ path syntax as well as \\<computer name>\C$\<directory name>\ syntax and also \\<ip address>\C$\<directory name>\, none of which work.
Is there any way to get the Network Service account to access local drives?
Just give the account permission to access those files/directories, it should work. For accessing local files, you need to tweak ACLs on the files and directories. For accessing via network share, you have to make changes to file ACLs, as well as permissions on network share.
File ACLs can be modified in Exploler UI, or from command line, using standard icacls.exe. E.g. this command line will give directory and all files underneath Read, Write and Delete permissions for Network Service.
icacls c:\MyDirectory /T /grant "NT AUTHORITY\Network Service":(R,W,D)
File share permissions are easier to modify from UI, using fsmgmt.msc tool.
You will need to figure out what minimal set of permissions necessary to be applied. If you don't worry about security at all, you can give full permissions, but it is almost always an overkill, and opens you up more if for any reason the service is compromised.
I worked around this problem by creating a new user at install time which I add to the Administrators group. This allows the service to write to local and network drives, without ever needing password/username info during the setup.
Could you tell me please. I wrote an application that uses 'Settings.ini' to save settings. The application is installed using InnoSetup. If there are several user accounts and the application is installed in one of them, so, if I try to run the application from another account I get error "Unable to write to....". That is, if run from another account, the application has no rights to write to the settings file. I don't know what happens in Windows XP, but that's the way application behaves in Windows 7.
So could you tell me please, is there something I should define in my application to make it work for multiple users or it should be changed during the installation, somewhere in InnoSetup parameters?
Thank you.
You should - install the very program into Program Files or some other common folder - folder that any user have rights to read and run, but not to write or delete. USually installers would allow to override the folder, but the rule remains: every user should have non-destructive rights (read and execute) and none - destructive (delete, overwrite)
That means your installer should request Admin rights and UAC Elevation - ask InnoSetup forum or documentation how to do it. That may deal with including manifests resources into installer. It is normal when a regular user runs the installer and installer then asks for another username and password with admin rights.
The settings and other user-unique data should be saved into special per-user data folders. Usually that is AppLocal folder under user profile. However it is task for your application rather than the installer. Installer may create global settings templates, that the application would just copy into user-local settings on the 1st run under given user, or would override by user-local settings if cascading settings storage is implemented.
http://msdn.microsoft.com/en-us/library/windows/apps/hh465094.aspx
http://blogs.msdn.com/b/patricka/archive/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions.aspx
Run command prompt, issue set command - and u would see all needed paths as environment variables wit hnames like AppPath, LocalAppPath and UserProfile
http://greatis.com/delphicb/tips/lib/systemifo-envstrings.html
http://www.delphidabbler.com/articles?article=6