Problems with windows server 2008 r2 and terminalserver

[ovebastiansen]

Hi,

I have a problem when trying to use chained installation on a windows server 2008 r2 after adding the terminal server service.

The installation works great before I add the service, but afterwards I am having trouble with a "Windows installer coordinator".
Just when the chained installation is going to start, there comes a third message box with the title "windows installer coordinator" that says its preparing the application for first time use. See attached screenshot.
The preparation takes indefinitely, I have waited for almost an hour, but nothing happens and when I click cancel in the coordinator box it cancels the chained installation.

Have anybody seen this behavior, and have a solution to this problem?

This is part of the log file, where I think it goes wrong.

=== Logging stopped: 23.02.2010 08:54:28 ===
MSI (c) (04:24) [08:54:28:263]: Windows Installer installed the product. Product Name: MARIA 5 Component. Product Version: 5.3.2. Product Language: 1033. Manufacturer: Teleplan Globe AS. Installation success or error status: 1618.

MSI (c) (04:24) [08:54:31:278]: Failed to grab execution mutex. System error 258.
MSI (c) (04:24) [08:54:31:278]: Cleaning up uninstalled install packages, if any exist
MSI (c) (04:24) [08:54:31:278]: MainEngineThread is returning 1618
=== Verbose logging stopped: 23.02.2010 08:54:31 ===

[CGregg]

If anybody has any insight, it would be greatly appreciated as I've just gotten my first report of this same exact issue with a Chained MSI on a 2008R2 Terminal Server.

[jarcinfo]

Hello all,
Sorry not to have yet an answer, but I have encountered the same problem.
I just wanted to inform you that I have submitted an incident to flexera last week.
As soon as I have an answer or a correction I will inform you.

[hyper255]

Anything new regarding this problem?

[jarcinfo]

(At the end of this post, I have copied the the Flexera response.)
I tested it.
Effectively the proposed solution allows the chained MSI install to run successfully, and so to install and to test our software in 2008 Server R2 environment with TS.
But, according to me, we can not ask our customers to do such a modification in their local group policy. Especially as most of the time they work with domains and I think that the group policy of a domain overrides local policy.

So I think that another solution (correction) is required.
Do you have an opinion ?

Here is the Flexera response:
The situation is arising from the new Remote Desktop Session Host introduced with Windows Server 2008 R2. Apparently, the Remote Desktop Session Host allows multiple installs to be in process at the same time by queuing the installs. It is my guess the process that queues the installs is the "Windows Installer Coordinator".

I discovered this Windows Installer queuing behavior is controlled by a System Group Policy called "Windows Installer RDS Compatibility".

When the Remote Desktop Session Host is enabled, by default, the Group Policy for the "Windows Installer RDS Compatibility" is enabled. When I disabled "Windows Installer RDS Compatibility", the chained MSI was able to run.

To disable this group policy:
1) Log on to the system with a User that has Adminstrative Privileges
2) Open the Windows Control Panel
3) Perform a search for Group Policy
4) The search results should display a link to the "Local Group Policy Editor"
5) Once inside the editor, go to:
Computer Configuration->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Application Compatibility
6) In the right pane, right click on 'Turn off Windows Installer RDS Compatibility" and select Edit from the drop down menu
7) Select the Radio Button labeled 'Enable'
😎 Click OK

[hyper255]

Thanks for posting the response.

Microsoft has a lot of installation programs with (from what I can tell) chained msis. I installed the SQL Server Express 2008 R2 on the same terminal server that I did the previous test on, and that worked without any problems.

By just watching the activity in Process Explorer, it seems like Installshield launches its own ISChainer process as a sub process of one of the server-side msiexec.exe processes and I couldn't see anything similar during the MS Express install. It would be interesting to hear from Installshield why their chainer get into problems since Microsofts doesn't (if they do the same).

I appreciate the workaround, but we are still a few months away from releasing the installation program I'm working now and aren't very interested in doing so as long as this bug is there.

Might be that Burn works better (planned released this summer AFAIK):
http://en.wikipedia.org/wiki/WiX#Burn

[jarcinfo]

Hello,

Concerning the initial problem, an issue (IOA-000055518) has been opened by Flexera to track it internally.
Unfortunately this problem is not yet actually resolved.

Did somebody found another way to allow such an installation without modifying the Group Policy ?
This issue is becoming critical for one of my customer who can not do such modification in his Group Policy.

Thank you.

[jarcinfo]

Unfortunately, no real news about this problem.
But there is a new workaround, usable via Custom Action.

Here is:
An IBM blog has posted a different approach to work around, where they turn the policy off by making a registry change rather than editing the policy through the Windows UI Control Panels.
To successfully install [...] set the following DWORD registry key to 0:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\TSAppSrv\TSMSI\Enable
It’s possible that not all keys exist [...] you have to create them manually.
Here is the link to the blog:
http://projectdream.org/wordpress/2010/05/07/ibm-i-access-7-1-installation-hangs-indefinitively-with-a-windows-installer-coordinator-window/

My installation package edits the registry, runs the chained MSI and then restores the registry, all this using Custom actions and ... it works !

I recently received InstallShield 2011 and the issue remains.
The issue IOA-000055518 is still in open status ...

[Ih8stupidrules]

/bump

Other than the current workaround, has a real fix to the issue been found?

Shouldn't Microsoft be the one who should fix the "Windows Installer Coordinator" to not deadlock installations when they are launched from the same root process?

[spinecrawler]

In case anyone else see checks this. I had a similar issue with other software. My solution was to remote in through console rather than rds. Not sure if this is viable for you folks, but in case someone else happens across this they might find it helpful

remote in through Remote desktop using:

servername /admin

Jeremy

[jarcinfo]

Hello all,

Please find below the last response of Installshield support:

...
We still believe that the problem where Chained .msi installers fail to execute on Windows Server 2008 R2 system targets when Remote Desktop Session Host feature is enabled with the Windows Installer Compatibility sub feature enabled is a Microsoft issue.

However, I am pleased to inform you that we have implemented an offering in our InstallShield product that is an alternative method for performing multiple installs from one setup launcher. This is our solution to the problem reported in this incident. The offering is in the form of a new project type called "Suite project".

The new feature is available in InstallShield 2012. For more information about InstallShield 2012, please to the Release Notes in the InstallShield Knowledge Base article, Q211161, at:
http://support.installshield.com/kb/view.asp?articleid=Q211161
...

It did not use yet.
jacqueline