Normally, I logoff my normal user account and logon to the administrator account (Windows 7), and then update Manager. However, a month or so ago, I tried the shift run as administrator option on my normal user login.
It appeared to update Manager, but when I ran Manager it came up with errors. Comparing files on my computer with my laptop it looked like the files where Manager is installed, so I just copied the files over from my computer to my laptop and it worked. Basically the files had not updated properly even though I was running shift run as admin.
So I decided in future, to just install from my admin account. The next time I updated Manager, I logged on as admin and ran the update and that worked fine. However, when I logged on as my normal user account, it was still running under the old version of Manager - the admin account was running under the new version of Manager, and the standard user account was running as the old version. I had to run the update again (but this time under standard user account) and then it updated to the latest version on my normal user account.
So when I update Manager on the laptop, I now need to login as admin, run the update, then logon as my normal user account and run the update again! I need to login as admin to get the program to install correctly as it does not install correctly under shift run as admin - as I got issues with that as described earlier. Then I need to run update under my normal user account to get the version of Manager to update on that login.
Can the install routine be fixed. I am going to try and see if deleting the profile on my standard user might fix it so that I only have to run the update once under the admin account.
Because Non Admins cannot update software in program files or in the c: root directory. They don’t have the security permissions. You always need admin privileges to install software or update software in c:\program files or in c: root directory.
I will try updating Manager as a non admin next time on the laptop and see whether it updates properly.
I had similar issues when I first started using Manager, because I refuse to install executables in the AppData directory. I install Manager in the Program Files directory (where I strongly think it belongs – @Lubos’s disagreement notwithstanding).
My workaround is to open a Command Prompt as Administrator (All Programs > Accessories > right-click Command Prompt > Run as Administrator) and invoke the Manager.exe installation program from there.
If that works for you, you might try uninstalling Manager (twice: first as your regular user, then as an administrator) and then reinstalling the way I described.
Of course, back up your Manager data first. I can’t guarantee that this method will work for you.
Thanks @Jon, however, I will just go back to what I used to do - logoff regular user account and logon as admin, install update and log off again. No biggie.
I will make a backup of Manager, remove it completely from both logins and then re-install it as before.
C:\program files is where the program itself should be stored.
c:\users%username%\appdata\roaming is where you store the settings for the program specific to that user logged on for example skype installs to c:\program files\skype and in the appdata\roaming section, it stores the users chats, login account etc. Same thing with Firefox, it installs the program in c:\program files and it installs the users Firefox Bookmarks etc in the appdata\roaming directory.
Some programs use the c:\programdata folder to store settings such as for a backupn program - the backup program would store the config settings in the programdata folder as usually the settings would apply to all users, but its advisable to keep the actual data separate from the c:\program files location.
I have my Manager configured to install to c:\Manager - at the time, I was concerned about installing it to the c:\program files area as I thought that it might have problems with permissions etc, so I thought it safer. However, seeing as Jon reports no issues doing that, I will move the program to the c:\program files where it belongs.
I have my data on a separate partition, so if I ever need to re-install windows, I just wipe the windows partition, without having to backup any of my data as these are on different partitions.
The problem with having the program installed to the users profile can be illustrated in an environment where there is jobshare for example with one secretary working three days and the other secretary working two days and they have different logins. Also many technicians do not think of backup up the users profile directory when re-installing the computer or deleting the profile when the user is having problems logging on. Also it avoids strange problems like this when you have Manager running one version on one login and another version on a different login!
Nearly every program follows the convention of storing the actual program in c:\program files, the program settings specific to the user in the userprofile and the program data in either the users documents folder or in the c:\programdata folder and many allow you to change the location of where the data is stored. I would suggest that you follow the same convention so that Manager is consistent with how other programs work. However you will need to fix the install routine to allow Manager to bring up the administrator prompt to install the program as you need admin privileges to install Manager in program files or c: root drive.
You and I agree on this, @Dalacor, but @Lubos has made it clear in the past that he does not share our opinion. At any rate, invoking the Manager.exe setup file from an elevated DOS prompt allows for an installation in a Program Files sub-directory, so there’s an easy workaround for those of us who want to do that without affecting users who are fine with the current install location.
I don’t think that its really a case that Lubos does not agree. I think that he has not given much thought to the matter as the priorities were and are in improving the accounting program itself and virtually nobody bar myself has raised the issue in the past.
Lubos has always stressed that standardisation and following conventions is important and has applied that to doing accounting in the best way by following best practices.
I have no doubt that when he has time to review this issue he will fully agree that the current installation routine does not meet best practice software installation standards and conventions as virtually all software installs the program into c:\program files and this is where IT Technicians will expect to find Manager installed. In addition moving Manager to the program files directory will solve many issues such as multiple users on one computer as well as the fact that most malware and viruses run from the users appdata location so moving Manager to the program files directory will actually make the program more trustworthy to IT Professionals who are responsible for installing software on many company computers! Running the program from the appdata location is not best practice and when Lubos has time to review the issue, I have no doubt that he will agree as he will want Manager to work in a way that meets best practices, installation conventions and have the software be consistent in that it installs in the same way as every other software product on the market. But I respect its not a priority at the moment.
Non-admin users cannot install to Program Files folder. It’s simple as that. All modern programs try to avoid elevating permissions if possible during installation, including Google Chrome.
If you haven’t noticed, Google Chrome by default installs to AppData folder instead of Program Files. The good thing about installing Chrome in AppData folder is it doesn’t require UAC elevation so any user including Guest account will be able to successfully install without problems.
No, it is not standard. Yes you do get the odd piece of software that installs to the appdata location, but just because chrome and a couple of other programs do it, does not make it standard.
I consider the requirement to elevate permissions as one of the most useful security features of windows to prevent business users from installing junk on their computers which then causes problems further down the line. Not to mention the fact that centrally updating software that is installed in each user profile would be a horrendous nightmare if I had to do that with all software. I have also on many occasions had to delete a profile to repair issues where the user either could not logon or the login was extremely slow. You do not want a situation where upon deleteting a user profile you have to re-install half a dozen programs again because the programs were removed when deleting that profile. Not to mention that if you have a home computer for example where the entire family uses Manager, you would have to update Manager on each login.
As somebody who works with computers all day long, I don’t mean to be rude but installing in the appdata location is a terrible idea and I have only just given a couple of reasons why its not good practice. I think with google chrome, they may have done it so that on a multi user computer one person can use Firefox, another can use IE and the third can use Chrome and in that instance there would be no need for a computer wide install. So I can see some use in this example, but I would not call this a modern way of doing this, but rather in certain instances like Chrome it might make sense to use that approach. It does not however make sense for software in general to be installed per user and not per computer especially an accounting program that may be used by several users in a job share environment - you would want a computer wide installation.
The article is quite long but it explains how installation context works when installing MSI packages.
If the program is installed in “per-user” context, Windows Installer will redirect all Program Files references to AppData within current user folder.
This is not something I have decided, it is not something Google has decided. It’s something Microsoft has decided many years ago.
You can argue that Manager is not the type of program which should be allowed to be installed in “per-user” context… but… many users don’t have admin access to their machines, especially in offices. So they wouldn’t be able to install Manager at all.
When I say standard, I mean that the vast majority of software installs into the c:\program files location so it has become standard convention. Even Microsoft themselves configure their software like Office, Skype and you name it to install as a computer wide location.
The article you referred to is meaning demonstrating that one has the ability to install computerwide or user only, but does not state that user only is the preferred approach - in fact it makes no reference to the recommended approach.
From an IT Technician point of view, users that install programs that don’t require admin privileges are a pain in the arse, because they are always installing software that is little better than spyware. If a user in the office needs a program they should be getting their IT Technician to install it as office computers belong to the company not to the end user! And there are many reasons (legal) and otherwise why its not desirable for end users to be able to install software on their work computer.
Manager is your program and you are free to have it configured as you so desire, it doesn’t worry me as I will install it in c:\program files on my computer so its not a problem. However as a technician that deals with malware, stupid people on computers etc as well as deploying software and many other reasons, I will always state that software should be installed to the computer location i.e. to the c:\program files. One thing to consider is that many technicians know that malware runs from the appdata location (and use application whitelisting accordingly) precisely because the end user has permission, thus this makes any software that runs from the appdata location less trustworthy than software that requires to be installed in the computer location - which usually in work locations requires the computer guy to install it.
Anyway this is completely offtopic from the original question. Now I know why Manager is doing that on my laptop, I can fix that no problem.
I have removed Manager from both logins on my laptop and re-installed the program. I have discovered that even if you run as different user by shift right clicking the setup file, it does not allow you to install into c:\program files. So while I can use your method of elevated Dos prompt I have decided to continue installing it into the c:\manager location that I have been using because I am concerned about things in Manager not working correctly in C:\program files as it clearly is not designed to run in that location with the correct permissions. So any system wide change in Manager, may not actually work properly as the program itself doesn’t support elevated privileges to run in c:\program files.
I just thought that I would mention that, although its unlikely to present a problem.
It turned out that I had Manager installed in the appdata location on the one account and in c:\manager in the admin account. I could have sworn that I told it to install to the c:\manager location on my standard login. Oh well, its working now.
Yes, I know. That’s why you have to install it from an elevated DOS prompt, as I recommended. I’ve had Manager installed in c:\Program Files\NG Software\Manager on my 32-bit machine and in c:\Program Files (x86)\NG Software\Manager on my 64-bit machine for nearly a year, without a hitch. When I invoke a new Manager setup file from the elevated DOS prompt after downloading an update, it even remembers which directory to use. I’ve never had any trouble with it being there.
Note that I am the only Manager user, and I am the only Windows user on either machine. Also note that I keep my Manager data files in c:\[User]\AppData\NG Software\Manager, not in c:\Program Files – but I know you’d approve of that!
Sorry you misunderstood the point I was making. I am aware that you update Manager using elevated Dos prompt. I was not referring to updating Manager.
My concern is more when you change something within Manager, it either does not change because it requires a change within c:\program files or it appears to change but does not work. For example, you could change the user location in preferences and this might be something that is changed within the c:\program files location rather than in the data location. I don’t think that there is anything that curently requires a change within c:\program files location, but this may change and this is why I was concerned about installing to that location, because Manager in gui form does not elevate privileges when required.
I actually recommend that people install a c: partition for windows and have a D: Partition for all their data and redirect the music, documents, videos and Pictures to the E: drive - including your Manager data. This way you don’t have to backup any data if your windows gets hosed. You just wipe the C: drive and re-install windows on that partition and all your data is safe on the e: drive. I spend more time backing up data before re-installing windows than I do installing windows. So I prefer to put data on a separate partition.