Have you compared verbose installation logs from the case where you install all three websites, against the case where you don't install all three? That would be my starting point for investigating the issue.

Yes, I have compared install logs (/l*xv) and I don't find anything significant. This is especially strange when I expect it to just work

I still see no reason, after reviewing the logs, why the web.config file is not being updated when only 1 or 2 out of 3 components is being installed. There must be a reason (or some switch I'm forgetting).

Without knowing a lot more about your project I can't really be of much help. Presuming that the web.config files are being updated by a custom action, is the action running the same way in all scenarios?

What action modifies xml/web.config files? I didn't create any custom action

I would assume it will be a Wise custom action - the verbose log should give you a clue, as well as a look in the CustomAction table.

Attached are two verbose log files. One is is the log file when all components are being installed and web.config is being updated; the other is when only one component is being deployed and the web.config file isn't updated.



I think the custom action, built into Wise, is called WiseTextReplacement. The manual seems to confirm that (page 555 on 7.0 SP1 version)



In the log where web.config doesn't get updated, the following line appears on line 11719:

Doing action: WiseTextReplacementInit

This tells me that it should be working, but apparently it still isn't. Now I am really stumped.



In Execute Immediate (and Deferred), this appears:



If NOT REMOVE~="ALL" then

Call DLL From Installation FunctionWiseTextReplacementInit(WiseTextReplacementInit)

End





Any more ideas?, thanks!

OK, here is a section of the log from the non working installation:



Action start 19:56:38: WiseTextReplacementInit.

MSI (s) (44:FC) [19:56:38:766]: Creating MSIHANDLE (4700) of type 790542 for thread 2812

MSI (s) (44:0C) [19:56:38:806]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI49.tmp, Entrypoint: WiseTextReplacementInit

MSI (s) (44!E8) [19:56:39:588]: Creating MSIHANDLE (4701) of type 790541 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4702) of type 790540 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4703) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4704) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Closing MSIHANDLE (4703) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4705) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Closing MSIHANDLE (4704) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4706) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Closing MSIHANDLE (4705) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4707) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Closing MSIHANDLE (4706) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Closing MSIHANDLE (4707) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Closing MSIHANDLE (4702) of type 790540 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4708) of type 790540 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4709) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Creating MSIHANDLE (4710) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:598]: Closing MSIHANDLE (4710) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:618]: Creating MSIHANDLE (4711) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:618]: Closing MSIHANDLE (4711) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:628]: Creating MSIHANDLE (4712) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:628]: Closing MSIHANDLE (4709) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:648]: Creating MSIHANDLE (4713) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:648]: Closing MSIHANDLE (4713) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:648]: Creating MSIHANDLE (4714) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:648]: Closing MSIHANDLE (4712) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:648]: Creating MSIHANDLE (4715) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:658]: Note: 1: 2753 2: FileNet.xml

MSI (s) (44!E8) [19:56:39:658]: Closing MSIHANDLE (4715) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:658]: Creating MSIHANDLE (4716) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:658]: Closing MSIHANDLE (4716) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:658]: Creating MSIHANDLE (4717) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:658]: Closing MSIHANDLE (4714) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:658]: Creating MSIHANDLE (4718) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:658]: Note: 1: 2753 2: Web.config143

MSI (s) (44!E8) [19:56:39:658]: Closing MSIHANDLE (4718) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:668]: Creating MSIHANDLE (4719) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:668]: Closing MSIHANDLE (4719) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:678]: Creating MSIHANDLE (4720) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:678]: Closing MSIHANDLE (4717) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:678]: Creating MSIHANDLE (4721) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:678]: Closing MSIHANDLE (4721) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:688]: Creating MSIHANDLE (4722) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:688]: Closing MSIHANDLE (4720) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:688]: Creating MSIHANDLE (4723) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:688]: Note: 1: 2753 2: Documentum.xml

MSI (s) (44!E8) [19:56:39:688]: Closing MSIHANDLE (4723) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Creating MSIHANDLE (4724) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Closing MSIHANDLE (4724) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Creating MSIHANDLE (4725) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Closing MSIHANDLE (4722) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Creating MSIHANDLE (4726) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Closing MSIHANDLE (4726) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Creating MSIHANDLE (4727) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Closing MSIHANDLE (4725) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:698]: Creating MSIHANDLE (4728) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:708]: Closing MSIHANDLE (4728) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:708]: Creating MSIHANDLE (4729) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:708]: Closing MSIHANDLE (4727) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:708]: Creating MSIHANDLE (4730) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:708]: Note: 1: 2753 2: WindowsFile.xml

MSI (s) (44!E8) [19:56:39:708]: Closing MSIHANDLE (4730) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:708]: Creating MSIHANDLE (4731) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:708]: Closing MSIHANDLE (4731) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:718]: Creating MSIHANDLE (4732) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:718]: Closing MSIHANDLE (4729) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:718]: Creating MSIHANDLE (4733) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:718]: Closing MSIHANDLE (4733) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:718]: Creating MSIHANDLE (4734) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:718]: Closing MSIHANDLE (4732) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Creating MSIHANDLE (4735) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Closing MSIHANDLE (4735) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Creating MSIHANDLE (4736) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Closing MSIHANDLE (4734) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Creating MSIHANDLE (4737) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Closing MSIHANDLE (4737) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Closing MSIHANDLE (4736) of type 790531 for thread 1256

MSI (s) (44!E8) [19:56:39:728]: Closing MSIHANDLE (4708) of type 790540 for thread 1256

MSI (s) (44!E8) [19:56:39:738]: Closing MSIHANDLE (4701) of type 790541 for thread 1256

MSI (s) (44:0C) [19:56:39:738]: Closing MSIHANDLE (4700) of type 790542 for thread 2812

Action ended 19:56:39: WiseTextReplacementInit. Return value 1.



Note the lines I have highlighted - the 2753 error means that the file mentioned is not marked for installation.



At this point, I would be looking very closely at where your web config files are located in terms of their presence in a particular feature. If they are all in one feature, and that feature is not being installed, then the files won't be either, and as a consequence, their edits just won't happen either.

If you search the failing log for web.config143, for example, the component is shown as:

MSI (s) (44:FC) [19:56:23:517]: Component: Web.config143; Installed: Absent; Request: Null; Action: Null

In the working log, the same component appears thus:

MSI (s) (D8:6C) [19:31:14:945]: Component: Web.config143; Installed: Absent; Request: Local; Action: Local



The Installed, Request and Action fields are the key. Installed: Absent means that the component is not installed.

Request signifies what the installer has determined the installation requirement to be - Null means no action, Local means a local install.

Action signifies the action that the installer is going to take - again, null means no action, whereas Local means that the component will be installed locally (instead of running from the CD, for example).



So I hope that gives you something to investigate

Thanks for digesting the log file! The web.config file is indeed being deployed, but not being updated. Each component has their own web.config files (deploying three separate websites/apps). Does that mean the action is somehow being ignored perhaps because of feature selection?

That's what I'm hypothesising. Hence my suggestion that you identify the components that hold your web.config files and check that they are in the correct features. I don't know how you built your projects, but if you added the same file more than one to your project, it is possible that the file's second and third instances are in the DuplicateFiles table (for example) - at which point if the master does not deploy, then neither do the duplicates.

Thanks EdT for helping out with this, I work with Marc and am now investigating this issue a little further. I've discovered something new as well.....when the installer is run, it gives you the option to install application1, application2 and application3. And as Marc said, when all 3 are installed, it updates application1's Web.config file beautifully. Upon further investigation, I noticed it also works fine when application1 and application3 are chosen for install. The problem only arises when application3 is not chosen for install, all other choices are irrelevant.



Here is the appsettings section when application3 is chosen for install:

<appSettings>

<add key="SystemInformationFolderUrl" value="C:\Program Files\********\*********\App_Data\" />

<add key="EnableMap" value="No" />

<add key="DocumentConnectorServiceURL" value="http://dcs.wanker.com/DocumentConnectorService.asmx" />

<add key="HostHeaderDomain" value="wanker.com" />

<add key="ExGISURL" value="http://gis.wanker.com/default.aspx" />

<add key="ExDbDataSource" value="schema" />

<add key="ExDbUserName" value="username" />

<add key="ExDbPassword" value="password" />

</appSettings>



And here is the appsettings section when application3 is not chosen for install:

<appSettings>

<!--WISEMETA: value="[APP_DATA]"-->

<add key="SystemInformationFolderUrl" value="" />

<!--WISEMETA: value="[MAP_CONFIG]"-->

<add key="EnableMap" value="Yes" />

<!--WISEMETA: value="[TRADCS]"-->

<add key="DocumentConnectorServiceURL" value="http://dcs.wanker.com/DocumentConnectorService.asmx" />

<!--WISEMETA: value="[ORG_DOMAIN]"-->

<add key="HostHeaderDomain" value="wanker.com" />

<!--WISEMETA: value="[EXGIS]"-->

<add key="ExGISURL" value="http://gis.wanker.com/default.aspx" />

<!--WISEMETA: value="[EXSCHEMA]"-->

<add key="ExDbDataSource" value="" />

<!--WISEMETA: value="[EXUSERNAME]"-->

<add key="ExDbUserName" value="" />

<!--WISEMETA: value="[EXPASSWORD]"-->

<add key="ExDbPassword" value="" />

</appSettings>

My guess is that the action is somehow tied to application 3. You may need to consider adding another "application" (or feature) that is always installed, and associate the action with this feature.



By the way, are you aware the the term "w*nker" is offensive in the UK and probably other English speaking territories? We do try and avoid using such language in these forums, so please be a little more careful when posting in future. (http://en.wikipedia.org/wiki/Wanker)

quote:
Originally posted by: EdT

My guess is that the action is somehow tied to application 3. You may need to consider adding another "application" (or feature) that is always installed, and associate the action with this feature.



By the way, are you aware the the term "w*nker" is offensive in the UK and probably other English speaking territories? We do try and avoid using such language in these forums, so please be a little more careful when posting in future. (http://en.wikipedia.org/wiki/Wanker)

Sorry, his last name's Wenger so we call him Wanker. No worries, I'll take a look at the log files and application3 a bit more.

This may not be an action issue as much as a possible bug. I was just reading thread http://forums.altiris.com/mess...id=51614&enterthread=y and saw someone else is having a similar problem. Could this be related? My latest testing shows that there is a line in my installer as follows:

If NOT REMOVE ~="ALL" then

Call DLL From Installation Function WiseTextReplacementModify(WiseTextReplatementModify)

End



If I comment this out, my Web.config looks the same as when I choose not to install application3. It has the WISEMETA tags around the XML nodes and nothing gets updated. So I'm thinking this line of code may not be getting hit when application3 is not chosen for install, or maybe it's some sort of bug to do with the update tables as specified in the other thread I linked to. Any ideas or should I be following the log files for clues like you were telling Marc?

Have a close look at the logs around this particular custom action. Perhaps, as you surmise, this CA is not getting run unless Application 3 is installed. How are the features structured by the way? Three "master" features or one "master" and some subfeatures?

I'll have to ask Marc when he gets back to be sure but I'm almost positive it's 3 separate master features. They can all be installed independently and are 3 of their own separate programs.



I just found something else as well (sorry, not ignoring your suggestions).......if I uncheck the option to Enable Dynamic Editing from the application3 Web.config file, the main Web.config file gets updated properly which is what I'm trying to achieve here. So everything is good except the one single line that gets updated in the application3 Web.config file doesn't get updated (obviously).



I want to say as well, a big thanks for helping me out with this, I see your name on just about every thread I read through.

3 separate web applications.

quote:
Originally posted by: EdT

If you cannot track down the exact problem from the installation logs, it may be quicker overall to script your own solution for editing the XML files to your requirements, as custom actions. The only other thing I would suggest, if you have a support agreement with Wise, is to let them have sight of your code and check where the problem lies.

I just called them and wow........do they even have anyone buy customer support? First I called, chose option 2 and got forwarded to a fax machine for a minute, then to a an answering machine for a place called NPU but before I could leave a message it transferred me to another machine that got cut off when I was finally transferred to a woman who answered the phone saying, "Yes'm?" She was the first one to pick up the phone, every other time was half a recording and an automatic transfer before it finished. And 5 seconds into my first sentence to this woman I got cut off and it hung up on me. ?????



So I called back a second time, this time waiting for the menu options before choosing......but after hearing them, I once again chose option 2 for support but this time it went to a recording which sounded more correct. Pushed 1 for technical support, waited and someone came on the line asking me a bunch of questions about my operating system and version, that's fine. She put me on hold, click, cut off again. ??????



So I tried calling twice, it doesn't work. So here I am again, at the mercy of people much more knowledgeable than I, eternally grateful for the people who are taking time from their day to help me out (EdT) but still frustrated because our company pays for support but can't use it. What do I do now?

Hi danmaher,



I've informed Symantec regarding your problem reaching the support center and requested them to contact you directly instead.

Awesome. Thank you.



I'll post my results, until then please continue to help me if you have any solutions.

I've ran into this type of issue: dynamic .config files ignored at times. I ended up using the dynamic text feature offered by Wise. I resorted to my own custom action to do that after files are installed in the Execute Deferred msi script section.

I thought about doing that, and I actually wrote one already that the installer executes at a certain point to edit the same Web.config file, but I wanted to get as much of this thing running the proper way as I could. Otherwise I could simply call a GetElementByTag() method, replace the nodeAttribute.value field and I'm done.

Hello Danmaher,

First of all let me appolize for the problem you had reaching techncial support. Do you have a case number so I can research what happened?

What number did you call? That might also help establish where the problem lies.

I clicked the large SYMANTEC banner at the top, hovered over SUPPORT, then click Contact Support, then dialed the number that came up:

Americas

+1 801 226 8500, option 2



I created 2 log files....1 without application3 and one without application2. Of course without application3 failed to update the Web.config but the one without application2 worked perfectly, same as previous. So I've got 2 20,000 line log files and put them into WinMerge to view the differences between them......there doesn't seem to be anything relating to a failed install.



The only part that caught my attention (besides the errors EdT pointed out in the log file Marc posted on page 1) were the following differences:



::WITHOUT APPLICATION3::

MSI (s) (B4:98) [15:04:17:096]: Leaked MSIHANDLE (1968) of type 790541 for thread 2216

MSI (s) (B4:98) [15:04:17:096]: Closing MSIHANDLE (1968) of type 790541 for thread 2216

MSI (s) (B4:98) [15:04:17:096]: Note: 1: 2769 2: WiseWriteWebXMLDll 3: 8

<this space is where all the MSIHANDLES posted below are missing from>

DEBUG: Error 2769: Custom Action WiseWriteWebXMLDll did not close 8 MSIHANDLEs.

Internal Error 2769. WiseWriteWebXMLDll, 8



::WITHOUT APPLICATION2::

MSI (s) (B4!C0) [15:15:28:005]: PROPERTY CHANGE: Adding WISEVIRTUALDIRECTORY9_BEGINURL property. Its value is 'http://localhost/'.

MSI (s) (B4!C0) [15:15:28:005]: PROPERTY CHANGE: Adding WISEVIRTUALDIRECTORY9_URL property. Its value is 'http://localhost'.

MSI (s) (B4!C0) [15:15:28:005]: PROPERTY CHANGE: Adding WISEVIRTUALDIRECTORY9_HOMEDIR property. Its value is 'C:\Program Files\**********\******EX\'.

MSI (s) (B4!C0) [15:15:28:005]: PROPERTY CHANGE: Adding WISEVIRTUALDIRECTORY9_INSTTYPE property. Its value is 'EXIST'.

MSI (s) (B4!C0) [15:15:28:005]: Closing MSIHANDLE (6293) of type 790541 for thread 4032

MSI (s) (B4!C0) [15:15:28:005]: Closing MSIHANDLE (6291) of type 790531 for thread 4032

MSI (s) (B4!C0) [15:15:28:005]: Closing MSIHANDLE (6288) of type 790531 for thread 4032

MSI (s) (B4!C0) [15:15:28:005]: Closing MSIHANDLE (6287) of type 790540 for thread 4032

MSI (s) (B4!C0) [15:15:28:015]: Closing MSIHANDLE (6290) of type 790540 for thread 4032

MSI (s) (B4!C0) [15:15:28:015]: Closing MSIHANDLE (6285) of type 790541 for thread 4032

MSI (s) (B4!C0) [15:15:28:015]: Closing MSIHANDLE (6283) of type 790531 for thread 4032

MSI (s) (B4!C0) [15:15:28:015]: Closing MSIHANDLE (6230) of type 790540 for thread 4032

MSI (s) (B4!C0) [15:15:28:015]: Closing MSIHANDLE (6229) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6226) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6226) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6220) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6220) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6214) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6214) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6208) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6208) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6202) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6202) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6193) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6193) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6187) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6187) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Leaked MSIHANDLE (6182) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Closing MSIHANDLE (6182) of type 790541 for thread 4032

MSI (s) (B4:18) [15:15:28:025]: Note: 1: 2769 2: WiseWriteWebXMLDll 3: 8

DEBUG: Error 2769: Custom Action WiseWriteWebXMLDll did not close 8 MSIHANDLEs.

Internal Error 2769. WiseWriteWebXMLDll, 8



As you can see, the WiseWriteWebXML was called in the top one, but not called in the bottom one. Then there was a pile of MSIHANDLE errors (errors everywhere in this log file) in the bottom one that aren't in the top one. Then the WiseWriteWebXML was called in both after saying it did not close 8 MSIHANDLES. I'm trying to decipher what this means but the name makes it sound like it's writing to a web XML file and it's not consistent in both. If this doesn't work, I'm not sure what the issue is.



Just to clarify, I'll explain again what's supposed to happen.

1. User chooses any combination of application1, application2 or application3 when running installer. All three are separate web applications.

2. If user chooses application1 (which usually is done but not required) then a Web.config file is created.

3. If user chooses a second (or even third) option, corresponding Web.config are created in their corresponding directories but they should also update the Web.config for application1 which is the main (but completely separate) application.

4. Works fine as long as application3 is chosen for installation. If not chosen, application1's Web.config does not get updated with anything and is left with assorted WISEMETA tags inserted everywhere.

5. Corresponding Web.config files for other installed applications do get updated properly under all situations and test cases.

quote:
Originally posted by: Altiris Forum Moderator

Hello Danmaher,

First of all let me appolize for the problem you had reaching techncial support. Do you have a case number so I can research what happened?

Case number? No, sorry, I wasn't given one.

Checking my email from Altiris registration, I have an invoice number, an order number and registration code. I'm told we have a year of technical support so I was hoping to present this issue to someone with more expertise.



And you can call me Dan if you like.

Hello Dan,

When you called support they should have given you a case number to troubleshoot the issue.

She asked me a few questions for 2 minutes, put me on hold and then I got cut off.

If you still need help I would sugget you try calling again.;

I'll try calling Symantec again today after some more troubleshooting.

I just removed application3 from the installer, recompiled, ran, chose to install application1 and appilcation2, and everything worked perfect. So it works when application3 is not present, but doesn't work when I simply choose not to install it. Weird.

Perhaps a comparison of the installation logs of the "Two Feature" MSI, compared to that of the "Three Feature MSI" with Feature 3 not selected, might yield something. It certainly appears weird based on what you've told us so far.

Okay, I might have it. First I want to say thanks to everyone for helping me out so far, the nightmare is almost over!



I load the .wsi file as I've been doing and click the Setup Editor on the bottom, click the Features tab, expand application3, click Components and it lists all the components assigned to application3. If I remove all of them except its Web.config component, it still breaks the main Web.config I'm trying to update. If I remove only its Web.config component, everything is peachy. I tried the test, as I say, leaving only that one and deleting only that one and got exact opposite results which is a good thing. So it looks like this file (somehow) is the culprit.



Just to clarify for anyone confused, I'm removing/leaving the application3 Web.config file and getting these mixed results. The results are that the Web.config for application1 (completely separate Web.config file) is either being updated or not updated. This is what I'm trying to achieve.



The only thing this Web.config file is doing is updating its own <appSettings> node with <add key="ConfigFilePath"value'"[App_Data13]"/>. Nothing else is changing. When I choose to edit this in the editor, it gives me the value for key as ConfigFielPath and the value for value as E:\work\VSS\Document Connector Service\ConnectorService\ConnectorService\App_Data. And the dynamic value is [App_Data13]. The weird thing is this file has nothing to do with the Web.config of application1 that's getting messed up in the process.

quote:
Originally posted by: EdT

Perhaps a comparison of the installation logs of the "Two Feature" MSI, compared to that of the "Three Feature MSI" with Feature 3 not selected, might yield something. It certainly appears weird based on what you've told us so far.

Also a good idea. Will try that if I come to another dead end, thanks.

Another quick update. If I modify the application3 Web.config file from:



<appSettings>

<!--WISEMETA: value="[App_Data13]"--><add key="ConfigFilePath" value=""/>

<add key="FilesCleanUpIntervalInSeconds" value="3600"/>

<add key="FileAgeToBeDeletedInHours" value="1"/>

<add key="FileCaching" value="False"/>

</appSettings>



to:



<appSettings>

<!--WISEMETA: value="[App_Data13]"-->

<add key="FilesCleanUpIntervalInSeconds" value="3600"/>

<add key="FileAgeToBeDeletedInHours" value="1"/>

<add key="FileCaching" value="False"/>

</appSettings>



then the install is flawless. Weird.

What happens if you try:



<appSettings>

<!--WISEMETA: value="[App_Data13]"-->

<add key="ConfigFilePath" value=""/>

<add key="FilesCleanUpIntervalInSeconds" value="3600"/>

<add key="FileAgeToBeDeletedInHours" value="1"/>

<add key="FileCaching" value="False"/>

</appSettings>

Still busted the application1 Web.config in the same way. So it didn't work.



Also, to answer your question a few posts higher about comparing the 2 log files, here's what I did and the attached log files.



- Compiled program without modification.

- Ran "msiexec /i exposuite.msi /l logfile.txt" to generate a log file from the baseline install.

- Disabled Dynamic Content from application3's Web.config file

- Recompiled

- Ran "msiexec /i exposuite.msi /l logfileNoDCS.txt" to generate a second log file from the install.

- opened both log files and did find/replace to remove timestamps with following method:

-- 2 -> 0

-- 3 -> 0

-- 4 -> 0

-- 5 -> 0

-- 6 -> 0

-- 7 -> 0

-- 8 -> 0

-- 9 -> 0

This gave me all the time stamps in the form of 0:00:0: and 0:00:00 so I did some more find/replace:

-- 0:00:00: -> 0:0:0:

-- 0:0:00: -> 0:0:0:

-- 0:00:0: -> 0:0:0:

-- and so on until I had all time stamps as 0:0:0: then I did a final find/replace:

-- 0:0:0: -> asdf

Now I have removed all time stamps from the files but I did not convert 1 -> 0 because that's used as a boolean switch operator throughout the files.

- Then I opened both in WinMerge and compared the files, these are the only differences I found and for some reason they're simply flipped top - bottom like mirror versions of each other.



logfile.txt:

AppSearch: Property: REG_DCSPATH

Signature: AppReg11

AppSearch: Property: REG_EXPOGISPATH

Signature: AppReg0

AppSearch: Property: REG_EXPOPATH

Signature: AppReg0

AppSearch: Property: REG_WSE

Signature: AppReg

AppSearch: Property: REG_AJAX

Signature: AppReg0

AppSearch: Property: REG_ADF

Signature: AppReg0

AppSearch: Property: REG_ADFSP

Signature: AppReg0

AppSearch: Property: REG_EXPO

Signature: AppReg0

AppSearch: Property: REG_EXPOGIS

Signature: AppReg0

AppSearch: Property: REG_DCS



logfileNoDCS.txt:

AppSearch: Property: REG_DCS

Signature: AppReg0

AppSearch: Property: REG_EXPOGIS

Signature: AppReg0

AppSearch: Property: REG_EXPO

Signature: AppReg0

AppSearch: Property: REG_ADFSP

Signature: AppReg0

AppSearch: Property: REG_ADF

Signature: AppReg0

AppSearch: Property: REG_AJAX

Signature: AppReg0

AppSearch: Property: REG_WSE

Signature: AppReg

AppSearch: Property: REG_EXPOPATH

Signature: AppReg0

AppSearch: Property: REG_EXPOGISPATH

Signature: AppReg0

AppSearch: Property: REG_DCSPATH

Signature: AppReg11



.......................



logfile.txt:

CreateShortcuts: Shortcut: FDSCIS~1|<company name> Support Forum

CreateShortcuts: Shortcut: FUGROD~1|<company name>

CreateShortcuts: Shortcut: FDSCIS~1|<company name> Support Forum

CreateShortcuts: Shortcut: FUGROD~1|<company name>



logfileNoDCS.txt:

CreateShortcuts: Shortcut: FUGROD~1|<company name>

CreateShortcuts: Shortcut: FDSCIS~1|<company name> Support Forum

CreateShortcuts: Shortcut: FUGROD~1|<company name>

CreateShortcuts: Shortcut: FDSCIS~1|<company name> Support Forum



Then a bunch of RollBackCleanup in the form of RollbackCleanup: File: C:\Config.Msi\0d1fa0d0.rbf



And that's it! I don't get it. I'll see if I can attach the log files.