I'm using a windows installer package to distribute a winforms application to several clients and because some of them have changed their security policies I need to figure out a way to run the application updates (through the installer) for users without administration rights.
Find below some information regarding the update process:
- The installer is created using InstallAware
- During the update process the old version is uninstalled and the new version is installed.
- The installer needs admin rights because it writes to the registry and installs some windows services.
- The application is installed in the program files folder.
At this moment the solution that I'm implementing is create a new scheduler task, that runs a simple console application that check for new updates and if a new version exists it downloads the installer and executes it in silence mode (the entire installation will execute silently, without a user interface, or any user intervention. The default values of dialog controls will be used).
Some consideration about this solution:
- It's difficult to handle possible errors during the update process.
- It's not possible to alert the user that a update process is running (because the scheduler tasks runs with a different user is not possible interact with the logged user).
Has anyone ever implemented anything similar? Is this the best way to achieve my goal?
If the updates are patches, and you meet a certain set of requirements regarding the first install of the product and sign both the MSI and the patches there is a mechanism for limited users to apply patches, UAC Patching described here:
http://msdn.microsoft.com/en-us/library/aa372388(v=vs.85).aspx
If you search for LUA Patching (its original name) or Least-privilege patching there's more info out there, although it's fairly obscure. If the security policies that they have in place include setting DisableLUAPatching then you won't be able to use it.
Related
We have made a WPF application and added setup project using InstallShield Limited Edition 2015 in normal mode (not in Run As Administrator). it gives below wrror.
Now we tried to manually copying this file in creating installation process and run project in Run As Administrator mode, the setup.exe crashes.
Please help.
Some tasks require admin privileges. EG installing new fonts.
If your users don't have admin privileges then you need to either avoid "installing" a component and instead just deliver it to disk OR some sort of work round.
Registration of an ocx results in writing to the users registry.
One thing you could do is just deliver that ocx to disk ( not install, as such ), then add the entries to the user branch of their registry.
Offhand, I don't know whether installshield allows you to do scripted tasks.
If it doesn't, you could write that registry entry when your app runs. Check if it's not there and add.
I have a windows application where I am creating an installer for it with InstallShield. The installer will be posted in a login-secured location on the internet. When the program starts up, I am going to have it check the download site to see if it needs to be updated, and if so direct the user to the site to update the app.
The problem is the version numbers. The app knows its own version number, and I can create an API to put on the site that can read the version number of the installer, but how can I keep them in sync? I'd rather not have to do it manually every time there's a build.
The installer is required to be behind a login wall and it can't have any way to direct link to it, so the site will feed it to the user with a binary stream. I had been experimenting with ClickOnce, but I couldn't find a way for it to create a single-file installer and it doesn't allow for authorization when updating.
The best approach depends on how you're building things. This answer assumes you are using a build system to come up with each version number, and specify it downstream to all the built items.
IsCmdBld ... -z "ProductVersion=1.2.3.4" can be used to specify the version at the command line. Be sure to consider that the (optional) fourth field of the ProductVersion is largely ignored by Windows Installer, and adjust your version numbering scheme as necessary.
Alternately the automation interface can be used to edit the project, and set the ProductVersion on the ISWiProject object. This is more flexible, but requires modifying the project before subsequently building it.
By the end of last week our central IT Department introduced SCCM and applied it to a bunch of clients in our division. My colleagues and I work as so called "IT-Partner" in a 1st level support for a few hundrets of colleagues. Now we're facing some problems with our new SCCM System (installed packages do not work etc.) Now we'd like to "reset" applications so the SCCM Agend will reinstall them. I've read something about the detection methods but unfortunatelly I do not really know how they work nor I know where those methods are saved. I want to "analyse" those methods so I know which file to modify / delete that the agent will reinstall the application.
By the way, how much time does SCCM take from "assigning" a package to applying to the client?
Assuming you only have the client and no access to the SCCM Console the detection methods can be found using WMI. They are stored in root\ccm\CIModels in the Class Local_Detect_Synclet.
The format is XML in one column and it is designed so that all kinds of detection methods can basically be represented in the same style so it's not very readable but you should be able to get some basic understanding about the detection method used.
Keep in mind this is only true if the software was deployed in the "new" (introduced in sccm 2012) application format and not for the "old" package/program format.
If you want more detail I once tried to automate the process of triggering a reinstall for any given application but ultimately failed due to problems with the chache/distribution point. I posted all my findings here.
So from an application POV. When you deploy an app the detection method is setup in SCCM to determine wether or not the application installed successfully. This detection method could be configured a variety of ways. For example, it could check to see if the msi code is installed to determine success, it could check the .exe and compare it to a specific version, or even check a registry file for existence. In order to change/modify these detection methods you should be an SCCM admin and be able to login to the console. From there you would select the specific application or package you want to analyze and click through the properties of the deployment.
I am writing a Windows forms application to go between our other systems and our new software package that we are still setting up. I am doing an iterative development method because I am creating the tools as we find that we need them. My problem now is that when I publish a new change, we have to go to the workstations, log in as admin, and install this app. Being the process as it is, this just isn't feasible.
What other options do I for releasing this to the users? And how would I go about doing it?
I am using VS2008 and .NET 3.5
Maybe you could use ClickOnce deployment.
I've used Web Update Wizard Which installs a service (which runs with admin rights) when you first install your app. Then when it updates, the service does the updating.
Is there any utility that will copy the "official" build of a windows forms app from a central network share and launch it (from a client desktop)? I want to make sure users get the latest version when I update the binaries on the central network share.
ClickOnce is user un-friendly so I'm looking for something else...
Is it possible you could revise your question to describe what it is you find unfriendly about ClickOnce? In my office we have found ClickOnce to be the most efficient and user-friendly way of updating and distributing applications desktop business apps that we have ever had. I'm wondering if the best way to resolve your question might be to address the issues you have with ClickOnce, rather than integrating/rolling another solution.
I've done this before by the following method:
1 - Keep the "official" build at a specific network location
2 - User launches program from their local machine
3 - At launch, program compares its' own file version # to the one on the server.
4 - If the two versions are different, copy the new version down from the server and relaunch.
Pretty simple, and it works as long as you are in an intranet environment.
Step 4 is the only tricky part. You can't replace a file while it's in use, so you have to either
1 - first rename the current (in-use) file and then copy down the new one. Since you will be updating many times, you'll also want to delete any existing renamed copies that are hanging around.
or
2 - Have the user launch a "helper" application that does the version check, updates if necessary, and then launches the real app. Of course then you have to deal with updating the helper app.
We have a tool that would do that, which has been in use before there was such a thing as Windows Update (or any other update.)
The problem with any sort of update of this fashion is the security level of the user. Many times you need to be administrator to perform certain functions.
Our solution is two part/one executable: 1. a service mode that runs local system or admin to perform such operations. 2. an executable which can be called by an app to fetch via UNC, HTTP, FTP the updates for an application and apply them.
The basic process is this:
1. Application checks its version number; we use a central database to list all applications and their version numbers.
2. If the application is a minor revision we give the user an opt out on the install; if it is a major revision we require an install.
3. Once the update is confirmed, we call the updater executable which in concert with its service mode product, retrieves the updates, installs them, and relaunches the application.
If you are interested, go to the website listed in my profile and send us a support request address to me and I will give you more details and the codebase if desired.
Check out this one:
.NET Client Applications: .NET Application Updater Component
It is a white paper which discuses in detail on what it takes to make an application auto-updatable.