I am distributing a multi-user MS Access FE database which needs to reside on the local workstation and could use some help with configuring an INNO Setup installer. Because of MS Access macro securities, each user is required to run the installer which sets up the HKCU registry information and user application icons.
My issue is after multiple-users on a single workstation has run the installer, if one of the users uninstalls, the MS Access FE is removed from all users.
Is there a way to create an installation log file that will keep track of how many times the application is installed and uninstalled on a single workstation and only uninstall the MS Access FE when install log is empty?
P.S. The installer needs to run without admin privileges.
Related
I got a MSI setup with personilized UI and Custom Actions working properly. It will be deployed on a specific park of computer, with always the same account design:
An Operator account with classic privilege.
A Setup account with administrator privilege.
We want to be able to launch our MSI on both account, but when doing it from the Operator, have to fill a form asking for the Setup credentials and install everything as it was made logged with the setup user.
Is there a Windows/MSI tool for that?
Can I do it with a specific Custom Action launched before the display of the UI?
Thank for your help
When you deploy an MSI to a user that has standard privileges this will always ask you for Admin credentials to install the MSI (assuming the MSI is a per-machine install and not a per-user install).
If you deploy your software via SCCM or other infrastructure management tool you can place this to run in an Administrator Context, thus, you won't need the Administrator privileges in order to install it.
Also, when you test an MSI it's nice to test it with PSexec. What is Psexec? Check it here.
PsExec is a portable tool from Microsoft that lets you run processes remotely using any user's credentials. If you run psexec -s -i (in a cmd with administrator rights) this will impersonate the System account and thus allow you to install applications without requiring you to provide administrative right (password, etc).
PSexec is a must when you test MSI's. For example, if you have any user data in your MSI. Because, when you install an MSI from another account, not all the data is automatically placed on the other user, for this you have to use ActiveSetup or other solutions to make it available on all users. See more about userdata here and any other MSI topics.
If you are installing an MSI from an Administrator account and want to run different actions on the current logged in user, i designed a tool for this that can be downloaded here.
So, to answer your question more directly, you can't suppress the credentials dialog as a normal user. The MSI must be deployed from some infrastructure management tool like SCCM, or another solution (which i don't recommend) is to design the MSI to be a per-user installation.
I am admin on my local machine. However the app I am creating (an outlook VSTO addin) will be deployed by a deployment admin to users who won't have admin.
The app installs correctly.
My issue is that I have code which checks if an EventLog.SourceExists("my VSTO addin"). If not it will EventLog.CreateEventSource("my VSTO addin").
My questions:
Do I really need to create an event source? Will it still log without the source existing?
How should I create the event source (if #1 is required)?
2a Perhaps I need to create a small app which creates the event source and this needs to be installed by an admin?
2b Perhaps I can put it in the code somewhere which will invoke when its being installed? (I'm using install shield)
2c Perhaps it can be done by an admin as part of group policy?
2d I can create a registry key as per https://learn.microsoft.com/en-us/windows/desktop/EventLog/event-sources
To answer my questions:
I do need create the source.
To solve this I created another console app which just creates the event log sources I require.
In installshield I added this new exe as a custom action. The install is done with Admin mode so the sources are created.
This fixes the application because non admins were using the app and it was trying to create the event log sources if they didn't exist. I removed this check.
So in IT environments we commonly lock down users profiles to prevent access to the registry, command, prompt, control panel,etc. This can easily be done via GPO. However, there are times when you need to make a quick change to the users profile when everything is locked down. Maybe it is to changes the video resolution or the wallpaper, or edit something under the restricted users HKEY_CURRENT_USER. So it is easy to reboot and login as an admin. Open their registry hive. and rename "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies" to Policies.disabled log them in and make the changes and refresh via gpupdate /force. But there should be a better way with impersonate user or Run As. But when you run RunAs as another user it runs it as the admin and you get the Admins HKCU.
How would you make it so you can run an app made in VB.NET that simply deletes "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies" so you can make those changes?
Under VB.Net 2005, I created a Setup Project which produced installation files for a windows application. I placed the mdb file in the User's Application Data Folder and remapped the DataDirectory to Environment.SpecialFolder.ApplicationData at runtime. Unfortunately, sometimes the system just did create the mdb file at the Application Directory. An example was that I installed the program in Windows 7 under a normal user account. I chose inside the installer that the program would be made available to everyone. After installation, the mdb file would be created automatically for the Administrator account but not for the normal user account. For XP, the whole thing worked fine.
I am tempted to write a routine to check and create the mdb file if it is not present, but why does this happens and what other opinions do I have?
If the application is installed for all users instead of once for each user that logs onto the machine, then you will eventually run into a problem where the database isn't available for the signed on user.
In order to resolve this, you would probably be better off checking for the existence of the database on application startup and then either copying a standard version from the application directory to the current user's data directory or creating a new db from scratch in place. I would recommend the first approach.
I want my program to be able to edit a values within a registry key that resides in 'HKEY_LOCAL_MACHINE'
My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\XYZ", "MyValue", "MyData")
The above works fine in Windows XP, but throws an UnauthorizedAccessException in Vista.
You are running into Vista's UAC feature. It will not let you write to arbitrary places in the HKLM hive because you are not running with Administrative priviledges.
There are two ways to work around this issue
Run the program with Administrative priviledges (different than running a program as an account which has Administrative priviledges)
Choose another place, perhaps HKCU, to store the data
The second option is much better as it allows your application to run with non-Admin priviledges which you can't always assume your user has.
Here is a fairly detailed article on UAC. It's not 100% programming material but it gives a good explanation as to what exactly it is and you can hopefully relate that to your particular program: http://technet.microsoft.com/en-us/library/cc709691.aspx
Since changes to the Local Machine hive can have affect across the system you will find that changes to it are restricted to non-administrative users. If you try to run your same code on an XP machine a non-admin account you will get the same error. On Vista since the process is non-admin by default you are getting this error. Information on this is in the "Made for Windows 2000", "Made for Windows XP", and "Made for Windows Vista" certification guidelines.
Given that I've got little information on what your program is doing more information may be needed to give you specific guidance, so I will speak in the general case. You want your application to leave the local machine hive alone unless you need it. When your program is run in non-admin mode it you can either disable the functionality that requires access to these admin keys or you can request that the admin privs.
Vista has tighter restrictions around Adminstrator accounts. If you're not logged in as an Administrator account, you'll have to write to HKEY_CURRENT_USER as opposed to HKEY_LOCAL_MACHINE.
IMO, this makes more sense. Each user has their own settings/etc for their programs. If you want to make global settings for your program, you'll have to do it with an Administrator account.