Where did my custom action permissions go? Terminal Server is special.

The other day a user complained that they were trying to donfigure Active Directory and their queries were intermittently getting access denied.  They had roughly identified the problem as having been related to the Windows 2003 server SP1 however they had not a clue why it worked intermittently.  I pecked at the edges saying it would be better not to reply on script custom actions as script custom actions are notorious for not being able to debugged and introduce an unneeded dependency which has lead some to advise against their use (such as astebner and robmen)

Handyman Heath swung in and noted the log contained the reason for the failure:

Not impersonating action for per-machine TS install.

Carolyn then laid down the law:

This is because you’re performing a per-machine installation on Terminal Server. There’s a section devoted to terminal server behavior in the Windows Installer documentation on MSDN. Of particular interest for you is the topic “Using custom actions from a terminal server”.

Using Custom Actions on a Terminal Server

This section describes the use of DLL, EXE, and Script custom actions only when all of the following conditions are true:

  1. The installer package is being installed on Windows 2000 or later.

  2. The package is installed on a system hosting Terminal Services. In this case, the installer sets the TerminalServer property.

  3. The package is installed as a per-machine installation.
If all of the preceding conditions apply, custom actions run in an environment similar to that which exists when an application is installed with no user logged-in. In this case, the following are true:

  • Deferred custom actions run in the context of the local system unless the action has the msidbCustomActionTypeTSAware attribute. This is true even if the custom action would normally impersonate the user on a system that was not a Terminal Server….

So then the person with the problem asked “so if I set the type of the CA from 9222 to 9222 + 16384 we would be back to the original behavior and impersonating the calling user?”

Which Carolyn of course answered with “Yes, on those platforms where msidbCustomActionTypeTSAware is supported/available.”

… and so we have yet another happy customer

Now if I could only find some documentation or logging magic that would help call these out without the homework.

Content credit also belongs to

  • Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
  • Heaths, Microsoft DevDiv CPX Dev. You can get other Heath insights about developing for Windows Installer from the Heath’s blog.

[Author: Robert Flaming]

This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Comments (2)

  1. One of our installers had begun to fail on some servers whilst succeeding on the rest. The error in the