InstallAware

You can also try using regedit /s on a .reg file in, for example, $SUPPORTDIR$, via Run Program (As) on $WINDIR$.

Hi, mohoch!

I would prefer using "reg" command. Try to type "reg /?" inside cmd.exe session for more info.

common usage is: "reg add ...."
or
"reg delete ..."

Hope this helps!

I'd just like to add a quick reply to this post as well. I've been battling this for the last 4 or so months as well. We had tracked it down to the same registry keys listed here but we were thinking that Microsoft had released a patch or something that was auto updated.

I was at a loss as to why, all of the sudden, our client's websites could no longer handle a process longer than 10 seconds.

Our workaround was for the clients to all change their receive timeout settings as mentioned. I have not yet changed this setting on the IIS server to see if it resolves this for all browsers hitting the website. I will try to verify and repost with my results.

tj wrote:I was at a loss as to why, all of the sudden, our client's websites could no longer handle a process longer than 10 seconds.

Yes, this is exactly the issue that is being discussed in this forum. Install programs that utilize IA could (depending on the settings) have this registry set to 10-second timeout by the installer. This will impact ANY web-based application or IE browser on the client. The setting on the IIS server itself will not impact anything. Any client machine that runs a setup program generated by IA must then ensure this registry setting is removed/restored after running the install program.

Interestingly enough, IA only installs our website and supporting services. We definitely see the timeout when running a client on the IIS server itself. However, we still see the timeout on any IE client connecting to the server.

This is why we were thinking it was a Microsoft updates introduced problem.

We've spent a great deal of time trying to identify this. We've gone so far as to watch the traffic between the clients and server.

My gut tells me that something has changed on the server. At one point, I thought that the installation of the AJAX extensions was setting something on the server which caused this behavior. ...that was the last point in my troubleshooting.

I am relieved but concerned that others are seeing something similar.

I think our biggest concern is that something is being set on the SERVER that is affecting all IE clients. The IE clients are reporting some odd errors from DNS error to "Could not display page" and "This page contains both secure and non-secure items..."

All of this started at the same time and seems to be related to some change on the IIS server itself.

IMPORTANT POINT: We MAY have been able to duplicate this behavior outside of InstallAware. I tried to manually replicate everything I do from within IA and check the client response with each step. Again, I think that installation (msi installation) of the AJAX extensions had a similar affect.

I would like to offer any help to IA as I've done a great deal of research on this issue.

tj wrote:Interestingly enough, IA only installs our website and supporting services. We definitely see the timeout when running a client on the IIS server itself. However, we still see the timeout on any IE client connecting to the server.

Hmm. Interesting. The ReceiveTimeOut "Represents the wait time to receive responses from a server." ... I did not think it would affect the server responding to the client (but MS documentation has been known to be wrong). The default is 60 minutes or so depending on the IE client (IA changes this to 10 seconds). A few possibilities ...
1. Do your clients have run any other install program that could have used IA?
2. Could IA be changing other registry settings that we have not identified yet (perhaps ones that might affect servers)?

[email protected] wrote:A few possibilities ...
1. Do your clients have run any other install program that could have used IA?
2. Could IA be changing other registry settings that we have not identified yet (perhaps ones that might affect servers)?

1) Good point, although I haven't run OUR setup on my Dev box, I do have the IA IDE installed. I have run some test apps in debug mode on my box. As for our clients? Not sure. It's certainly possible. One of our clients actually identified the registry setting for us based on a Microsoft tech note.

2) I'd lean towards this or something related to the AJAX extensions.

Is anyone else installing the AJAX msi as part of the installation?

tj wrote:1) Good point, although I haven't run OUR setup on my Dev box, I do have the IA IDE installed. I have run some test apps in debug mode on my box. As for our clients? Not sure. It's certainly possible. One of our clients actually identified the registry setting for us based on a Microsoft tech note.

Aha! The IA IDE WILL change this setting! It schedules a task (actually using the IA engine) that runs (I believe on Sundays) that do some requests to their servers. This does zonk the settings (I have to schedule a registry change every Mon morning to "undo" this change).

[email protected] wrote:Aha! The IA IDE WILL change this setting! It schedules a task (actually using the IA engine) that runs (I believe on Sundays) that do some requests to their servers. This does zonk the settings (I have to schedule a registry change every Mon morning to "undo" this change).

Actually, the task is not scheduled automatically - you do get to pick your own schedule right after your first logon after installing the IDE. What you assume to be the automatically scheduled time is just the default time that is offered during this manual scheduling step.

Also, note that the web update client used by the IDE is the same one that you get to use with your own products, and you get the full source codes for it as MSIcode scripts and editable dialogs (in the very same format consumed by the IDE update utility); you can apply any workaround(s) to these items as well.

I added this at the end of our installers. This appears to have worked well on 32 bit boxes. We are testing this on 64bit boxes today. I'll follow up with a post if there are any problems.

When can we expect a fix for this issue? It is still driving me mad on the ocassions that I have to use IE..

This behavior has been updated in InstallAware 9 R2 as follows: the previous time-out value is automatically restored upon completion or cancellation of a download.

Please help yourself to a release candidate of InstallAware 9 R2 to ensure it works to your satisfaction:
http://www.installaware.com/forum/viewt ... 3&start=30

Hi to all IA community!

As we have a new R2 release with restoring the Receive Timeout value the problem is still persist.
I'll try to explain what i mean.

One of our clients uses a NOD32 antivirus program (in general, i think that it doesn't matter what Antivirus software is installed, they all commonly work in the same manner). When downloading web media block from an update server (where our distribution resides) antivirus start to check the web media archive (which is 7zip as we all know). In our case this web media archive consist of 30-40 .NET assemblies (*.dll files) and some executables (also .NET). Antivirus unpacks every file and then check it. Of course it take some time, which in our case isn't enough to accomplish in 10 seconds! InstallAware shows its default message box about an error during downloading of Media Block. So the problem is still persist! We cannot told our customers to turn of their protection, they wouldn't do that (and we couldn't blame them for that). They cannot afford latest i7 processors with multi-cores on every machine (to do the antivirus check faster), so it's obvious that with our software getting bigger (at least more assemblies, or larger assemblies) the would always have this behavior (event if the CPUs would be upgraded).

So, what is i'm trying to say is that the best, imo, solution for this problem would be to have a predefined or precompile (at least) variable where we could set this timeout value. For our case i guess 30 seconds would be sufficient (to check or web media blocks). Some other IA users (with larger web media blocks) could have 60 seconds to do the job.

Or maybe there's a solution for this?
I hardly imagine that no one else have encountered this with antivirus programs being check all the downloaded files.

Any help would be appreciated,
Thanks!

OK - while that is a good suggestion, and a compiler variable binding for a custom timeout value sounds great (it will be added in a future release I think), this now has nothing to do with InstallAware.

InstallAware uses Microsoft's own APIs for reasons previously discussed. As far as available API documentation indicates, the time-out value refers to the amount of time the remote computer does not respond. It should have nothing to do with the local computer.

If an anti-virus product is actually hooking these APIs and changing their behavior, there is nothing we can do about that at InstallAware. It is simply a bug in the anti-virus hooks and they are the ones who you should be talking to, not us.

I imagine they are scanning files with the 7zip extension before letting the local system "receive" the file, and are doing this with a poor implementation that breaks other software. If anything, you should be glad InstallAware exposed this bug in your AV software, so you are aware of one issue they have going.

I don't know what impact this would have on your system security, this vulnerability sounds like something malware could exploit too.

MichaelNesmith wrote:If anything, you should be glad InstallAware exposed this bug in your AV software, so you are aware of one issue they have going.