asked on VS 2013 installer, Install, Update and uninstall via SCCM
I have an application that now needs to be installed via a msi file using SCCM.
The application consists of a executable, library (.dll), configuration and a number of other files plus a number of folders containing HTML pages, javascript files and stylesheets.
The users can create there own stylesheets (with unique names) and these must not be removed when the update is performed.
What I need to be able to do is
for a new install, copy all files and folders to path specified by installer.
for an update, overwrite any named files but leave all other files.
for an uninstall remove all folders.
The ability to roll back would be handy but not essential at this stage.
If a new path is chosen for the install then the old files and folders are left where they are so it is treated as a new install, not a modification.
Does anyone know how of any examples where this has been done or any tutorials on it?
The application consists of a executable, library (.dll), configuration and a number of other files plus a number of folders containing HTML pages, javascript files and stylesheets.
The users can create there own stylesheets (with unique names) and these must not be removed when the update is performed.
What I need to be able to do is
for a new install, copy all files and folders to path specified by installer.
for an update, overwrite any named files but leave all other files.
for an uninstall remove all folders.
The ability to roll back would be handy but not essential at this stage.
If a new path is chosen for the install then the old files and folders are left where they are so it is treated as a new install, not a modification.
Does anyone know how of any examples where this has been done or any tutorials on it?
SCCMC#* msi
Last Comment
jetbet
ASKER
The current release is a zip-file containing all folders needed, which is sent out to the users to unzip in their own time and copy any of there own style-sheets into the appropriate folders where they are used by the HTML pages. The HTML pages are created on the fly and so they can select the style-sheet they wish to use from the GUI. Likewise the users also have a configuration file that they contains their preferences for what fields are added to the HTML page, etc.
Most of the Servers and Laptops that this application runs on are only occasionally connected to the network due to the nature of the functionality.
In the new world I have been told that the users will no longer be allowed to install this manually and it must be done via SCCM.
I have been told that I need to provide the people that manage the SCCM process with a single .msi file and a list of users.
If a user is in the correct group then when they connect to the network the release will be installed automatically without any user input and so will overwrite the existing release.
Many releases may only have a couple of files changed but I also need to cater for new users that need the entire set of folders and files.
VS2013 is Visual Studio 2013 which is what the code base is developed in.
It appears from my reading that there are 2 ways of creating the .msi file. The first is to create a new project and have this package up the files from the existing solution. The second is to add the installer as a project to the existing solution.
Most of the Servers and Laptops that this application runs on are only occasionally connected to the network due to the nature of the functionality.
In the new world I have been told that the users will no longer be allowed to install this manually and it must be done via SCCM.
I have been told that I need to provide the people that manage the SCCM process with a single .msi file and a list of users.
If a user is in the correct group then when they connect to the network the release will be installed automatically without any user input and so will overwrite the existing release.
Many releases may only have a couple of files changed but I also need to cater for new users that need the entire set of folders and files.
VS2013 is Visual Studio 2013 which is what the code base is developed in.
It appears from my reading that there are 2 ways of creating the .msi file. The first is to create a new project and have this package up the files from the existing solution. The second is to add the installer as a project to the existing solution.
Hi,
Thanks for the clarification. Let me explain first what ConfigMgr (aka SCCM or CM) can do:
1) Deploy "Applications".
In CM Microsoft has made MSI installers the default format to install software. This works very well when vendors provide a MSI. When you download any software it is either an MSI file or an EXE. If it is an EXE the chances are good that there is an MSI inside.
If you have an EXE then you either use (2) or choose custom setup and provide a command line that does a *silent* install.
2) Deploy Packages
This is used when you either do not have an MSI or want to use the Legacy style deployment. This is best left for doing file copies, with a simple script.
Solution
The approach: provide "the people that manage the SCCM process" with a single .msi file and a list of users is not helpful. If you have 100 people and each setup/install is different that is 100 MSI files.
The difficulty you have is the using (1) OR (2) you will need 100 deliverables.
If the SCCM team is inflexible and only want MSI files, then that will be expensive because you need to know pay someone to sit and create 100 MSI installers using a commercial copy of Adminstudio (or other packaging software).
You need to explain to the SCCM guys the above, depending on how many users you have. The more users the more work you and they will end up doing. I doubt either of you want that.
The only way around it would be to create one master package (not MSI) that copies the files to the local machine and then have a PowerShell script that copies a delta per user. You would need something like
VSCore
..\Moe\files
...\Harpo\files
..\Groucho\files
If you have more than 5 users, the last thing you want is create MSI files. You *could* create one MSI and create "user" deltas per user using MST files but that's still making work.
Mike
Thanks for the clarification. Let me explain first what ConfigMgr (aka SCCM or CM) can do:
1) Deploy "Applications".
In CM Microsoft has made MSI installers the default format to install software. This works very well when vendors provide a MSI. When you download any software it is either an MSI file or an EXE. If it is an EXE the chances are good that there is an MSI inside.
If you have an EXE then you either use (2) or choose custom setup and provide a command line that does a *silent* install.
2) Deploy Packages
This is used when you either do not have an MSI or want to use the Legacy style deployment. This is best left for doing file copies, with a simple script.
Solution
The approach: provide "the people that manage the SCCM process" with a single .msi file and a list of users is not helpful. If you have 100 people and each setup/install is different that is 100 MSI files.
The difficulty you have is the using (1) OR (2) you will need 100 deliverables.
If the SCCM team is inflexible and only want MSI files, then that will be expensive because you need to know pay someone to sit and create 100 MSI installers using a commercial copy of Adminstudio (or other packaging software).
You need to explain to the SCCM guys the above, depending on how many users you have. The more users the more work you and they will end up doing. I doubt either of you want that.
The only way around it would be to create one master package (not MSI) that copies the files to the local machine and then have a PowerShell script that copies a delta per user. You would need something like
VSCore
..\Moe\files
...\Harpo\files
..\Groucho\files
If you have more than 5 users, the last thing you want is create MSI files. You *could* create one MSI and create "user" deltas per user using MST files but that's still making work.
Mike
ASKER
I am hoping that it is not quite as bad as that as I believe, at most, I just need to have 2 instances, the first that copies the entire directory structure for a new install and the second that just replaces the changed files for those with an existing install.
I am unsure If SCCM can detect the existence of an installation on the target machine and so choose the correct option. It would be good if there was just one .msi file that checked the existence as part of the install and used a list of changed files for pre-existing installs.
The other thing that I am unsure of is that SCCM seems to be done on a per user basis so this would say that any machine the user logs in from may end up getting the install automatically.
I am unsure If SCCM can detect the existence of an installation on the target machine and so choose the correct option. It would be good if there was just one .msi file that checked the existence as part of the install and used a list of changed files for pre-existing installs.
The other thing that I am unsure of is that SCCM seems to be done on a per user basis so this would say that any machine the user logs in from may end up getting the install automatically.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thanks for that it gives me a good starting point to continue my development
I don't understand the question: you start with a statement "I have an app that needs to be installed via MSI"
but then proceed to explain something that is totally opposite of an MSI.
Please elaborate with full detail. Is the MSI replacing the current version? Is VS 2013 Visual Studio 2013? If so, why are you talking about copying files and folders etc.
Mike