Restriction of number of MSP Patches that can be installed
Hello,
Is there any restriction or default value to number of MSP patches that can be installed on particular MSI package ?
I am facing one issue which is :-
I have one MSI package installed and we usually create MSP patches to fix bugs\issues which are then installed one by one. So on my system there are 127 patches installed and when i try to install 128th MSP patch, it fails with error 1636.
Main engine returns error 1636 and internal installation log (created with /l*v) gives following error :-
DEBUG: Error 2226: Database: . Transform failed.
If i install same patch on the system having 126 patches, then it installs successfully without any error.
Is there any setting or default value to number of patches that can be installed ?
Any help\suggestions would be appreciated.
Thanks,
Ishant
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
ibahrani
7 years ago
Thanks guys for your inputs.
I had contacted Microsoft for this and they have confirmed that it is the limitation i.e., we cannot install more than 127 patches
I had contacted Microsoft for this and they have confirmed that it is the limitation i.e., we cannot install more than 127 patches
Posted by:
anonymous_9363
7 years ago
Error 1636: This patch package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer patch package.
To answer your question, no, there is no limit. A much more efficient way to deploy patches, however, would be to create an Administrative Installation Point, patch that and then deploy the resulting MSI.
Comments:
-
Thanks you so much VBSCab.
Can this behavior of installation failure on 128th MSP be because we are using installshield quickpatch project ?
Few questions, please help me having more understanding on the approach you suggested,
Is the approach you suggested above exactly equivalent to installing MSP alone ?
I am asking this because right now our customer installs MSP patches in any order based on the issue\bug faced (suppose we have released 10 MSPs till date for 10 different bugs and customer faced bug 5 first so he will install MSP number 5 first and then based on the top of it based on next bug faced he can install MSP number 1 or 2 or 9 or 10 etc., in any order) and because of patch sequence, internally MSI + MSP takes care of non-version file and registry updates.
we also use "overwrite existing file" setting of installshield quick patch project as non-version files are also changed by customer externally (manually) so we need to have this overwrite setting.
e.g. if lower MSP number (MSP 1) is installed on top of higher MSP number (MSP 5) than in that case we get copy of non-version file (a.xml) of higher MSP number (MSP 5) (note :- a.xml is present in both MSPs).
Now with this approach will we get same behavior because there won't be any concept of patch sequence.
We have already released more than 100 MSPs patches and they are in production environment.
Thanks again for the response. - ibahrani 7 years ago -
Thanks guys for your inputs.
I had contacted Microsoft for this and they have confirmed that it is the limitation i.e., we cannot install more than 127 patches - ibahrani 7 years ago
Posted by:
anonymous_9363
7 years ago
To answer your first question, yes, the MSI you end up with in the AIP will produce exactly the same deployment as applying the patches one by one but it sounds like you're creating patches for your clients, in which case it's up to them how they approach deployment.
For non-versioned files, you could use companion files, rely on date/time stamping to differentiate older/newer files or stick with your overwrite rule. Personally, I like the last approach but obviously, your client needs to be made aware that their carefully crafted files will be overwritten.
.
Posted by:
Pressanykey
7 years ago
Hi,
patching can always be a bi*ch and there are not really many vendors (i.e. can count on one hand) that get it right.
Have you though about using a "fully patched" full msi and telling your customers to use the /fup (I remember correctly) to install / patch an existing product.
This will allow you to (dependent on the sequence of RemoveExistingProducts) complete a normal full installation on clients on which the product has never been installed and patch existing installations (only replacing the components that need to be patched) or removing the product and carrying out a full installation...
@Ian, help me out on this one, it's been years since I did this ;-)
Cheers
Phil
patching can always be a bi*ch and there are not really many vendors (i.e. can count on one hand) that get it right.
Have you though about using a "fully patched" full msi and telling your customers to use the /fup (I remember correctly) to install / patch an existing product.
This will allow you to (dependent on the sequence of RemoveExistingProducts) complete a normal full installation on clients on which the product has never been installed and patch existing installations (only replacing the components that need to be patched) or removing the product and carrying out a full installation...
@Ian, help me out on this one, it's been years since I did this ;-)
Cheers
Phil