IIS components features optimisation

[TheRocket]

We are currently working with advanced installer 17.6 and also testing Advanced installer 23.2 and our installation package comprises 2 IIS web applications.

During the installation of our package, the installer will attempt to install the 2 web applications.
Prior to this operation, Advanced installer makes sure he has components on the system to manage the IIS. I believe it runs the "Install-WindowsFeature -Name Web-Scripting-Tools" command or something similar.
On certain systems, this component validation can take several minutes. Behind the scenes, "TiWorker.exe" is eating up 100% cpu for more than 20 minutes. Eventually, the installation will succeed.

On the uninstallation of the package, the IIS operations and web application removal completes quickly.

When installing the same application again, the installation takes a very long time, even if all the required components are in place.
It becomes annoying as :
- we are installing our application package on hundreds of servers.
- we are also relying on CI/CD pipelines for testing our software solution.

We would suggest that Advanced installer would be using the registry to identify if the required iis components are already installed for it's internal use. If so, it could skip the components validations, and proceed quicky with the web applications installation.

Sample log with the delay:

Code: Select all

MSI (s) (F4:E8) [13:24:10:827]: Executing op: ActionStart(Name=AI_IIsConfig,Description=Configuring Internet Information Services,Template=Installing "[1]")
MSI (s) (F4:E8) [13:24:10:827]: Executing op: CustomActionSchedule(Action=AI_IIsConfig,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (F4:40) [13:24:10:840]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIF0F3.tmp, Entrypoint: OnIIsConfig

(The issue is somewhere here)

MSI (s) (F4:E8) [13:48:56:787]: Executing op: End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=0)
MSI (s) (F4:E8) [13:48:56:803]: Note: 1: 2265 2:  3: -2147287035 
MSI (s) (F4:E8) [13:48:56:803]: User policy value 'DisableRollback' is 0
MSI (s) (F4:E8) [13:48:56:803]: Machine policy value 'DisableRollback' is 0
MSI (s) (F4:E8) [13:48:56:818]: Note: 1: 2265 2:  3: -2147287035 
MSI (s) (F4:90) [13:48:56:850]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI9DA4.tmp, Entrypoint: OnAiRemoveFilesCommit

It would be very nice to optimize for a future version.

[Catalin]

Hello,

Apologies for the quite delayed reply here.

Regarding your scenario here, it does not make much sense, at least if I understood it correctly.

Could you please confirm that the issue on your side is during a reinstall (basically a first time install)? If so, this does not make much sense here as this should be the same as for the first time install, which you mentioned is quick (also the uninstall is quick).

Also, do I understand this correctly that the waiting time is the same between version 17.6 and 23.2? I am asking this to confirm that this is not a "problem" that appeared after the upgrade.

Also, is this issue reproducible on all machines, or is it specific to some machine only (because if so, then this might be related to that machine)? For example, if you test this on a clean VM, does the issue still occur?

Best regards,
Catalin

[TheRocket]

Hi Catalin,

The high delay is both on the first time install, and on the second/third/fourth/etc. install.
The "uninstall" is quick (components uninstall during upgrades/removal).

The waiting time is very similar between version 17.6 and 23.2, so the behavior didn't change. It wasn't improved either with the latest AI version.
The long waiting time is before creating new site, creating new applications pools and new "web directories".

The waiting time is variable between different machines.
A freshly installed VM may be quicker than a VM built a few months ago.
A VM may suddenly become very slow after an Windows update.
This occurs on our VM's, and also on some of our customers VM's.

We think that the delay is related to a command used by the AI custom dll, that may hang due to Windows features.

We can confirm that the

Code: Select all

DISM /Online /Cleanup-Image /RestoreHealth

returns success, and we ran it twice.

We can confirm that the following powershell commands are quick:

Code: Select all

Install-WindowsFeature Web-Server -IncludeManagementTools
dism /online /enable-feature /featurename:IIS-ASPNET45 /all
Get-WindowsFeature -Name Web-*

We suspect the following command ran by the custom DLL is causing the performance delays:

Code: Select all

DISM /quiet /norestart /english /online /get-features /format:table

We believe this command is executed on IIS installation preparation, but not executed on uninstallation.

We don't have much control over this command or it's execution time from the AIP project.
We can work on resolving "DISM" issues on our VM's internally and at customers sites.

Thus, we suggest to improve AI by bypassing this command, and use registry keys to validate if features are installed already, so the custom dll can proceed immediately with creating new site, creating new applications pools and new "web directories".
We can understand that on the very first installation, it would need to deploy components for IIS management, but subsequent installations should find the components and complete the installation quickly.

[Catalin]

Hello,

Apologies for the quite delayed reply on this.

Thank you very much for the followup on this and for sharing the details with us.

I have forwarded this improvement to our dev team and we will improve this if we will find a relaible way to check the state of the machine instead of dism.exe.

Best regards,
Catalin