Hello everyone,

We used to have Windows 2003 R2 terminal servers and several days ago we decided to upgrade to 2008 SP2 with clean install. But we encountered a problem that is not happened before.

Our software development team is developing applications and these applications run on Terminal servers. These exe files are in a shared folder in Application Server. Like \\ApServer\Application1\test.exe. All users have a shortcut of these exe files on TS.

These exe files are updated time to time with exact same name. And if a user wants to run app,old one runs even if the exe is updated. Now We have to make sure all users close the old application before using new one. This was not a problem for us with  Windows 2003 R2 terminal servers.

- Our applications doesn't make service calls.
- OS version Microsoft Windows Server 6.0 Build 6002 SP2 ( Windows Server 2008 Ent Sp2)
- Apllications are developed in Visual Studio 2008 / C# and VB 6.0

I have read something about Windows Terminal Server 2008 Resource Kit that, Windows Server 2003 TS shares DLL with users who use application. But in 2008 only TS have the DLL file and doesn't distribute it. Is it the reason?

What is the reason of this behaviour?

Any help will be much appreciated.

Thank you all!

• Moved by Brent HuModerator Tuesday, November 09, 2010 1:23 AM (From:General)

Hi Baran,

 

According to your post, my understanding is: you want to make the older application be killed before running the new one on the Terminal server. If I misunderstand, please let me know.

 

In this case, I’d like to configure the Application Control Policies to restrict to access older application. You can specify the product name, file name, or file version, etc to match the parameters which are involved in your application.

 

For more information:

 

Understanding AppLocker Rules and Enforcement Setting Inheritance in Group Policy

http://technet.microsoft.com/en-us/library/ee449492(WS.10).aspx

 

 

Meanwhile, there is an option to use the Tskill.exe to kill one specific process, and also this is a built-in command.

 

Tskill.exe ends an active process and/or processes on a selected server.
http://support.microsoft.com/kb/243202

 

Hope this helps.

Alan Zhu Hi!

Thank you for reply.
It seems I couldn't describe the issue clearly. When our developers update the exe file(overwrite the old one-while users continue to use it),users who are already using old exe continue using it. But if a new user run the exact same named-updated exe file this user can use new version with Windows 2003 R2 terminal servers.

But now we upgraded Windows Server 2008 Ent Sp2 all users have to close the application before someone could use the updated version of it. If every body close the application and then run the exe its ok.

I hope this will clarify the issue.

Hi Baran,

 

As the architecture of windows server 2008 has been changed, and this application may be not suitable in server 2008. In this case, I’d like to find a measure to block the old application and let users run the new one. Does it make sense?

 

Hi, Baran,

Copy-on-write was not introduced in WS08; that technology has been around for some time.  You may want to use the app compat toolkit with your application to see if you can pinpoint the issue.

See this blog entry for more details.

http://blogs.msdn.com/b/rds/archive/2010/01/19/how-to-detect-rds-specific-application-compatibility-issues-by-using-the-rds-application-compatibility-analyzer.aspx

Hope this helps,

Christa

Merhaba Baran Bey,

Bu problemin aynsn biz de yayoruz. Herhangi bir çözüme ulaabildiniz mi?

hi Baran,

We have here the same problem.

Did you solve this problem now?

If yes how did you do this?

regards,

William

 

 

 

 

I'd suggest that what you have done in the past is not a good idea.

Consider if the previous version of the application has a DLL and this DLL is modifed in the new version and is using the same filename.  You copy/install the new version of the application to the server while users are still connected and running the application.

Your NEW DLL is loaded on demand by a user who had already launched the previous version of the application.  Is your new DLL 100% compatible or could it potentially cause data corruption or other faults?  Could you even cause a server to hang/crash and therefore cause all users on the server to lose their work?

A better practice would be a rolling update across the servers, Take a server out of the pool of servers hosting the application and force all the users to logoff (after business hours?).  Install your new application, and put the server back into the pool.  Take the next server out and do the same, cycling thru all the servers.  Assuming you have the application published on multiple servers, this method prevents a situation where the application is not available to users at all.  A better practice would be to perform the application update at a time that no one is using the application, just as you might do when you're patching the OS.

Hi, I know this is an old post but I have found the simple answer / solution.

Situation: Windows Server 2008 R2 in Terminal Server mode.

The Users copy of application does not update when a new version is placed in the primary directory ie c:\program files\app

When an applications directory and contained files do not have Modify permissions for the logged in user, a cached copy of the application is placed in C:\Users\username\AppData\Local\VirtualStore\Program Files\app

In my case the Access mdb application could not create a *.ldb file and so cached a copy in order to do so. Since adding the specific OU users to the directory permissions and allowing Modify, the issue has never re-occured.

I trust this helps solve your issue.

Clyde Wynter

Durban

Baran Bey merhaba,

Sorunla ilgili bir zm bulabildiniz mi acaba?Ayn problemi bizlerde yayoruz.

I experienced similar issue on 2008 R2. In my case EXE is not a problem, but if i replace a DLL on app-server (rename & upload a new one), seems that one is cached on all the terminal servers somehow.

It is not a SMB issue because when i 'dir' the remote folder it shows the proper timestamp of the updated DLL.

Hopefully a Solution:

Fool the terminal server by renaming the (remote) DLL directly from the terminal server itself, so it thinks the cached DLL has now a different name:

ren  \\appserver\dir\new.dll  new.tmp
copy  \\appserver\dir\new.tmp  \\appserver\dir\new.dll
del  \\appserver\dir\new.tmp

i need more cases to test, but seems i fooled the cache in one case now successfully (while the last user is still running the app with the old DLL, and i start the app with the updated DLL already)

maybe post your results, too

• Edited by chura.sk 4 hours 56 minutes ago