I'm creating a Windows application that needs to add an entry to the Send-To explorer context menu, and needs to do so for all users. Since the Send-To folder is specific for each user, with no common folder for all users, I'm left with two choices:
I can go over all user profiles, as well as the default user profile, find the SendTo folder and add the shortcut to it. This will ensure the shortcut is deleted during uninstall.
Or, I can make sure the shortcut is in the SendTo folder each time a user logs in (by adding my application to the start-up folder of all users). This will make my life a lot easier during installation, but when the application is uninstalled, all those shortcuts will not be removed.
So either way, I need a way to find the SendTo folder of all users. I can scan HKEY_USERS and find the SendTo folder of each user (it might not be in the default location, the user can move it), but how do I find out the user profile's root folder? The registry has something like %USERPROFILE\AppData\Roaming... for the SendTo folder. How can I figure out what %USERPROFILE% is for another user?
Thanks.
Easier approach: use the launch sequence of the exe itself to check whether the shortcut it present on launch, and create it if not.
Uninstall for all users is best handled using ActiveSetup which will run "something runnable" once for each user logging onto the machine. In your case a simple batch command could do the job.
If you do chose this uninstall approach, you must make sure that your msi installer checks for this uninstall key and deletes it on install - otherwise you have a delete operation scheduled for the shortcut the next time a user logs on.
Also keep in mind that each install should use a different entry in ActiveSetup to ensure that the shortcut creation is re-run for a user who has had it uninstalled already. This last part might be slightly incomprehensible before you read more about ActiveSetup: http://www.etlengineering.com/installer/activesetup.txt
You can create a custom action inside MSI, which will go through all user profiles and remove your shortcuts from SendTo folder. All users profile you can find, just scan all folders in %systemdrive%\Users folders in Windows7 (Vista), or Documents and Settings in Windows XP.
Or you can use ActiveSetup mechanism for this purpose, create some script (application) which remove your shortcut from SendTo folder, when user will log in to system next time.
Related
I script a lot of things to manage the computers in my company. I often need to add shortcuts into the personnal startup folder of users (without a GPO).
Windows 8/8.1 doesn't have a personnal startup folder by default.
Its location is C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\
It is easy to create this folder, but it needs a desktop.ini file into it, with the correct content, for the name to be localised (else it is displayed "Startup" whatever the language).
What is the "official" way to create this folder?
Or what is the official way to add something into it?
I'd prefer a PowerShell or batch command, but whatever reliable mean is okay.
I guess you can do something with the ComObject for this special folder:
$startup = (New-Object -ComObject Shell.Application).NameSpace(0x07)
By the way, if I enter shell:startup in a run box (Win+R) on my Win 8.1 system, it directs me to my personal startup folder (C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup).
As far as I know, there is no reliable way to do this.
You can get the path with [environment]::getfolderpath("Startup") but the returned string is empty if the folder was neve created. And I don't know any API entry to create it.
So you have to manually create it:
check if the former command return anything (if yes, just create you shortcut)
create yourself the startup folder. Use [environment]::getfolderpath("StartMenu") and add \startup to the path
then create the desktop.ini file and populate it yourself
and update the registry HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (I didn't check if this is the right place. [environment]::getfolderpath("Startup") must return the right value)
UPDATE: I just found SHGetKnownFolderPath API which allow to create the required folder if needed (with dwFlags). I'm not good at PowerShell, so I don't know how to call this. Maybe Someone can give a better answer.
I have an addin program that works with MS Word (version 2007). It is located in the C:\Program Files location. I installed Windows 7 and then went to make a routine change to my files in this location and it would only bring up a read only file. How can I grant myself permission to write to my own program? I cannot change this location or use any other workaround. I have this product out to 25 different companies and I can't change the programming to work from any other location. Thanks
You could also embed a manifest in your EXE that makes your program require adminrights on Windows 7 / Vista.
On Windows Vista, UAC means that users run without admin rights and don't have write access to the program files directories.
The correct solution is to write to a folder for which standard users do have write permissions.
The solution you are looking for is to make your app's folder within program files writeable to all users. You can do this by adding a DACL when installing. It is extremely bad practice to allow standard users to write inside the program files directory and I urge you instead to re-code your app so that it does not need to write there.
Assuming you're doing this as part of modifying the config (and not when your application is running for regular users)...
Your user account probably doesn't have the correct permissions to write/modify the file. Assuming your account is an administrator account, right-click the file, select "Properties". Click the "Security" tab. Click edit and give your user account Full Control.
If you can't do this, it's probably because the ownership of the file doesn't allow you. If this is the case, click on "Advanced", go to the "Owner" tab, and click "Edit".
However, if it needs these permissions when it's running, you should instead be using the %AppData% folder.
I have a program that was written on XP. What I've found out is that it doesn't work properly on Win7 because HLKM is no longer writable by non-admins.
Essentially, when you register the program, the licensing information is supposed to go into the registry. That information is valid for everyone on the computer, not just the one user, so I don't want to put it in HKCU. But any copy of the program needs to be able to edit that registry (even if it's a non-admin running it), because there are certain situations when it's going to go get updated license information from my web server (for example, if the registry data is lost or damaged, or if your current license is expired and it needs to see if we've applied an extension).
It's not horrible if it goes out to the web server for every unique user who starts up the program, but it causes some annoying issues, so I'd rather it continue to work the way it did in XP. Is there a way to store data in the registry and still have it shared under Win7, or am I going to have to start looking at storing an INI file on the drive?
Here is how I would architect it: your setup runs elevated and sets up the key. Then if their licensing gets corrupted or whatnot, you enable a button or menu item that has text like "fix license" or "update license". You put a shield on that button or menu item. When they click it, you launch a separate exe using ShellExecute. That exe has a manifest that requires elevation. It can then write to the protected area of the registry. The rest of the app can have a manifest with asInvoker.
If you want it to be completely invisible, either the whole app must always run elevated (annoying) or sometimes the app will just launch another exe that asks for elevation without warning - in which case the smart users will say no. A little less invisibility is a good thing imo.
Could you get the installer to make your particular area of the registry to be writeable by everyone? The installer will need to be run with elevated privileges anyway, I'd expect - so this would seem an ideal approach.
I need my application installer set the program to auto-startup for all users.
Then each individual user should be able to modify this option without affecting others.
Currently I write to HKLM/../Run with installer, which acomplishes the first task.
But then I can't disable autorun for current user, because deleting th HKLM/../Run entry would disable it for everybody.
Is there a way to do that, without using shortcuts in Autostart folder?
start it for all users always but check a configuration variable in HKLU to see if it should exit immediately
Any reason not to use the HKCU Run key in the first place?
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
I am working on a Windows application which needs to be able to update itself. When a button is pressed it starts the installer and then the parent application exits. At some point during the installer, the installer attempts to rename the directory that the parent application was running from and fails with "Access Denied" If you run the installer from the desktop it works.
I am using CreateProcess to start the installer, is there some way of using this or another API to create the installer completely independantly from the parent application so that it doesn't retain some attachment to the directory.
I'm not convinced that launching the installer separately will solve your issue. It sounds more like a permissions problem that you might be able to solve using ACL manipulation. If the app doesn't already have permissions to mess with that folder, you might be able to write a custom action to remedy the problem by adding the necessary permissions to your process.
Another way of doing this is to make sure that the directory deletion is happening within a custom action that you control (as in, you own/maintain the code that performs the deletion, rather than rely on MsiExec to do it for you). Then, set that custom action to run in the System context so that it will have the same permissions as a service. That should provide your installer with sufficient rights to remove the folder.
You should use the normal update system within the windows installer.
your access denied message appears because file/directory is in use.
renaming directories isn't also not a good idea.
what happened if the user clicks "repair" or "uninstall" ?
you can start the msi with shellexec. after that terminate you app immediately.
you should check that in the msi that your app is NOT running anymore.
do the update. if a file is in use the installer automatically wants to reboot to replace the stuff.
CreateProcess should work if you are passing it the right parameters. Don't reference the parent process in any way and set most things to NULL. If that doesn't work, then you can try WinExec().