By Bill Cunnien - 9/1/2009
Has anyone done this? I am going to look into this as an alternative to the Click-Once deployment. I am agreeing with Trent (see http://forum.strataframe.net/Topic24399-7-1.aspx) that Click-Once sounds great but starts to breakdown after the installation becomes a bit large.
Any tips, links, etc. would be greatly appreciated!
Bill
|
By Trent L. Taylor - 9/2/2009
I have not done this directly with Group Policies, but it should be more than doable if you are creating an MSI distribution file. We have our own distribution (or auto-update) mechanism built into our medical application.
We have a server to which all clients connect for licensing, etc. This server also checks for updates from a web service. When an update is seen, it downloads the update to the client and loads it on the server (if setup) at a predetermined time (generally 3:00 AM). When the clients then get fired back up when the users start using the software, it queries the server to see if there is an update, if so, it copies the update local, installs it, and the install then re-shells the application so that it is one seamless update.
This has been the best solution that we have ever had and it has been extremely smooth. Many times people come in and have a major bug or issue resolved without missing a beat.
|
By Edhy Rijo - 9/2/2009
Trent L. Taylor (09/02/2009)
We have a server to which all clients connect for licensing, etc. This server also checks for updates from a web service. When an update is seen, it downloads the update to the client and loads it on the server (if setup) at a predetermined time (generally 3:00 AM). When the clients then get fired back up when the users start using the software, it queries the server to see if there is an update, if so, it copies the update local, installs it, and the install then re-shells the application so that it is one seamless update.
Hi Tent,
In the above scenario, lets say the software is setup in several workstations, if the update needs to update the database, how do you avoid every single copy of the update to trigger the update to the database?
|
By Greg McGuffey - 9/2/2009
If I were doing it, I'd have the server update the database. I.e. The client's server contacts the SF server, is notified of an update, update is downloaded, likely with some meta data...does SQL Server need to be updated, is this a required immediate update, etc. The server would then take any necessary actions...like updating the database, perhaps after kicking everyone off (gently of course). Of course, if this is happening at 3am, likely it is no big deal. When clients reconnect, they then get the update and it gets installed.
In my scenario (which isn't using anything like this  ) , I couldn't allow the clients to update the database in any case, as they are all remote, connecting via ES. I now have to do the db update manually before deploying the client app (via Click-Once...More tm).
|
By Edhy Rijo - 9/2/2009
Greg McGuffey (09/02/2009)
In my scenario (which isn't using anything like this ) , I couldn't allow the clients to update the database in any case, as they are all remote, connecting via ES. I now have to do the db update manually before deploying the client app (via Click-Once...More tm).
Yeap, this is also my case, even though I do not use ES. This scenario will required a Server application (which I have it almost done) to control the updates. Thing are getting really complicated, specially when dealing with several applications (projects) for many customers. 
I miss those days, where you just copy the single file to update everything 
|
By Bill Cunnien - 9/2/2009
If I understand software deployment using Active Directory, it boils down to one file. Here is the breakdown (untested):
Create the MSI file from my solution.
Copy the file to a shared folder on the server from which AD will deploy the software.
Done.
The setup in AD is quite simple, too. Create a group policy object (or edit an existing) with the software installation package pointing to the MSI file. Assign the group policy object to the appropriate container. When the user in that container logs on the software is installed.
This doesn't seem too hard. I will be testing this scenario within the IT group to see how it works. If it works as advertised then this will be magic!
I'll post my results here.
|
By Bill Cunnien - 9/3/2009
The first test went as follows:
1) Created and built the setup project for the StrataFrame application
2) Created a network shared folder to store the MSI file
3) Copied the MSI file to the shared folder
4) Created a Software Installation Package for a specific group policy (pointed to the MSI file in the shared folder)
a) The group policy has been assigned to the IT users only
b) The package was added to the User Configuration - Software Settings section
c) Changed the installation user interface option to 'Basic' (under Properties - Deployment)
5) User logged off then back on
a) Desktop icon created
b) Program menu icon created
6) User double-clicked the desktop or menu icon and the application installed.
Everything went very, very smoothly. I am absolutely amazed at how easy this whole process was.
Next, I am going to figure out how to handle any updates to the software. I will post those results here, too.
Bill
|
By Bill Cunnien - 9/4/2009
The update method was extremely simple (once I figured out how to get the setup project to produce an updated MSI file). I copy the MSI file to the shared folder. I told it to overwrite the file that already exists there. Then, I go to the group policy, user configuration, software settings and right-click on the existing package. From the "All Tasks" menu, I choose "Redeploy application". There is a confirmation to approve--basically it tells me that the software will be reinstalled only in places where it is already installed. The rest will be fresh installations.. After that, it is set. The user will have the new software updated (technically, reinstalled) the next time he logs in.
Good stuff. For me, this will work beautifully!
|
By Trent L. Taylor - 9/7/2009
In the above scenario, lets say the software is setup in several workstations, if the update needs to update the database, how do you avoid every single copy of the update to trigger the update to the database? As I mentioned, we have a server for our medical software. The server must be updated first before any workstations. The same update is used for both, but the clients do not attempt to do anything that is specific to the server (the updater we wrote knows if we are on the server or a client). The server, as mentioned, downloads the update and then updates itself through the service and updates any structures, etc. Within the updater we have a little script that knows what needs to be done on the server and what needs to be done on the client and what belongs to both. So it really is not a difficult thing to implement.
|
|