Upgrading Communicator 2007 R2 MSI with Jan 2010 Hotfix MSP
Looking for some assistance here - searching the forums has helped some, but not given me the answer. My packaging skills are about 'learning novice' IMO.
I'm looking to deploy a package of Communicator 2007 R2 via ConfigMgr, using the base version MSI (3.5.6907.0), which has been slipstreamed to include the latest Jan 2010 hotfix KB967135 (MS deliver the hotfix as an MSP). So far, so good. Deployment of the original MSI (3.5.6907.0) via ConfigMgr works just fine.
The base MSI does not appear to behave properly when trying to create an Admin Install using msiexec /a. It just creates an identical randomly-named MSI in the admin user profile temp directory, which is deleted when you click Finish.
If I apply the MSP onto the original MSI using msiexec /p Communicator.msp /a Communicator.msi, it appears to complete successfully (the MSI is updated) but it also creates a \PFiles and \Windows directory in the same path which contain various files/subdirs.
Every attempt to install the resulting MSI (whether I include the unpacked PFiles and Windows directories as mentioned above in the package, or just the updated MSI), gives the error 'the file 'UCDll' cannot be installed because the file cannot be found in cabinet file 'MsgrCore.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package'.
The MsgrCore.cab file is contained in the original MSI, and the updated MSI. Neither version contain a file 'UC.dll' or UCdll, but both contain Uccp_dll. That may be a red herring.
As an alternative I've tried applying the MSP during the deployment install using the syntax "msiexec /qn+ /i Communicator.msi /p Communicator.msp (and variations on this using PATCH=Communicator.msp) , and the only command that works is by specifying the full path to the MSP, e.g. "msiexec /qn+ /i Communicator.msi PATCH="C:\temp\Communicator.msp".
If only using the full path and not a relative path to the MSP works, I can't use the above command line for ConfigMgr deployment unless I script the MSP file to be copied to a known local path on the client machine first. Which is undesirable.
Is my slipstream/deployment strategy completely wrong? Or is there some known issue with this MSI that I haven't found through searching?
Thanks & apologies for the long post.
I'm looking to deploy a package of Communicator 2007 R2 via ConfigMgr, using the base version MSI (3.5.6907.0), which has been slipstreamed to include the latest Jan 2010 hotfix KB967135 (MS deliver the hotfix as an MSP). So far, so good. Deployment of the original MSI (3.5.6907.0) via ConfigMgr works just fine.
The base MSI does not appear to behave properly when trying to create an Admin Install using msiexec /a. It just creates an identical randomly-named MSI in the admin user profile temp directory, which is deleted when you click Finish.
If I apply the MSP onto the original MSI using msiexec /p Communicator.msp /a Communicator.msi, it appears to complete successfully (the MSI is updated) but it also creates a \PFiles and \Windows directory in the same path which contain various files/subdirs.
Every attempt to install the resulting MSI (whether I include the unpacked PFiles and Windows directories as mentioned above in the package, or just the updated MSI), gives the error 'the file 'UCDll' cannot be installed because the file cannot be found in cabinet file 'MsgrCore.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package'.
The MsgrCore.cab file is contained in the original MSI, and the updated MSI. Neither version contain a file 'UC.dll' or UCdll, but both contain Uccp_dll. That may be a red herring.
As an alternative I've tried applying the MSP during the deployment install using the syntax "msiexec /qn+ /i Communicator.msi /p Communicator.msp (and variations on this using PATCH=Communicator.msp) , and the only command that works is by specifying the full path to the MSP, e.g. "msiexec /qn+ /i Communicator.msi PATCH="C:\temp\Communicator.msp".
If only using the full path and not a relative path to the MSP works, I can't use the above command line for ConfigMgr deployment unless I script the MSP file to be copied to a known local path on the client machine first. Which is undesirable.
Is my slipstream/deployment strategy completely wrong? Or is there some known issue with this MSI that I haven't found through searching?
Thanks & apologies for the long post.
0 Comments
[ + ] Show comments
Answers (19)
Please log in to answer
Posted by:
nheim
14 years ago
Hi Tim,
this behaviour occurs, because this package is not well designed (it lacks some dialogs) for an admin install.
You need to call the commands, like i suggested for OC 2k5 in this post:
http://www.appdeploy.com/messageboards/fb.asp?m=38573
Regards, Nick
this behaviour occurs, because this package is not well designed (it lacks some dialogs) for an admin install.
You need to call the commands, like i suggested for OC 2k5 in this post:
http://www.appdeploy.com/messageboards/fb.asp?m=38573
Regards, Nick
Posted by:
MSIPackager
14 years ago
If only using the full path and not a relative path to the MSP works, I can't use the above command line for ConfigMgr deployment unless I script the MSP file to be copied to a known local path on the client machine first. Which is undesirable.
Your patching process seems good to me - apart from trying to patch the original MSI, rather than patching an AIP - which from what you've said it won't create.
I don't know anything about the ConfMgr deployment tool but can you not call a vbscript to install the MSI and then the MSP? You can then have the script code workout where it's being run from and prefix the path accordingly - e.g. PATCH="\\random\share\Communicator.msp" where the \\random\share bit is resolved by the script - obviously before running the commandline.
Does this make sense?
Cheers,
Rob.
EDIT - or just follow Nick's link [;)]
Posted by:
timread
14 years ago
Thanks guys, excellent advice. It almost worked [:(].
I followed your advice Nick, and created the AI point using TARGETDIR. Then applied the MSP also using this property. All went OK, and the Admin Install point was patched without errors. It still unpacked the MSI and populated the \PFiles and \Windows subdirectories though - the patched Communicator.msi file is only 690KB.
I then tested installing from the patched Admin Install, using msiexec /qn+ /i Communicator.msi /L*v C:\temp\communicator.log. I got the install completed successfully dialog, all looked OK and I see no errors in the verbose log.
But when I run Communicator, it displays the error 'The application has failed to start because Uc.dll was not found. Reinstalling the application may fix this problem.'
What is it with this file?!
I followed your advice Nick, and created the AI point using TARGETDIR. Then applied the MSP also using this property. All went OK, and the Admin Install point was patched without errors. It still unpacked the MSI and populated the \PFiles and \Windows subdirectories though - the patched Communicator.msi file is only 690KB.
I then tested installing from the patched Admin Install, using msiexec /qn+ /i Communicator.msi /L*v C:\temp\communicator.log. I got the install completed successfully dialog, all looked OK and I see no errors in the verbose log.
But when I run Communicator, it displays the error 'The application has failed to start because Uc.dll was not found. Reinstalling the application may fix this problem.'
What is it with this file?!
Posted by:
nheim
14 years ago
Hi Tim,
that means, something with the patching went wrong!
This is the only file which is added by the patch.
It should lie here: .\PFiles\Microsoft Office Communicator\uc.dll
Make sure, you issue the patch command from the AIP dir.
Regards, Nick
that means, something with the patching went wrong!
This is the only file which is added by the patch.
It should lie here: .\PFiles\Microsoft Office Communicator\uc.dll
Make sure, you issue the patch command from the AIP dir.
Regards, Nick
Posted by:
timread
14 years ago
Nick, you hit the nail on the head - I ran the patch command from the original MSI directory, not the AIP directory. Rooky error.
I redid the AIP and ran patch upgrade from the AIP directory, and everything worked this time - the patch applied, and installing the patched package no longer gives me the UC.dll error and reports the correct version (3.5.6907.83). Looks like I have a working package [:D]
Much appreciated!
I redid the AIP and ran patch upgrade from the AIP directory, and everything worked this time - the patch applied, and installing the patched package no longer gives me the UC.dll error and reports the correct version (3.5.6907.83). Looks like I have a working package [:D]
Much appreciated!
Posted by:
nheim
14 years ago
Hi Tim,
good to hear it's working now.
And to take something out of it:
If there is no dialog to put in the destination directory on admin install, use the TARGETDIR property.
Happy MSI'ing...
Regards, Nick
good to hear it's working now.
And to take something out of it:
If there is no dialog to put in the destination directory on admin install, use the TARGETDIR property.
Happy MSI'ing...
Regards, Nick
Posted by:
guy.forum
14 years ago
Hi,
I am right now also doing the same stuff but facing a wierd problem.
I need to have an MST post patching the MSP to communicator MSI.
What i did is:
1.) msiexec /a c:\communicator.msi TARGETDIR=C:\AIP
2.) msiexec /p c:\communicator.msp /a C:\AIP\communicator.msi > All went OK till here..
3.) Create the MST of C:\AIP\communicator.msi and add registries and files in System32 and compiled it.
4.) Execution msiexec /i c:\Aip\communicator.msi TRANSFORMS=c:\aip\comm.mst /qb!
Here it gives error cannot find the file at c:\aip\system32\<filename.exe> . Actually the file is in CAB file outside.
Why this error is occuring and how to resolve it?
Workaround: I placed the required file in system32 of admin image and it works but i dont think this is a good solution to this issue.
Please comment..
I am right now also doing the same stuff but facing a wierd problem.
I need to have an MST post patching the MSP to communicator MSI.
What i did is:
1.) msiexec /a c:\communicator.msi TARGETDIR=C:\AIP
2.) msiexec /p c:\communicator.msp /a C:\AIP\communicator.msi > All went OK till here..
3.) Create the MST of C:\AIP\communicator.msi and add registries and files in System32 and compiled it.
4.) Execution msiexec /i c:\Aip\communicator.msi TRANSFORMS=c:\aip\comm.mst /qb!
Here it gives error cannot find the file at c:\aip\system32\<filename.exe> . Actually the file is in CAB file outside.
Why this error is occuring and how to resolve it?
Workaround: I placed the required file in system32 of admin image and it works but i dont think this is a good solution to this issue.
Please comment..
Posted by:
anonymous_9363
14 years ago
Since you're using an AIP, that's the only solution. Almost by definition, an AIP contains uncompressed external files, not CABs.
Posted by:
guy.forum
14 years ago
Thanks VBScab for the quick reply.
So it means that even if I create MST and cab file is created and then also i need to place those files in that System32 folder.
Is this is a good solution? Will it work from the network share seemlessly?
Any other way to achieve this? But yes I need to do AIP and then MST has to be created..
So it means that even if I create MST and cab file is created and then also i need to place those files in that System32 folder.
Is this is a good solution? Will it work from the network share seemlessly?
Any other way to achieve this? But yes I need to do AIP and then MST has to be created..
Posted by:
anonymous_9363
14 years ago
Hang on...I have to think now! :)
What does the Media table look like? Match the file's sequence number in the File table against the corresponding Media table entry. That table's 'Cabinet' column will tell you where the file needs to be.
What does the Media table look like? Match the file's sequence number in the File table against the corresponding Media table entry. That table's 'Cabinet' column will tell you where the file needs to be.
Posted by:
guy.forum
14 years ago
In Media table there is an addition of one more row (external cab) and cabinet colum shows the file is in the CAB which was newly created.
I checked the file sequence , seems to be alrite..
I checked the file sequence , seems to be alrite..
Posted by:
guy.forum
14 years ago
Idea: [:-]
Can i go like this way?
1.) msiexec /a c:\communicator.msi TRANSFORMS=c:\communicator.mst TARGETDIR=C:\AIP > create transform first and apply with in admin
2.) msiexec /p c:\communicator.msp /a C:\AIP\communicator.msi > apply patch
3.) Execution the msi with transform command.
Is this is a good way?
Or I just copy the files to system 32?
Which one is the better approach though i hvnt tried this one as of now..
Can i go like this way?
1.) msiexec /a c:\communicator.msi TRANSFORMS=c:\communicator.mst TARGETDIR=C:\AIP > create transform first and apply with in admin
2.) msiexec /p c:\communicator.msp /a C:\AIP\communicator.msi > apply patch
3.) Execution the msi with transform command.
Is this is a good way?
Or I just copy the files to system 32?
Which one is the better approach though i hvnt tried this one as of now..
Posted by:
guy.forum
14 years ago
m still waiting if any 1 could throw some light on this topic... [:o]
Posted by:
nheim
14 years ago
Hi Guy,
this makes no sense. A patch changes a package to its actual version (well, at least all packages, which are not named O2k7...).
And here is the border to the vendor.
A transform contains the changes and preferences, which YOU put into the package.
So, don't mix them up.
One solution would be, to create separate entries for your file in the directory table. Something like this:
CustSysFolder TARGETDIR System32:SourceDir
Then you need to change the directory entry of the component, which contains your file, to CustSysFolder.
With this changes, your file would get picked up right from the AIP folder.
You could even create a subfolder (we name it 'MySystem32') below AIP with the additional stuff inside.
That would need 2 additional entries in the directory table:
CustSysFolder TARGETDIR System32:MySysFolder
MySysFolder SourceDir MySystem32
Hope, this gives you some advice,
Regards, Nick
this makes no sense. A patch changes a package to its actual version (well, at least all packages, which are not named O2k7...).
And here is the border to the vendor.
A transform contains the changes and preferences, which YOU put into the package.
So, don't mix them up.
One solution would be, to create separate entries for your file in the directory table. Something like this:
CustSysFolder TARGETDIR System32:SourceDir
Then you need to change the directory entry of the component, which contains your file, to CustSysFolder.
With this changes, your file would get picked up right from the AIP folder.
You could even create a subfolder (we name it 'MySystem32') below AIP with the additional stuff inside.
That would need 2 additional entries in the directory table:
CustSysFolder TARGETDIR System32:MySysFolder
MySysFolder SourceDir MySystem32
Hope, this gives you some advice,
Regards, Nick
Posted by:
guy.forum
14 years ago
The files already having SystemFolder as a destination path n I have rechecked the same...
So, Can I just copy the file in System32 as the workaround that I did as of now? Is it good enuf to proceed?
So, Can I just copy the file in System32 as the workaround that I did as of now? Is it good enuf to proceed?
Posted by:
nheim
14 years ago
Hi Guy,
my suggestions in post #15 are useful, if you want a strict separation of the program itself and your alterations.
However, this is merely cosmetic.
Your approach works, that's the main thing.
Regards, Nick
my suggestions in post #15 are useful, if you want a strict separation of the program itself and your alterations.
However, this is merely cosmetic.
Your approach works, that's the main thing.
Regards, Nick
Posted by:
ramu_ch
14 years ago
I am right now also doing the same stuff but facing a wierd problem.
I need to have an MST post patching the MSP to communicator MSI.
What i did is:
1.) msiexec /a c:\communicator.msi TARGETDIR=C:\AIP
2.) msiexec /p c:\communicator.msp /a C:\AIP\communicator.msi > All went OK till here..
3.) Created the MST of C:\AIP\communicator.msi and did some modifications to Transform like moving shortcuts and adding some registry branding as per my company standards.
4.) Execution msiexec /i c:\Aip\communicator.msi TRANSFORMS=c:\aip\comm.mst /qb!
5.) Installation is completed successfully and as soon as i launched the shortcut i am getting the following error.
Microsoft Office Communicator R2 cannot start. The product license may be expired because you are using a pre-release or evaluation copy of the program, or the product key information may have been modified in your windows registry. Please run setup to uninstall and then reinstall office communicator.
i have the "certnew.p7b" file and i have installed the same still i am getting the error.
Note: I didn't get the error if i install only the MSI.
Please suggest ....
Thanks,
Ramu
I need to have an MST post patching the MSP to communicator MSI.
What i did is:
1.) msiexec /a c:\communicator.msi TARGETDIR=C:\AIP
2.) msiexec /p c:\communicator.msp /a C:\AIP\communicator.msi > All went OK till here..
3.) Created the MST of C:\AIP\communicator.msi and did some modifications to Transform like moving shortcuts and adding some registry branding as per my company standards.
4.) Execution msiexec /i c:\Aip\communicator.msi TRANSFORMS=c:\aip\comm.mst /qb!
5.) Installation is completed successfully and as soon as i launched the shortcut i am getting the following error.
Posted by:
anonymous_9363
14 years ago
In a case like this, where you have a discrepancy between installs, the FIRST thing to do is a comparison between the verbose logs of an MSI-only install and an MSI-plus-MST install.
Posted by:
Kipster
14 years ago
Well certainly way too late now, but as I ran into the same problem I thought I would go ahead and add this in. The transform did not register the Digital PID and PID value into the registry for me.
HKLM\Software\Microsoft\Communicator\3.5\Registration
DigitalProductID dword value ...
ProductID String value ...
I exported/imported them from a direct MSI installation. Seems to work for me now.
HKLM\Software\Microsoft\Communicator\3.5\Registration
DigitalProductID dword value ...
ProductID String value ...
I exported/imported them from a direct MSI installation. Seems to work for me now.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.