Errors after packaging Filenet using Winstall
First of all, Hi, and at the same time thank god I found you!
I'm taking part in a deployment of 1000+ PC's on a couple of sites and having done 800 of them our team is now faced with having recently lost our packaging guru, and are left with a few inexperienced people to do the job. We didn't think it was goign to be too much of a chore until we moved to another site and an application we were unfamiliar with cropped up. Namely Filenet which is being used as a fax and scanning gateway amongst several other things.
nobody was left ot package it so, I had to have a go myself, which I thought wouldn't be too hard, as I've done a couple of packages in the past that went smoothly and hadn't anticipated any problems with it.
However it looks like I'm doing something wrong and I can't figure out what it is.
the full installation of the product requires 3 reboots which isn't something I've had to deal with in the past so I wasn't sure how to proceed with it. First off I just tried to do the whole installation reboots and all just running Winstall before and after to do the snapshots, and I got some warnings that although it was successful some minor errors came up with regard to UNC shortcuts etc (see below):
http://img78.photobucket.com/albums/v290/vibe666/MSI_Errors_2.bmp
I wasn't sure which part of the installation was causing these packaging errors so I decided to make 3 MSI's of the 3 parts of the installation so I'd know which bit was the troublemaker and maybe (hopefully) it would be the last part which was 2 patch installs, so I could just to the last bit manually, which although not perfect would cut down on the time it took to deploy FileNet.
No such luck though, as it was the first part of the install that was causing these errors, with the other two being OK. I made the most of it however by making the configuration changes needed for filenet in the second MSI so the first part is a relatively simple manual install and any config changes to it are bundled in the second MSI, cutting install time a little.
My main problem now, was to see if I could get the first part out of the way altogether and package it sucessfully.
I was still getting the same errors at the end of packaging, no matter how I tried to do it, and in addition was getting the following errors when running that first MSI:
http://img78.photobucket.com/albums/v290/vibe666/Error_1.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_2.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_3.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_4.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_5.jpg
So, I'm hoping someone will be able to tell me where I'm going wrong and how to do it the right way, or I'm going to have to install this thign manually on about 200 PC's, and even the thought of that is driving me crazy!
Thanks in advance for any help.
***viBe***
I'm taking part in a deployment of 1000+ PC's on a couple of sites and having done 800 of them our team is now faced with having recently lost our packaging guru, and are left with a few inexperienced people to do the job. We didn't think it was goign to be too much of a chore until we moved to another site and an application we were unfamiliar with cropped up. Namely Filenet which is being used as a fax and scanning gateway amongst several other things.
nobody was left ot package it so, I had to have a go myself, which I thought wouldn't be too hard, as I've done a couple of packages in the past that went smoothly and hadn't anticipated any problems with it.
However it looks like I'm doing something wrong and I can't figure out what it is.
the full installation of the product requires 3 reboots which isn't something I've had to deal with in the past so I wasn't sure how to proceed with it. First off I just tried to do the whole installation reboots and all just running Winstall before and after to do the snapshots, and I got some warnings that although it was successful some minor errors came up with regard to UNC shortcuts etc (see below):
http://img78.photobucket.com/albums/v290/vibe666/MSI_Errors_2.bmp
I wasn't sure which part of the installation was causing these packaging errors so I decided to make 3 MSI's of the 3 parts of the installation so I'd know which bit was the troublemaker and maybe (hopefully) it would be the last part which was 2 patch installs, so I could just to the last bit manually, which although not perfect would cut down on the time it took to deploy FileNet.
No such luck though, as it was the first part of the install that was causing these errors, with the other two being OK. I made the most of it however by making the configuration changes needed for filenet in the second MSI so the first part is a relatively simple manual install and any config changes to it are bundled in the second MSI, cutting install time a little.
My main problem now, was to see if I could get the first part out of the way altogether and package it sucessfully.
I was still getting the same errors at the end of packaging, no matter how I tried to do it, and in addition was getting the following errors when running that first MSI:
http://img78.photobucket.com/albums/v290/vibe666/Error_1.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_2.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_3.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_4.jpg
http://img78.photobucket.com/albums/v290/vibe666/Error_5.jpg
So, I'm hoping someone will be able to tell me where I'm going wrong and how to do it the right way, or I'm going to have to install this thign manually on about 200 PC's, and even the thought of that is driving me crazy!
Thanks in advance for any help.
***viBe***
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
Gripper
19 years ago
I've packaged this before using WinInstall. Remove the check from the box for self-registration. I don't remember where it is exactly as I'm using Wise at the moment so can't check. I think it's in the properties of the file?
Post back how that goes as I think there's another step to take which I'll look up.
Post back how that goes as I think there's another step to take which I'll look up.
Posted by:
vibe666
19 years ago
thanks for the help.
I'm just going to re-do it now, so I'll let you know how I get on.
I'm just going to re-do it now, so I'll let you know how I get on.
Posted by:
MSIMaker
19 years ago
I have had the pleasure for doing this app already and I know one major thing about it that is beyond reason but unavoidable.
The Filenet IDM manager which starts itself on startup must have full access to HKCR key. I know this sounds unbelievable but its true. As your users will not have write access to that key, you will have to create a custom action to permission that key and ALL keys below it. I suggest you create a group in AD that will be allowed this access. Filenet does an OpenKey query statement on that key and if the rights to the key are not both Open and Write the IDM Manager will fail on startup. It doesnt even write to the key....but the program still requires the access. Beats me but its true.
As for your other errors...load the msi in (insert your packaging software name here) and go to the selfreg table and remove all the entries.
All of the Filenet dll's that are installed to the System32 folder can be moved safely to the app folder as well. The app also trys to install some dll's that Office already installs so you can remove them without a worry ie ctl3dv2.dll. remove the file and any reg keys that point to that file. Also remove the CLSID and Typelib associated to it.
Look in the .reg file that Wininstall makes and do a search on \system32 and remove those keys altogether.
All of the Filenet DLL's that have registry keys pointed at System32 can be changed to c:\Program Files\Filenet\IDM after you move them there.
From memory the Filenet config entries are stored in HKLM\Sofware\IDM and if your users dont have write access to that key it then you will need to open that key for them or they wont be able to connect to a Filenet Library. Dont hardcode the library info for them or you will have to uninstall the whole app everytime a new library is added to the network. Best idea is to split out the IDM config file altogether and send it as a seperate msi to save uninstalling the whole app in the future.
If they are going to use the high speed scanner options then package the scanner and drivers as a separate msi as well just in case.
There is also an IDM Filenet viewer which is part of the desktop install that you might want to package separately as well......in case they want to have users who are not Filenet Authors or Admins......just viewers. Its just a few ActiveX controls that let them view with Internet Explorer.
Thats all I can think of at the moment.....if you get in trouble let me know.
The Filenet IDM manager which starts itself on startup must have full access to HKCR key. I know this sounds unbelievable but its true. As your users will not have write access to that key, you will have to create a custom action to permission that key and ALL keys below it. I suggest you create a group in AD that will be allowed this access. Filenet does an OpenKey query statement on that key and if the rights to the key are not both Open and Write the IDM Manager will fail on startup. It doesnt even write to the key....but the program still requires the access. Beats me but its true.
As for your other errors...load the msi in (insert your packaging software name here) and go to the selfreg table and remove all the entries.
All of the Filenet dll's that are installed to the System32 folder can be moved safely to the app folder as well. The app also trys to install some dll's that Office already installs so you can remove them without a worry ie ctl3dv2.dll. remove the file and any reg keys that point to that file. Also remove the CLSID and Typelib associated to it.
Look in the .reg file that Wininstall makes and do a search on \system32 and remove those keys altogether.
All of the Filenet DLL's that have registry keys pointed at System32 can be changed to c:\Program Files\Filenet\IDM after you move them there.
From memory the Filenet config entries are stored in HKLM\Sofware\IDM and if your users dont have write access to that key it then you will need to open that key for them or they wont be able to connect to a Filenet Library. Dont hardcode the library info for them or you will have to uninstall the whole app everytime a new library is added to the network. Best idea is to split out the IDM config file altogether and send it as a seperate msi to save uninstalling the whole app in the future.
If they are going to use the high speed scanner options then package the scanner and drivers as a separate msi as well just in case.
There is also an IDM Filenet viewer which is part of the desktop install that you might want to package separately as well......in case they want to have users who are not Filenet Authors or Admins......just viewers. Its just a few ActiveX controls that let them view with Internet Explorer.
Thats all I can think of at the moment.....if you get in trouble let me know.
Comments:
-
Please can you tell me which is the HKCR key (exact key) that i should give access
Thanks in advance - abhaypatil00@gmail.com 10 years ago
Posted by:
vibe666
19 years ago
OK, so the good news is I finally got it fixed, and it seems to be working fine.
I haven't got it in AD yet, but the MSI is workign perfectly from a manual install.
the better news is that all it took to get rid of the errors and get it working properly was opening the MSI in the Winstall console and finding the .DLL's that were causing the errors and turning off autoregistration for those files.
I'm quite chuffed with myself really.
I didn't even need to move anything around or give users admin rights for that registry key or anything. i feel quite chuffed with myself. [:D]
thanks again for the help.
***viBe***
I haven't got it in AD yet, but the MSI is workign perfectly from a manual install.
the better news is that all it took to get rid of the errors and get it working properly was opening the MSI in the Winstall console and finding the .DLL's that were causing the errors and turning off autoregistration for those files.
I'm quite chuffed with myself really.
I didn't even need to move anything around or give users admin rights for that registry key or anything. i feel quite chuffed with myself. [:D]
thanks again for the help.
***viBe***
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.