recent problem under Win2008 R2 TS

[kenknight]

Ok, I think I'm losing it. I thought I typed in a message an posted it to the forum, but it doesn't look like it went through.

About two weeks ago we started getting calls from people who installed updates of our software on Windows 2008 R2 Terminal servers. It appears to be resetting the permissions on the directories involved.

We have made zero changes to our installer, so I'm curious if it is something that microsoft has pushed out that is causing the problem.

Any ideas or suggestions? Again, this is just Server2008 R2 TS.

Thanks,
Ken

[linder]

Ken,

The only thing I can say is that nothing has changed in the SetupBuilder updates. The file install function in SetupBuilder did not change for years.

Friedrich

[kenknight]

Hi Friedrich,

I definitely don't think it was/is something in setupbuilder, but I do think that MS has changed something that is causing the effect. I'm really hoping some others are starting to see this also.

thanks,
ken

[linder]

Hi Ken,

Up to now, we have not received a similar report. I'll post here in case our Support received such a message.

Friedrich

[tonisa]

Hi,
I've a similar problem I'll try to describe:

- I put the terminal server in install-mode (change user /install)
- I install the upgrade, this copies my application to the "program files (x86)"\MyApp-folder
- the terminal server is changed to executemode (change user /execute)

The installing user is a member of the local-Administrator-group. The TS makes part of a Windows-Domain (server 2008 R2 SBS). The TS is 2008 R2 Enterprise.
All this works fine if the application is not in use by someone during installation (update) process. If some user has the application open so after he/she closes and tries to restart the session, he/she has no rights to execute the application. After reassigning the rights the problem disappears.
Could be you are able to reproduce the problem with above steps.
best regards
Toni Santa

[linder]

Unfortunately, this is completely out of the control of SetupBuilder. Nothing changed in this SetupBuilder area and the installer itself does not (and cannot) reset rights / permissions.

Friedrich

[linder]

Quick thought: you said "application open". Perhaps you are not checking if all files can be written (not in-use file check). If the installer can't replace a file, it has to write it to a temporary location and then Windows replaces it at the next reboot. In other words, the install continues and some time later, the reboot process replaces the previously locked "old" file with the "new" one. This process seems to change the "rights" in your case.

Friedrich

[tonisa]

And probably it has to do with some shadowing the server is doing, because on the installing session I see just the newly installed .exe and the installing user has all rights on it and can run it without problems. Seems MS has some problem in updating the permissions when the file is locked during the installation/update process.
And just in regard: How acts the "Detect Active Application" on a Terminal Server? Does it check on all active sessions or only the session of the installing user?
best regards
Toni

[linder]

Hi Toni,

The "Detect Active Application..." function can't help in a TS environment. I would suggest to use the "Check In-use File..." and/or "Check In-use Folder Tree..." script function. This can help to check if files are in-use (locked).

I am really interested in a solution to the locked file / updating TS scenario. But I don't have enough background information to understand what is going on behind the scenes in this case :( When a file is locked, then Windows replaces it at a later time. So the one million dollar question is, what can be done here to make sure that Windows carries over the correct permissions.

Friedrich